Subject: zmaap and session discovery

From: Erik Guttman <[email-masked]>
Date: Thu, 28 Jun 2001 11:55:37 +0200 (MET DST)

draft-ietf-zeroconf-zmaap-01.txt provides the following capabilities:

ZMAAP allows an application to allocate an address which will be
defended.  In addition the application can 'share defense' of
an address allocated elsewhere.

In the case of a conflict (which can occur either because 
some ZMAAP packets are lost or due to fusion of two previously
isolated networks), one or more of the allocations will be
abandoned, and new addresses will have to be allocated.

*** How can members of a session rediscover it after a conflict
*** at a newly allocated multicast address?

draft-ietf-zeroconf-zmaap-01.txt suggests that hosts should discover 
sessions by listen for SAP announcements, which will contain a 'zmaap 
lease-id' SDP attribute.  This will enable rendezvous initially and 
at subsequent multicast group allocations.  

*** The problem with this approach is that SAP advertisements 
*** occur very seldom.  SAP is not suited for short-lived (ad hoc) 
*** local-area session discovery.  RFC 2974 puts it this way:
 
   SAP is intended to announce the existence of long-lived wide-area
   multicast sessions.  It is not an especially timely protocol:
   sessions are announced by periodic multicast with a repeat rate on
   the order of tens of minutes, and no enhanced reliability over UDP.
   This leads to a long startup delay before a complete set of
   announcements is heard by a listener.  This delay is clearly
   undesirable for interactive browsing of announced sessions.

An alternative for session discovery is needed, which allows
prompt rendezvous after a conflict and rapid browsing of 
available sessions.  Alternatives I can think of are:

(1) Add a SDR attribute list to address-in-use (AIU) messages.
    AIUs are retransmitted before the 'lease-lifetime' expires.  
    This lifetime can be from 1 second - ~18 hours.  If lifetimes
    of ~1 minute were used, session discovery would be pretty
    prompt:  Session caches could be used for browsing.  
 
    This approach uses a lot of bandwidth and increases processing
    and storage requirements of mini-MAASs.  Further, ZMAAP becomes
    a session discovery *AND* address allocation protocol.

(2) Add a new ZMAAP session request and session reply message.
    These would contain a list of SDR attributes.  A reply
    would be sent if it matched the attributes in the session
    request.

    This approach doesn't use much network or system resources,
    but it complicates ZMAAP.  Further, ZMAAP becomes a 
    session discovery *AND* address allocation protocol.  Finally,
    there already exists an IETF standard discovery protocol, SLP.

(3) SLP could be used to discover multicast sessions.

    This adds a requirement on SLP to support ZMAAP.  SLP has not
    previously be used for multicast session discovery.  

(4) In the limited context of the scopes supported by ZMAAP
    SAP could be defined so that it sends more frequent advertisements
    (on the order of 10s of seconds instead of 10s of minutes).

    SAP is an Experimental protocol - meaning we could not base a
    standards track protocol (ZMAAP) on it. 

What do you think of these alternatives?  

I am inclined to (4).  Given the limited discussion of ZMAAP, 
perhaps it should be issued as an Experimental RFC.  In this
case relying on SAP would not be an issue.

Erik