Background Information:OK.
On Page 19 of RFC2960, the following is stated regarding Chunk Length:
Chunk Length: 16 bits (unsigned integer)
This value represents the size of the chunk in bytes including the
Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields.
Therefore, if the Chunk Value field is zero-length, the Length
field will be set to 4. The Chunk Length field does not count any
padding.
On Page 20, the following is stated for the TLV:
Chunk Parameter Length: 16 bits (unsigned integer)
The Parameter Length field contains the size of the parameter in
bytes, including the Parameter Type, Parameter Length, and
Parameter Value fields. Thus, a parameter with a zero-length
Parameter Value field would have a Length field of 4. The
Parameter Length does not include any padding bytes.
By looking at all the Chunk formats, I can see that if there is no TLV
present, then the Chunks will always be a multiple of 4 by design. So the
only time a chunk will follow on a non-4 byte boundary is when a TLV is
present.
It appears to me that the statement on page 20 under "Chunk ParameterFrom the length given in the length field you know how may padding
Length" is the only one that applies. Shouldn't the Chunk Length then
contain the padded bytes in the TLV? If it is not then how will the receive
verify the Adler-32 checksum. The checksum of the packet is calculated for
the whole packet including the padded bytes.
SalMichael.Tuexen AT micmac.franken.de
_______________________________________________
discussion mailing list
discussion AT sctp.de
http://www.sctp.de/mailman/listinfo/discussion
Archive powered by MHonArc 2.6.19+.