Re: [forces] IPv4prefix packing

[Jamal Hadi Salim <hadi at mojatatu.com>]

2012/2/2 Chuanhuang Li <chuanhuang_li at hotmail.com>:
> Hi, Jamal and all
>      If we consider the alignment issue, besides the type of IPv4Prefix,
> IPv6Prefix and
> EncapTable, VlanInputTable in EtherClassifier also need to be modified. The
> way to solve
> alignment with adding Reserved field, please see the attachment.

I think this is fine - Note: I dont feel as strongly about this as i
did about the
ipv4 prefixing.

> I agree to Jamal's modification suggestion.  But, i still think this is just
> an FE's implementation issue.
> The main goal of LFB definition is that CE can control and configure FEs
> implemented by different users, not
> guiding user to implement an FE.
> The alignment said in ForCES protocol and the aligment in FE's
> implementation are two different issues.
> If user sends ForCES message with TLV length not multiple of 32 bits,
> Padding is required.
> Whatever the LFB is defined, this requirement can be reached. But the LFB
> can be implemented in different ways.
> For example, the "SupportedLFBType" defined in FEObject LFB,
>                 <dataTypeDef>
>                 <name>SupportedLFBType</name>
>                 <synopsis>table entry for supported LFB</synopsis>
>                 <struct>
>                   <component componentID="1">
>                     <name>LFBName</name>
>                     <synopsis>
>                       The name of a supported LFB class
>                     </synopsis>
>                     <typeRef>string</typeRef>
>                   </component>
>                   <component componentID="2">
>                     <name>LFBClassID</name>
>                     <synopsis>the id of a supported LFB class</synopsis>
>                     <typeRef>uint32</typeRef>
>                   </component>
>                   ......
> LFBName is string type, LFBClassID, uint32 type, respectively.
> User can implement this type in the following way:
> typedef struct SupportedLFBType{
>         UINT8    LFBName[FEOBJECTLFB_MAX_STRING_LENGTH];
>         UINT32   LFBClassID;
>         ......
> The macro "FEOBJECTLFB_MAX_STRING_LENGTH" used by LFBName can be any value
> that user wants to use
> (for alignment, Usually be multiple of 32 bits).
> But if user encapsulates the information into TLV, the string length is the
> actual length
> of the value. It is not multiple of 32 bits in most cases.

Strings are easy.
You have no choice but to pack variable sized entities(like strings) in TLV
or ILV. In the case the string size is not 32-bit aligned, xLV must be
padded to be
32-bit aligned. So accessing the on-the-wire format is alignment friendly.
Imagine instead of a string you have a uint8 in the place of LFBName;
then the issue is clear.

cheers,
jamal