headers
La Monte Yarroll | 19 May 2009 20:50

Seeking clarification of "unregistered packet"

I have a couple questions about the following material from RFC 4541,
2.1.2:

> 3) An unregistered packet is defined as an IPv4 multicast packet with
>    a destination address which does not match any of the groups
>    announced in earlier IGMP Membership Reports.
> 
>    If a switch receives an unregistered packet, it must forward that
>    packet on all ports to which an IGMP router is attached.  A switch
>    may default to forwarding unregistered packets on all ports.
>    Switches that do not forward unregistered packets to all ports
>    must include a configuration option to force the flooding of
>    unregistered packets on specified ports.

Is the ability to "force the flooding of unregistered packets on
specified ports" only important on switches which are only processing
v1 and v2 packets (or v3 packets ignoring "include source" and "exclude
source")?

If it is relevant for a switch which processes fully general v3 Joins,
the definition of "unregistered packet" seems a little ambiguous.

Consider traffic from source S1 to group G which no Joins seen. This
traffic (S1,G) is unregistered packets. If we then see a Join for
(S2,G), we have now seen the group G mentioned in a Join. How am I
supposed to treat the (S1,G) traffic? Is it still unregistered packets?
Or am I supposed to stop forwarding that traffic to "specified ports"?

My problem may be that I simply do not understand what kinds of devices
I might have on "specified ports" that I may need to flood unregistered
(Continue reading)

Permalink | Reply | 4 comments |
headers
V, Magesh (Magesh | 20 May 2009 05:10
Favicon

Re: Seeking clarification of "unregistered packet"

I think the recommendation holds good for even V3 switches. That is, if its a fully v3 aware switch then
(S1,G) traffic should still be considered as unregistered data. 

On the other hand, if we assume that the presence of (S2,G) join has forced the switch to no more consider
(S1,G) data as unregistered then it will start forwarding traffic to the v3 receiver (who sent S2,G join).
If such a thing happens then your v3 purpose is defeated.

Thanks,
Magesh.

-----Original Message-----
From: magma-bounces <at> ietf.org [mailto:magma-bounces <at> ietf.org] On Behalf Of La Monte Yarroll
Sent: Wednesday, May 20, 2009 12:20 AM
To: magma <at> ietf.org
Cc: Manish Vora; Todd Derr
Subject: [magma] Seeking clarification of "unregistered packet"

I have a couple questions about the following material from RFC 4541,
2.1.2:

> 3) An unregistered packet is defined as an IPv4 multicast packet with
>    a destination address which does not match any of the groups
>    announced in earlier IGMP Membership Reports.
> 
>    If a switch receives an unregistered packet, it must forward that
>    packet on all ports to which an IGMP router is attached.  A switch
>    may default to forwarding unregistered packets on all ports.
>    Switches that do not forward unregistered packets to all ports
>    must include a configuration option to force the flooding of
>    unregistered packets on specified ports.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bharat Joshi | 20 May 2009 05:25
Favicon

Re: Seeking clarification of "unregistered packet"

Hi,

     Please see my response in line.

Thanks,
Bharat

> I have a couple questions about the following material from RFC 4541,
> 2.1.2:
> 
> > 3) An unregistered packet is defined as an IPv4 multicast packet with
> >    a destination address which does not match any of the groups
> >    announced in earlier IGMP Membership Reports.
> >
> >    If a switch receives an unregistered packet, it must forward that
> >    packet on all ports to which an IGMP router is attached.  A switch
> >    may default to forwarding unregistered packets on all ports.
> >    Switches that do not forward unregistered packets to all ports
> >    must include a configuration option to force the flooding of
> >    unregistered packets on specified ports.
> 
> Is the ability to "force the flooding of unregistered packets on
> specified ports" only important on switches which are only processing
> v1 and v2 packets (or v3 packets ignoring "include source" and "exclude
> source")?

No. I think it is required even for V3 capable switch. Though I think while defining unregistered packet,  it
would have been  better if RFC should have used 'destination address or a combination of source and
destination address which does not....' instead of just 'destination address which does not..'.
(Continue reading)

Permalink | Reply | 2 comments |
headers
La Monte Yarroll | 20 May 2009 16:07

Re: Seeking clarification of "unregistered packet"

On Wed, 2009-05-20 at 08:55 +0530, Bharat Joshi wrote:
> La Monte H.P. Yarroll wrote:
> > I have a couple questions about the following material from RFC 4541,
> > 2.1.2:
> > 
> > > 3) An unregistered packet is defined as an IPv4 multicast packet with
> > >    a destination address which does not match any of the groups
> > >    announced in earlier IGMP Membership Reports.
> > >
> > >    If a switch receives an unregistered packet, it must forward that
> > >    packet on all ports to which an IGMP router is attached.  A switch
> > >    may default to forwarding unregistered packets on all ports.
> > >    Switches that do not forward unregistered packets to all ports
> > >    must include a configuration option to force the flooding of
> > >    unregistered packets on specified ports.
> > 
> > Is the ability to "force the flooding of unregistered packets on
> > specified ports" only important on switches which are only processing
> > v1 and v2 packets (or v3 packets ignoring "include source" and "exclude
> > source")?
> 
> No. I think it is required even for V3 capable switch. Though I think
>  while defining unregistered packet,  it would have been  better if RFC
>  should have used 'destination address or a combination of source and
>  destination address which does not....' instead of just 'destination
>  address which does not..'.

Thanks, this is the revised definition of "unregistered packet" which I
was expecting.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Todd Derr | 20 May 2009 17:34

Re: Seeking clarification of "unregistered packet"

Can someone comment on exactly what the purpose of flooding unregistered
packets is?

I think most of my confusion comes from the third paragraph of 2.1.2
(3), where it discusses v3 hosts and switches that do not process v3
REPORTs.  That gives me the impression that flooding unregistered
packets was meant to solve that issue and ensure the v3 hosts receive
traffic.  However, in the last paragraph of that section it is conceded
that when both v2 and v3 hosts are present, this does not work because
v2 joins cause the v3 hosts to stop receiving traffic.  If there are
only v3 hosts present, the point is moot - if the switch doesn't
understand the v3 REPORTs there is no "snooping" happening at all, and
it has to flood all multicast to all ports.  So, if v3 hosts are to
function in such an environment, it appears we need to flood ALL traffic
to ports with v3 hosts attached rather than just unregistered traffic.

Is there another purpose for flooding unregistered traffic in a "normal"
network?  I was considering a bootstrapping scenario - i.e. when the
switch comes up, we don't know what groups the hosts had previously
joined, so flooding unregistered traffic allows hosts to start receiving
sooner.  However, this seems to be of marginal benefit because as soon
as we receive a join for a group on any port, the other ports will be
"cut off".  Using some sort of restart timer (where we flood all traffic
to all ports for some amount of time after boot) seems like a better
solution to that problem.

thanks,

todd.
(Continue reading)

Permalink | Reply | 501 comments |
headers
Bharat Joshi | 21 May 2009 05:24
Favicon

Re: Seeking clarification of "unregistered packet"

Hi,

      Please see my response in line.

Thanks,
Bharat

> > La Monte H.P. Yarroll wrote:
> > > I have a couple questions about the following material from RFC 4541,
> > > 2.1.2:
> > > 
> > > > 3) An unregistered packet is defined as an IPv4 multicast packet with
> > > >    a destination address which does not match any of the groups
> > > >    announced in earlier IGMP Membership Reports.
> > > >
> > > >    If a switch receives an unregistered packet, it must forward that
> > > >    packet on all ports to which an IGMP router is attached.  A switch
> > > >    may default to forwarding unregistered packets on all ports.
> > > >    Switches that do not forward unregistered packets to all ports
> > > >    must include a configuration option to force the flooding of
> > > >    unregistered packets on specified ports.
> > > 
> > > Is the ability to "force the flooding of unregistered packets on
> > > specified ports" only important on switches which are only processing
> > > v1 and v2 packets (or v3 packets ignoring "include source" and "exclude
> > > source")?
> > 
> > No. I think it is required even for V3 capable switch. Though I think
> >  while defining unregistered packet,  it would have been  better if RFC
> >  should have used 'destination address or a combination of source and
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bharat Joshi | 21 May 2009 05:59
Favicon

Re: Seeking clarification of "unregistered packet"

Hi Todd,

     Please see my response in line.

Thanks,
Bharat

On Thu, 2009-05-21 at 08:57 +0530, Bharat joshi wrote:
Can someone comment on exactly what the purpose of flooding unregistered
> packets is?
>

Let me put forward my understanding. Please correct me if I am wrong.

> I think most of my confusion comes from the third paragraph of 2.1.2
> (3), where it discusses v3 hosts and switches that do not process v3
> REPORTs.  That gives me the impression that flooding unregistered
> packets was meant to solve that issue and ensure the v3 hosts receive
> traffic.  However, in the last paragraph of that section it is conceded
> that when both v2 and v3 hosts are present, this does not work because
> v2 joins cause the v3 hosts to stop receiving traffic.  If there are
> only v3 hosts present, the point is moot - if the switch doesn't
> understand the v3 REPORTs there is no "snooping" happening at all, and
> it has to flood all multicast to all ports.  So, if v3 hosts are to
> function in such an environment, it appears we need to flood ALL traffic
> to ports with v3 hosts attached rather than just unregistered traffic.

I completely agree with your reasoning. But flooding all traffic to v3 hosts will surely be an overkill. I
think in such a case, a service provider should upgrade the switch.
(Continue reading)

Permalink | Reply | 501 comments |
headers
Todd Derr | 21 May 2009 06:41

Re: Seeking clarification of "unregistered packet"

Thanks, if that is the case I don't see any benefit to treating "unregistered" traffic specially.  I am inclined to treat it the same as any other multicast traffic - i.e. send it to all ports requesting it (obviously, this is an empty set in the unregistered case) plus router ports.  This is technically not compliant with the RFC but I think it is better than the alternative of flooding it to all ports which has the somewhat counter-intuitive behaviour of sending traffic that no one is interested in to all ports.
 
I believe the only way to handle the v3-host/non-v3-switch case (assuming the switch doesn't even do "partial" v3 as suggested) is to provide an option to flood all traffic to flood all traffic to specified ports.  As you say, that is certainly overkill - but if the switch does not process the reports at all it is impossible to do anything better.
 
thanks,
 
todd.
 
From: magma-bounces <at> ietf.org on behalf of Bharat Joshi
Sent: Wed 5/20/2009 11:59 PM
To: Todd Derr; magma <at> ietf.org
Cc: La Monte Yarroll; Manish Vora
Subject: Re: [magma] Seeking clarification of "unregistered packet"

Hi Todd,

     Please see my response in line.

Thanks,
Bharat

On Thu, 2009-05-21 at 08:57 +0530, Bharat joshi wrote:
Can someone comment on exactly what the purpose of flooding unregistered
> packets is?
>

Let me put forward my understanding. Please correct me if I am wrong.

> I think most of my confusion comes from the third paragraph of 2.1.2
> (3), where it discusses v3 hosts and switches that do not process v3
> REPORTs.  That gives me the impression that flooding unregistered
> packets was meant to solve that issue and ensure the v3 hosts receive
> traffic.  However, in the last paragraph of that section it is conceded
> that when both v2 and v3 hosts are present, this does not work because
> v2 joins cause the v3 hosts to stop receiving traffic.  If there are
> only v3 hosts present, the point is moot - if the switch doesn't
> understand the v3 REPORTs there is no "snooping" happening at all, and
> it has to flood all multicast to all ports.  So, if v3 hosts are to
> function in such an environment, it appears we need to flood ALL traffic
> to ports with v3 hosts attached rather than just unregistered traffic.

I completely agree with your reasoning. But flooding all traffic to v3 hosts will surely be an overkill. I think in such a case, a service provider should upgrade the switch.

> Is there another purpose for flooding unregistered traffic in a "normal"
> network?  I was considering a bootstrapping scenario - i.e. when the
> switch comes up, we don't know what groups the hosts had previously
> joined, so flooding unregistered traffic allows hosts to start receiving
> sooner.  However, this seems to be of marginal benefit because as soon
> as we receive a join for a group on any port, the other ports will be
> "cut off".  Using some sort of restart timer (where we flood all traffic
> to all ports for some amount of time after boot) seems like a better
> solution to that problem.

I do not think there is any other purpose to forward unregistered packet except to try to support some IGMPv3 hosts attached to a non-IGMPv3 switch. But this looks to be a half hearted attempt and things won't work as discussed in the RFC.

As recommended in paragraph 4, I think things will work properly if at least a cut-down version of IGMPv3 is supported in a switch.
**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely
for the use of the addressee(s). If you are not the intended recipient, please
notify the sender by e-mail and delete the original message. Further, you are not
to copy, disclose, or distribute this e-mail or its contents to any other person and
any such actions are unlawful. This e-mail may contain viruses. Infosys has taken
every reasonable precaution to minimize this risk, but is not liable for any damage
you may sustain as a result of any virus in this e-mail. You should carry out your
own virus checks before opening the e-mail or attachment. Infosys reserves the
right to monitor and review the content of all messages sent to or from this e-mail
address. Messages sent to or from this e-mail address may be stored on the
Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***
_______________________________________________
magma mailing list
magma <at> ietf.org
https://www.ietf.org/mailman/listinfo/magma

_______________________________________________
magma mailing list
magma <at> ietf.org
https://www.ietf.org/mailman/listinfo/magma
Permalink | Reply | 0 comments |
headers
Ines BEN JEMAA | 27 May 2009 11:41
Picon

(MLD)-Based Multicast Forwarding

Dear all,

I'm working on IPv6 multicast. I have to test and deploy IPv6 multicast in a network topology of two subnets with two MLDv2 routers as shown below : 


      Source (Multicast Sender)
                |

                |
MLDv2 Router1===============MLDv2 Router2                
                  |                                                             |
    --------------|-------------                                       ---------|---------
                  |                                                             |
             Host1                                                       Host2
(Multicast listener)                                     (Multicast listener)


If I understand, the use of MLD forwarding proxy [RFC 4605] is useful in case we have a simple network topology and we don't need to run a multicast routing daemon as PIM. My question is : In our topology, can we use the MLD forwarding proxy to route multicast packets from the source to the multicast listeners in the two subnets?

If it can be used, is there any implementation or configuration of the multicast forwarding (MLD proxying) (any software which implements this mechanism)?


Thank you in advance for your help,

Best regards,
Ines  

_______________________________________________
magma mailing list
magma <at> ietf.org
https://www.ietf.org/mailman/listinfo/magma
Permalink | Reply | 0 comments |
headers
Brian Haberman | 28 May 2009 16:14

Re: MLD Based Multicast Forwarding

Ines BEN JEMAA wrote:
> Dear all,
> 
> 
> I'm working on IPv6 multicast. I have to test and deploy IPv6 multicast 
> in a network topology of two subnets with two MLDv2 routers as shown 
> below : 
> 
> 
>       Source (Multicast Sender)
>                 |
>                 |
> MLDv2 Router1===============MLDv2 Router2                
>                   |                                                      
>        |
>     --------------|-------------                                       
> ---------|---------
>                   |                                                      
>        |
>              Host1                                                       
> Host2
> (Multicast listener)                                     (Multicast 
> listener)
> 
> 
> If I understand, the use of MLD forwarding proxy [RFC 4605] is useful in 
> case we have a simple network topology and we don't need to run a 
> multicast routing daemon as PIM. My question is : In our topology, can 
> we use the MLD forwarding proxy to route multicast packets from the 
> source to the multicast listeners in the two subnets?

As long as the network forms a tree (no cycles in the network), RFC 4605 
can be utilized.

> 
> If it can be used, is there any implementation or configuration of the 
> multicast forwarding (MLD proxying) (any software which implements this 
> mechanism)?

My understanding is that it is supported in the Linux kernel and by a 
company called MikroTik.  In addition, there are at least 2 open source 
projects:

http://sourceforge.net/projects/igmpproxy
http://potiron.loria.fr/projects/madynes/internals/perso/lahmadi/igmpv3proxy

Regards,
Brian
Permalink | Reply | 0 comments |

Gmane