constraint distribution protocol

Jon Crowcroft <> Wed, 21 October 1998 19:28 UTC

Received: from ( []) by (8.8.5/8.8.7a) with ESMTP id PAA00929 for <>; Wed, 21 Oct 1998 15:28:52 -0400 (EDT)
Received: (from smtpd@localhost) by (8.8.8/8.6.12) id PAA20674 for; Wed, 21 Oct 1998 15:28:53 -0400 (EDT)
Received: from, claiming to be "" via SMTP by, id smtpdICAa20050; Wed Oct 21 15:28:36 1998
Received: from by; Wed, 21 Oct 1998 14:54:17 -0400
Received: by (SMI-8.6/SMI-SVR4) id NAA25305; Wed, 21 Oct 1998 13:15:08 -0400
Subject: constraint distribution protocol
Date: Wed, 21 Oct 1998 07:31:16 +0200
Message-Id: <>
From: Jon Crowcroft <>
Precedence: bulk
X-Info: [Un]Subscribe to

thinking about higher level call admission and qos routing scalablity
- it seems to me that several of the neat algorithms around might
scale adequeately for qos routing provided the scope of the links and
metrics they considered for alternate paths were constrained. but then
they sould be in any case for lots of reasons (policy, higher level
call admission, fault tolerance etc)....

the problem is that  a lot of these reasons traverse inter-domain
boundariies so we cannot just split the problem in the "usual" way
between intra-domain qos routing an inter-domain - we need a seperate
scheme for distributing constraints for qos routin that is independant
of routing protocols - i am making the same argument elsewhere for a
protocol for distributing current traffic conditions to areas of the
network that don't currently share flows with the reporting region, 
and in fact the properties of these two protocols might be quite
similar - basically, they are like link state in advertisement, but
must summarise based on region, and have source, sink and transit
filtering like BGP.....

a suitable case for nimrod....