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

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Sun, 7 Mar 2004 22:37:22 -0800

Hi Weiming,

This is good, thanks for sending your point of view. It seems like we are in agreement on this one.

Thanks
Hormuzd

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Wang,Weiming
Sent: Sunday, March 07, 2004 9:07 PM
To: [email-masked]
Subject: Re: [Forces-protocol] Issue 0: Application addressing

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

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.

[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]

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.

[Wang Re: Agree] 

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.

[Wang Re: Agree]

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 

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

- 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? 
Moreover, how about FE proxies then?]

- 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
 
ŠzÊ¢Ú¢YŠX‚X´Zqë®‹r‰z×®¶›ÿ
Ö'~Šþf–fþX¶)£÷Ç¦º¡Ê

����趇(�f��)��+-��z�k���X���+�m����5��_��?�������+-�w���+q�)��hr�

---

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Sun, 7 Mar 2004 22:54:58 -0800

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

Same here.

[HK] Great, seems like Weiming would also prefer CE, FE ID. Can we go
with that terminology then?

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

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

>....

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. 

[HK] Could you give me an example of why this 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 :-))

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

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

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

---

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Wed, 10 Mar 2004 17:19:56 -0800

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Deleganes, Ellen M

Jamal,

I think we are in agreement about the FE ID portion of the addressing
and what it identifies (an FE instance). It also looks like everyone is
in agreement that a LFBID and LFBInstanceID are also needed for the
protocol. Where there appears to be disagreement is whether the LFBID
and LFBInstanceID belong in the common header or in the TLV.

I believe, like many others that LFB-related IDs (LFBID and
LFBInstanceID) belong in the TLV and not the common header. The primary
reason is to allow one message to affect more than one LFB. This is more
reasonably handled in the TLV. 

If we are in agreement that the LFBID and LFBInstanceID are part of the
TLV, it seems like Issue 0 can be closed. Do others agree?

[HK] Yes, I do :-)

Thanks
Hormuzd

---

From: "Wang,Weiming" <[email-masked]>
Date: Tue, 9 Mar 2004 22:52:43 +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
>
> From: "Jamal Hadi Salim" <[email-masked]>
> To: <[email-masked]>
> Sent: Monday, March 08, 2004 9:03 PM
> > 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
> > Yes, example "all IPV4 fwding LFBs" instead of "all LFBs".
> >
> > > - proxies for LFBs,
> > > [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.
> >
> > They dont need to be addressed by anything speacial in the header.
> >
> > On Mon, 2004-03-08 at 01:54, Khosravi, Hormuzd M wrote:
> >
> > Lets talk about what needs to be addressed first before we jump to
> that.
> > Refer to the two diagrams i sent.
> >
> > 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
> > ..
> > 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
> >
>
>