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

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Thu, 4 Mar 2004 18:11:46 -0800

Jamal,

Thanks for your response. See my comments below...

-----Original Message-----
> 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)

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.

[HK] I am responding to this issue in the separate email that you sent
out.

> 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 TLVs being 32 bit aligned as well would be a good thing to have.

[HK] Agreed

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

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?

[HK] Yes. I will respond to your email on ID/header separately.

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

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

[HK] Yes, that's the direction of the FE model.

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

Is there a good reason for such separation?

[HK] Yes there are several good reasons. One is reliability, the second
is robustness against DoS attacks, yet another one pointed out by Steve
was efficient delivery into CE's networking stack. I thought we had a
common
understanding on this, but I will be happy to send out a more detailed
email on this topic if that helps.

>From my reading, you have one connection less reliable than the other,
is that correct?

[HK] Yes and we clearly specify which messages/packets are sent on which
Connections...important for interop.

> The ForCES protocol will mandate a minimum set of transports for data
> 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.

[HK] I agree, we need to have a discussion on this soon after resolving
some
of the other topics that you have raised.

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

---

From: Jamal Hadi Salim <[email-masked]>
Date: 05 Mar 2004 14:30:13 -0500

Hormuzd,

On Thu, 2004-03-04 at 21:11, Khosravi, Hormuzd M wrote:
[..]
> common understanding on this, 

I think we do - but i am getting confused by some of the messages i see
from Weiming. Why dont you put some text around this and lets
settle on it; 
Note, my confusion is the nature of the beast: I would take it if 
you have two channels/sockets/connections then they must differ somehow.
Is the difference in priority, reliability, availability, bandwidth,
or what? This is what needs to be clarified so we reach a conclusion
of some sort. Note in our case, the separation of the socket connection
was based on
a) cost: It is cheaper to reach more FEs with a single message to 
a multicast channel. 
b) reliability: Retransmissions go out on unicast TCP connections.

In other words it was not the packets that were important, it was 
"which channel should i use to achieve a goal?".

To reiterate the issues (and hopefully add discipline to the discussion
so we can settle quickly), the above would be issue 2). The others are:

0) ID on the header.
1) Encoding
2) Multiple channels/connections
3) Transport: unicast/multicast/broadcast 
{ TCP, UDP, SCTP, DCCP, Direct over L2 or proprietary backplanes, TIPC} 
4) Congestion control
5) Reliability
6) Security
7) High availability

cheers,
jamal