Subject: RE: [Ipoverib] IPoIB multicast

From: "Larsen, Roy K" <[email-masked]>
Date: Fri, 19 Apr 2002 12:05:44 -0700

Jerry and Bill,

As Vivek alluded to when he published his latest thinking on multicast and
again here, the IBTA is currently considering making some significant
changes to multicast semantics and facilities.  I echo Vivek's sentiments on
not taking the multicast design any further until the IBTA makes public
their multicast updates.  Otherwise, we are going to have to revisit many of
these issues or worse, accept non-optimal solutions because no one wants to
rehash this again.  Therefore, I am requesting that this topic be tabled
until we have a stable IBA multicast service to design against.

Roy

-----Original Message-----
From: Vivek Kashyap [mailto:[email-masked]]
Sent: Friday, April 19, 2002 11:36 AM
To: Aditya Dube
Cc: [email-masked]; [email-masked]
Subject: RE: [Ipoverib] IPoIB multicast

Vivek

Thanks for sending this out. This definitely makes it much easier for me
to analyze the proposed solution.

The Router algorithm has a problem:

                         if report informs of leave
                                     IB_leave corresponding IB group

The First leave will cause the Router to leave the group regardless of
whether there are other nodes that have done an IB_Join.

<VK>
Yes, I was careless in stating this. I certainly didn't mean that one
leaves at the first report but was listing conditionals for leaving. I am
not looking into it anymore because of the changes being contemplated in
IBTA; and it also the reason for the delete case not being fully fleshed
out. I guess if we allow the router to leave the IB group (due to no
receivers and no need to forward) we also need to ensure that the senders
leave the groups. It works ok with my earlier comment on check for group
before every send(that could be quite inefficient though). Now one would
need to check for group existence periodically or have the router set a
timer when there are no receivers or need to forward on an MGID and leave
after some idle time.

The algorithms provide an outline that we can revisit (along with the
corrections as discussed above) and see how the conditions are met with the
IBA changes.

<VK>

The other thing that I have recently learnt is that Profile B hardware
requires a node to support a minimum of 16 multicast groups. Each join
is therefore a valuable resource.

<VK>
      Isn't profile B just a list of characteristics that are needed. As
far as I know it doesn't reflect the actual products in the market. Do you
know what is the number advertised by various vendors ?

      If it is number of MLIDs - one can always overload them. If it is
number of MGIDs at the CA then we need to consider the issue - it is not
limited to IPoIB multicast though. It is an IB multicast issue. We might
have to just say, use adequately provisioned CAs just like we state that
one must use multicast aware CAs or CAs which support a minimum of 2K MTU
etc.

Vivek
<VK>

Aditya Dube

-----Original Message-----
From: Vivek Kashyap [mailto:[email-masked]]
Sent: Thursday, April 18, 2002 11:16 AM
To: [email-masked]
Subject: [Ipoverib] IPoIB multicast

Aditya,

Below is the overall algorithm since you had asked me to submit it in
one writeup. However, in IBTA we are working on some ideas (I
participated in one such meeting today morning) that will make all
this a lot simpler.

The following is assuming IB multicast as defined at present.
There is no notification in IB that can be sent to IB nodes on group
creation or deletion. As per Mike's mail the IB group gets deleted
when the last member leaves.

Note: In this discussion I am referring to IP routers, receivers and
senders.

The idea below is to let the router(an IP router) know that a group
has been created (by the receivers) or have the routers create the
groups when they need to forward. This is accomplished by the routers
acting on the IP group creation reports(IGMP/MLD) or the routing
protocol updates.

A sender can send at any time. It therefore attempts to join the group
when it has some packet ot send and retries if it cannot join the
first time.

The receivers leave the IB groups when they are not interested in the
associated IP group. The routers leave when they leave the associated
IP group or determine that they no longer have to forward the
associated IP group packets.

Senders leave the groups when the group has not been used for some
time.

             Receiver:

        IP receivers must join a specific local interface and send a
        report to the router.

                         IP_ADD_MEMBERSHIP called
                                     check for corresponding IB group
                                     if IB group exists
                                                 IB_join it
                                                 IB_send report to group
                                     else
                                                 IB_create IB group
                                IB_send report to all-routers MGID or
                                could send it to all-hosts group

                         IP_DROP_MEMBERSHIP called
                                     (Send leave report to router )
                                     IB_leave the IB group

             Router:
                         always receive on broadcast/all-hosts and
all-routers
                         if IGMP/MLD indicates new group
                                     IB_join corresponding IB group
                         if routing protocol indicates new group
                                     IB_create corresponding IB group
                         if report informs of leave
                                     IB_leave corresponding IB group
                         if routing protocol indicates no need to forward
                                     IB_leave corresponding IB Group

             Sender:
                IP senders can send at any time. They don't have to
                join at an interface or report to an IP router.

                         got IP multicast packet to send
                                     map to the corresponding IB group
                                     if already 'IB_joined' the IB_group
                                                 IB_send to it
                                                 reset timer

                                     else if IB group exists
                                                 IB_join the group
                                                 start a timer
                                                 IB_send to it
                                     else

                                                 IB_send to all-routers
MGID ....(c)

                         if timer goes off
                                     IB_leave the IB group

        We can modify (c) above to 'send to all-hosts MGID'. That way
        the timer can be set to a longer value and the sender
        algorithm can become:

                         got IP multicast packet to send
                                     map to the coresponding IB group
                                     if already IB_joined
                                                 IB_send to it
                                                 reset timer
                                     else
                                                 IB_send to all-hosts MGID
                                                 if no timer associated
                                                             create a timer

                         if  timer goes off
                                     if IB_joined
                                                 IB_leave the IB group
                                     else
                                                 try to IB_join
                                                 restart timer

Vivek

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

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

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

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

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

---

From: Michael Krause <[email-masked]>
Date: Fri, 19 Apr 2002 12:31:08 -0700

>until we have a stable IBA multicast service to design against.

You have a good idea based on what I wrote and Vivek wrote to understand 
that there will be minimal impact to IP over IB specifications and this can 
go forward.  All that needs to be done is just describe the IP multicast 
address encapsulation and the work is essentially done.  The IP router 
interactions are also a non-issue.  Keep in mind that the IP over IB 
implementation is what is impacted by any of these IB changes and not the 
IP over IB protocol so let's finish encapsulation for unicast and multicast 
and be done with it.

Mike