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

From: "Weiming Wang" <[email-masked]>
Date: Tue, 20 Apr 2004 23:58:08 +0800

Hi Jamal,Hormuzd,

As said in my earlier mail, I'm ok with the scheme to use flags or inference of
other fields in the protocol message to signal transmission requirements to TML
layer, though I'm a little worry if this can meet all what we need, therefore I
highly suggest we try to compose all possible flags and point out all that may
be used for inference to see if it works well now (not later). We have actually
said something on reliability (use a flag or use the message type as tip) and
have already said somthing on multicast/broadcast, how about lets try to define
or find out others then?

Cheers,
Weiming

> From: Jamal Hadi Salim <[email-masked]>
> 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
>
> On Mon, 2004-04-19 at 23:59, Khosravi, Hormuzd M wrote:
> > 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.
>
> Lets call this technique inference-by-TML
>
> > 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.
> >
>
> 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.
>
> > 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.
>
> 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
> > 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 :)
>
> 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
> > different ways.
>
> 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
>
>

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

---

From: [email-masked]
Date: Tue, 20 Apr 2004 13:14:16 -0400

I have communicated this in yesterday's email. 
regards
ramg

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext Weiming Wang
> Sent: Tuesday, April 20, 2004 11:58 AM
> To: [email-masked]
> Cc: Khosravi, Hormuzd M; [email-masked]; [email-masked]
> Subject: Re: RE: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA]
> 
> 
> Hi Jamal,Hormuzd,
>