[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: ULE Extension Headers
Hi Alain,
Well, my initial proposal on ULE extension headers is also to retain the
D-Bit, But today when i really start the draft, i went crazy, like why don't
we push the Dest. Mac into Ext. Header. I understand your concern here,
saving 2 bytes(Satellite traffics are very expensive ;)).
in that case, i should work out in a better way...
Regarding 4-bit for Ext. header Type, initially i thought, we'll not be
having ext. header more than 15. Also one bit for Next Ext. Header. Then
remaining 3 bits can be used for ext. header Length, if Length is going to
be multiples of 2 i.e. it supports max 7 * 2 = 14 bytes of ext. header
value, which is much bigger to support todays needs. But i wonder the future
enhancements.
If we agree on 8-bits of Ext. Header type field, we can support the
Drop/process next bit, incase the Receiver is uneducated about the ext.
header type received.
Remaining 1 bit for next ext. header field and 7 bits for ext. header
length, which was the orginal proposal :)
+----------------+-----+---------------+----// ....... //----------+
|Ext.Header Type |NEHB | Ext. H Length |Ext. Header Param Value |
+----------------+-----+---------------+---// ....... //-----------+
Ext. Header type = 1 byte
NEHB = 1 bit ( if 0 Ext. Header is present, otherwise not present)
Ext. H Length = 7 bits ( Length here is only the Ext. Header Param Value
length)
Ext. Header Param Value = variable length based on Ext. H Length i.e. MAX
127 bytes
Best Regards,
William
-----Original Message-----
From: owner-ip-dvb@erg.abdn.ac.uk [mailto:owner-ip-dvb@erg.abdn.ac.uk]On
Behalf Of Alain RITOUX
Sent: Friday, March 12, 2004 2:05 PM
To: ip-dvb@erg.abdn.ac.uk
Subject: Re: ULE Extension Headers
Hi William,
First thanks, for drafting. I have seval concerns :
- Destination Address Field
You propose to make it become one of the extension headers, and I
admit I had the same idea, but I think extension headers should
be reserved for additinal data that are not usually present in SNDU,
because such mechanism has an extra cost (2 bytes).
The current definition of ULE, makes the Dest Add field a MUST for all
unicast traffic. So the bit gained in ULE header finally gives extra
overhead of 2 bytes, and if it is for 90% (no idea about the value ;-))
of ULE SNDU, it's an heavy cost.
So I would be in favour of keeping the destination Address bit,
and create th Extension header bit separate (i.e. stealing one more
bit from length field).
- The Ext Header format
Why 4 bits for ext header type ? It makes following info (length, data
..) not aligned on byte boundary. I would prefer 8 bits type.
- The Ext Header Processing
You state that ext header processing (I mean internal processing, not
blind parse) is not mandatory, but I think that ext header that changes
payload semantic should be made mandatory (i.e. cause the SNDU to be
dropped if type is not known).
For that I would propose (with an 8 bit type) to split ext header type
byte in
1 bit do idicate behaviour (drop/process next)
7 bits for exte headertype itself
> ... snip ...
> 4.5 Type Field
> <no change>, Even if the extension headers are present, the Type
Field
> carries the final SNDU payload type, i.e. even the payload is
> scrambled
> IP packet, it SHOULD have the value of 0x0800 in case of IPv4
==> it MUST have the value of 0x800 in case of IPv4
>
> 4.6.2 Next Extension header present field
>
> The most significant bit of the extension header Length Field
carries
> the value of the Next Extension Header Present Field, the N-bit.
> A Value of 0 indicates the absence of next extension header.
Otherwise
> a value of 1 indicates presence of extension header.
>
> By default, the N-bit value MUST be set to a value 0. i.e.
> next extension header doesn't exist.
Wherever this bit is, it would be better to have the ULE-end-indicator /
padding values, make this bit tell "no extension headers"
So the opposite value would do it:
A Value of 1 indicates the absence of next extension header. Otherwise
a value of 0 indicates presence of extension header.
By default, the N-bit value MUST be set to a value 0. i.e.
next extension header doesn't exist.
>
> 4.6.3 Extension header Length
>
> The 7-bit value that indicates the extension header value length, in
bytes,
> for the Extension header of ULE.
Precision to add : This Length does NOT include the first two bytes of
Extension Header (type-length pair).
Cheers.
Alain.
--
Alain RITOUX
Tel +33-1-39-30-92-32
Fax +33-1-39-30-92-11
visit our web http://www.6wind.com
***************************************************************************
This message is proprietary to Future Software Limited (FSL)
and is intended solely for the use of the individual to whom it
is addressed. It may contain privileged or confidential information
and should not be circulated or used for any purpose other than for
what it is intended.
If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message.
FSL accepts no responsibility for loss or damage arising from
the use of the information transmitted by this email including
damage from virus.
***************************************************************************