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

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Thu, 15 Apr 2004 16:04:51 -0700

Resending since I received an error.

-----Original Message-----
From: Khosravi, Hormuzd M 
Sent: Thursday, April 15, 2004 11:20 AM
To: [email-masked]'
Cc: [email-masked]'; [email-masked]'
Subject: RE: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA

Jamal,

Thanks for your comments...my replies below.
-----Original Message-----
From: Jamal Hadi Salim [mailto:[email-masked]] 

> True on introducing more complexities - not sure i agree on the
> "unwanted" part. Maybe this is something that we need to decide on
first
> before moving forward. Do we wanna say it that Forces can work only on
> the spefic TMLs? 
> 
> [HK] No we don't, but that doesn't mean we need to define and
> standardize an API. Look at GSMP for example, it doesn't define an API
> but can still function on multiple TMLs. Why cant we use a similar
> approach ?

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. Do you see TMLs as something more than a layer to
abstract interconnect details and provides certain services to the PL
above ?

> > The interfaces between the layers is completely implementation
> > dependent. 
> 
> I think it may be beyond "implementation" specific now that we have
> decided to go TMLs, no? I still would like our customers to use their
> own TMLs as long as they provide "services" to the PL layer for the
> items you mention: reliability, congestion control, security, HA etc.
> Infact in their own private environment i would like to care less if
> they present those services to the PL layer or not. Seems to me like
> this would provide greater spread for Forces.
> 
> I believe we need to decide on this issue before moving forward.
> 
> [HK] Sure your customers can use their own TMLs, infact that is the
> idea. But as you said, what is important are the services or
> requirements for TMLs such as reliability, etc.
> 

Right, but exposing the abilities of the TML to meet the desires of the
the PL needs an interface defined.

[HK] In some cases, yes you need and interface...but there can be
implementations which don't have a clean interface. I am not opposed to
APIs or interfaces, infact we have them in our implementation...but I
don't see the value of standardizing them or this team defining them.
The reason for separating the PL and TML was 2 fold, 1. to allow fast
progress on both in parallel, 2. to allow defining multiple TMLs for
different interconnects. If we start defining interfaces, my fear is
that we defeat the 1st reason. Also, unless you think that separate
vendors will be implementing TMLs and PLs, there is no need to
standardize the interface. Am I missing something here ?

> 
> [HK] Sure the layering will need an API in some implementations, but
we
> don't need to define those APIs. Lets leave this to the vendors who
> implement the protocol. In any case, do you really think we can
> standardize APIs in the IETF ?
> 

We need to define an interface that TMLs can attach to (or looked at
from the other side PLs can attach to). 
Whether its a protocol between TML and PL(TCP would be fine to me) or an
API is not as important - the important piece is an agreement that such
an interface is needed to begin with.
I dont think the IETF is adverse to standardizing on some sane APIs
when it is sensible; example:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-08.txt

[HK] Sure, it makes sense in case of SCTP sockets...I really don't think
its needed in our case....What do others think on this issue ??

I think its important to resolve this issue to move forward.

Regards
Hormuzd

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

---

From: [email-masked]
Date: Mon, 19 Apr 2004 09:40:18 -0400

Hello Jamal, All,

Comments are inline.

> From: ext Jamal Hadi Salim [mailto:[email-masked]]
> Sent: Friday, April 16, 2004 11:41 AM
> To: Gopal Ram (Nokia-NRC/Boston)
> Cc: [email-masked]; [email-masked]; 
> Weiming Wang
> On Fri, 2004-04-16 at 05:08, [email-masked] wrote:
> 
> > Instead of defining the TML layer API if we specify the 
> required functioanlity what is expected 
> > from PL that's a good starting point.  Defining API's may 
> make sense if more there are many potential
> > applciations going to use the TML directly, current ForCES 
> PL is the one which has this requiements.
> 
> Note, could be an API or protocol (Refer to my last email to Hormuzd 
> on this). There could also be more than one PL using the same TML.
> I agree with you a good starting point is defining what services
> are to be provided by the TML to the PL.
> Clearly, the most important one is transport and all its aspects.
> Also clear that the PL should have a say in the degree on how those
> services are provided. Again, this is valuable if you are able to
> request at a per packet level.
> >From an API perspective (could easily be mapped to a simple protocol
> over TCP for example), i see:
> 
> =>open(): connects a PL to a TML
> => close(): disengages PL from TML
> => read(): PL reading from TML
> => write(): PL writting to TML
> => event(): dont want to talk about poll/select() - TML notifying PL
> => ioctl(): PL controlling something within a TML (eg you 
> could fit both
> a bind() and connect() like call here, also things like a "move"
> operation from PL->TML etc).
> 
> 
> > One clarification ... because its confsuing from the emails...
> >   
> > If we are going to define the API for TML layer(top half), 
> then ForCES message structure what we have 
> > been discussing becomes the part of the TML layer (bottom 
> half). Then ForceS PL layer (bottom half)becomes implementation
> > specific all it has to do is invoke those TML (top half) 
> API's. Then it becomes the repsonsibility of the TML bottom half
> > to transform those API data strcuture into the ForCES 
> message format...  
> 
> Yes, i think it becomes a blackbox how the TML does things. There may
> be some things where it may be more of grey than black box; example is
> what you mention above on encoding where the possibilities I see are:
> 
> 1) raw mode: TML creates and fills all the headers
> 2) medium mode: PL creates the headers and partially fills 
> some headers.
> TML adds the rest of the headers. 
> 3) cooked mode: PL is responsible for headers
> 
> [..]

<RamG>

We already have several configuration options... unessary and extra configuration may make the 
protocol useless.

If there is a strong requirement as you pointed out  - my opinion is that instead of having several 
options between PL and TML as we were clarfiing here.... between TML and PL . Let us make the TML and PL simpler
with less to do configuration, may be have an at TML (top half)API irrespective of the mode of operations and then TML
layer (bottom half) handles the messages. This makes the definition and configuration simpler and will work in any mode.

Any opnion?
<RamG>

Regards
Ramg

> 
> > <RamG>
> > 
> > As mentioned earlier..
> > 
> > SCTP and TCP has wide application usage, there is clealy companies 
> > involved in providing stack and companies involved in
> > developing applications. 
> > 
> > Where as in TML and PL case, the requirements are ForCES 
> specifics, no 
> > applications other than ForCES have 
> > such requirements. IMHO, if we specify only the 
> requirements and leave 
> > the adaptation (implemenation open) will be a good
> > idea. 
> 
> I think we need some minimal interface; however i havent looked at the
> GSMP RFCs maybe theres something clever there.
> True that this will add one more twist, but i am not sure how to avoid
> it.
> 
> cheers,
> jamal
> 
>