Subject: Re: problem about Packet Redirect TLV encapsulation

From: Jia Fenggen <[email-masked]>
Date: Tue, 17 Jan 2006 11:19:27 +0800

Hi,Evangelos:
    According to your comments then we have non 32bits aligned redirect 
TLVs encapsulation in a Packet Redirect Message,the message is shown below: 

common 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |version| rsvd  | Message Type  |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Source ID                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Destination ID                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Correlator                           |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Flags                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The message is 32 bit aligned.(page 26 of draft 06)

Redirect TLVs: 
 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Type = Redirect        |               Length          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          LFB Class ID                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        LFB Instance ID                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Meta Data TLV                          |
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Redirect Data TLV                      |
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
this conflict with the saying about the common header length 
definition(page 26 of the 06 draft),which says "length of header + the rest 
of the message in DWORDS (4 byte increments)." And still i think there is 
the same probem with the metadata ILV especially when the meta data is not 
32bits.what's you opinion?

Yours,fenggen

>From: "Evangelos Haleplidis" <[email-masked]>
>To: "'Jia Fenggen'" <[email-masked]>
>Subject: RE: problem about Packet Redirect TLV encapsulation
>Date: Mon, 16 Jan 2006 17:46:54 +0200
>
>Hello Jia,
>
>I'm not part of the WG and I'm not 100% sure, but I think that the answer 
to
>your question lies with the definition of the TLV (page 31 of the 06 
draft).
>The Length field is measured in octects and includes the Type, the Length
>and the Data without the padding. So, the actual packet is: Length-4.
>
>While this is not clearly stated in the draft I think this is what the WG
>mean. If not then nothing can work correctly, because you cannot insert
>variable size in a TLV.
>
>I hope this clears it up,
>
>Regards,
>
>Evangelos Haleplidis.
>
>-----Original Message-----
>From: Forwarding and Control Element Separation
>[mailto:[email-masked]] On Behalf Of Jia Fenggen
>Sent: Monday, January 16, 2006 10:44 AM
>To: [email-masked]
>Subject: problem about Packet Redirect TLV encapsulation
>
>Hi,all:
>     I have excerpt the following text from the 
draft-forces-protocol-6.txt
>for easing my explanation:
>
> >Redirect Data TLV
> >      This is a TLV describing one packet of data to be directed via the
> >      redirect operation.  The TLV format is as follows:
> >
> >   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >   |    Type = REDIRECTDATA        |               Length          |
> >   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >   |                        Redirected Data                        |
> >   .                                                               .
> >   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> >Redirected Data:
> >      This field presents the whole packet that is to be redirected.
> >      The packet should be 32bits aligned.
> >
>my question is:
>     how to use the above TLV to express the vary sized redirect 
packet?since
>the length field is the total length of the padded redirect packet in quad
>words including the type and length field, when  CE receive such a 
redirect
>packet,it can't infer from the TLV how long  the redirect packet really
>is,should we further define the Redirect Data to include the real length 
of
>the redirect packet?
>
>Yours,fenggen
>
>_________________________________________________________________
>与联机的朋友进行交流，请使用 MSN Messenger:  http://messenger.msn.com/cn
>
>

_________________________________________________________________
与联机的朋友进行交流，请使用 MSN Messenger:  http://messenger.msn.com/cn

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 16 Jan 2006 22:24:45 -0500

Evangelos was quite correct.
The length of the TLV (see section 6.2 at the top of page 31) is in 
octets.  The length of the total message is in DWORDs, (as described on 
page 26) but that is not the relevant length.  The length field (the L 
portion of TLV) of the Redirect TLV gives the length in octets of the 
packet being redirected.

Yours,
Joel M. Halpern

At 10:19 PM 1/16/2006, Jia Fenggen wrote:
>definition(page 26 of the 06 draft),which says "length of header + the 
>rest of the message in DWORDS (4 byte increments)." And still i think 
>there is the same probem with the metadata ILV especially when the meta 
>data is not 32bits.what's you opinion?
>
>Yours,fenggen

---

From: Jia Fenggen <[email-masked]>
Date: Tue, 17 Jan 2006 13:22:53 +0800

Thanks!Catched what you are saying.
If I understand well then there will possibly be some padding octets in the 
final ForCES message in order to compy with the 32bits alligment requriment 
and i may choose to use an arbitrary value for the padding purpose,am i 
right?

>From: "Joel M. Halpern" <[email-masked]>
>Reply-To: "Joel M. Halpern" <[email-masked]>
>Subject: Re: problem about Packet Redirect TLV encapsulation
>Date: Mon, 16 Jan 2006 22:24:45 -0500
>
>octets.  The length of the total message is in DWORDs, (as described 
>on page 26) but that is not the relevant length.  The length field 
>(the L portion of TLV) of the Redirect TLV gives the length in 
>octets of the packet being redirected.
>
>Yours,
>Joel M. Halpern
>
>>definition(page 26 of the 06 draft),which says "length of header + 
>>the rest of the message in DWORDS (4 byte increments)." And still i 
>>think there is the same probem with the metadata ILV especially 
>>when the meta data is not 32bits.what's you opinion?
>>
>>Yours,fenggen

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 17 Jan 2006 00:27:17 -0500

We probably should specify in the protocol spec that the padding after the 
last TLV (if any such padding is need) must be zero on transmission and 
must be ignored upon reception.

Yours,
Joel

At 12:22 AM 1/17/2006, Jia Fenggen wrote:
>If I understand well then there will possibly be some padding octets in 
>the final ForCES message in order to compy with the 32bits alligment 
>requriment and i may choose to use an arbitrary value for the padding 
>purpose,am i right?
>
>
>ÓëÁª»úµÄÅóÓÑ½øÐÐ½»Á÷£¬ÇëÊ¹ÓÃ MSN Messenger:  http://messenger.msn.com/cn

---

From: Jia Fenggen <[email-masked]>
Date: Tue, 17 Jan 2006 13:36:19 +0800

Agree,and for the consistency,i think the same rule applys to all the other 
TLVs.

Yours,fenggen

>Date: Tue, 17 Jan 2006 00:27:17 -0500
>
>We probably should specify in the protocol spec that the padding 
>after the last TLV (if any such padding is need) must be zero on 
>transmission and must be ignored upon reception.
>
>Yours,
>Joel
>
>>If I understand well then there will possibly be some padding 
>>octets in the final ForCES message in order to compy with the 
>>32bits alligment requriment and i may choose to use an arbitrary 
>>value for the padding purpose,am i right?
>>
>>
>>>The length of the TLV (see section 6.2 at the top of page 31) is 
>>>in octets.  The length of the total message is in DWORDs, (as 
>>>described on page 26) but that is not the relevant length.  The 
>>>length field (the L portion of TLV) of the Redirect TLV gives the 
>>>length in octets of the packet being redirected.
>>>
>>>Yours,
>>>Joel M. Halpern
>>>
>>>>definition(page 26 of the 06 draft),which says "length of header 
>>>>+ the rest of the message in DWORDS (4 byte increments)." And 
>>>>still i think there is the same probem with the metadata ILV 
>>>>especially when the meta data is not 32bits.what's you opinion?
>>>>
>>>>Yours,fenggen
>>

---

From: Weiming Wang <[email-masked]>
Date: Tue, 17 Jan 2006 22:43:32 +0800

Avri,

Based on the discussion, I suggest changes as below:

Page 32(Section 6.2):

<original>
   TLV Value (variable):
           The TLV Value field carries the data.  For
           extensibility, the TLV value may in fact be a TLV.
           TLVs must be 32 bit aligned
</original>

<change to>
   TLV Value (variable):
           The TLV Value field carries the data.  For
           extensibility, the TLV value may in fact be a TLV.
           TLVs must be 32 bit aligned. Padding used
           for the alignment must be zero on transmission and must
           be ignored upon reception.

   All types of TLVs used in this document follow the TLV rules described as
above.
</change to>

Thanks,
Weiming

From: "Jia Fenggen" <[email-masked]>

---

From: "Guo, Xiaoyi" <[email-masked]>
Date: Wed, 18 Jan 2006 09:59:47 +0800

hi,weiming,

Joel said the padding after the last TLV must be zero.
If the TLV section changes to the follow, it looks 
the padding for all TLVs should be zero instead of the last one,
right?

cheers,
xiaoyi

----- Original Message ----- 
From: "Weiming Wang" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, January 17, 2006 10:43 PM
Subject: Re: problem about Packet Redirect TLV encapsulation

| Avri,
| 
| Based on the discussion, I suggest changes as below:
| 
| Page 32(Section 6.2):
| 
| <original>
|   TLV Value (variable):
|           The TLV Value field carries the data.  For
|           extensibility, the TLV value may in fact be a TLV.
|           TLVs must be 32 bit aligned
| </original>
| 
| <change to>
|   TLV Value (variable):
|           The TLV Value field carries the data.  For
|           extensibility, the TLV value may in fact be a TLV.
|           TLVs must be 32 bit aligned. Padding used
|           for the alignment must be zero on transmission and must
|           be ignored upon reception.
| 
|   All types of TLVs used in this document follow the TLV rules described as
| above.
| </change to>
| 
| Thanks,
| Weiming
| 
| From: "Jia Fenggen" <[email-masked]>
| 
| > Agree,and for the consistency,i think the same rule applys to all the other
| > TLVs.
| >
| > Yours,fenggen
| >
| > >From: "Joel M. Halpern" <[email-masked]>
| > >
| > >We probably should specify in the protocol spec that the padding
| > >after the last TLV (if any such padding is need) must be zero on
| > >transmission and must be ignored upon reception.
| > >
| > >Yours,
| > >Joel
| > >

---

From: Weiming Wang <[email-masked]>
Date: Wed, 18 Jan 2006 10:15:35 +0800

Xiaoyi,

I think the rule should apply to all TLVs rather than the last TLV. Only should
we note that for nested TLVs padding is possible only in the last(the deepest)
TLV.

thanks,
weiming

From: "Guo, Xiaoyi" <[email-masked]>

---

From: "Guo, Xiaoyi" <[email-masked]>
Date: Wed, 18 Jan 2006 15:21:36 +0800

That's a good suggestion,  i agree. and Joel ?

cheers,
xiaoyi

----- Original Message ----- 
From: "Weiming Wang" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, January 18, 2006 10:15 AM
Subject: Re: problem about Packet Redirect TLV encapsulation

| Xiaoyi,
| 
| I think the rule should apply to all TLVs rather than the last TLV. Only should
| we note that for nested TLVs padding is possible only in the last(the deepest)
| TLV.
| 
| thanks,
| weiming
| 
| From: "Guo, Xiaoyi" <[email-masked]>
| 
| > hi,weiming,
| >
| > Joel said the padding after the last TLV must be zero.
| > If the TLV section changes to the follow, it looks
| > the padding for all TLVs should be zero instead of the last one,
| > right?
| >
| > cheers,
| > xiaoyi
| >
| > ----- Original Message -----
| > From: "Weiming Wang" <[email-masked]>
| > To: <[email-masked]>
| > Sent: Tuesday, January 17, 2006 10:43 PM
| > Subject: Re: problem about Packet Redirect TLV encapsulation
| >
| >
| > | Avri,
| > |
| > | Based on the discussion, I suggest changes as below:
| > |
| > | Page 32(Section 6.2):
| > |
| > | <original>
| > |   TLV Value (variable):
| > |           The TLV Value field carries the data.  For
| > |           extensibility, the TLV value may in fact be a TLV.
| > |           TLVs must be 32 bit aligned
| > | </original>
| > |
| > | <change to>
| > |   TLV Value (variable):
| > |           The TLV Value field carries the data.  For
| > |           extensibility, the TLV value may in fact be a TLV.
| > |           TLVs must be 32 bit aligned. Padding used
| > |           for the alignment must be zero on transmission and must
| > |           be ignored upon reception.
| > |
| > |   All types of TLVs used in this document follow the TLV rules described as
| > | above.
| > | </change to>
| > |
| > | Thanks,
| > | Weiming
| > |
| > | From: "Jia Fenggen" <[email-masked]>
| > |
| > | > Agree,and for the consistency,i think the same rule applys to all the
| other
| > | > TLVs.
| > | >
| > | > Yours,fenggen
| > | >
| > | > >From: "Joel M. Halpern" <[email-masked]>
| > | > >
| > | > >We probably should specify in the protocol spec that the padding
| > | > >after the last TLV (if any such padding is need) must be zero on
| > | > >transmission and must be ignored upon reception.
| > | > >
| > | > >Yours,
| > | > >Joel
| > | > >