Subject: Re: Multiple CEs talking to the same FE

From: Robert Haas <[email-masked]>
Date: Mon, 14 Feb 2005 19:08:49 +0100

Coming back to implementation issues that fire up in the protocol:

In the case of a single active CE, there can be multiple processes 
"hiding" behind the same CE ID, i.e., a process updating firewalling 
rules and another process updating the routing table, in parallel. We 
must be able to:

1) correlate at the CE the responses from the FE with the commands that 
were originated by each process.
2)  forward at the CE FE-event notifications to the appropriate 
processes that registered for it.

So if the CE ID is the same for all these processes, something is 
missing in the protocol  to support 1) and 2) ... Unless the ForCES PL 
decides to use different TCP/UDP ports for each process (I wouldn't 
recommend this), but this will anyway not solve 2).

BTW, the multi-CE problem is something one should still think of while 
defining the model. Although the requirements draft only talks of a 
single active CE for each FE, it is a scalability issue if I can't run 
the firewalling and routing processes on two different boxes (i.e. two 
CEs). So let's at least consider the impact of the multi-manager problem 
on the model so we don't close all the doors for future support.

Regards,
-Robert

Joel M. Halpern wrote:

> I thought we had agreed that for now we would focus on a single active 
> CE per FE>  An FE that wants to be managed by several CEs is (I 
> thought) to pretend it is several FEs, probably with distinct resources.
>
> The multi-manager problem is very very messy.
>
> The demultiplexing is a valid issue anyway.  I think that the answer 
> is probably that one should use different ports if one is going to run 
> several CEs (or FEs) on the same machine / interface.  I am not sure 
> we can / should introduce an extra demux layer for the "native 
> ethernet transport" case.
>
> Yours,
> Joel
>
> At 11:25 AM 1/12/2005, Robert Haas wrote:
>
>> Here are some considerations around many CEs talking to the same FE, 
>> based on early implementation experience:
>>
>> Associations: Multiple CEs may access the same FE, for instance to 
>> accomplish different tasks, such as routing, security, QoS. These CEs 
>> may each run in a separate machine, or they may share the same 
>> machine. So there is an association for each (CE-FE) pair. Or do we 
>> consider associations to include more than two members ? Note that 
>> multiple associations may share the same TCP/SCTP/... connection.
>>
>> Demultiplexing: Note that in the case where multiple CEs run on the 
>> same machine, the CE ID can be viewed as a demultiplexor. The ForCES 
>> protocol does not otherwise include correlators that would enable 
>> callbacks to the appropriate CE on the response to a ForCES command 
>> (or reception of an event).
>>
>> Access conflicts: The framework draft specifies that CE 
>> synchronization is beyond the scope of ForCES. This means that, for 
>> instance, two CEs changing the same LFB attribute value, is not 
>> viewed at the ForCES level as a conflict. But if two CEs try to 
>> perform interleaved 2-phase commit operations on the same attribute, 
>> then ForCES should of course prevent it and report it.
>>
>> Event reporting: If multiple CEs subscribe to different events in an 
>> LFB, then the LFB must somehow know to which CE(s) events must be 
>> fired. I propose that a list of interested CE IDs is associated with 
>> each event attribute in the LFB.
>>
>> Regards,
>>
>> -- 
>> Dr. Robert R. Haas
>> IBM Zurich Research Laboratory
>> Säumerstrasse 4
>> CH-8803 Rüschlikon/Switzerland
>> phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha
>
>
>

-- 
Dr. Robert R. Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha

---

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Tue, 15 Feb 2005 17:18:55 -0800

Robert, 

-----Original Message-----
From: Robert Haas [mailto:[email-masked]] 

How far did you go with your implementation of demuxing ? In our case, 
we found that relying on sequence numbers or message types is not useful

when you want to direct an event notification coming from the FE to the 
appropriate process in the CE. But maybe you found a way to solve that ?

[HK] You could use a couple of approaches here. One you could send
events to all processes and let them decide on which events are relevant
to them. Or, you could use the LFB IDs in the Event messages to demux
between the different processes, in this case your shim layer will have
more intelligence.

Regards
Hormuzd