Subject: RE: [Ipoverib] IPoIB multicast forwarding

From: Michael Krause <[email-masked]>
Date: Thu, 11 Apr 2002 21:52:37 -0700

At 09:32 PM 4/11/2002 -0700, Aditya Dube wrote:
>Hello Vivek
>
>I have a question. Could you clarify what will happen in the following
>scenario in the third scheme that was proposed below:
>
>Pure senders - at IB level check for the relevant IB group.
>            If it exists then send to the IB group else send to the
>            'all-routers' IB group.
>
>What happens if a Receiver creates the 'relevant IB group' after the
>sender has made the check?

There should not be such an option in the first place: the relevant group 
should always exist or else nothing is sent.

Mike

_______________________________________________
IPoverIB mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipoverib

---

From: Vivek Kashyap <[email-masked]>
Date: Fri, 12 Apr 2002 00:15:07 -0700 (PDT)

> should always exist or else nothing is sent.

        Unfortunately we do have to have such an option. There maybe
        no IP group receiver and hence IB group on the subnet. But the
        router may still need to receive the packet to forward out.

        The router could create the IB group if it knew it has to
        forward for the relevant IP group. However, the router does
        not know this for the first multicast datagram it sends for
        this group(DVMRP). So, we need to ensure that it receives the
        packet and therefore the need to have the option to the
        all-routers IB group.

        A receiver creating the group after the sender checks is no
        different than the receiver creating the group after a
        hypothetical atomic check and send of a multicast packet by a
        sender. I thought about suggesting that sender sends to the
        broadcast-GID but then decided against it - why punish
        everyone for a once in a while race condition that can go
        either way even if the sender could do atomic 'check (i.e.
        join) and send'.

        For the next packet the sender will find the group and from
        then onwards directly send on the group.

Vivek

-- 
Vivek Kashyap
Linux Technology Center, IBM
[email-masked] 
[email-masked] 
503 578 3422 (o)

---

From: Michael Krause <[email-masked]>
Date: Fri, 12 Apr 2002 13:40:54 -0700

>         router may still need to receive the packet to forward out.

If an IP multicast group is to be used on an IB fabric, then there must 
exist an IB multicast group.

>         packet and therefore the need to have the option to the

A management agent above the SA can track whether there are routers that 
also support IP to non-IB fabrics, i.e. there is an IB TCA that acts as an 
IP router (it isn't a router in the IB use of the term).  This management 
agent can determine whether to include this TCA in any IB multicast group 
or not.  As such, the management agent not the TCA creates the IB multicast 
group.  When an IB endnode wishes to use multicast, it would communicate to 
the SA and find that there is a corresponding multicast group for the 
service it is trying to deliver and if so, a join would be performed and 
the packets would be automatically forwarded to all members which may now 
include these IB TCAs.  It is strictly policy as to whether the management 
agent adds in these TCAs into all multicast groups or not.  The application 
though continues to use the same multicast group identifier whether such 
TCAs are present or not.

>         either way even if the sender could do atomic 'check (i.e.

Broadcast is not required for the sending endnode.  All router multicast is 
not required for any of this to work; the sender injects packets to the 
selected IP multicast group which maps to a corresponding set of 
participating CAs, thus no race condition exists, no additional 
notification is required, etc.

>         then onwards directly send on the group.

How exactly would it find out anything in this regard?  There is no 
mechanism to perform a dynamic update of all participating endnodes and 
there should not be except to indicate the multicast group no longer exists 
or a prune is performed for this endnode.

Mike