Subject: (ION) Resent queries regarding RFCs 2022 & 2149

From: Vineet_Shukla <[email-masked]>
Date: Thu, 29 Oct 1998 09:25:52 +0530

Hi, 
I had sent this mail some days back. Am resending it, hoping this time
it
will elicit some responce.
Regards,
Vineet
--------------------------------------------------------------------
Hi,
We have some queries regarding MARS description as given in the 
following RFCs:

RFC 2022 
"Support for Multicast over UNI 3.0/3.1 based ATM Networks"

1. The RFC details out the operations for a client on the receive 
   side where a client can join
   a) a block of multicast groups in response to a join request
      from a upper layer application functing as a multicast router
      application
   b) a single multicast group in response to a join request
      from a upper layer application functing as a multicast router
      application
   c) a single multicast group in response to an upper layer client
      application
   All these are done to receive data meant for the relevant multicast
   groups.

   It is not very clear from the RFC if a separate mapping is maintained
   for groups joined by a client in response to a router application,
and 
   those in response to other applications' requests, for the same
group,
   both on the client and the MARS Server side.

   Some cases that may arise out of normal operations of a client can
   be as follows:
   a) the client joins a hypothetical multicast range <10, 100> 
      (router application), then it joins <50, 50> (single group) as a
pure
      client application, and subsequently leaves <10, 100>.
      Should it remain a member of <50, 50> in this case?

   b) the client joins a group <50, 50> (router application), and then
      again <50, 50> as a pure upper layer application. 
      Should these different joins for the same group be maintained  
      separately on the client and the MARS Server? And should
their       corresponding LEAVE messages be processed differently?
   
2. The RFC 2022 in section 5.2 discusses JOIN operations of clients
   with special requirements (multicast routers). It says that such
   a client may not issue a multigroup block join which overlaps -
   fully/partially a multigroup block join issued previously, but may 
   issue single group joins overlapping existing memberships. 
   Does this mean that in order to subscribe to a such an overlapped 
   range the client has 2 options:
   a) leave the earlier range, and join the old & new ranges afresh
      with no overlap (???)
   b) issue single group joins for router application as well

The main issue here in both the above points is how strict are the 
demarcations between joins for router application, and for others for
the same multicast groups on a single client instance.

RFC 2149 "Multicast Server Architecture for MARS-based ATM 
multicasting" - describes the working of the Multicast Server (MCS)

1. Section 4.1.2 describes registration & deregistration of an MCS
   to support multicast groups. This explicitly says that an MCS can
   "register with the MARS to support particular group(s). To register 
   groups X through Y, a MARSMSERV with a <min, max> pair of <X,Y> MUST  
   be sent to the MARS". 

   Now the RFC mentions that a copy of this message is sent out to other
   MCSs on the ServerControl VC. A "copy" means that the punched flag
   is reset, and there is no hole punching involved here in the case
   of MCS(as opposed to that of a client). 
   Does this mean that the MARS Server can issue overlapping MSERV
requests
   to the server, which are then forwarded to the other MCSs unaltered?

2. The RFC mentions that in response to a MARS_MSERV reply from the
server,
   the MCS issues a MARS_REQUEST for the groups it has registered
support
   for (Section 4.2).
   Now if an MCS registers for multiple groups in one message, does it
send
   out MARS_REQUESTs for all the groups in the message the moment it
gets 
   a reply from the server? 
   Will this not swamp the server with a lot of MARS_REQUESTs? Or should 
   there be some staggering done by MCS in sending these MARS_REQUEST
messages 
   to the server?
   
   The RFC is not very explicit in this issue. 

Your comments shall be much appreciated.
Thanks,
Vineet Shukla
X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe ion' in the body of the message.