Subject: ZMAAP changes

From: "Octavian Catrina" <[email-masked]>
Date: Wed, 28 Mar 2001 11:08:44 +0200

The idea of removing the lifetime from the ZMAAP messages makes a lot of sense.
I'm definitely in favor of this solution.

The lifetime was an AAP vestige (to quote Erik). AAP used it for its replicated
database of allocations (which became in ZMAAP draft 00 an optional caching of
allocations made by others). However, maintaining the consistency of such a
database implies a lot of overhead.

I tried to sketch a modified version of ZMAAP without lease lifetime in the
messages. I started with a really minimal protocol, sort of a reference, to
which we can add some (possibly optional) extensions. In the text below I
maintained this approach to facilitate the discussion (it helps understanding
the limitations of the minimal protocol and the additional
functionality/overhead of any extensions we might want).

I've already added a simple extension allowing any multicast session participant
to monitor the session's address (actually a feature already present in draft
00).

1. Minimal ZMAAP:

- Protocol messages:

ACLM means: Is this address allocated?
AIU means: I allocated the address (defense).
ACLM and AIU only specify addresses: no lease lifetime, no lease id
(the id will come back in the extended version).

- Allocation records:

Each mini-MAAS maintains allocation records for the addresses it has allocated.
A record is maintained for the duration of the allocation lifetime requested by
the app and removed when the lifetime expires.
The records allow the mini-MAAS to defend its allocations and are consulted when
choosing a "free" address for allocation.
A mini-MAAS does not record allocations made by other mini-MAASs (no caching in
this minimal version, because allocation lifetime is unknown).

- Address allocation:

The allocator app asks its mini-MAAS to allocate an address in some scope for a
certain lifetime. The mini-MAAS picks randomly an address in that scope and
claims it using ACLM (no lease-lifetime and lease-id in ACLM).
If the mini-MAAS does not receive an AIU reply, it allocates the address
(becomes its "owner") and starts defending the address for the requested
lifetime (no need to send an AIU, no other mini-MAAS is interested).
Otherwise, it aborts the claiming and tries again with another address.

- Allocation defense:

An allocated address is only defended by its owner (no other mini-MAAS can do
it). The defense of an allocated address consists in sending an AIU in reply to
an ACLM that claims the address.

- Lifetime change and deallocation:

After obtaining an address allocation, an app can change its lifetime, to extend
it or reduce it. In particular, it can terminate the allocation indicating
lifetime = 0. This only requires a local dialogue between the app and the local
mini-MAAS.

- Efficiency issues

When a relatively small fraction of the address space is allocated a random
address selection will likely succeed (the protocol is optimized for this case).
When the fraction of allocated addresses increases, claims will fail and
allocations require a greater number of attempts.

- Allocation conflicts detection and resolution:

Allocation conflicts can still occur in at least 2 situations:
- During a network partition, an address is independently allocated in each part
and afterwards the network is reunited.
- The mini-MAAS that owns the address crushes, so the address is no longer
defended and another mini-MAAS allocates it. This can cause an allocation
conflict if the multicast session continues in the absence of the participant
that allocated the address.

A mini-MAAS can only detect an allocation conflict by receiving an AIU for an
address it currently owns. For example, mini-MAAS A tries to allocate an
addresss already allocate by mini-MAASs B and C. Such a situation has a quite
low probability.

Therefore, we can only expect this minimal protocol to reduce the probability of
allocation conflicts. We cannot rely on it to detect and resolve allocation
conflicts.

Also, with this minimal version, only the session participant that allocated the
session's address can control the allocation: learn from its mini-MAAS if the
allocation is valid or not, change its lifetime or deallocate it. The other
session participants can just rely on the allocator. (If the session is supposed
to continue without the allocator and the remaining participants can detect the
absence of the allocator app, one of them can try to take over the session's
address by reallocating it - this may not work if the mini-MAAS that allocated
the address is still defending it).

So the apps using this protocol must be able to recover from allocation
conflicts.

However, a multicast app needs anyway some mechanism for filtering received
messages - the allocation protocol does not prevent some other app from sending
to a multicast address without first allocating it. If the conflict is between
sessions that use the same UDP port (same app), then the app can detect an
allocation conflict using its filtering mechanism and can request the allocation
of another address (I suppose this could even be done gracefully). Otherwise,
the packets are discarded by UDP and just cause additional processing overhead
in that host (any way to solve this problem ?).

- Conclusions
This minimal profile is based on the assumption that claiming clashes and
allocation conflicts occur very infrequently. In such a case, mechanisms that
avoid claiming clashes and detect allocation conflicts imply an excessive
overhead and are not justified. Therefore:
- A minimal claim-defense mechanism is provided for allocating addresses. An
allocation is only recorded and defended by the allocator.
- Allocation conflict detection and resolution is left to the apps.

***

The minimal protocol outlined above is some kind of baseline. We can try to
extend it. But as long as we don't accept periodic advertisements, even at a
lower rate, there is no way to detect conflicts.

Here is a simple extension. I'll point out only the differences and some
implications.

2. Extensions of the minimal ZMAAP:

The basic idea is that an address allocation must be maintained as long as the
multicast session continues, regardless of the changes in the group membership.
For this purpose, the address allocation should be monitored by all the
participants in the multicast session instead of being exclusively taken care of
by the allocator (session initiator).

After the allocation of the address by the session initiator, other participants
may ask their mini-MAAS to monitor the session's address for a specified
lifetime. One mini-MAAS is the current owner (initially, the allocator). The
others are "passive" monitors. The owner and the monitors maintain allocation
records for the address during the lifetime indicated by their local app (may
not be the same lifetime value!).

The owner defends the address by sending immediately an AIU. A monitor sends a
randomly delayed AIU if the owner fails to defend.

The lease must have a unique id, and the AIUs must specify it.
(It doesn't seem necessary to specify a lease id in ACLM, since it just tests if
the address can be allocated.)

I don't like the delayed defense but we can minimize its use by allowing a
transfer of ownership: after a delayed defense, a monitor takes over address
ownership and starts defending without delay. And the other way around: if an
AIU is received, an owner becomes monitor, just to make sure we have at most one
owner.

Change of lifetime and deallocation remains a local matter, between an app and
its local mini-MAAS, both for the allocator and the passive monitors.

The only problem is to start those monitors. Let's assume that the allocator app
distributes (session announcement) both the allocated address and the lease id
returned by its mini-MAAS. Then another session participant can just ask its
mini-MAAS to start monitoring the allocation of address A with lease id L. To
make this safer, the mini-MAAS could check the lease by sending an ACLM. If it
receives an AIU with A and L, the allocation is confirmed. However, this (and
any other variation) causes additional traffic when a session starts. We could
let the mini-MAAS trust its app (a malicious app can just start sending to the
session's address at 100 Mbps without trying to allocate it and a flawed app can
do anything).

This version practically makes all session participants peers with respect to
the control of the session's address. The protocol complexity and overhead added
to the minimal version is negligible (except perhaps for the optional test when
a mini-MAAS starts to monitor). It does not solve the problem of conflict
detection in case of network partition and reunification.

Any comments?

Octavian.

---
Dr. Octavian CATRINA
International University in Germany
School of Information Technology

---

From: erik guttman <[email-masked]>
Date: Wed, 28 Mar 2001 15:07:23 -0800

Octavian Catrina wrote:

> overhead and are not justified. 

I do not think we can make this assumption.  IPv4 link-local multicast has 
only 217 addresses left: 

  http://www.isi.edu/in-notes/iana/assignments/multicast-addresses

   The range of addresses between 224.0.0.0 and 224.0.0.255, inclusive,
   is reserved for the use of routing protocols and other low-level
   topology discovery or maintenance protocols, such as gateway discovery
   and group membership reporting.  Multicast routers should not forward
   any multicast datagram with destination addresses in this range,
   regardless of its TTL.

   224.0.0.37-224.0.0.250 Unassigned                            [JBP]
   224.0.0.252-224.0.0.255 Unassigned                           [JBP]

We should eventually request a ZMAAP address from this range.

We need a range of available v4 link-local addresses that can be 
allocated by ZMAAP.  I'm not sure we can get an allocation of several 
addresses for this purpose out of the link local v4 range. See the 
definition above.  It would be great if we could - since multicast 
routers already do not forward messages with destination addresses 
from 224.0.0/24.  The most we could conceivably obtain would be 
something like 32 addresses.

We could of course attempt to get another allocation, but existing
routers would not know they were link-local!

> The basic idea is that an address allocation must be maintained as 
> long as the multicast session continues, regardless of the changes 
> in the group membership. For this purpose, the address allocation 
> should be monitored by all the participants in the multicast session 
> instead of being exclusively taken care of by the allocator (session
> initiator).

This is needed to fulfill the zeroconf requirements for mc address
allocation.

> After the allocation of the address by the session initiator, 
> other participants may ask their mini-MAAS to monitor the 
> session's address for a specified lifetime. One mini-MAAS is 
> the current owner (initially, the allocator). The others are 
> "passive" monitors. The owner and the monitors maintain allocation
> records for the address during the lifetime indicated by their 
> local app (may not be the same lifetime value!).
> 
> The owner defends the address by sending immediately an AIU. 
> A monitor sends a randomly delayed AIU if the owner fails to defend.
> 

Excellent.

> I don't like the delayed defense but we can minimize its use by 
> allowing a transfer of ownership: after a delayed defense, a 
> monitor takes over address ownership and starts defending 
> without delay. And the other way around: if an AIU is received, 
> an owner becomes monitor, just to make sure we have at most one
> owner.

Coordinating ownership is much more complicated than transmission 
timers which can be cancelled.

> The only problem is to start those monitors. Let's assume that 
> the allocator app distributes (session announcement) both the 
> allocated address and the lease id returned by its mini-MAAS. 
> Then another session participant can just ask its mini-MAAS to 
> start monitoring the allocation of address A with lease id L. To
> make this safer, the mini-MAAS could check the lease by sending 
> an ACLM. If it receives an AIU with A and L, the allocation 
> is confirmed. 

Agreed.  Note the coupling between the session discovery protocol
and ZMAAP.  Perhaps AIUs should carry SDP strings of advertised
sessions?  This would coordinate SAP and ZMAAP.

Erik

._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._.
E r i k   G u t t m a n                   Email: [email-masked]
Sr Staff Engineer, Sun Microsystems               Cell # 415 420 4425