[Click] dynamic changes to a click configuration

[Mike Wilson]

Hi, all,

 	I've used click for a number of fairly typical projects - IP 
routers, tracking latency and throughput, etc.  Now I've got a project 
that I don't think fits the click model.  I certainly don't see a good
way to do it, but I wanted to double-check with the rest of the click 
community before I abandoned click as an option.

 	Picture a router with a potentially unlimited number of virtual 
interfaces of varying forms of encapsulation.  What I need is a way to
dynamically add and remove interfaces, and change the encapsulation of 
virtual interfaces on this router.  It's enough that these virtual 
interfaces only exist within click, but I've got nothing against them
also being OS-level virtual interfaces, too.  The protocols over the
virtual interfaces are not necessarily all IP.
 	For any static configuration, click is simple and easy.  I'd have 
something like this, for a 2-interface version:

FromDevice("eth0") -> Classifier(...)[0] -> Strip(...) -> ... ;
                       Classifier(...)[1] -> Strip(...) -> ... ;

 	Now if I need to add a new interface, I can't because the number 
of Classifier outputs are static.  I suppose I could use a classifier with 
a huge number of output and only map to the ones in use, then change the 
filters on the fly.  Classifier doesn't do this, but the IPRouteTable 
does, and I'm sure some of the other elements do.  However, they *don't* 
allow me to change the decapsulation in the next stage.

 	A heavy-handed approach would be to re-write the configuration 
file and kill/restart click.  Unfortunately, this loses everything in the 
Queues.  I could dummy out a kludged configuration where there are 
multiple click configs and the queuing is all in separate configurations, 
but this strikes me as increasingly ugly.  I think I'd potentially lose a 
packet in the non-queuing configurations, too.

 	The next approach is to write my own elements that just track
all of the virtual interfaces internally, applying the appropriate 
decapsulation and processing for each one.  I think I'd end up embodying 
most of the functionality from a lot of other elements in my new element, 
losing the major benefit of click -- having it all pre-written and 
tested.

 	Is this problem just ill-suited for the click model, or is there 
an option I'm missing?  The ideal would be to change the configuration on 
the fly by adding new elements, changing the intial Classifier to add the 
new element chain (and probably the queues at the far end to accept 
packets from it).  I don't think this is even in the click model, is it?

-Mike Wilson