Hi All,

I have some quries regarding MULTICASTING. As recently I was looking
out net for building a simple multicast application, using
setsockopt(IP_ADD_MEMBERSHIP). By using that application I thought
there will be some multicast routers, and we will be subscribing to
them using their IP addresses. But while using sniffer I was surprised
to see the results.


However I was sending multicast join report through
setsockopt(IP_ADD_MEMBERSHIP) to a IP address 234.5.6.7 (assuming the
IP address of Multicast router), but actually outgoing IP datagram had
224.0.0.2 as its destination IP address........Seeing this I could make

out that the actual ip address of multi-router would be 224.0.0.22
only, whereas it will be holding some groups like 234.5.6.7 etc. But
later I found this 224.0.0.2 is a special class D address, which is to
make sure delivery of this mutlicast join request to each router, with
TTL of 1. But still I am not clear with the whole process, like what
are the things each router will do one receipt of this join request, as

well as until when this packet will be circulated in the net, to make
sure its delivery for each router??


Next how we could make sure of a exclusive group, say A and B wanted to

use a special multicast address 234.5.6.7 exclusively for their use
only, how would they make sure that this multicast wont be in use by
others??


And how the routing will take place for IP 234.5.6.7, from multicast
router to subscribed clients. Like way so many question are going
around in my mind, could any body put some light over basics.

Thanks,
Rajat.

<myself_rajat@yahoo.com> wrote:

> I have some quries regarding MULTICASTING. As recently I was looking
> out net for building a simple multicast application, using
> setsockopt(IP_ADD_MEMBERSHIP). By using that application I thought
> there will be some multicast routers, and we will be subscribing to
> them using their IP addresses. But while using sniffer I was surprised
> to see the results.
>
> However I was sending multicast join report through
> setsockopt(IP_ADD_MEMBERSHIP) to a IP address 234.5.6.7 (assuming the
> IP address of Multicast router), but actually outgoing IP datagram had
> 224.0.0.2 as its destination IP address........Seeing this I could
> make
>
> out that the actual ip address of multi-router would be 224.0.0.22
> only, whereas it will be holding some groups like 234.5.6.7 etc. But
> later I found this 224.0.0.2 is a special class D address, which is to
> make sure delivery of this mutlicast join request to each router, with
> TTL of 1. But still I am not clear with the whole process, like what
> are the things each router will do one receipt of this join request,
> as
>
> well as until when this packet will be circulated in the net, to make
> sure its delivery for each router??

First of all, you need to determine which version of IGMP the host is
using.

If it's IGMP versions 1 or 2, the reports a host sends to its
multicast-enabled router, to join a multicast group, are addressed to
the multicast address (Class D address) of the multicast group. That
way, the router knows that someone has requested membership to that
particular multicast group. (See RFCs 1112 and 2236). And when one host
of a given multicast group renews its membership, in response to a query
from the router, all local members of the multicast group receive that
host's report, so they don't need to send one of their own.

If it's IGMPv3, then the host wanting to join a multicast group sends
reports to IP Class D address 224.0.0.22, as stipulated in RFC 3376
section 4.2.14.

Multicast address 224.0.0.2 is the "all routers" multicast address. It
is used by hosts to send "leave group" reports in IGMPv2 only.

> Next how we could make sure of a exclusive group, say A and B wanted
> to
> use a special multicast address 234.5.6.7 exclusively for their use
> only, how would they make sure that this multicast wont be in use by
> others??

That particular address you mentioned is in a "reserved" range. So it
shouldn't be used.

In general, IP multicast addresses have to be managed. The network
admninistrator and the IANA keep track of these, to make sure there are
no conflicts. You can't just randomly pick an address and use it.
(Although if people do this, ususally no harm is done. That's because
ISPs typically block any multicast they aren't controlling themselves.)

Some IP multicast address ranges are registered with the IANA and are of
global scope, some are dedicated to specific purposes, and some are
meant to remain within the boundaries of individual networks only, so
they don't need to be registered with the IANA. You need to read RFC
2365 and 3171 to see how the IP Class D address range is allocated.

To get the address group information out to hosts of a network, there
are various ways of doing this. And this keeps changing still. Some
possible schemes are Multicast Source Discovery Protocol (RFC 3618),
Session Announcement Protocol (RFC 2974), use of a local web server, or
static configuration. And other schemes that have been proposed at one
time or other, but not survived the test of time.

> And how the routing will take place for IP 234.5.6.7, from multicast
> router to subscribed clients. Like way so many question are going
> around in my mind, could any body put some light over basics.

From the last router to the subscribed clients, the router simply sends
the multicast frames using the MAC multicast address derived from the IP
multicast address. When a host "joins" a multicast group, it must also
set its MAC layer to accept frames from a MAC multicast address that is
algorithmically derived from the IP Class D address. This is explained
in RFC 1112.

In the local Ethernet, the layer 2 switches can do either of two things.
They can flood all ports in the spanning tree with multicast frames
(default), or they can route the MAC frames only to ports that have
membership in the multicast group of the frame. Layer 2 switches can
figure out where the members are either with IGMP "snooping" or with a
layer 2 protocol called GMRP (Clause 10 of IEEE 802.1D).

To download the RFCs, just go to http://www.ietf.org/rfc.html

To download IEEE 802 standards, go to
http://standards.ieee.org/getieee802/802.1.html

Bert

Albert Manfredi wrote:
> <myself_rajat@yahoo.com> wrote:
>
> > I have some quries regarding MULTICASTING. As recently I was looking
> > out net for building a simple multicast application, using
> > setsockopt(IP_ADD_MEMBERSHIP). By using that application I thought
> > there will be some multicast routers, and we will be subscribing to
> > them using their IP addresses. But while using sniffer I was surprised
> > to see the results.
> >
> > However I was sending multicast join report through
> > setsockopt(IP_ADD_MEMBERSHIP) to a IP address 234.5.6.7 (assuming the
> > IP address of Multicast router), but actually outgoing IP datagram had
> > 224.0.0.2 as its destination IP address........Seeing this I could
> > make
> >
> > out that the actual ip address of multi-router would be 224.0.0.22
> > only, whereas it will be holding some groups like 234.5.6.7 etc. But
> > later I found this 224.0.0.2 is a special class D address, which is to
> > make sure delivery of this mutlicast join request to each router, with
> > TTL of 1. But still I am not clear with the whole process, like what
> > are the things each router will do one receipt of this join request,
> > as
> >
> > well as until when this packet will be circulated in the net, to make
> > sure its delivery for each router??
>
> First of all, you need to determine which version of IGMP the host is
> using.
>
> If it's IGMP versions 1 or 2, the reports a host sends to its
> multicast-enabled router, to join a multicast group, are addressed to
> the multicast address (Class D address) of the multicast group. That
> way, the router knows that someone has requested membership to that
> particular multicast group. (See RFCs 1112 and 2236). And when one host
> of a given multicast group renews its membership, in response to a query
> from the router, all local members of the multicast group receive that
> host's report, so they don't need to send one of their own.
>
> If it's IGMPv3, then the host wanting to join a multicast group sends
> reports to IP Class D address 224.0.0.22, as stipulated in RFC 3376
> section 4.2.14.
>
> Multicast address 224.0.0.2 is the "all routers" multicast address. It
> is used by hosts to send "leave group" reports in IGMPv2 only.
>
> > Next how we could make sure of a exclusive group, say A and B wanted
> > to
> > use a special multicast address 234.5.6.7 exclusively for their use
> > only, how would they make sure that this multicast wont be in use by
> > others??
>
> That particular address you mentioned is in a "reserved" range. So it
> shouldn't be used.
>
> In general, IP multicast addresses have to be managed. The network
> admninistrator and the IANA keep track of these, to make sure there are
> no conflicts. You can't just randomly pick an address and use it.
> (Although if people do this, ususally no harm is done. That's because
> ISPs typically block any multicast they aren't controlling themselves.)
>
> Some IP multicast address ranges are registered with the IANA and are of
> global scope, some are dedicated to specific purposes, and some are
> meant to remain within the boundaries of individual networks only, so
> they don't need to be registered with the IANA. You need to read RFC
> 2365 and 3171 to see how the IP Class D address range is allocated.
>
> To get the address group information out to hosts of a network, there
> are various ways of doing this. And this keeps changing still. Some
> possible schemes are Multicast Source Discovery Protocol (RFC 3618),
> Session Announcement Protocol (RFC 2974), use of a local web server, or
> static configuration. And other schemes that have been proposed at one
> time or other, but not survived the test of time.
>
> > And how the routing will take place for IP 234.5.6.7, from multicast
> > router to subscribed clients. Like way so many question are going
> > around in my mind, could any body put some light over basics.
>
> From the last router to the subscribed clients, the router simply sends
> the multicast frames using the MAC multicast address derived from the IP
> multicast address. When a host "joins" a multicast group, it must also
> set its MAC layer to accept frames from a MAC multicast address that is
> algorithmically derived from the IP Class D address. This is explained
> in RFC 1112.
>
> In the local Ethernet, the layer 2 switches can do either of two things.
> They can flood all ports in the spanning tree with multicast frames
> (default), or they can route the MAC frames only to ports that have
> membership in the multicast group of the frame. Layer 2 switches can
> figure out where the members are either with IGMP "snooping" or with a
> layer 2 protocol called GMRP (Clause 10 of IEEE 802.1D).
>
> To download the RFCs, just go to http://www.ietf.org/rfc.html
>
> To download IEEE 802 standards, go to
> http://standards.ieee.org/getieee802/802.1.html
>
> Bert

Thanks a lot Albert, for your response.

ya I did check with IGMP version(using sniffer), its V3. So host is
sending multicast reports at 224.0.0.22. As I found this special class
D address is ment for IGMP, does this mean that its specifying the
address of local IGMP enabled router.

And what will happen if the local subnet it having no multicast enabled
router but simple unicast-router, then how that router will behave
after getting multicast report destined to 224.0.0.22??

Again thanks a lot for your response.

<myself_rajat@yahoo.com> wrote:

> ya I did check with IGMP version(using sniffer), its V3. So host is
> sending multicast reports at 224.0.0.22. As I found this special class
> D address is ment for IGMP, does this mean that its specifying the
> address of local IGMP enabled router.

The address 224.0.0.22 goes to all multicast-enabled (IGMPv3) routers
within one hop, meaning in the same IP subnet of the host. But only one
of these routers becomes the "querier," as the RFCs explain. So IGMP
never worries about the specific address of any one router. The routers,
if multiple exist in the subnet, negotiate among themselves who gets to
be in control, and the hosts can remain as dumb as possible. Always do
the same thing, no matter what the router situation is.

> And what will happen if the local subnet it having no multicast
> enabled
> router but simple unicast-router, then how that router will behave
> after getting multicast report destined to 224.0.0.22??

You would get no IGMP queries from any router, and IGMP reports would be
dropped. You will note, for example, that Windows Media Player does not
depend on IP Multicast. It can also use unicast, TCP, HTTP, etc.

Buy the way, all of this discussion has been about edge multicast router
to multicast hosts. There is a whole other discussion about building
multicast trees between routers. There have been many schemes developed
to achieve that, but it looks like the ones in favor now are under the
Protocol Independent Multicast (PIM) banner.

Bert

Thanks bert, now the picture is clear in my mind.

Hi,

Here I have one question, As I read that for multicast packet
forwarding, router uses its unicast spanning tree of router by looking
into its routing table. So while maintaining info about multicast
groups, does router send query to neighbour routers also??

Like as we know, for querying about multicast group subscription,
router will send packet to 224.0.0.1(means to all host in the subnet).
Dose this "all host" includes its adjacent or neighbour routers(which
are directly connected with it) also. So that based on their response
it could maintain routing table.

So if each router(say A) could receive the neighbour router's(say B)
multicast group query, then it could inform that router about its
multicast group subscriptions. So that later, whenever B gets any
packet to forward, it will fwded to A, only if A has
any subscription for that group, otherwise not. This will avoid
unnecessary flooding of multicast packets. Thats why I wondered, if B
sends a multicast query packet at 224.0.0.1, then will it be received
and processed by its neighbour router A also??

As well as I am not clear with TTL significance in multicast routing.
Somewhere I read, "For multicast messages(i.e. expect query/report) the
value of TTL should be greater than one". Dose it mean, by putting any
TTL value greater than one(say 2) will assure the delivery of this
packet to all of its group subscribers?? However I don't think so, in
that case how we decide about TTL value for a muticast packet on a
originating source.

Thanks in advance.


Albert Manfredi wrote:
> <myself_rajat@yahoo.com> wrote:
>
> > ya I did check with IGMP version(using sniffer), its V3. So host is
> > sending multicast reports at 224.0.0.22. As I found this special class
> > D address is ment for IGMP, does this mean that its specifying the
> > address of local IGMP enabled router.
>
> The address 224.0.0.22 goes to all multicast-enabled (IGMPv3) routers
> within one hop, meaning in the same IP subnet of the host. But only one
> of these routers becomes the "querier," as the RFCs explain. So IGMP
> never worries about the specific address of any one router. The routers,
> if multiple exist in the subnet, negotiate among themselves who gets to
> be in control, and the hosts can remain as dumb as possible. Always do
> the same thing, no matter what the router situation is.
>
> > And what will happen if the local subnet it having no multicast
> > enabled
> > router but simple unicast-router, then how that router will behave
> > after getting multicast report destined to 224.0.0.22??
>
> You would get no IGMP queries from any router, and IGMP reports would be
> dropped. You will note, for example, that Windows Media Player does not
> depend on IP Multicast. It can also use unicast, TCP, HTTP, etc.
>
> Buy the way, all of this discussion has been about edge multicast router
> to multicast hosts. There is a whole other discussion about building
> multicast trees between routers. There have been many schemes developed
> to achieve that, but it looks like the ones in favor now are under the
> Protocol Independent Multicast (PIM) banner.
>
> Bert

"newbie" <huntedsole@yahoo.com> wrote in message
news:1145121133.688245.145890@v46g2000cwv.googlegr oups.com...
> Hi,
>
> Here I have one question, As I read that for multicast packet
> forwarding, router uses its unicast spanning tree of router by looking
> into its routing table. So while maintaining info about multicast
> groups, does router send query to neighbour routers also??

This depends on the multicast router - router protocol used. Most common
deployed seems to be PIM sparse mode....

this builds trees on actual traffic when destinations ask to be added to the
multicast address group.
>
> Like as we know, for querying about multicast group subscription,
> router will send packet to 224.0.0.1(means to all host in the subnet).
> Dose this "all host" includes its adjacent or neighbour routers(which
> are directly connected with it) also. So that based on their response
> it could maintain routing table.

The subscriptions happen on a per subnet basis - this is really what hosts
do to tell the routers which groups they want to listen to.
Separate protocols handle router to router comms.
>
> So if each router(say A) could receive the neighbour router's(say B)
> multicast group query, then it could inform that router about its
> multicast group subscriptions. So that later, whenever B gets any
> packet to forward, it will fwded to A, only if A has
> any subscription for that group, otherwise not. This will avoid
> unnecessary flooding of multicast packets. Thats why I wondered, if B
> sends a multicast query packet at 224.0.0.1, then will it be received
> and processed by its neighbour router A also??

the local routers elect an IGMP gateway so that only 1 is working at a time
for host queries.
>
> As well as I am not clear with TTL significance in multicast routing.
> Somewhere I read, "For multicast messages(i.e. expect query/report) the
> value of TTL should be greater than one". Dose it mean, by putting any
> TTL value greater than one(say 2) will assure the delivery of this
> packet to all of its group subscribers?? However I don't think so, in
> that case how we decide about TTL value for a muticast packet on a
> originating source.

TTL can be used to limit how far a multicast goes across a network - but
actually using this mechanism is difficult as soon as you have a significant
number of routers and / or a complicated topology.

There are some additional protocols like MSDP that handle joining multicast
domains together - these allow you to limit the scope of a specific set of
multicast addresses.

> Thanks in advance.
>
>
> Albert Manfredi wrote:
> > <myself_rajat@yahoo.com> wrote:
> >
> > > ya I did check with IGMP version(using sniffer), its V3. So host is
> > > sending multicast reports at 224.0.0.22. As I found this special class
> > > D address is ment for IGMP, does this mean that its specifying the
> > > address of local IGMP enabled router.
> >
> > The address 224.0.0.22 goes to all multicast-enabled (IGMPv3) routers
> > within one hop, meaning in the same IP subnet of the host. But only one
> > of these routers becomes the "querier," as the RFCs explain. So IGMP
> > never worries about the specific address of any one router. The routers,
> > if multiple exist in the subnet, negotiate among themselves who gets to
> > be in control, and the hosts can remain as dumb as possible. Always do
> > the same thing, no matter what the router situation is.
> >
> > > And what will happen if the local subnet it having no multicast
> > > enabled
> > > router but simple unicast-router, then how that router will behave
> > > after getting multicast report destined to 224.0.0.22??
> >
> > You would get no IGMP queries from any router, and IGMP reports would be
> > dropped. You will note, for example, that Windows Media Player does not
> > depend on IP Multicast. It can also use unicast, TCP, HTTP, etc.
> >
> > Buy the way, all of this discussion has been about edge multicast router
> > to multicast hosts. There is a whole other discussion about building
> > multicast trees between routers. There have been many schemes developed
> > to achieve that, but it looks like the ones in favor now are under the
> > Protocol Independent Multicast (PIM) banner.
> >
> > Bert
--
Regards

stephen_hope@xyzworld.com - replace xyz with ntl

stephen wrote:
> "newbie" <huntedsole@yahoo.com> wrote in message
> news:1145121133.688245.145890@v46g2000cwv.googlegr oups.com...
> > Hi,
> >
> > Here I have one question, As I read that for multicast packet
> > forwarding, router uses its unicast spanning tree of router by looking
> > into its routing table. So while maintaining info about multicast
> > groups, does router send query to neighbour routers also??
>
> This depends on the multicast router - router protocol used. Most common
> deployed seems to be PIM sparse mode....
>
> this builds trees on actual traffic when destinations ask to be added to the
> multicast address group.
> >
> > Like as we know, for querying about multicast group subscription,
> > router will send packet to 224.0.0.1(means to all host in the subnet).
> > Dose this "all host" includes its adjacent or neighbour routers(which
> > are directly connected with it) also. So that based on their response
> > it could maintain routing table.
>
> The subscriptions happen on a per subnet basis - this is really what hosts
> do to tell the routers which groups they want to listen to.
> Separate protocols handle router to router comms.
> >
> > So if each router(say A) could receive the neighbour router's(say B)
> > multicast group query, then it could inform that router about its
> > multicast group subscriptions. So that later, whenever B gets any
> > packet to forward, it will fwded to A, only if A has
> > any subscription for that group, otherwise not. This will avoid
> > unnecessary flooding of multicast packets. Thats why I wondered, if B
> > sends a multicast query packet at 224.0.0.1, then will it be received
> > and processed by its neighbour router A also??
>
> the local routers elect an IGMP gateway so that only 1 is working at a time
> for host queries.
> >
> > As well as I am not clear with TTL significance in multicast routing.
> > Somewhere I read, "For multicast messages(i.e. expect query/report) the
> > value of TTL should be greater than one". Dose it mean, by putting any
> > TTL value greater than one(say 2) will assure the delivery of this
> > packet to all of its group subscribers?? However I don't think so, in
> > that case how we decide about TTL value for a muticast packet on a
> > originating source.
>
> TTL can be used to limit how far a multicast goes across a network - but
> actually using this mechanism is difficult as soon as you have a significant
> number of routers and / or a complicated topology.

Still I am not clear about the fact, "putting any TTL value greater
than one(say 2) will assure the delivery of this packet to all of its
group subscribers, across the networks". Is it true??

>
> There are some additional protocols like MSDP that handle joining multicast
> domains together - these allow you to limit the scope of a specific set of
> multicast addresses.
>
> > Thanks in advance.
> >
> >
> > Albert Manfredi wrote:
> > > <myself_rajat@yahoo.com> wrote:
> > >
> > > > ya I did check with IGMP version(using sniffer), its V3. So host is
> > > > sending multicast reports at 224.0.0.22. As I found this special class
> > > > D address is ment for IGMP, does this mean that its specifying the
> > > > address of local IGMP enabled router.
> > >
> > > The address 224.0.0.22 goes to all multicast-enabled (IGMPv3) routers
> > > within one hop, meaning in the same IP subnet of the host. But only one
> > > of these routers becomes the "querier," as the RFCs explain. So IGMP
> > > never worries about the specific address of any one router. The routers,
> > > if multiple exist in the subnet, negotiate among themselves who gets to
> > > be in control, and the hosts can remain as dumb as possible. Always do
> > > the same thing, no matter what the router situation is.
> > >
> > > > And what will happen if the local subnet it having no multicast
> > > > enabled
> > > > router but simple unicast-router, then how that router will behave
> > > > after getting multicast report destined to 224.0.0.22??
> > >
> > > You would get no IGMP queries from any router, and IGMP reports would be
> > > dropped. You will note, for example, that Windows Media Player does not
> > > depend on IP Multicast. It can also use unicast, TCP, HTTP, etc.
> > >
> > > Buy the way, all of this discussion has been about edge multicast router
> > > to multicast hosts. There is a whole other discussion about building
> > > multicast trees between routers. There have been many schemes developed
> > > to achieve that, but it looks like the ones in favor now are under the
> > > Protocol Independent Multicast (PIM) banner.
> > >
> > > Bert
> --
> Regards
>
> stephen_hope@xyzworld.com - replace xyz with ntl