Re: ForCES TLV size

Jamal，

Firstly， I agree it is quite possible the 16bit Length  shortage in Path-Data TLV will lead to severe problems for implementations.

Whereas, I just a little worry the solution proposal you presented below may also lead to a complex situlation for the usage of Path-Data TLV. 

Is it possible we just define that a Path-Data object is encapsulated by a data format of ILV rather than a TLV? This just extends the Length from 16bits to 32bits.

Other TLVs may face less data encapsulation than the Path-Data TLV, so we may just still keep them as TLVs.

thanks,
Weiming

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

> This issue was brought up by Fenggen, and was discussed by Joel in the
> last meeting. Joel and I had a discussion and we came up with the
> proposal below. 
> Fenggen and the rest of the ForCES community please take a look and
> comment. I feel this is the last issue we have before we close on the
> protocol; so if we can reach a quick compromise, that would be good for
> progress.
> 
> cheers,
> jamal
> 
> 
> Problem Statement:
> -----------------
> The TLV structure we have today for transporting data defines a 
> 16 bit length which makes TLVs larger than 64KB not feasible.
> Although  the protocol goes at great length to ensure one can transport
> (sub)objects at very granular level by using paths, and therefore
> eliminating this problem, it is feasible there may be a ForCES object
> that is unforseen that will not fit in 64KB. 
> 
> 
> Proposed solution:
> -----------------
> We add to the path-data TLV a new flag which says "this is multipart".
> The presence of the multipart flag changes the encoding of the
> path-data TLV to include two new 32 bit fields:
> a) a 32 bit value which carries the total content length
> b) A 32 bit value which carries the offset into the total
> length.
> 
> The general path-data layout with these two new fields then looks as
> follows:
>  T = Path-data
>      |
>      + -- flags (flag bit "this is multipart" is turned on)
>      + -- IDCount
>      + -- IDs
>      + -- TotalLength
>      + -- TotalOffset
>      + -- SPARSE/FULLDATA TLV
>           ....
>   .....
> 
> The contents of DATA TLV get concatenated to reconstruct the original
> object.
> 
> Example:
> -------
> For the sake of explaining the example, consider that we want to use
> the methodology described above with a 15 byte object and split it
> into 3 5-byte messages. The message flow would be:
> 
> message 1:
>  ..
>  ..
>  T = Path-data
>      |
>      + -- flags (flag bit "this is multipart" is turned on)
>      + -- IDCount = ...
>      + -- IDs = ...
>      + -- TotalLength = 15
>      + -- TotalOffset = 0
>      + -- SPARSE/FULLDATA TLV
>           5 byte content ..
> 
> message 2:
>  ..
>  ..
>  T = Path-data
>      |
>      + -- flags (flag bit "this is multipart" is turned on)
>      + -- IDCount = ...
>      + -- IDs = ...
>      + -- TotalLength = 15
>      + -- TotalOffset = 5
>      + -- SPARSE/FULLDATA TLV
>           5 byte content ..
> 
> message 3:
>  ..
>  ..
>  T = Path-data
>      |
>      + -- flags (flag bit "this is multipart" is turned on)
>      + -- IDCount = ...
>      + -- IDs = ...
>      + -- TotalLength = 15
>      + -- TotalOffset = 10
>      + -- SPARSE/FULLDATA TLV
>           5 byte content ..