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

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Sat, 6 Mar 2004 13:37:20 -0800

Alright, here are my views on this issue/topic...

Terminology: Src ID, Dest ID vs CEID, FEID
I don't like to get stuck up on terminology, so I will go with whatever
the majority likes on this as long as we agree on the semantics.

Semantics: This is where we differ a bit. As our terminology suggests,
these can be individual FE, group of FE, all FEs and same applies for
CEs. However, this field does not represent LFBs. LFB ID is something
which has to be assigned by FEs for representing static topologies, and
may be assigned by FEs for dynamic topologies (I think this is also what
the Model team concluded on this issue, but not 100% sure). In contrast,
FE IDs is something assigned by the CE as Jamal suggested. Moreover LFB
ID is not something which is needed in all ForCES messages, hence does
not need to be in the common header. It will be part of the TLV defined
for carrying configuration/control/event messages.

Length: Acc to the scalability requirements, we need to support hundreds
of FEs (<=1000) and even much less no of CEs (<=100). So 10 bits would
be enough for FEID/Dest ID and 7 bits for CEID/ Src ID. However, in
order to accommodate even higher requirements and have the fields 32-bit
aligned we used 16 bits for FEID, CEID. If there is a good technical
reason for requiring 32-bits I would be willing to compromise on this.
However, one thing to keep in mind is that this is the common header so
every byte we add to it will be added to all the messages, so it would
be a good design principle to be a bit stingy here. If it was part of an
optional TLV, we wouldn't care as much.

Let me know what other views are on this topic.

Thanks
Hormuzd

-----Original Message-----
From: Jamal Hadi Salim [mailto:[email-masked]] 
Sent: Thursday, March 04, 2004 1:48 PM
To: Khosravi, Hormuzd M
Cc: [email-masked]
Subject: Issue 0: Application addressing

Hormuzd,
heres some text for application addressing

----
Source and Destination IDs:

These are application level identifiers. They could be used
to address the following:
- an LFB on the FE,
- a set of LFBs on an FE
- a set of LFBs on different FEs 
- proxies for LFBs,
- proxies for control application in the form on the CEs, 
- the FE,
- a set of FEs
- all FEs
- the CE.
- a set of CEs
- all CEs

The above shows need for having the ID being able to be IDed
as unicast, broadcast or multicast.

For clarity, i could create a diagram of what we used.

I will post the header i posted earlier next. Or maybe we should 
stick to resolving this first.
Hopefully we can get to a good way to beat the several issues, i am
doing this to hopefuly come to a style that we can use to beat the
issues.

cheers,
jamal

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

---

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

> the majority likes on this as long as we agree on the semantics.

Same here.

> for carrying configuration/control/event messages.

My wording was insufficient. The targeted end point for an ID is
not something thats on the datapath (although i have a feeling some
of the NPF folks may disagree with me). In otherwords, the ID is that
of a Forces application (or OS process or thread) which resides on a CE
or FE.
If we looked at the entity that is being addressed by this ID as
a forces application then we could say that:
- the ID is always needed since there maybe more than one such app on a
specific endsystem. This is true regardless of the end system being a
CE or FE. 
So lets ignore the LFB part and see if the above is agreeable.

> reason for requiring 32-bits I would be willing to compromise on this.

32 bits is not that expensive and it always saves you from famous last
words like "nobody will ever need more than 640K of RAM" or 
"you can give light bulbs IP addresses if you used 32 bit IP addresses".

The partitioning of CEID or FEID is a little limiting in my opinion.
The end target may not be precisely a CE or FE; it could be an OSPF 
offloader on an FE. 

> optional TLV, we wouldn't care as much.

Forces is almost middleware; typical middleware abuses a lot of
the PID space usually around 128 bits for each direction.
Example look at corba or:
http://www.rti.com/products/ndds/index.html

Note in their case the IDs above are known as UUIDs with one of the Us
standing for universal; in our case the universe is the NE so a 32 bit
maybe suffice.

> Let me know what other views are on this topic.

Well the other issues are in regards to semantics of the ID;

To quote what i said earlier:

> .. shows need for having the ID being able to be IDed

in other words we should be able to address a single forces app,
or several.

cheers,
jamal

---

From: "Wang,Weiming" <[email-masked]>
Date: Mon, 8 Mar 2004 13:07:19 +0800

Hi Hormuzd, Jamal, and all,

Please let me  first put our original thoughts on the way to address entities defined by ForCES framework at ForCES protocol layer, 
so that we can get to understand each other more easily. 

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 we address entities at LFB layer, we use FE ID along with a LFB Instance ID to support multi-instances.  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:

- any FE or all FEs
- any CE or all CEs
- any LFB or all LFBs with the same type in any FE or all FEs 
- any LFBs with different types in any FE or all FEs

I think this idea is quite identical with Hormuzd's, but different from Jamal's. Let's take an example to show the difference. Say we have several
rooms with many different chairs and tables in every room, we then need to find the entities inside the rooms as well as the rooms themselves. 
We propose that to find a room, just use room number, to find a chair in the room, we need to first find the room then to find the chair in it. 
I suppose Jamal's idea is to use a uniform ID to find the chair directly ( Jamal, please excuse me if it's not right). 

As a result, we may need to have some discussion on which is more feasible, efficient and easier to use.

Some more comments put inlines for both your email as below. 

Cheers,
Weiming

----- Original Message ----- 
From: "Khosravi, Hormuzd M" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, March 07, 2004 5:37 AM
Subject: [Forces-protocol] RE: Issue 0: Application addressing

[Wang Re]
Personally I prefer FE ID and CE ID as the names. In other words, I would like to tell an engineer 
" please help to fit FE ID xxx", rather than "to fit Dest ID xxx".  But I'm afraid in fact the Src.ID and Dest ID
here are not just for FEs and CEs. 
[/Wang Re]

[Wang Re: Agree] 

[Wang Re: Agree]

Thanks
Hormuzd

-----Original Message-----
From: Jamal Hadi Salim [mailto:[email-masked]] 
Sent: Thursday, March 04, 2004 1:48 PM
To: Khosravi, Hormuzd M
Cc: [email-masked]
Subject: Issue 0: Application addressing

Hormuzd,

----

[Wang Re: Are the set of LFBs of the same type?]

- proxies for LFBs,

[Wang Re:  If ever we have these proxies, are they need to be seen at the protocol layer? 
Moreover, how about FE proxies then?]

- the FE,
- a set of FEs
- all FEs
- the CE.
- a set of CEs
- all CEs

cheers,
jamal
 
¢·²šè¶‡(–f¢–)à–+-ŠÜzÊk¢Ú¢Xžµú+‚m¦ÏÿÃ5‰ë_¢¸?™¨¥™©ÿ–+-Šwèýú+që)®‹hr‰

---

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

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.

> [Wang Re: Are the set of LFBs of the same type?]

Yes, example "all IPV4 fwding LFBs" instead of "all LFBs".

> [Wang Re:  If ever we have these proxies, are they need to be seen at the 

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

---

From: Alex Audu <[email-masked]>
Date: Mon, 08 Mar 2004 10:29:30 -0600

Hi Hormuzd,

We should be able to support FEs in the thousands. A distribute GiGa router
could comprise of 2048 FEs for example. The more powerful the FEs, the 
smaller this number ( I believe).

Alex.

Khosravi, Hormuzd M wrote:

>[snip..]

---

From: Alex Audu <[email-masked]>
Date: Mon, 08 Mar 2004 14:10:12 -0600

I believe what Weiming seems to be saying is that we don't have to 
expose the LFB
addressing in the common message header, since not all messages will 
target LFBs.
So, it makes sense that  such LFB addressing be carried on the TLVs for 
the messages
that apply to the TLVs.  I fully agree with this idea.  Id does away 
with clutter, and makes
for  cleaner  implementation.  Also, the code will run faster since you 
don't spend time
checking if LFBs are being addressed or not before you actually handle 
the core
message (especially when LFBs are not being addressed.)

Regards,
Alex.

Jamal Hadi Salim wrote:

>.
>------------------------------------------------------------------------
>
>
>
>         +-----FE0---------------------------------------------+
>         |                                                     |
>         |                                                     |
>         |                                                     |
>         |      /~~~~~\     /~~~~~\         /~~~~~\            |
>         |     | FEC0  |   | FEC1  |       |  FECx |           |
>         |     |       |   |       | ..... |       |           |
>         |      \_____/     \_____/         \_____/            |
>         |         |           |               |               |
>         |       /~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\             |
>         |      |                                 |            |
>         |      |       Netlink2 Manager          |            |
>         |      |                                 |            |
>         |       \_______________________________/             |
>         |               |             |                       |
>         |               |             |                       |
>         +--------------/--------------|-----------------------+
>                       |               |
>                       |               |
>              wire0  --+               + --- wire1
>
>
>Figure 1.
>
>
>                    /~~~~~\
>                   | FEC0  |
>                   |       |
>                    \_____/
>                       |
>                       Y
>                       | netlink, proprietary, NPF API, etc
>                       ^
>                       |
>                     +-+---------+
>        datapath     |           |  processed packet
>         ----------> |  LFB10    | ---->
>                     |           |
>                     +___________+
>
>
>Figure 2.
>  
>

---

From: Jamal Hadi Salim <[email-masked]>
Date: 08 Mar 2004 15:25:02 -0500

> addressing in the common message header, since not all messages will

Thats not what i read it to be. If it is the case then it is precisely
what i am saying as well.
But please dont respond to this message.
Instead please respond to the points raised in detail in my email.
By just adding a paragraph at the top and not addressing the other 9 out
of 10 items raised in the email, we end up reiterating things which
have already been said 3 emails later. This is not for you in
particular but just general email/usenet DNA.

cheers,
jamal

---

From: "Wang,Weiming" <[email-masked]>
Date: Tue, 9 Mar 2004 20:37:11 +0800

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

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

> > [Wang Re:  If ever we have these proxies, are they need to be seen
at the
> > protocol layer?