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

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

I agree with Alex. The FE ID should map to the FE, for the purposes of
the protocol. 

If the FE implementation has some kind of process (daemon, or whatever)
that is handling incoming messages addressed to that FE to either
process or distribute, that should not be exposed by the protocol. The
protocol should not dictate or restrict implementation choices where
possible.

It is not even clear that an FE ID is needed in the protocol. For most
underlying transports some destination identifier (IP address, MAC or
whatever) is part of the transport header. Assuming only one FE is
associated with that destination, an FE ID might not be necessary in the
ForCES protocol header.

Regards,
Ellen

-----Original Message-----
From: Alex Audu [mailto:[email-masked]] 
Sent: Wednesday, March 10, 2004 2:57 PM
To: [email-masked]
Cc: Deleganes, Ellen M; [email-masked]
Subject: Re: [Forces-protocol] Issue 0: Application addressing

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.

Jamal Hadi Salim wrote:

>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
>
>
>_______________________________________________
>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: 10 Mar 2004 18:26:49 -0500

> protocol should not dictate or restrict implementation choices where

You can use a single ID. 
Think of a machine that is proxying for several non-intelligent
FEs. It would have more than one ID. This has nothing to do with
implementation enforcement. An implementor could decide to run
one or more daemons.
The same applies to some variants of a partitioned FE.

> associated with that destination, an FE ID might not be necessary in the

Missing the ID is enforcing an implementation; i.e there can only
be a single daemon running.
Refer to what i said above on the proxy.
The protocol should not have to do anything speacila to identify
proxies.

cheers,
jamal

---

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

Well, one good use of the FEID is to make life easy for the protocol 
when managing
resources. For example, if the CE has to interact with 10 FEs, the CE 
might  need to create
10 FE objects with sequential IDs (say 0-9).  Each object hides all the 
details of the FE
addressing.  It  is a lot easier for the CE to match FE ID 2  to the 
corresponding object, for example,  than it is to map IP address  
123.345.456.034. I mean, comparing an integer
is much easier and quicker than comparing a string.  Again, this impacts 
protocol speed.

Regards,
Alex.

---

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

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.

Regards,
Alex.