Re: server-to-server protocols

Kim Kinnear <> Wed, 16 April 1997 18:27 UTC

Received: from cnri by id aa13440; 16 Apr 97 14:27 EDT
Received: from by CNRI.Reston.VA.US id aa17696; 16 Apr 97 14:26 EDT
Received: from by; (5.65v3.2/ id AA09483; Wed, 16 Apr 1997 14:17:40 -0400
Date: Wed, 16 Apr 1997 14:17:40 -0400
Message-Id: <>
Precedence: bulk
From: Kim Kinnear <>
To: Multiple recipients of list <>
Subject: Re: server-to-server protocols
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: Discussion of DHCP for IPv4

Erikas said (concerning using SNMP as a transport for the server-server

> * Addresses available for leasing on any given subnet. This probably
> needs some way of ensuring that addresses are handed out only by one
> server at a time, but ideally could distribute the available addresses
> amongst the servers automatically (or so I would think at least). In
> theory, you could put a new server into an existing mix and it would
> automatically pick up address space from the others if permitted. The
> trick here is figuring out what to do about the address space when a
> server is partitioned (intentionally or unintentionally) from the
> network. If we don't do this, it simply degenerates into a case where
> the address blocks are allocated manually on each server (losing load
> balancing).

Kim commented:

	Exactly.  The ALT draft handles this partition case, and we
	plan to keep that approach in the combined 02 draft that
	Bob Cole, Ralph Droms, and I are working on.
> * Dynamic client binding information. This goes back to the desire to
> have redundency in leases between the servers so in the case of a failed
> server or a network partition, clients can reestablish their existing
> leases with a different server. Ideally, we want the basic information
> propagated out (push) to all servers as quickly as possible (SNMPINFORM)
> with the capability for a newly bootstrapped (hmmm) server to pull over
> all the leases at once (SNMPGET / SNMPGETBULK). We probably don't want
> to wait on a SNMPINFORM before responding to a request, so it makes more
> sense to give someone an address, then update the servers.

	I'm far from expert on SNMP.  I'll clearly be doing some more
	research soon, but let me ask you some (possibly stupid)

	1. Using SNMPINFORM can one send information about multiple
	happenings in one message?

	2. You mention that SNMPINFORM is reliable.  Is that more than
	simply a request->response pair?  
> * Static client binding information. This is just a subset of the
> dynamic case, although there might be a slightly different application.
> In theory, you could have a machine which "seeds" your server farm with
> static address allocations like a bootptab file might do on a server
> today. In our environment (semi-isolated case), we could have our
> database directly talk the server-to-server protocol to distribute
> static bindings and dynamic address allocations, but not have it be a
> DHCP server at all. (We currently us AFS to copy files between the
> database machine and our server machines which, frankly, isn't the
> greatest solution.)

	Certainly having non-serving members of a DHCP server-server
	protocol group is a neat idea that is currently also in the
	ALT draft and that I think we'll keep (since we'd have to 
	try hard to prevent it, and that would be foolish).
> As I mentioned in the working group, we currently have a network
> monitoring system based upon SNMPINFORMs as a transport. The different
> "modules" of the system communicate with each other via SNMPINFORMs,
> thereby passing network event information around. It works pretty well
> and is pretty stable. It's fairly simple to extend the basic model to a
> DHCP environment instead.

	Do you have *any* information as to the performance, actual or
	potential, of this approach?  One of my concerns about SNMP is
	that its complexity may limit the ultimate performance of the
	protocol and thereby create a server-server protocol that
	doesn't scale well.

	While we haven't set firm goals yet, I believe that we need to
	be able to support DHCP servers with >100K IP addresses
	(probably *much* greater than 100K).  We need a protocol
	architecture that will support servers that are required
	themselves to handle at *least* 50 and more likely 100-200
	transactions/sec.  But this is another good topic for the list,
	I guess.

	(To be clear, I'm not saying we can do 200 transactions/second
	today, but that I don't want the server-server protocol to be
	the reason that we can't get there tomorrow!)

> Anyway, I've rambled enough about things that others have probably
> already mentioned but haven't yet entered into my stream of
> consciousness... :-)

	Thanks for raising the issue -- better we figure it out now
	than later -- after we've already done all of the work going in
	another direction.

	Cheers -- Kim