Subject: [Forces-protocol] summary of discussions so far... (part 1)

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Fri, 19 Mar 2004 14:21:46 -0800

Hi All

Here is a list of high level design ideas/principles that we all agreed
on...

All ForCES protocol messages should consist of a common fixed size
header and variable size payload fields. 

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 should also be
32-bit aligned.

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

The ForCES protocol should support logical addressing for multicast,
broadcast in addition to unicast.

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

I have incorporated comments from Jamal, others that I received on the
original text.
I will send out a summary of each issue shortly. Let me know what you
guys think ?

Regards
Hormuzd

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

---

From: [email-masked]
Date: Sat, 20 Mar 2004 14:32:03 +0800

Hi Hormuzd,

----- Original Message ----- 
From: "Khosravi, Hormuzd M" <[email-masked]>

Hi All
 .....

[Weiming Re] I'm afraid this sub-issue has not completely come to an agreement. 
I actually agree to use TLVs in ForCES protocol.  The only question is why it 
should be MUST.  I think we only need to use it when we actually need it. 
Talking about this, I'm afraid I have to kindly mention FACT again. I have just 
found that in many cases inside FACT where the first layer 'Tag' and 'Length' 
field are used, after these fields have been moved away while without any other 
changes, the protocol still can run very well . Please allow me to take one 
from FACT as an examples as below (FACT P.18):

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |           Tag (0x04)           |             Length           | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                              Reason                           | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

When we just use:

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                              Reason                           | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

It still can work well. In this way, we actually have taken the 'reason' field 
as a field inside the large ForCES message TLV( the message type as the T, the 
message length as the L).

To compare with, I would more appreciate the way the TLV is used in Netlink2, 
in which I think it has not strictly tried to use TLV when not necessary. For 
example, the Netlink2 ACK message (Netlink2 P.28):

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Netlink2 message header                 |
    |                       type = NLMSG_ERROR                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          error code                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       OLD Netlink2 message header             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where the error code and old message header part are explicitly expressed 
instead by TLVs. 

Actually GRMP has taken the way like this to use TLV. That is to use TLV only 
when necessary. 

Another problem related to strictly and uniformly use TLV in the payload of the 
message body is, then we have to define the TLV's Tag field globally even when 
the TLV is a very micro item (as above example where the Tag (0x04) is glabal), 
which may result in so many types of TLV we need to define, as a result, I'm 
not sure if the 16 bits space will become exausted or not in the future. 

As a result, I would prefer to use TLVs as follows:

1. All items (parameters) that have variable length and are mostly defined by 
FE models Must be defined as TLVs.

2. All items that actually have global meanings for more than one kind of 
ForCES messages is better to be defined as TLVs. 

3. All items that are optional to a message payload is better been described as 
TLV(just like IP, TCP, etc do)

Anyway, I just want to say that it may be too early to decide "all ForCES 
messages must use TLV encoding". We may need to gain more experiences (when we 
actually begin to encode the ForCES messages), then to decide it. I don't think 
to do in this way has any harm to all of us. 

Yours,

Weiming

-------------------------------------------------
This mail sent through HUCNIC Webmail system.

---

From: [email-masked]
Date: Sun, 21 Mar 2004 01:34:04 EST

Weiming,

The tag is used to communicate the meaning of the value being communicated in 
the
reason field. Otherwise, there is no way of telling whether the 32 bit field 
carries LFBID or
reason code or any other 32-bit value. 

And of course, we may also want to encode the values in other formats like 
XML,..etc.
So, there ought to be a way to communicate the method of encoding we are 
using in the
header. I have hinted at this in my earlier suggestion for a common header 
structure.

Regards,
Alex.

---

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Sun, 21 Mar 2004 10:39:58 -0800

Hi Weiming,

I think you are reading too much into this. By TLV I don't mean a
specific implementation that we have done for FACT. What I mean is using
some kind of compact encoding other than XML, OIDs, etc. I believe there
is agreement on this and all the protocols are using this. What you have
provided below are details which still need to be flushed out. But that
doesn't mean we don't agree on the basics. I will clarify in the text
that the "details of TLV encoding are TBD"

Hormuzd

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Friday, March 19, 2004 10:32 PM
To: [email-masked]
Subject: Re: [Forces-protocol] summary of discussions so far... (part 1)

Hi Hormuzd,

----- Original Message ----- 

Hi All
 .....

[Weiming Re] I'm afraid this sub-issue has not completely come to an
agreement. 
I actually agree to use TLVs in ForCES protocol.  The only question is
why it 
should be MUST.  I think we only need to use it when we actually need
it. 
Talking about this, I'm afraid I have to kindly mention FACT again. I
have just 
found that in many cases inside FACT where the first layer 'Tag' and
'Length' 
field are used, after these fields have been moved away while without
any other 
changes, the protocol still can run very well . Please allow me to take
one 
from FACT as an examples as below (FACT P.18):

When we just use:

It still can work well. In this way, we actually have taken the 'reason'
field 
as a field inside the large ForCES message TLV( the message type as the
T, the 
message length as the L).

To compare with, I would more appreciate the way the TLV is used in
Netlink2, 
in which I think it has not strictly tried to use TLV when not
necessary. For 
example, the Netlink2 ACK message (Netlink2 P.28):

Where the error code and old message header part are explicitly
expressed 
instead by TLVs. 

Actually GRMP has taken the way like this to use TLV. That is to use TLV
only 
when necessary. 

Another problem related to strictly and uniformly use TLV in the payload
of the 
message body is, then we have to define the TLV's Tag field globally
even when 
the TLV is a very micro item (as above example where the Tag (0x04) is
glabal), 
which may result in so many types of TLV we need to define, as a result,
I'm 
not sure if the 16 bits space will become exausted or not in the future.

1. All items (parameters) that have variable length and are mostly
defined by 
FE models Must be defined as TLVs.

2. All items that actually have global meanings for more than one kind
of 
ForCES messages is better to be defined as TLVs. 

3. All items that are optional to a message payload is better been
described as 
TLV(just like IP, TCP, etc do)

Anyway, I just want to say that it may be too early to decide "all
ForCES 
messages must use TLV encoding". We may need to gain more experiences
(when we 
actually begin to encode the ForCES messages), then to decide it. I
don't think 
to do in this way has any harm to all of us. 

Yours,

Weiming