PDU Concat specification - design options we could explore

[Gorry Fairhurst <gorry@erg.abdn.ac.uk>]

It would be good to look at posisble other approaches to the header 
format shown in section 3.2 (the PDU-Concat Extension) of:

http://tools.ietf.org/wg/ipdvb/draft-ietf-ipdvb-ule-ext/draft-ietf-ipdvb-ule-ext-00.txt


Currently the draft proposes the following format for concatenating PDUs 
into a SNDU. This sets the most significant bit of the first byte of the 
PDU-Length field to zero (shown X below).

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|           Length  (15b)     |  Type = 0x<#NH-PDU-CAT>       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Receiver Destination NPA Address  (6B)             |
      +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               |        CONCAT-PDU-Type        | 

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |X|      PDU-Length-1  (15b)    |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
      =                        PDU-1                                  =
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |X|      PDU-Length-2  (15b)    |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
      =                        PDU-2                                  =
      |                                                               |

                                 More PDUs as required

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             (CRC-32)                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

During the last WG call, there were comments on possible usage of this 
"X" bit.

Christian wrote:
> (S.1) Regarding the PDU-Concat Extension:
> Maybe we can somehow use the (currently unused) most-significant
> bit in the first byte of they PDU-Length field?
> Of course, as nothing comes for free, every possible use of
> it will complicate the receiver processing.
> Nevertheless, we should consider it. My suggestions are:

>    (a) It could be used to selectively enable a type field for
> each concatenated PDU, i.e. sort of "Type Field present indicator"
> (denoted by T). Of course it could also be an "absent indicator" ;-). 
> From now on, I'll denote the PDU-Length field along with the
> optional type field as "concat header". The first concat header
> must have T=1 to indicate the type of the payload. After that one,
> if in subsequent concat headers T=0 then the the type field is
> omitted and the type is the same as indicated in the last
> concat header which had a type field (T=1).

> This also gives us the option to use extension headers in
> concatenated PDUs. The question is if we should allow them.
> I might add that using the T-bit would make the CONCAT-PDU-Type
> of the current draft version unnecessary.


> I also discussed this point with Gorry. It would be glad if
> we could get some comments on this one.

I would like to be sure we understood this and the WG comes to the 
correct decision.

In the first draft I made, there was a Type field for each PDU.  The 
discusssions that followed made me doubt that this was the correct way: 
many PDUs were likely to have the same Type, it did not seem sensible to 
mix IPv4 with IPv6 or MPLS, VLAN traffic in the same concatenated PDU, 
and certainly it would make processing more complex (i.e. more error 
prone). So, in the draft with Bernhard we added the rule that all PDUs 
must have the Type within the concatenated PDU (your inputs helped 
motivate this).

The T-bit seems a middle ground, allowing both varients at additional 
complexity. I'm interested to see where this can help... are there 
use-cases in which this would be desirable? Anybody have thoughts?


>    (b) We could also use the MSbit for padding purposes,
> i.e. to achieve alignment (e.g. 2- or 4-byte) for the
> concatenated PDUs.
> The bit (P) would then control the presence of a padding control
> byte right after the PDU-Length field. The content of this padding
> control byte (PDU-Pad) is interpreted as the number of (additional)
> padding bytes (containing the hexadecimal value 0xff) preceding the
> start of the concatenated PDU.

> Example:
> If P=1 and the PDU-Pad field has a value of 2, this means that
> 2 bytes of padding follow the padding control field. This means
> that in total the PDU is padded by 3 bytes (including PDU-Pad).
>
> If PDU-Pad=0, then we've a 1-byte of padding.
<snip>


How big an issue is this? The byte stream itself in which the SNDUs are 
carried can result in odd alignments. One of the strengths of removing 
the type field was that it reduced the number of possibly non-byte 
aligned 16-bit numbers, although the PDU-Length field (as above) still 
needs to be placed in a 16 bit register, and the data move that 
marshalls the PDU into its destination could in some architectures 
benefit from starting on an aligned address. So, I'm not sure what 
people feel about the use of padding to provide byte-alignment?

If anyone has thoughts or opinions on either of these, do tell us. is a 
T-bit a good use? Is a form of P-bit good use? Should we reserve X 
(assign 0) as in the current draft?

Gorry