Subject: RE: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Mon, 19 Apr 2004 20:59:09 -0700

Jamal,

I see your point of view a little better now and I think I know where
the confusion is :)

Let me try and explain....

In case of ForCES, since we have said that we have different
requirements for control and data or lets just say for different
messages, you think we need to have some API to convey this information
from the PL to the TML. This is true but the API is more of an
implementation issue. The way I see this information being conveyed is
simply using the ForCES Common Header.

For example, if we decide that Messages A-X need Reliability and
Messages Y-Z need unreliability, the header the MessageType field which
will convey this info to the TML. Also, if you want to specify that this
message has to be unicast to FE 1 the FE ID field in the header will
have this information. Now whether we have an API between PL and TML of
the form,
EncapsulatePLMessage(message*) or
Send(buffer), is implementation details.

So what we need to do is define the requirements or services for
different messages or message categories such as Data and Control and
the TML designers will try to satisfy those requirements. Now, I don't
expect that there will be multiple ways of providing the same service
for a particular interconnect-specific TML...for example, the IP TML
might decide to use TCP or SCTP to provide Reliable/CC aware service,
but it will not use both. However, we don't need to get into this
discussion, since we are not on that team :)

I hope this helps...I think we are saying the same thing but in
different ways.

regards
Hormuzd

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

On Mon, 2004-04-19 at 06:23, [email-masked] wrote:
> On 17 apr 2004, at 13.51, Jamal Hadi Salim wrote:
> 
> > I am finding it very hard to say we can do multiple TMLs and not say

> > how
> > a Forces PL can use them.
> 
> I am not in favor of trying to create an PL-TML api.  I personally 
> think how these things are connected is an implementation issue.
> 
> That is why GSMP took the encapsulation route.  What needed to be 
> defined was what went out on the wire.  How the GSMP messages got to 
> the encapsulator and what if any communication existed between them
was 
> left to the implementer - I didn't expect that part of the system to 
> ever be an open interface.  And I don't expect it to be in the ForCES 
> case either.

There are really two things as i see it.

One is the media encapsulation service which you defined in that RFC.

The second is the transport services (which is more contentious in
Forces).In the GSMP case the simplicity was a result of choosing a
single transport (example TCP over IP).
In our case i may want to run both TCP and UDP and want to use different
features of each transport protocol. How do i signal selectively to the
TML what features to use?
I really dont want the API either, but i am not seeing a way out.
We could create classes templates for each TML, example "use transport x
always when you want reliability" - but at the end that would be the
same as creating APIs in terms of workload.

cheers,
jamal

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

---

From: Jamal Hadi Salim <[email-masked]>
Date: 20 Apr 2004 10:48:05 -0400

Hi Hormuzd,

To reword #3 to provide context:

JHS>3)(PL) to just send the Forces Messages with some of its flags turned on to
JHS>mean reliability on and such a message is translated (by TML)to mean send via
JHS> a reliable means.
JHS>
JHS#3 may be the API-avoidance scheme.
> 
> [HK] Exactly, #3 is what I was explaining in my last email that I just
> sent out. (Use fields/flags in the Common Header to correspond to a
> transport service e.g. TCP connection in the TML). 

I have no issues i can think of right top of my head on this. I am CCing Jon Maloy 
since TIPC is being proposed as a TML to get his PoV. Jon please chip in here.
So the above implies that the TML _infers_ what to do with the packet based on 
the Forces header or (no choice but to get into implementation details) theres 
an abstraction that takes a look at those headers and makes the correct TML calls.
I would prefer to put the burden on the TMLs instead of implementing something that
remaps to the TML. In other words this is shaping the requirements for the TML.
 
[Of course the best method is for PL to explicitly tell TML what it wants - so 
this is second best. The pro for this is reduced complexity]. 

I think the moral to all this discussion is that we now must make sure that if we are 
going in the path of inference that the main header carries sufficient information
to be usable by the TML. So it was not a total waster of time to go through this 
pain ;->

More below

> simply using the ForCES Common Header.

Lets call this technique inference-by-TML

> Send(buffer), is implementation details.

This is fine with me. Lets say explicitly if we want to use
inference-by-TML and we can move on. I would like to hear Weimings view.

> the TML designers will try to satisfy those requirements. 

I think the standard protocol requirements we have should suffice.
How they get signalled is the next step we should discuss. You seem to
be saying by message type; i think the better way to do it is probably
using flags

> Now, I don't

Sure, we just treat the TML as a blackbox. The main header can signal
what service we want out of the TML and the PL should be agnosric if
that service is delivered over avio pigeons or ATCA data fabric.

> I hope this helps...I think we are saying the same thing but in

I think we are getting close; from this we can derive more the
requirements on the TML and what to go on the header.

cheers,
jamal