Subject: RE: [Forces-protocol] PL/TML Interface

From: [email-masked]
Date: Mon, 26 Apr 2004 08:47:33 -0400

Hello David,

Comments are inline.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext Putzolu, David
> Sent: Tuesday, April 20, 2004 4:55 PM
> To: Gopal Ram (Nokia-NRC/Boston); [email-masked]
> Cc: Khosravi, Hormuzd M; [email-masked];
> [email-masked]
> Subject: [Forces-protocol] PL/TML Interface
> 
> 
> Hi all.
> 
> Still getting caught up on the discussions!
> 
> The protocol design team could define a PL/TML
> API if desired.  However, since APIs are not
> currently in the charter, we would have to make
> a case to the ADs for adding it.  This might be
> tough, because an intra-endpoint API is a 
> different problem than the once ForCES protocol 
> tackles.

Agree, so far to my knowledge IETF has defined application level API's only for FTP other than socket API's.
As of now the forces has restricted usage (PL'layer).  

> ForCES protocol tackles FE/CE interoperability.
> A PL/TML API would be tackling intra-FE and intra-CE
> interop between an implementer of the ForCES PL and
> the implementer of the interconnect.   This isn't a
> bad idea at all - but the challenge would be convincing
> the ADs that a standard API is needed here.
> I'm not ruling it out - just letting you know that
> we would need to make a good case for it to the ADs.
> 
> 
> Using a implicit/PL header flags approach is also
> feasible, although I'm a bit concerned in that I'm
> not familiar with prior examples of such an approach.
> Are there other cases where a protocol had header
> fields to signal the protocol implementation on the
> same endpoint, rather than to the other end of the
> connection?  

There are similar protocols like what we are dealing here, One that is currently
worked out is  Midcom they define the message structure and payload details and 
left the transport mechanism as untouched. There focus is between on midcom elements. 
The draft states that  this message structure is generic and can be carried over 
any transport prtocol. 

Hormuzd also pointed out GSMP also seems taken the similar approach.

IMHO, We cannot mandate TML layer requirements, they are there and we need to use them as it is.
Forces PL layer can work on IP, TCP or UDP or any layer-2 . As far as PL is concerned TML layer can come and go, PL is the standardized interface point. 

My comments on your second part, another approach is that instead of passing on thro' header fields TML 
layer can be informed either via configuration or via some initial message setup.  This would be a nice 
and cleaner approach. If you see any of the services like security, HA, etc they are operated per session 
basis and passing it on each message may not be  cleaner approach.  
 
> 
> Finally, there is the option of simply handwaving
> and saying that implementers will implement the
> system such that the TML is signaled appropriately.

This is a good alternative.

IMO it will be diffcult to mandate the TML layer with set of requrirements.
PL needs to live with it whatever the lower layer provides. IMHO this will enable smooth integration (adoption)
of Forces into existing interconnects rather than complete migration.

End of comments
Regards
Ramg

> So for example:
> 
> The TML abstract definition section of the doc might say:
>   "A multicast, unreliable message-oriented service
>    is provided.  Each message delivered to this
>    service includes an indication of which recipients
>    should receive the message.  The service does not
>    guarantee reliable delivery but does guarantee
>    messages will not be corrupted and will be delivered
>    in order.  This service is intended to be used
>    for timely delivery of information." 
> 
> The PL configuration section of the doc might say:  
>   "when adding an IP route to multiple FEs, the 
>    TML's multicast,  unreliable message oriented service 
>    is used to deliver the following message to each
>    desired FE:
>      ------------------------------
>      | (list if FEid/LFBid pairs) |
>      ------------------------------
>      | new route                  |
>      ------------------------------
>    Each FE scans the list of FEids and LFBid pairs
>    to see which of its LFBs should be given the
>    new route structure"
> 
> And the Ethernet TML doc might say:
>   "The multicast, unreliable message oriented service 
>    is implemented using Ethernet broadcast as follows:
>    the PL indicates the list of FEs and passes
>    down a PDU...the TML uses Ethernet broadcast
>    and the following header listing which FEs should
>    parse the message and includes a CRC and message
>    number for ensuring non-corruption and ordering:
>      ---------------------------------
>      | FEid,                         |
>      | ...                           |
>      | FEid                          |
>      ---------------------------------
>      | CRC-32                        |
>      ---------------------------------
>      | Message #                     |
>      ---------------------------------
>      | Payload to deliver to each FE |
>      ---------------------------------
> 
> Finally, a PL implementer might implement it as a
> generic (but proprietary) API that they define and
> share with customers, e.g.
>   "FooCorp's implementation of ForCES includes a
>    TML abstraction API allowing customers to use
>    any interconnect.  The API that an interconnect
>    must support for FooCorps' implementation to work
>    for multicast unreliable connections is 
>    void FooSendMulticast(addressee_type *addrAray, 
>         messageType m)"
> (In this case m would correspond to the PL-defined
> PDU shown in the PL config section above).
> 
> Sorry to jump in to the technical discussion - 
> my original intention was to just clarify that we would
> need to go to the ADs to define an API, and to ask if there
> was precedent for using protocol header bits to signal
> within an end point (as opposed to other endpoints).
> I just can't resist a good technical discussion :)
> 
> -David
> 
> _______________________________________________
> Forces-protocol mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/forces-protocol
> 

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

---

From: Jamal Hadi Salim <[email-masked]>
Date: 26 Apr 2004 17:05:31 -0400

Going backwards and referencing a few emails 

On Mon, 2004-04-26 at 08:47, [email-masked] wrote:

> Forces PL layer can work on IP, TCP or UDP or any layer-2. As far as PL is concerned TML layer 
> can come and go, PL is the standardized interface point. 

I think if we are going to allow for interop between FE and CE, we can
assume that the TMLs although of the same type maybe written by
different people. 
In addition if you consider that infact a TML maybe a blackbox that
hides a few transport protocols (eg A TCP +UDP combo), then one can say
that it such a blackbox needs to say or be told what is needed of it.
Hence requirenments are needed.

cheers,
jamal