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

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Fri, 16 Apr 2004 13:29:01 -0700

I think you should continue reading this and try to understand their
approach.
(For example, in case of IP, TCP is used to deliver the transport
service)

They achieve the same goal using encapsulation headers, its very similar
to what the TMLs are trying to achieve,

Let me know what you think

regards
Hormuzd

-----Original Message-----
From: Jamal Hadi Salim [mailto:[email-masked]] 
Sent: Friday, April 16, 2004 1:20 PM
To: Khosravi, Hormuzd M
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: RE: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA

On Fri, 2004-04-16 at 11:10, Jamal Hadi Salim wrote:

> > Any particular GSMP RFCs/drafts? 
> > [HK] See RFC 3292, RFC 3293. The 1st is the protocol and the second
is
> > the TML approach, i.e. encapsulations defined for different
> > interconnects. 
> 
> Thanks; i just printed them to study them later.

Hormuzd, I just looked at RFC 3293 and briefly at 3292 i cant see the
relation to a TML. 
All 3293 does is encapsulate; none of the transport "services" are
really delivered to the GSMP layer.
Should i continue reading or is this pretty much covering it? ;->

cheers,
jamal

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

---

From: Jamal Hadi Salim <[email-masked]>
Date: 17 Apr 2004 13:51:00 -0400

> Let me know what you think

I have read enough i think and i dont see a good relation (in my
thinking at least). In our case there may be for example more than one
socket in a TML which may be used for different reasons. What GSMP
transport level does is simple encapsulation first. The fact that
reliability exists for example may is secondary.
Lets say you even said "this TML provides both reliable and unreliable
unicast transport" then dont you think the PL at least needs to know how
to use either one when it chooses to?

On Fri, 2004-04-16 at 21:31, Weiming Wang wrote: 
> 
> I agree APIs are very useful for customers with their ForCES system design,
> especially I think they are good for CE side design, but I also feel it may be
> not the very time to standardize it currently in the ForCES protocol document.
> Maybe it can be considered as a specific Informational document later,  just
> like others do.

I am finding it very hard to say we can do multiple TMLs and not say how 
a Forces PL can use them. 

> For those TML requirements you listed currently, I think we can just define FE
> attributes for TML policies (like TML reliability policy, TML link mang. policy,
> TML security policy, etc) and some metadata (such as for priority)  to meet
> them.  I think it's better currently to treat the TML as a blackbox,  though
> some of the grey part in the box always looks so attractive.

I think if we can define it from an API level, it should be easy to
translate into a protocol message. 
The way i see it so far the major major difference between all proposals
has been how transportation should be handled. We agreed to the TML.
There has to be a way to hook up to the TML, no? In other words this
seems to be a fundamental requirement. 

I realize the complexities involved of having not just PL-PL but also
PL-TML interface definition, but so far i see nothing convincing to say
we can only have one interface. The way i see it, even if you just had
one CE and one FE, theres possibility of three implementors: 1) the TML
implementor. I think the same TML has to run on both CE and FE.
2) the FE PL implementor 3) the CE Pl implementor.
Of course this is a worst case scenario, the simplest is one implementor
for all three.
Note to both Hormuzd and Weiming: I dont want to go this path if i can
avoid it. 

cheers,
jamal

---

From: [email-masked]
Date: Mon, 19 Apr 2004 06:23:54 -0400

> 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.

a.

---

From: Jamal Hadi Salim <[email-masked]>
Date: 19 Apr 2004 07:48:52 -0400

> ever be an open interface.  And I don't expect it to be in the ForCES 

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

---

From: "Weiming Wang" <[email-masked]>
Date: Mon, 19 Apr 2004 23:48:24 +0800

Hi Jamal,

I'm trying to propose some more of my ideas on the TML-PL as below, hoping to
find the difference between us. Actually now what confuse me the most is where
in hell is the difference between our ideas. Pls excuse me that i just try to
rush out something, which therefore is very very incomplete.

I think the description for the TML model (take TML at FE side as an e.g. first)
may include following items:

1. TML capability
From the protocol layer, this item looks as an FE capability attribute, which
can be queried by CE.

TML capability may include elements like:
. Connection ID
. Connection Type, such as TCP, UDP, IP, TIPC, etc.
. Connection Capability, such as bandwidth, etc.
. Allowed/Supported Connection QoS policy (or Congestion Control Policy)
. (more TBD)

Note that, CEM and FEM act only at the TML capability layer, that is, what CEM
and FEM do is only limited to setup enough capability for PL to use. For e.g.,
the Connection ID will be assigned by FEM, therefore PL will not pay any
attention to things like connection physical addresses. The TML capability may
change even after it has been setup first by CEM and FEM. The TML event
described below will be responsible to report such changes.

Also note that the TML capability at the FE side can surely be queried by CE,
while for FE itself, we always suppose it surely know everything about the TML,
therefoe PL in the FE will know all these capability without any information
exchange between PL and TML in the FE.

2. TML attributes

There are several TML attributes, by which CE and PL at the FE side can use the
TML resources.

1) Attribute for TML usage policy
This is actually an attribute to tell FE how to use the TML connections based on
the TML capability. It may include information like:
. Connection ID to use
. Connection QoS policy
. Connection fail policy
. (more TBD)
The attribute is to tell things like 'for message type xx(or just the response
to this message), use connection xx with connection QoS policy xx'.

2) (more TBD)

3. TML event
The TML event is usually used to report the TML capability change, which also
include the failover of connections.

Jamal, what I wrote above actually also tried to answer your questions in your
reply below to Avri.I have been trying to understand your idea all the time. I'm
not sure if we have a very basic different viewpoint on TML, that is, it seems
you may more like TMLs both at CE and FE side be defined universally, while I
(also Hormuzd, Avri, etc) may only pay attention to the TML at the FE side,
because we may think that the definition of TML at CE side is out of the scope
of ForCES protocol.  Another difference may be that you seems like to have TML
in FE also be able to be controlled by FE itself, while we consider TML control
mainly based on master-slave mode, that is, TML at FE side is controlled by CE.
Pls excuse me if i misunderstand your idea. If it is, I suppose we may need to
discuss the architecture first instead of using API or not. Hence, I also
suggest we may start your proposed "expected architecture' topic by defining a
model for TML first, because when we try to model TML, we may have things become
more clear. I'm now thinking about how the TML model would look like. Maybe
several days later I can post something on it.

Sincerely,
Weiming

----- Original Message -----
From: "Jamal Hadi Salim" <[email-masked]>

---

From: Jamal Hadi Salim <[email-masked]>
Date: 19 Apr 2004 16:31:13 -0400

Weiming,

> rush out something, which therefore is very very incomplete.

Thanks for putting this effort. As long as we have somewhere to start,
things can be refined.

> From the protocol layer, this item looks as an FE capability attribute, which

yes.

> TML capability may include elements like:

Do you mean the PID? There could be multiple connections per TML. It
would still be useful to have connection IDs but only for (TML)internal
use to just track multiple connections whereas PID has a protocol level
semantic.

> . Allowed/Supported Connection QoS policy (or Congestion Control Policy)

Would you say that the above is valid for each connection as opposed for
each TML?

> described below will be responsible to report such changes.

Note that the simplest xEM is a config file read on startup.
But i certainly agree that the scope of the xEM is the TML.
Also note that to be precise, the config actually happens 
from CE(TML at CE?)->CEM->FEM->TML(at FE)
Infact the first thing probably the config should do is say
"use TML #3"

> Also note that the TML capability at the FE side can surely be queried by CE,

Sure.

> exchange between PL and TML in the FE.

Now you loose me. How will the PL in the FE know about all these
details? Maybe you mean it wont care about these details?

> There are several TML attributes, by which CE and PL at the FE side can use the

I can see CE using this; how does FE-PL use it? 
Unless you want to have the FE-PL be smart enough to make transport
decisions? 

> the TML capability. It may include information like:

Same questions as in #1

> to this message), use connection xx with connection QoS policy xx'.

This is a hard one. It is best to not even exchange such details and
have them hardcoded within the TML.  I am assuming that if a TML has
been defined we already know what to do when we want to reliably deliver
a message (i.e TML has the knowledge embedded in it)

> include the failover of connections.

Event is needed, we can datafill that later.

> you may more like TMLs both at CE and FE side be defined universally,

TMLs i dont see as being very different whether they reside at the CE or
FE in terms of overall behavior. The PLs would behave differently for
sure.

>  while I
> of ForCES protocol.  

what is out of scope is a CE-TML talking to another CE TML (or FE-FE). 

> Another difference may be that you seems like to have TML

Lets take an example of CE-PL sending a message that requires a reliable
delivery; assume we have a UDP and TCP connection in the TML:

I would like to send such a message from the PL level via the TML with
some indication to the TML that this message needs to be delivered
reliably (obviously via TCP in this example). Clearly it is cleaner for
the PL to have no clue that the TPC connection is being used.
2-3 ways i could do it:
1) call a speacial function[1] which is translated by the CE-TML to mean
send via TCP
OR
2) call a generic function[1] with flags turned to say "reliability
needed" and the TML translates this to mean send via TCP.
OR
3) just send the Forces Messages with some of its flags turned on to
mean reliability on and such a message is translated to mean send via
TCP.

#3 may be the API-avoidance scheme.

> several days later I can post something on it.

Lets start with the above example i have and see if it is resolvable.

cheers,
jamal

[1] could be a protocol message in the PL-TML interface