Subject: Re: updated message layout doc

From: "Wang,Weiming" <[email-masked]>
Date: Mon, 6 Sep 2004 12:43:07 +0800

Seems still not work for the attachment. I just directly put the contents below.

Sorry for it.
Weiming

****************************************************************

Followed are some of my thoughts on the message TLV format for discussion:

1. Message Format

1) Config Message

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                   Msg Header(MessageType='Config')            ~
~                                                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                          LfbTLV                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                          OpTLV                                ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                          DataTLV                              ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                          ...                                  ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                          OpTLV                                ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                          DataTLV                              ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                          ...                                  ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                          ...                                  ~
~                          ...                                  ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                          LfbTLV                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                          OpTLV                                ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                          ...                                  ~
~                          ...                                  ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2) Query Message
        MsgHeader(Type='Query')
        LfbTLV
        DataTLV
        ...
        LfbTLV
        DataTLV
        ...

There is no OpTLV for Qeury Message, because the message has actually
limited its operation to query.

3) Query Response Message
        MsgHeader(Type='Query Response')
        LfbTLV
        DataTLV
        ...
        LfbTLV
        DataTLV
        ...
There is also no need for OpTLV for this message.

3) Event Notification Message
        MsgHeader(Type='Event Notification')
        LfbTLV
        DataTLV
        ...
        LfbTLV
        DataTLV
        ...
There is also no need for OpTLV here.

2. Definition of TLVs

1). LfbTLV

The LfbTLV presents the LFB(s) that are addressed by the message. The
LfbTLV format is uniform and can be applied to all types of messages
that need LFB addressing. We can think of an LfbTLV format like:

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    Type = 'LFBTLV'            |               Length          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     LFB Type ID #1            |     LFB Instance ID #1        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~                             ...                               ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     LFB Type ID #N            |     LFB Instance ID #N        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

We can also define a more complex LFBTLV for more complex LFB addressing,
e.g., we may allow addressing a range of LFB instances, like LFB A with
the instance id ranging from #1 to #10.

2). OpTLV

The OpTLV is to describe operation to the LfbTLV addressed LFB(s)

Note that although the OpTLV is globally defined, it may only be applied
to configure message. For query, query response, and event notification
messages, the operation has actually been implicitly assigned, therefore
there no needs for OpTLV for them.

I think of the OpTLV format as:

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    Type = 'OpTLV'             |               Length          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |      Operation                |           FLAGs               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where,
Operation field indicate the operation mode. For configration message,
following operations are defined:
          'Add'         to add an attribute value to the addressed LFB(s)
          'Delete'      to delete an attribute value
          'Modify'      to modify an attribute value

'Flags' indicates operational features like inner-message 'batch','atomicity',
etc (inter-message 'batch' and 'atomicity' are defined by flags in the
protocol message headers).

Note that for 'Modify' operation, the followed Odd 'DataTLV' assign the
Data Name (ID) to be modified, while the followed Even 'DataTLV' assign
the Data value to be modified (see section 3 example #3 below).

3). DataTLV

DataTLV is to describe the data reqired by operation. The TLV globally
has format as:

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    Type = 'DataTLV'         |               Length            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         Data ID                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~                         Data Value                            ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The 'Data ID' includes following IDs:

        LFB attribute type ID
        LFB capability type ID
        LFB event type ID

For Config Message, the Data ID is for LFB attribute type ID.
For Query and Response Message, the Data ID is for LFB attribute type
and capability type IDs.
For Event Notification Message, the Data ID is for LFB event type ID.

(need to discuss if the Data ID should be global or only LFB specific.)

The 'Data Value' describes the actual data value for the Data. In some
cases it is optional, i.e., there is only Data ID there. For example,
in Query Message, there may only be 'Data ID' while no 'Data Value'.
In this case, it means to query all data with the 'Data ID'. E.g., if
the 'Data ID' is 'RoutingTable' for an Forwarder LFB, then to use only
the RoutingTable to query is actually to query all routing items in
the table. If we need to query some specific items in the routing table,
we then use Data Value to specify it. (I'm trying to describe how we can
use the 'Data Value' to query items in the routing table based on the
table 'Index' as Joel and Jamal proposed, later in Section 3 examples.)

I think above are that which may appear in the the protocol specification,
while the detailed 'Data value' definition will not appear in the protocol
description. I think a specific "FE Data Model" is responsible to define
the above 'Data Value' format for all FE LFBs in details.

Following is some of my thoughts on the 'Data Value' format in the
'FE Data Model', which I think does not belong to the protocol specification.

========Below only for "FE data model"===========
In the "FE Data Model", the 'Data Value' may be composed of several field as:

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~                         Field #1                              ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~                         ......                                ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~                         Field #N                              ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Taking an routing table as an example, a routing table may have fields
like 'Index', 'SrcIP', 'Mask', 'OutPort', etc. A more complex field can
also be defined. E.g., we can define an 'IndexRange' or 'IndexEnum' to
address a range of intexed items or enumerated items. I also wonder if
we need to define some field to describe logical relationship between
the fields, such as logica AND, OR, etc for fields.

A 'Field' is described by a TLV as:

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    Type = FieldID           |               Length            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~                         Field Value                           ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The FieldID does not need to be global, it may only be LFB-specific.

"FE Data Model" is responsible to accurately define the Field Value
format and the meanings for all Data IDs of all LFBs.

========above only for "FE data model"===========

3. Some examples

Coming back to the protocol message, we take a few examples to show
how a table operation can be implemented based on above model. Note that,
the 'Index' can not been seen in the protocol specification it is only
a field in the "FE Data Model". It also means protocol users can also
choose not to use such Index for table operations, but if they choose
to use it, we can also support it.

1). To add a routing rule to a routing table in a Forwarder LFB
(Type=0x01, InstanceID=0x45), the routing rule has value as: Index=7,
SrcIP=192.168.0.5, Mask=255.255.0.0, OutPort=3

Below is the message format for this purpose:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                   Msg Header(MessageType='Config')            ~
~                                                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                 LfbTLV (LFBtype=0x01, InstanceID=0x45)        ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                          OpTLV('Add')                         ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~       DataTLV ( Data ID  ='RoutingTable',                     ~
~                Data Value= Index:7, SrcIP:192.168.0.5,        ~
~                            Mask:255.255.0.0, OutPort:3)       ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Note: the items in Data Value are all represented by field TLVs defined above.

2). To delete Index=7 routing rule from above routing table

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                   Msg Header(MessageType='Config')            ~
~                                                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                 LfbTLV (LFBtype=0x01, InstanceID=0x45)        ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                          OpTLV('Del')                         ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~       DataTLV ( Data ID  ='RoutingTable',                     ~
~                Data Value= Index:7                            ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3). To modify Index #7 routing rule in above routing table to Index=8, OutPort=5

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                   Msg Header(MessageType='Config')            ~
~                                                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                 LfbTLV (LFBtype=0x01, InstanceID=0x45)        ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                          OpTLV('Modify')                      ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~       DataTLV ( Data ID  ='RoutingTable',                     ~
~                Data Value= Index:7                            ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~       DataTLV ( Data ID  ='RoutingTable',                     ~
~                Data Value= Index:8, OutPort:5)                ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4). To query a whole routing table in a Forwarder LFB (Type=0x01,
InstanceID=0x45)

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                   Msg Header(MessageType='Query')             ~
~                                                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                 LfbTLV (LFBtype=0x01, InstanceID=0x45)        ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~       DataTLV ( Data ID  ='RoutingTable',                     ~
~                Data Value= Null                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5). Query Response to above Query message

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                   Msg Header(MessageType='QueryResponse')     ~
~                                                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                 LfbTLV (LFBtype=0x01, InstanceID=0x45)        ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~       DataTLV (Data ID   ='RoutingTable',                     ~
~                Data Value= Index:1,...                        ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~       DataTLV (Data ID   ='RoutingTable',                     ~
~                Data Value= Index:2,...                        ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~       DataTLV (Data ID   ='RoutingTable',                     ~
~                Data Value= ...                                ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                     ......                                    ~
~                                                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6). To query a routing rule with index=7 in a routing table in a
Forwarder LFB (Type=0x01, InstanceID=0x45)

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                   Msg Header(MessageType='Query')             ~
~                                                       ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                 LfbTLV (LFBtype=0x01, InstanceID=0x45)        ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~       DataTLV (Data ID   ='RoutingTable',                     ~
~                Data Value= Index:7                            ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

********************* The End ***************

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 13 Sep 2004 11:52:48 -0400

Weiming,
I was away the last week. I just went over your text briefly.

While you are trying to reduce the amount of parsing involved
(a noble effort), the result is you have lost clean structuring.
As i am digging deeper i am more inclined to think that maybe Joels
approach or a refined variant of it is the way to go. It is a little
more processor intensive but will make management interface a lot more
sane. Unfortunately mngmt interface is a very important tradeoff in the
overall design (at some point manageability of Forces will kick in -
currently people write MIBS - we should be able to use XML instead).
My suggestion is to try and look at Joels delta and see if that can be
cleaned up.

Lets talk in tommorows design meeting (or if you can respond before the
meeting then we can have a starting point).

cheers,
jamal

---

From: "Wang,Weiming" <[email-masked]>
Date: Tue, 14 Sep 2004 21:39:10 +0800

Hi Jamal,

Thank you for the response. Some replies inline.

----- Original Message -----
From: "Jamal Hadi Salim" <[email-masked]>

> (a noble effort), the result is you have lost clean structuring.
[Weiming]As I mentioned before, the effort is not just for easy parsing, but
also for more clean structure and more flexibility (by use of universal LfbTLV,
OpTLV and even DataTLV). I'm not very sure of clean structuring you mean here.
Do you mean the individual TLVs are too complicated, or the message format is
too complex? I'm trying to understand it. would be helpful if you could give a
litlle more detailed thoughts here, thank you.

> My suggestion is to try and look at Joels delta and see if that can be
[Weiming]I checked your summary on Joel's idea. I suppose what you summarized
there is mainly about the way for table indexing. We the teams truly have quite
different thoughts on if the index should be put in protocol layer or not,
therefore I suppose this can be one separate from TLV topic for the call meeting
to discuss, as Ellen suggested.
> meeting then we can have a starting point).
[Weiming]As Ellen suggested, I also suppose the two topics: one for TLV format
for messages, one for table indexing way as well as for LFB attribute
representation for protocol messages.
> jamal

Cheers,
Weiming