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

From: Jamal Hadi Salim <[email-masked]>
Date: 09 Mar 2004 09:08:24 -0500

On Tue, 2004-03-09 at 08:33, Wang,Weiming wrote:
> Jamal,
> 
> Actually I have understood what your Src. ID and Dest. ID is refered to
> even before you put this email.  In one word, your IDs (actually are
> PIDs) are in fact mapped to PIDs of FECxs. 

This is correct. How that is done is implementation detail.

> When I carefully read your
> approach,  it just seems to me that there may be some limitation to use
> such an addressing scheme.  Let's say there are two LFBs LFB1 and LFB2,
> which in your scheme are belong to two different threads FEC1 and FEC2.

A FEC can service zero or more LFBs as i mentioned in the last email.

Look at xEC as something that will control an "atomic service".
An atomic service could be an OSPF implementation at the CE and an
hello offloader at the FE. In such a scenario, there are zero LFBs
being controlled by the FEC.
[Note i am refering to an LFB in this sense as an entity that is
on the datapath]
The example for multiple LFBs that i gave is the "IPV4 forwarder"- for
this specific FEC you can have it control multiple LFBs ranging from
Qos schedulers to nexthop entities, etc.
So to just correct what you are refering to above: there is not 
a FEC for every LFB.

> Now we need to address the two LFBs in one ForCES message, then I'm not
> sure how this will be implemented in the PID based scheme? Will the two
> LFBs be defined as a group then can be addressed at the same time or any
> others? 

Refer to my note above, the FEC controls an atomic service.
Given my example above, are you refering to sending one
message to both the hello-offloader and IPV4 forwarder?
When would this be useful?

> Actually, GRMP (I suppose FACT also) can deal with this such
> case very easily. It's true that GRMP uses quite the same addressing
> method as FACT.  The FE ID should be put in the message header,  so that
> the ID is only used to tell which FEs the message will go, while leaving
> further addressing tasks to be implemented by the FEs themselves. Are
> there any limitations for such an addressing way?

This does not leave out further addressing of the LFBs embedded within
the TLVs for a specifc LFB. I believe we are in agreement there.
I may have assumed this so didnt communicate properly.
Example a port LFB could further be mapped to an ifindex; a meter could
further be mapped to an index, etc.

Infact, the scheme i described has absolutely nothing to do with
netlink2. Rather it is an implementation experience i was sharing.
It does make a lot of sense if you think of Forces as distributed 
Inter process communication (which it is). 
Note that the scheme was initially suggested by Joel Halpern
in the mailing list; i just came to the same conclusion the hard way - 
via experience.

cheers,
jamal

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

---

From: "Wang,Weiming" <[email-masked]>
Date: Tue, 9 Mar 2004 21:33:17 +0800

Jamal,

PIDs) are in fact mapped to PIDs of FECxs. When I carefully read your
others? Actually, GRMP (I suppose FACT also) can deal with this such

Best regards,
Weiming

----- Original Message -----
From: "Jamal Hadi Salim" <[email-masked]>
To: <[email-masked]>
Sent: Monday, March 08, 2004 9:03 PM
Subject: Re: [Forces-protocol] Issue 0: Application addressing

> Hormuzd, Weiming,
>
> Apologies for long email; i am attempting to respond to two emails in
> one.
>
> Ok, let me provide an example of an FE (same concept applies at
> the CE).
> Heres a diagram that may help to clarify what i have been refering
> to; note that netlink2 did not start like this, however over
> time implementation ended being like this; this shows an FE
> side implementation. I have attached the two diagrams so they
> dont get mangled.
>
> Figure 1. shows the netlink2 manager ( a s/ware daemon) managing
> two socket connections on the lower side labelled as wire0 and wire1
> and entities called FECs on the upper side.
> Figure2 shows the role of the FEC; it MAY manages one or more LFBs.
> The communication mechanism used there is again beyond the scope of
> ForCES.
> Messages arriving at either of the sockets could end up in two sorts
of
> general classes of destinations:
> 1) for the FE - in which they are serviced by the netlink2 daemon.
> 2) for any of FEC0 to FECx; in that case the netlink2 daemon
multiplexes
> them to those entities.
>
> Although i only list two classes, there could be more - but thats
beside
> the point.
> FECs are OS processes/applications. (How they communicate to the
> netlink2 daemon is beyond the scope of ForCES; lets say it could be a
> local OS IPC.)
>
> As an example, there may be a FEC which controls several LFBs;
> Another example is an FEC which sends and receives OSPF hellos.
> Each FEC has a counterpart which understands it on the CE side.
> The CE piece of OSPF (call it CEC) sends messages to
> a specific PID when it wants to talk to the FEC portion (the hello
> offloader).
> As you can see this is application talking to another application;
> this could be looked at as essentially IPC. Therefore the concept of
PID
> is useful.
>
> Now to address your emails:
>
> On Mon, 2004-03-08 at 00:07, Wang,Weiming wrote:
>
> Weiming, could you make sure your emails wrap around at 80 characters?
> It helps when i am trying to respond.
>
>
> > We think a layer-based tree structure according to the ForCES
architecture
> > is efficient to do such addressing. If we address entities at
> > the FE coarse layer ( to take the FE as a whole entity, which idea
is also
> > used by new version of FE model ), we only need to
> > have a FE ID.
>
> If i am not mistaken what you are talking about is a detail
> on how the address gets split; i.e you want to have a hierachical
> addressing - as an example you want to split the address above to
> FEx:FECx or CEx:CECx (refer to the meanings of CEC and FEC above).
> If this is the case, i think it is a small detail and we could move
> on and talk baout it later; if not please look at the diagram and
> tell me how you would split the ID to configure LFB0. I actually have
> a feeling your approach to this would be VERY different from
Hormuzd;->
>
> >  To address
> > CEs, we use CE ID.  By defining IDs for FE broadcast, LFB broadcast,
LFB
> > Instance broadcast, and CE broadcast, following addressing can be
> > implemented:
>
> I think we all agree on the broadcast or multicast to a specific
> type of entities.
>
> >>- a set of LFBs on an FE
> > - a set of LFBs on different FEs
> >
> >
> > [Wang Re: Are the set of LFBs of the same type?]
>
> Yes, example "all IPV4 fwding LFBs" instead of "all LFBs".
>
> > - proxies for LFBs,
> > - proxies for control application in the form on the CEs,
> >
> > [Wang Re:  If ever we have these proxies, are they need to be seen
at the
> > protocol layer?
>
> No, there is nothing speacial needed at the protocol header. The list
> was an exhaustive example.
>
> > Moreover, how about FE proxies then?]
>
> They dont need to be addressed by anything speacial in the header.
>
> On Mon, 2004-03-08 at 01:54, Khosravi, Hormuzd M wrote:
>
> > [HK] Great, seems like Weiming would also prefer CE, FE ID. Can we
go
> > with that terminology then?
>
> Lets talk about what needs to be addressed first before we jump to
that.
> Refer to the two diagrams i sent.
>
> > [HK] I don't see the value of having an App ID in the common header.
How
> > is it useful ? May be if you could give a good example of how this
can
> > be used, it would help. The ForCES endpoints are CEs and FEs which
> > should be addressed in the common header. LFBs are like knobs on the
FEs
> > used to program its functionality. I am sure you know all this very
well
> > and I think most folks will agree on this. If we go with a different
> > view, we will probably land up breaking the FE Model as well. Other
> > views on this one ?
>
> Refer to the two diagrams i sent for an example, then lets discuss.
>
> [HK] Could you give me an example of why this is limiting?
>
> I was refering to the fact that you have a single ID to address
> entities within an FE or CE. In my diagram i am rtying to show theres
> more than one class of end targets. So calling it CEID or FEID
> is limiting.
>
> > I would like
> > to know if using 16 bits would break in some scenarios. If this was
part
> > of a TLV I wouldn't care as much, but since this is the common
header, I
> > am a bit concerned...acting stingy :-))
> ..
>
> [HK] Exactly, ForCES has much limited/specific scope (NE) than general
> > purpose middleware such as Corba. You cannot compare these 2 because
of
> > the difference in scope.
>
> I gave the historical experience of PCs (by quoting a naive bill
gates),
> IPV4(by making a mockery over the famous last words that brought IPV6
to
> the world)  and  now i can add the experience of unix which would have
> been more interesting with 64 bit PIDs.
> Summary: Nothing would break; however it is useful to learn from
history
> and say lets go with something larger.
>
> Again, apologies for long email; hopefully this would group
> things together.
>
> cheers,
> jamal
>