The IP over ATM Mailing List Archive by date

[susan@backup.mitre.org]

John,

I more or less agree with you.  See my comments below.

Susan Symington
The MITRE Corporation
(703) 883-7209

---------------------------

> To: susan@backup.mitre.org
> Cc: jshirron@fore.com, ip-atm@matmos.hpl.hp.com
> Subject: Re: Multiple outstanding MARS_JOINs? 
> In-Reply-To: Your message of "Thu, 16 Feb 95 17:31:40 EST."
>              <9502162231.AA19204@backup.mitre.org> 
> Date: Thu, 16 Feb 95 18:04:42 -0500
> 
> 
[...]
> 
> I just came across another section of the spec which indicates the above
> problem may not be present just for block joins/leaves.  From section 8.2:
> 
>    When a cluster member issues MARS_JOIN or MARS_LEAVE for a single
>    group, the MARS checks to see if the group has an associated server
>    map.
> 
>    If the specified group does not have a server map the MARS_JOIN or
>    MARS_LEAVE is retransmitted on ClusterControlVC.
> 
>    If it does have a server map two transmissions occur:
> 
>       A copy is made with type MARS_SJOIN or MARS_SLEAVE as appropriate
>       and transmitted on ServerControlVC. This allows the server(s)
>       supporting the group to note the new member and add it as a leaf
>       node.
> 
>       The original message's ar$pnum field is set to 0, and it is
>       transmitted back using the VC it arrived on (rather than
>       ClusterControlVC).
> 
> So even if a cluster member issues a join for just a single group (as a
> non-router host would), if that group is served by multicast servers, the
> MARS_JOIN copy I receive will have ar$pnum set to 0, and therefore contain no
> information about which join is being confirmed.  

I see your point, but I had read this another way.  I thought that setting ar$pnum to 
zero didn't necessarily affect the value in the ar$min.1 field.  In other words,
if an entity sends a MARS_JOIN for group X and group X is served by a multicast 
server, the entity will get back the original MARS_JOIN with ar$pnum set to 0 but
ar$min.1 would still have the value <X,X>, thus enabling the returned MARS_JOIN
to confirm the actual group being joined.

If my reading is "correct", then there is still the question that you bring up
below: why is ar$pnum set to zero?  What purpose does it serve, if any?

If your reading is correct, I agree with your assessment (below).

At a minimum, the draft needs to be clarified so that we know whether or not the
group (<X,X>) actually appears in the MARS_JOIN that the MARS returns to the joining 
entity.

> And since a cluster member
> does not have any a priori knowledge of which groups are being handled by
> multicast servers, it cannot have more than one outstanding MARS_JOIN/LEAVE,
> be it for a single group or a block of groups.
> 
> > So, aren't routers the only cluster members that we have to worry about having
> > multiple outstanding block MARS_JOINs?  Or am I missing something.
> 
> If my above reasoning is correct, I think ALL cluster members have to worry.
> 
> I'm not sure I understand the reasoning behind setting ar$pnum to zero if a
> host is attempting to join a single group served my multicast servers.
> In this case, the MARS_JOIN copy is specifically sent on the VC it arrived on,
> so other cluster members will not get confused.  So since the originating
> cluster member is the only one to see the copy, what harm is there in including
> the joined group in the MARS_JOIN copy?  A cluster member must detect copies
> of its own messages anyway, so it can avoid adding itself as a leaf to the PMP
> connection for this group (the only confusion I can see).
> 
> The way the spec stands, I think ALL cluster members must refrain from having
> multiple outstanding MARS_JOIN/LEAVEs.  If setting ar$pnum to zero when
> generating the copy for a group served by multicast servers turns out not to
> be required and is removed, then I agree with your above procedures for when
> a host can and cannot have multiple outstanding MARS_JOIN/LEAVEs.
> 
> John Shirron
> FORE Systems, Inc.
> 412-772-6561