Subject: [Forces-protocol] RE: ForCES Protocol Analysis Design Team Administrivia

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Wed, 3 Mar 2004 22:50:47 -0800

Here is a starter list of common high level ideas/features/principles
that I believe we all agree on...

All ForCES protocol messages should consist of a fixed size header and
variable size payload fields. Further, the protocol header is made up of
CE ID, FE ID fields in addition to other fields (TBD)

All ForCES protocol messages should be 32-bit aligned.

The ForCES protocol payload consists of a number of variable size TLVs
i.e. all ForCES messages must use TLV encoding.

The FE ID field in the protocol header is assigned or allocated by the
CE.

The ForCES protocol/model must support the discovery of static
capabilities of an FE. The protocol/model may also support dynamic
capabilities when they are supported by the FEs.

The ForCES protocol should support logical addressing for multicast in
addition to unicast. The FE ID, CE ID fields in the header will be used
for addressing FEs, CEs.

The ForCES protocol should have separate channels/connections/(any other
terminology ?) for data and control messages. By data messages we mean
control protocol packets such as OSPF, RIP packets, etc. which need to
be redirected from FE to CE or forwarded from CE to FE. By control
messages we mean all other control/capability/configuration messages.

The ForCES protocol will mandate a minimum set of transports for data
and control connections/channels for interoperability reasons.

The ForCES protocol will take advantage of underlying transports/
interconnects to provide features such as reliability, security to keep
the protocol design itself simple.

The ForCES protocol will run directly over layer 2 interconnects. It can
either use additional TLVs or encapsulation headers or transports such
as TIPC to provide the missing functionality such as reliability,
fragmentation, etc.

This is just a starting list, we should continue adding to this one as
we discuss more ideas.
Pls feel free to give comments or make any changes to the text above.

BTW note to the list-admin, [email-masked] address is not working.

Regards
Hormuzd

-----Original Message-----
From: Khosravi, Hormuzd M 
Sent: Tuesday, March 02, 2004 4:55 PM
To: [email-masked]'
Cc: Putzolu, David; [email-masked]; [email-masked];
[email-masked]; Steve Blake; Robert Haas;
[email-masked]; [email-masked]; Wang,Weiming; Patrick Droz;
jeff pickering; [email-masked]; Deleganes, Ellen M; [email-masked];
[email-masked]; [email-masked]
Subject: RE: ForCES Protocol Analysis Design Team Administrivia

Hi Jamal, All

I briefly chatted with David, Patrick regarding our deliverables by
March 20th and I got a feeling that they are looking for whether we can
merge the protocols and what are the high level design features that we
all agree on.
I think most of us already agree that we can achieve a merge if we work
towards it. I would suggest that we first try to get all the high level
features list out and agree on it, then proceed to the details.

So in that spirit I would suggest to postpone getting into details such
as length of bits in the header, what the format is, etc for now and
quickly come up with a list of common ideas. Some of the items below
that we all seem to agree on may be a good start.

regards
Hormuzd

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

---

From: Alex Audu <[email-masked]>
Date: Thu, 04 Mar 2004 14:55:58 -0600

Hormuzd,

I don't understand this requirement (reproduced below):

------------------------------------------------------------------------
The ForCES protocol will run directly over layer 2 interconnects. It can
either use additional TLVs or encapsulation headers or transports such
as TIPC to provide the missing functionality such as reliability,
fragmentation, etc.
------------------------------------------------------------------------

Can you explain this?  Which L2 are you refering to? (Internet Protocol
layer 2 or OSI layer2). 

Regards,
Alex.

---

From: Jamal Hadi Salim <[email-masked]>
Date: 04 Mar 2004 16:27:45 -0500

> CE ID, FE ID fields in addition to other fields (TBD)

The general term should be ID (PID is what we called it).
Essentially this is an application Identifier. There could be 
more than one application per FE or CE. So the description
FE ID or CE ID is limiting.

> i.e. all ForCES messages must use TLV encoding.

The TLVs being 32 bit aligned as well would be a good thing to have.

> The FE ID field in the protocol header is assigned or allocated by the

Again, note my comments above; btw, i did describe this detail
in the implementation experience notes i sent. I could resend.
It is also acceptable that the CE issue the FE with a range of PIDs
that it can be used by the various apps. We did this in our
implementation (i realize its an implementation specific, but its
a good experience to share)

Maybe we should start with resolving the header? It's the easiest thing
to come to agreement on.    
Actually before that even, lets identify the value of the ID.
Is this acceptable?

> capabilities when they are supported by the FEs.

However, note, this may have some protocol semantic value.
Perhaps, part of the capability exchange can resolve the may.

> addition to unicast. The FE ID, CE ID fields in the header will be used

I take it this is application level addressing; i think we need to
resolve this first as i said above.

> messages we mean all other control/capability/configuration messages.

Is there a good reason for such separation?
>From my reading, you have one connection less reliable than the other,
is that correct?

> and control connections/channels for interoperability reasons.

Refer to the mail David posted on some of the suggestions the ADs were
making i.e dual mandatory" approach.
I agree on the interop part. We need to scope this out.

> the protocol design itself simple.

Agreed

> as TIPC to provide the missing functionality such as reliability,

Agreed.

cheers,
jamal