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

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Tue, 20 Apr 2004 19:48:18 -0700

Hi David,

I am fine with the hand waving approach as well that you have described
below.
Actually, I wont call it hand waving since we will have text in the PL
which will clearly state which service will be required for which
messages. This approach will definitely help us make quick progress on
the PL design.

What do others think ?

Thanks
Hormuzd

-----Original Message-----
From: Putzolu, David 

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

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

---

From: [email-masked]
Date: Wed, 21 Apr 2004 14:18:17 -0400

that is the approach I recommend.

a.