The IP over ATM Mailing List Archive by date

[susan@gateway.mitre.org (Susan Symington)]

Comment on proposed changes to ipmc-04.txt:

Grenville:

In your proposed diffs to ipmc-04, you mention two possible
mechanisms for informing the MARS whether a MARS_JOIN is the 
result of a layer 3 multicast group being explicitly joined
or the result of an IP/ATM interface registering to receive 
traffic on a particular group for its own reasons (e.g. a
router trying to ensure that it sees traffic for that group).

I am writing this to register my vote in favor if the mechanism
that you describe in diff # 15 (as opposed to that described 
in diff # 17).

Your diff # 15 describes a flag mechanism for achieving this
goal: a flag is used in the JOIN/LEAVE to allow the joining
or leaving entity to inform the MARS of the reason that the
entity is joining or leaving the group.

Your diff # 17 describes an implicit mechanism for achieving
this goal: the assumption that a JOIN/LEAVE for group <x,x>
(e.g. a single group) is because of a layer 3 group join
operation and that a MARS_JOIN for <x,y> (multiple groups) is
simply an IP/ATM interface going promiscuous for groups
x through y.

While I can see that alternative # 17 would be easier to
implement, in my opinion it would be wiser for you to use
the mechanisms described in # 15 (an explicit flag).  
If the implicit approach (described in #17) is used, then 
it would not be possible for a router to issue a MARS_JOIN 
for group <x,x> and have that be interpreted as the router's
IP/ATM interface simply wanting to see all traffic for the
given group being joined.  

Consider the case of a stub IP LAN and the router that
connects it to a wider ATM network. If no hosts on the stub
LAN are participating in any multicast groups, then there
is no reason that the router (using some conceivable multicast 
routing capabilities of the future) would need to be 
receiving any multicast data from the wider ATM network.
However, if some host on the LAN suddenly joins a given group
G, then the router would want to register with the MARS to
receive traffic for group G by issuing a MARS_JOIN for <G,G>.
If mechanism # 17 is used, then the MARS will interpret this
MARS_JOIN to mean that the router is explicitly joining 
group G (which is not accurate). In this case, use of the
flag mechanism (#15) would allow the router to inform the
MARS that the MARS_JOIN for <G,G> is instead the result of 
the router registering to receive traffic for group G so that
it can in turn forward it on the appropriate interface.

--Susan Symington



susan@gateway.mitre.org