Subject: [Forces-protocol] RE: FEM/CEM experiences

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Thu, 13 May 2004 12:54:48 -0700

Jamal,

Thanks for sharing your experiences on FEM/CEM. I think this very useful
info.

We had similar experiences. We definitely still need #2, #3 below for
FEM/CEM (Configuration of FE, CEIDs, Addrs, Security Keys,). #4 seems
implementation specific, this could be part of FEM/CEM or implementation
guidance in the protocol ? I am not so sure about #5, 5a looks similar
to #2, 5b we can do using the PL itself. For #1, as you said this
belongs to TML, so it should be standardized by the TML team. Once we
have some TML draft out, we will have a better idea about it. 

Anyways overall, this looks pretty good. May be you could just summarize
it based on the comments you receive ? Hopefully we shouldn't need to
spend too much time on this.

Thanks
Hormuzd

-----Original Message-----
From: Jamal Hadi Salim [mailto:[email-masked]] 

This is to start the discussion on FEM/CEM interface as well as respond
to my action item from the concal.

The FEM/CEM interface is used for configuration of non-protocol
specific parametrization.
In our implementation we used it for:

1) 
a) selecting the number of connections to be used. Example:
"use 3 UDP multicast + one TCP connection"
b) describing details about each of the connections. Example 
"for UDP multicast connection 1 use IP address a.b.c.d port x"

The above could be seen as TML specific now - i am not sure if that gets
rid of the need for xEM.

2) In our case an FE could be issued a set of PIDs which are
a 32 bit number with 32 bit mask. This was because there were multiple
IDs that could be allocated per FE. In the current thought process we
are saying a FE can only have one ID; however, the FE could still obtain
its ID via the FEM. Example, in one specific hardware, the FE on bootup
could discover the slotID and chassi ID it was on and pass that to the
forces s/ware via the FEM.

3) Security parameterization such as keys etc. In order to have the
forces s/ware independent, we had decided but never implemented that the
security key exchanges will happen elsewehre and the forces s/ware will
be notified of the parametrization via FEM.

4) Connection setup parametes

Example "send up to 3 association messages each 1 second apart" Vs
" send upto 4 association messages with increasing exponential timeout".

5) probably the most important piece we found:

controlling the FE s/ware and parametrization throughout the life of the
FE s/ware daemon. This is also implies FEM-CEM interface was alive
during this phase.

a) The FE may get its own paramters localy (such as the ID to use. We
however found it useful to have the FEM in continous contact with the
CEM because we could dynamically change its parameters
(example adding a new connection to scale things).
b) As well we could shutdown a FE via its FEM interface etc.

_______________________________________________
Forces-protocol mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/forces-protocol

---

From: Jamal Hadi Salim <[email-masked]>
Date: 13 May 2004 20:51:59 -0400

I dont think we should spend a lot of time on this. Just wanted to get
it out so we could have something to talk about and maybe use for draft
write up.
I have no strong disagreements with Weinings or Hormuzds comments below.

cheers,
jamal