Subject: [Forces-protocol] PL/TML Interface

From: "Putzolu, David" <[email-masked]>
Date: Tue, 20 Apr 2004 13:54:54 -0700

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.

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?  

Finally, there is the option of simply handwaving
and saying that implementers will implement the
system such that the TML is signaled appropriately.
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

---

From: "Wang,Weiming" <[email-masked]>
Date: Thu, 22 Apr 2004 13:54:27 +0800

It also seems to me a little abnormal  to define a unit in PDU that is for local
use. If we need to choose between explicit flags and implicit fields,  implicit
is also more aceeptable to me.

Cheers,
Weiming
----- Original Message -----
From: "Putzolu, David" <[email-masked]>
To: <[email-masked]>; <[email-masked]>

Hi all.

-David