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

[Alex Audu <[e-mail]>]

I don't know what the flags could be used for. The TypeID could be used for
siganling the type of data encoding explicitly,  (i.e. XML, ASN.1 etc). 

My preference will be the following.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |vers   |eType  | prio| reservd |  msgClass     |   msgType     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       message length                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Source xID           | Destination xID               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        Sequence Number                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    
    

1) version # indicates the version of the protocol.
2) the type of encoding comes next.
3) the priority of the message comes next.
4) the command has been divided into message class and type to ease 
management and handling.
5) the source and destination are now both 16 bits each. This allows up 
to 64K FEs. That is cool!
6) the length is now 32 bits long. This will accommodate flow 
measurement messages which
    tend to be huge,  from FE to CE.  It will also accommodate large 
table dumps from CE to
    FE.
7) then comes the sequence number.

Any comments?

Regards,
Alex.

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


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