Re: [tsvwg] A review of draft-ietf-tsvwg-udp-options-12

[Joseph Touch <[e-mail]>]

FYI, here’s where this appears to be going for fragments:

- OCS always comes first if present (it’s still optional in the same cases where UDP checksum is optional, e.g., when the entire UDP frame is a payload that is protected by some other layer, e.g., in a tunnel)

- FRAG can always come next if present (OCS still optional, per above), with the following format (moving things around a little to keep 32-bit alignment where possible):

	Kind/8, len = 10 or 12/8
	FRAGSTART/16	= location where the options end and frag data starts
	FRAGID/32
	FRAGOFFSET/16
	(For last frag) FRAGEND/16 = location where options continue after the frag for the final fragment

Other options that apply to that fragment come after this option but before where FRAGSTART points. This effectively puts the info needed for offload in one of two fixed locations (with and without OCS).

The frag data is not scrambled or reordered; it just comes in order as intended. Frag data always goes to the end of the IP packet data area UNLESS its the terminal fragment, in which case FRAGEND points to where post-reassembly UDP options occur.

Would this work?

Joe