RE: [Forces-protocol] issue 1: packet encoding

["Khosravi, Hormuzd M" <[e-mail]>]

Jamal,

Before I give my comments, I would like to say that I appreciate the
fact that you did not copy/paste the netlink header from your draft over
here! That is a very positive sign to me, lets try to stick to the best
technical solution rather than pushing our own protocol implementations.
That's the best way to make progress on this merger!!
 
Here are my views on this issue, particularly the common header:

Command: Agree this is needed. We think 8-12 bits will be more than
sufficient for this depending on whether it is subdivided. We have
sub-divided this field into Class/type...this is an OO approach, seemed
pretty neat. However, I am personally fine with having a single field
for this, no problem with that.

Length: Agree needed and agree with size.

xIDs: Agree this is needed. More detailed comments on length, semantics
in my previous email.

Sequence No: Agree needed and agree with size.

Flags/Priority: We need 2-3 bits for priority in every message. I don't
think we need any other flags in all messages.

Typeid: This is one field I don't think is needed in all messages. I am
not sure why this is needed at all cause, we will be using the Model and
LFB IDs to address processing functional blocks on the FEs.

Missing field: Version (2-4 bits): This is present in all protocols, and
is generally included in most IETF protocols. Its usually the 1st field.

General comment: Lets try to be stingy on the size of the header and its
fields since this will be included in all ForCES messages.

Jamal's text.......
The Forces Message Header: 

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                     0               1               2             3
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             Command         |               Length            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          Source xID                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        Destination xID                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        Sequence Number                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             flags           |             typeid              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


XML encoding:
XML encoding may be useful in capabilities definition
(i.e slow path) but not in the configuration of data path tables.
This is because of its nature to require higher bandwith and
CPU computational needs.

HK Comment: I think we should stick with a single encoding type, namely
TLV. This is also what some of the model team folks have mentioned
before for the protocol. Is there a reason why capabilities cannot be
expressed using TLVs?


Thanks
Hormuzd

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Jamal Hadi Salim
Sent: Friday, March 05, 2004 2:00 PM
To: [e-mail]
Subject: [Forces-protocol] issue 1: packet encoding


Attached is text for stimulating discussion on issue 1.

cheers,
jamal


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