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

From: Jamal Hadi Salim <[email-masked]>
Date: 05 Mar 2004 16:59:46 -0500

Attached is text for stimulating discussion on issue 1.

cheers,
jamal

---

From: Alex Audu <[email-masked]>
Date: Fri, 05 Mar 2004 16:35:43 -0600

Jamal,

After a quick glance, we don't need  OuterTLV / IinnerTLV to be 
explicitly called out.
As far as I know, this is an inherent TLV encoding property.

I'll take a look at the rest and comment later.

Regards,
Alex.

Jamal Hadi Salim wrote:

>------------------------------------------------------------------------
>
>Packet encoding suggestion. 
>
>Binary encoding to be used to be able to pack as much as possible
>within an allowed MTU. 
>TLVs to be used to map the various attributes.
>TLVs within TLVs were used to encode complex attributes such as
>lists or compound structures.
>
>The layout below is to get a discussion going.
>
>
>     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
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                                                               |
>    |                   Forces message header                       |
>    |                                                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                                                               |
>    |                   Forces  Attributes                          |
>    |                                                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
>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              |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>The xIDs are being discussed in issue 0.
>
>The command would be of the sort of ADD, DEL, GET.
>The xID will address the entity being targeted.
>[A command from a CE -> FE is for querying or configuration, whereas one
>from FE -> CE is a response or event].
>
>The typeid identifies further the type of target by looking at
>typeid.
>[ for example, in our implementation we extended the popular tcpdump 
>sniffer to look decode the packet for protocol debugging purposes.
>
>Length: length of the message including the attributes + header.
>
>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.
>
>TLVs:
>
>    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
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   | TLV Type                    | variable TLV Length             |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   ~                                                               ~
>   |            Value (Data of size TLV length)                    |
>   ~                                                               ~
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>It is possible to extend the data in the TLV to contain another
>TLV to build complex structures (such as the ones described in
>XML by the model draft or lists susch as those defined by GRMP).
>
>Example:
>    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
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   | Outer TLV Type              |    Outer TLV Length             |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   | Inner TLV1 Type             |   Inner TLV1 Length             |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   | ~~~~~~~~~~~~~~           VALUE1    ~~~~~~~~~~~~~~~~~~~~~~     |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   | Inner TLV2 Type             |   Inner TLV2 Length             |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   | ~~~~~~~~~~~~~~           VALUE2    ~~~~~~~~~~~~~~~~~~~~~~     |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>Which could be used to represent the following layout :
>
>  +-+-+-+-+-+-+-+-+-+-+-+        .-~-~-~-~-~-~-.
>  |  TLV1               | ------>|   param 1   |
>  +-+-+-+-+-+-+-+-+-+-+-+         -~-~-~-~-~-~-
>  |  TLV2               | --->--+
>  +-+-+-+-+-+-+-+-+-+-+-+       |
>                                V
>                                |
>                               /
>                  +-----------+
>                  |           
>                  V                 .-~-~-~-~-~-~-.
>                  |            +--->|  param2_1   | 
>  +-+-+-+-+-+-+-+-+-+-+-+      |     -~-~-~-~-~-~- 
>  |  TLV2_1             | --->-+       .-~-~-~-~-~-~-.
>  +-+-+-+-+-+-+-+-+-+-+-+         +--->| param2_2    |
>  |  TLV2_2             | --->----+     -~-~-~-~-~-~- 
>  +-+-+-+-+-+-+-+-+-+-+-+  
>
>
>It is thought that TLVs and nested TLVs will generally constitute
>slightly higher requirements for compute and bandwdith than encodings 
>based on fixed layouts (XML is many more factors demanding). 
>The added advantage with TLV usage of course is ability to add new 
>TLVs easily without redefining the packet or the protocol.
>In addition, being able to optionally leave a TLV out during communication
>(the message example would have been perfectly decoded if TLV1 was
>never encoded).
>
>A small challenge that needs to be overcome for TLVs is to detect
>where failures happen (when you have a list or other compound structure). 
>This is mostly useful/needed for batching or configuring a list of elements. 
>If we were to use our implementation as a sample space: we had the "all 
>upto failed one applied" scheme, in which case a NACK with the failed 
>TLV Type is sent back.
>
>An interesting idea is to encode an 8 bit sequence number in the 
>type to find precisely which TLV failed.
>
>
>  
>

---

From: Jamal Hadi Salim <[email-masked]>
Date: 05 Mar 2004 21:00:00 -0500

> As far as I know, this is an inherent TLV encoding property. 

Alex,

nod

cheers,
jamal

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

---

From: "Wang,Weiming" <[email-masked]>
Date: Mon, 8 Mar 2004 22:35:21 +0800

Hi Jamal, Alex, and all,

I jsut want to have this email specifically for TLV format and List format discussion.

Firstly, I have to say that whether a List format is explicitly defined, it will be used in the
protocol. Actually current candidate protocols have all already used this kind of format
(pls allow me to mention that the format used at Page 23 in FACT is actually a list).
I'm sure it will be used more when the datapath part and other FE model entities are becoming 
more clear. The essence for a list is to describe a group of the same entities, its elements can 
be TLVs or any other elements. Of course, we may say that list format can surely be replaced 
by a TLV format, but I don't think we need to very intentionally to do like this, because it
is very obvious that list format saves lots of bits and make things more clear. I don't think we
need to sacrifice a lot just to nominally get a uniform name.  

To explicitly and uniformly define a list format in GRMP is just in the purpose of having the 
protocol file not too big. It is true we have saved lots of txt by doing like this. 

Cheers,
Weiming

----- Original Message ----- 
From: "Jamal Hadi Salim" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, March 06, 2004 10:00 AM
Subject: Re: [Forces-protocol] issue 1: packet encoding

> > As far as I know, this is an inherent TLV encoding property. 
����趇(�f��)��+-��z�k���X���+�m����5��_��?�������+-�w���+q�)��hr�

---

From: "Sandy Pavel" <[email-masked]>
Date: Mon, 8 Mar 2004 10:31:56 -0500

Alex is right. The Value field of a TLV can contain other TLVs but this
is the actual TLV definition.
I suppose this explicit representation was made only for clarification.
 
If we look at other protocols defined in the last few years, many use
TLV. The reasons are many and it
i no point in elaborating on this. I have noticed that XML was mentioned
here. This requires quite a bit 
of resources and seems to be more appropriate for an application-type
protocol rather than the one we try to
define here. (this is debatable, of course).
 
Sandy

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Alex Audu
Sent: March 5, 2004 5:36 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Forces-protocol] issue 1: packet encoding
 
Jamal,

Regards,
Alex.

Jamal Hadi Salim wrote:

cheers,
jamal

  _____  

 

     0                   1                   2                   3

 
     0                   1                   2                   3

 

XML encoding:
 
TLVs:
 
    0                   1                   2                   3

Example:
    0                   1                   2                   3

In addition, being able to optionally leave a TLV out during
communication
 
A small challenge that needs to be overcome for TLVs is to detect
where failures happen (when you have a list or other compound
structure). 
This is mostly useful/needed for batching or configuring a list of
elements. 
If we were to use our implementation as a sample space: we had the "all 
upto failed one applied" scheme, in which case a NACK with the failed 
TLV Type is sent back.

---

From: Alex Audu <[email-masked]>
Date: Mon, 08 Mar 2004 10:53:22 -0600

I have raised this same issue in the past.  We are hoping that the use 
of binary XML
will decrease the presure on resources. But then we should be able to 
support other
commonly available and efficient encoding of data for transport between 
FE and CE.

Alex.

Sandy Pavel wrote:

> Alex is right. The Value field of a TLV can contain other TLVs but 
> this is the actual TLV definition.
>
> i no point in elaborating on this. I have noticed that XML was 
> mentioned here. This requires quite a bit
>