Kishore,

Looks a pretty good summary of our discussions - let's see what fallout it generates!!!

Chris, Kishore,

here are some ideas on the problem for further thinking (no solutions, of course :-)

In essence, basing a protocol action on on whether the provoking message was sent via unicast or multicast is not a very good idea anyway -- even if you manage to solve the problem of distinguishing one from the other upon reception. Rather, we may need a "bit" indicating transmission via multicast or unicast:

Our data transmission allows for multi-unicast, so why should discovery not do so as well? Particularly, you could imagine a scenario where you receive a set of potential gatekeeper locations via private DHCP extensions, via manual configuation, etc. some of which may be up and willing to register you and some may not -- be it for load balancing, robustness, etc. Now you have to try all those locations to find a gatekeeper that accepts your registration but your network (unfortunately) is not supporting multicast. Querying the gatekeepers one by one may (but need not) lead to having to wait for timers to expire before you try the next one. Querying them in parallel is semantically equivalent to multicast even if you do not us IP multicast to reach everybody. Finally note that a gatekeeper's decision if to respond (and how much information to include in a response) may depend on whether it was asked individually or together with a number of other gatekeepers.

Assuming these considerations are valid, the remaining question would be which piece(s) of information to use to implement the "this-request-is- multicast-bit".

Joerg