Subject: RE: [Ipoverib] IPoIB multicast forwarding

From: "Aditya Dube" <[email-masked]>
Date: Fri, 12 Apr 2002 11:03:59 -0700

Vivek

As the sender will only send packets to the all-router MGID after doing
the check, how will a receiver who creates the MGroup on the same subnet
as the sender ever receive the multicast packets that it should get?

On Ethernet the sender does no check. The sender will simply send
packets to corresponding Ethernet multicast address. Whenever, the
receiver wants it can start listening for the multicast address it is
interested in.

As you state, on Ethernet the router will be in promiscuous multicast
receive mode so the router will keep get all the multicast packets that
it needs to route. 

-----Original Message-----
From: Vivek Kashyap [mailto:[email-masked]] 
Sent: Friday, April 12, 2002 12:15 AM
To: Michael Krause
Cc: Aditya Dube; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [Ipoverib] IPoIB multicast forwarding

> 
> 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.

        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

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

-- 
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

---

From: Vivek Kashyap <[email-masked]>
Date: Mon, 15 Apr 2002 11:38:42 -0700 (PDT)

> as the sender ever receive the multicast packets that it should get?

        The suggested solution is as follows. The basic idea is
        certainly workable. Hopefully, after some discussion we can
        refine it to cover all the issues that crop up.

	Sender:
		got IP multicast packet to send
			determine the corresponding IB group
			if already 'IB_joined' or 'recorded'
				IB_send to it

			else if IB group exists
				IB_join/record MGID locally
				IB_send to it
			else
				
				IB_send to all-routers MGID

	Receiver:
		want to receive IP multicast beloging to an IP group 
			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
				(IB_send report to 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 

        Now, a sender must check for the IB group everytime it is sending
        to an IB group it doesn't know about (no prior IB_join/record
        with it). But once the group exists and the sender has a
        packet to send, it will detect the presence and join the
        group. From then on it will always send to that MGID. The
        receiver will get the packets since it (or another receiver)
        created the IB group.

        In other situation where the router determines that there are
        external receivers it creates the group too. The sender will
        therefore find this and join the group.

        The sender needs to continuously check for the IB group only
        in case is where the router doesn't need to forward the packet
        and there are no receivers in the local subnet. I don't think
        this will be too often. Is this case of concern ?

Vivek

<snip>

---

From: Yaron Haviv <[email-masked]>
Date: Mon, 15 Apr 2002 21:12:24 +0200

Vivek,

Since checking the Group any time you send a multicast packet is very costly
We can adopt some kind of a broadcast notification message sent by the
router, this way the node will update its caches

The process goes:
	Sender wants to send multicast
	No Group so sends to all Router Group
	(Can optionally create the group (like Mike suggested) still sending the
packet to all-routers without delaying the packet, since we need to first
have the router joining this group prior to our send)

Now we need someone to tell us that the router is registered to this group
already
This could be done by either the router or by the SM

now there are two possible scenarios
1 - 	Router receives the packet and sees there is a need for a new group
	it creates the group, and then sends a broadcast message saying this group
was formed
	(Can optionally send a unicast back to the sender)
	Sender updates its cache

2- 	SM sees a create/join from the router and than send a notification to
all other nodes
	this enables updating the cache

Updating PathRecord cache is probably an essential IBA requirement too when
dealing with the unicast traffic
It could use a similar notification mechanism

Yaron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Vivek Kashyap
Sent: Monday, April 15, 2002 8:39 PM
To: Aditya Dube
Cc: [email-masked]
Subject: Re: [Ipoverib] IPoIB multicast forwarding

        Sender:

                        else if IB group exists

        Receiver:

        Router:

Vivek

<snip>

---

From: Michael Krause <[email-masked]>
Date: Mon, 15 Apr 2002 12:46:47 -0700

>router, this way the node will update its caches

How would an application distinguish between what is now a control message 
independent of the multicast group and application messages which were part 
of the multicast group's work?  I prefer to leave all of this to the IB 
management realm to solve (as described in my other e-mail) and just have 
IP focus on IP operations.  The mappings should be obtained once and only 
upon an update from a management entity within the IB framework would this 
mapping be changed.  In general, I find much of the discussion to date as 
making things more complex / difficult for endnodes to implement when it 
should not be so.

Mike

---

From: Vivek Kashyap <[email-masked]>
Date: Mon, 15 Apr 2002 13:41:34 -0700 (PDT)

> 	No Group so sends to all Router Group

	OK. This is exactly what I have written.

        Note: once the group is created (see the soution in the
        previous mail) we no longer have to do anything of this type.
        The checking is only for the time the sender has not joined
        the group.

         Sender:
                 got IP multicast packet to send
                         determine the corresponding IB group
                         if already 'IB_joined' or 'recorded' ----(a)
                                 IB_send to it
 
                         else if IB group exists             -----(b)
                                 IB_join/record MGID locally
                                 IB_send to it
                         else
 
                                IB_send to all-routers MGID   -----(c)
 
        We need to evaluate if case (c) will be a common case and if
        it is will it last for long. Only then can we say it is
        costly. 

	We can modify the solution a bit though:

                Let the sender send to the all-hosts MGID if it
                doesn't have the MGID recorded or the group doesn't
                exist. Since it is sending ot all-hosts MGID the
                packet will be received by all multicast hosts
                (routers/receivers). Thus the sender can check for new
                groups periodically and not with every new packet to
                the given group.

> have the router joining this group prior to our send)

        How will the router know to join ? The reason I suggested
        using the IGMP report is since it is a direct indication of
        the group coming into being. For a sender there is no IP level
        or IB level hook to tell anyone that a group is created.

> 	(Can optionally send a unicast back to the sender)

	I take you mean:

        Router receives the IP_packet-in-all-router-MGID. The router's
        IPoIB driver determines the new MGID based on the IP_group.

        Now, the IPoIB driver of the router sends a <broadcast packet>
        - has to be at IB level - and defined by a standard. This is
        received by all IPoIB drivers and they create the group and
        add it.

	I would modify this to:

                The router's IPoIB driver creates the group. Next time
                the sender will check and find the group exists and
                join it.

        This also is workable. It asks the router's IPoIB driver to be
        a little more aggressive. The rest of the solution can stay as
        I have suggested earlier. The difference is that we are
        ensuring that the router always create a group. The negative
        is that too many groups may be created, even if one IP packet
        was sent to the group, whether one needs them or not.

Vivek

> 	this enables updating the cache
        If IB solution provided such updates we wouldn't need any
        IPoIB level solutions. It doesn't. There is no point in
        discussing updates to IBA in IPoIB WG; they need to be looked
        into in the IBA WGs.