Subject: Claim and defend

From: "Philip Nye" <[email-masked]>
Date: Mon, 17 Sep 2001 11:37:43 +0100

Hello,

I am fairly new on this list and have been following the Autoconfigure and
ZMAAP discussions with interest.

There seem to be a growing number of protocols and applications which use a
claim and defend principle for allocating exclusive numbers in a peer to
peer system. The same general principle is used in autoconfigured IP
addresses, in ZMAAP, for allocation of address space between MADCAP servers
and elsewhere. I have come across several other areas of development where I
would like a serverless way to negotiate number assignment across multiple
hosts.

Because the details differ in all existing cases I am confronted by the
probability of having to implement several of these separately in a single
lightweight product.  I find myself wondering whether some sort of
generalised number assignment protocol wouldn't be "a good thing". I
envisage a protocol which can use the same general claim and defend
principle with a different parameter set to obtain a number or range of
numbers of whatever class is required. The same protocol could then be
applied wherever this need arose.

Has this been looked at or discussed before? Does anyone else see a benefit?

Philip Nye

---

From: Aidan Williams <[email-masked]>
Date: Mon, 17 Sep 2001 22:10:13 +1000

Philip Nye wrote:
> Because the details differ in all existing cases I am confronted by
> the probability of having to implement several of these separately
> in a single lightweight product.  I find myself wondering whether
> some sort of generalised number assignment protocol wouldn't be "a
> good thing". I envisage a protocol which can use the same general
> claim and defend principle with a different parameter set to obtain
> a number or range of numbers of whatever class is required. The same
> protocol could then be applied wherever this need arose.
> 

Yes, I see a benefit.  I don't recall email to the list.  Allocation
of the number in a distributed way is reasonably straightforward.
Dealing with collisions tends to be fairly protocol/application
specific, and collisions are unavoidable when networks are joined.

As much as I like the idea, it doesn't currently fit under the
zeroconf working group charter, which says:

[ http://www.ietf.org/html.charters/zeroconf-charter.html ]:
> The WG will also produce two protocol specifications. First, the WG
> will develop a document describing automatic generation and
> assignment of link-local IPv4 addresses in environments lacking host
> configuration (static or using DHCP). The document will describe
> existing practice as well as define recommendations for future
> implementations. Second, the WG will develop a profile of the
> Address Allocation Protocol (AAP) to provide Zero Configuration
> Multicast Address Allocation support for IPv4 and IPv6.

ZMAAP would probably look different, but hey, it already looks
different to AAP..

regards
	aidan
____
:wq!

Communications and Networks Lab         [email-masked]
Motorola Australian Research Centre          phone: +61 2 9666 0649
Locked Bag 5028, Botany NSW 1455              phax: +61 2 9666 0501
Australia                            http://cnlab.arc.corp.mot.com/

---

From: Erik Guttman <[email-masked]>
Date: Mon, 17 Sep 2001 15:02:50 +0200 (MET DST)

Philip, Aidan,

> Philp Nye wrote:
> > I find myself wondering whether
> > a number or range of numbers of whatever class is required. 

Current thinking is that you want the claim and defend protocol to be
the same one which is *used* so that conflicts can be detected passively
(without periodic messages or polling to detect conflicts).  v4 LL 
autoconfiguration uses ARP for claim and defend.  It has hosts 
broadcast ARP replies so that others can see if there's a conflict.
The current discussion of ZMAAP would make it use ZMAAP for session
discovery as well as address allocation, so session discovery replies
would automatically clue in other mini-MAASs of an allocation conflict.

> > Does anyone else see a benefit?

I believe claim and defend is completely bound to the application 
protocol which it serves - if it is to be done with this elegant
'use provides maintenance' characteristic.  If no traffic exists
for a particular protocol, no periodic messages need be sent to
maintain its namespace, given this approach.

So I do not see a benefit.

> of the number in a distributed way is reasonably straightforward.

Not really if you want scalable properties.  Every problem has its
unique scoping issues and usage pattern.

> specific, and collisions are unavoidable when networks are joined.

These can be detected in an app specific way, as I noted, or using
a beackon approach (scales linearly to the number of nodes sending
the beackons - which is bad) or polling (scales linearly to the 
number of clients seeking to maintain a conflict-free namespace,
which is worse.) 

> zeroconf working group charter, which says:

I completely agree.  This will not be taken up by the ZEROCONF WG.
I encourage you (Philip) to investigate this on your own, but I am not 
hopeful about the results.

Erik

---

From: "Philip Nye" <[email-masked]>
Date: Mon, 17 Sep 2001 17:03:07 +0100

> From: "Erik Guttman" <[email-masked]>
>
> Philip, Aidan,
>
> > Philp Nye wrote:

I would see just about all of ZMAAP as being simply a special instance of
the more generalised case and would expect the lookup or discovery (session
discovery in
the case of ZMAAP) to be a part of the same generalised protocol.

LL autoconfiguration is rather different only because it is relies on a
whole lot of backwardly compatible assumptions from long before any of this
was devised.

It is my prediction that there will be more applications of the same
principle and the whole thing will have to be re-invented each time. Could
ZMAAP be turned into a more general protocol?

Meanwhile - is there a description of session discovery under ZMAAP? What
does the term mean? The only reference in the current draft seems to be to
SAP and SDP which at first glance seem rather restricted in their
application and wouldn't seem well suited to dynamic detection of address
conflicts.

Philip