Subject: [Forces-protocol] Issue 0: Application addressing

From: "Deleganes, Ellen M" <[email-masked]>
Date: Wed, 10 Mar 2004 10:58:10 -0800

Jamal,

I am still trying to understand the value of the extra layer of
abstraction (application addressed by the PID) for addressing purposes.
This implies that the FE capabilities are reported to the CE need to be
expanded because in addition to the LFBs and topologies the FE can
support, the CE also needs to understand the mapping of the PIDs to the
applications on the FE, and which applications are responsible for which
LFBs. Otherwise, the CE would not know which PID it needed to send a
message to in order to configure an LFB or set of LFBs. The CE could
address the LFBs directly through the schemes being proposed on the
list.

In some schemes, using a PID could be less efficient. For example, if
you happen to want to configure all LFBs on the FE of a certain type the
same way, this could require more messages using the PID-based scheme.
In the case where multiple applications are controlling LFBs that belong
to the same class, then you would have to send a message to each
application. In the direct LFB addressing scheme, you would probably
only have to send one message indicating the LFB type. I believe this is
also a similar argument that Weiming was making in a previous email.

For the purposes of configuring and controlling LFBs, I don't see the
value of the PID. Perhaps you can elaborate further.

Regards,
Ellen 

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

---

From: Jamal Hadi Salim <[email-masked]>
Date: 10 Mar 2004 17:02:33 -0500

Ellen,

> abstraction (application addressed by the PID) for addressing purposes.

To be clear there is no extra layer of abstraction.

> applications on the FE,

The CE needs to know which IDs it has allocated to which FE.
It would allocate more than one.
What application uses what ID on the FE is upto the FE.
Same with how IDs are used on the CE.
An app on a FE with ID1 can talk to an app on CE with ID2
(not unlike a TCP app on port1 can talk to a TCP app on port2).

>  and which applications are responsible for which

Addressing LFBs directly is an NPFish approach. I dont have a problem
with it. I just want to generalize it. For this reason i refer to
to the consumer of the destination ID as a target or app instead of LFB
or LFB proxy etc.

> value of the PID. Perhaps you can elaborate further.

Ok, let me explain this again just for sync purposes:

Actually let me use one of the notations Weiming posted to do this.
[FE ID: LFB ID: LFB Instance ID];

*FE ID will be mapped possible to a process of some sort. FEID IS NOT a
OS PID rather an identifier of where to send the message once it hits
the FE. I see this as something that sits on the main header. 

*LFBID maps to the type of LFB; example "TB rate meter". This may sit
in the main header. But that decision is based on what the general case
would turn out to be. I can discuss this later with you.

*LFB Instance ID: maps to a specific instance of LFB eg an instance
of TB rate meter - typically this maps to a table index. This really
doesnt belong in the main header; unless someone has some good reasons
for it to be there.

I am gonna stop there to make sure we are in sync.

cheers,
jamal

---

From: Alex Audu <[email-masked]>
Date: Wed, 10 Mar 2004 16:57:05 -0600

Jamal,

NO! FEID doesn't map onto a process. It maps onto a physical device: an 
FE.  There
is only one object  instance of this per physical FE.   Why would we map 
this to a
process????

Regards,
Alex.

---

From: Jamal Hadi Salim <[email-masked]>
Date: 10 Mar 2004 18:18:57 -0500

> is only one object  instance of this per physical FE.   Why would we map 

I have a feeling your opinion of the FEID is some static configuration
identifier, perhaps related to a slot number and geographical location
within a room or two. Is this accurate? This is still valid and does not
preclude anything i said so far. The hardware id is within the 32 bit
number and definetely part of the FEID. 
 
cheers,
jamal

---

From: Alex Audu <[email-masked]>
Date: Wed, 10 Mar 2004 17:37:56 -0600

What I am saying is there  should be no ambiguity as to which FE an FEID 
maps to.
An FEID maps to one and only one FE instance.  There should be no other 
interpretation
of this FEID.  At least I don't see a use case for what you are 
proposing. May be you can
explain some more,..

Regards,
Alex.

---

From: Jamal Hadi Salim <[email-masked]>
Date: 10 Mar 2004 19:03:53 -0500

On Wed, 2004-03-10 at 18:37, Alex Audu wrote:
> What I am saying is there  should be no ambiguity as to which FE an
> FEID maps to.

There is none. 

> An FEID maps to one and only one FE instance.  There should be no
> other interpretation
> proposing. May be you can explain some more,..

Actually let me throw that at you instead; you said:

On Wed, 2004-03-10 at 18:45, Alex Audu wrote: 
> A machine that is proxying for multiple FEs should be transparent to
> the protocol. This is 
> important for interoperability. In short, how the message gets routed
> to the FE of interest
> should be transparent to the protocol.
> 

So is this machine an FE, an FE proxy or what?
Do you have multiple FEIDs destined to it or do you have a single one?
The protocol is still using only the ID field (i dislike the FEID naming
for this reason - its an ID). In other words no extra header info is
needed. 

cheers,
jamal