[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: ULE Extension Headers
Hi Alain,
hope with this update your concerns are addressed. Also i am looking at (c)
of Gorry's views. Definitly wish to draft the other vision as well. So that
we can discuss the pros n cons
Best Regards,
William.
<snip>
4. SNDU Format
PDUs (IP packets and bridged Ethernet frames)are encapsulated using
ULE to form a SNDU. Each SNDU is sent as an MPEG-2 Payload Unit. The
encapsulation format to be used for PDUs is illustrated below:
<---------------------------- SNDU ----------------------------- >
+-+-+-------+------+---------+-----------+--------------+--------+
|D|E|Length | Type |Dest.Mac*|Ext.Header*| PDU | CRC-32 |
+-+-+-------+------+---------+-----------+--------------+--------+
Figure 1: SNDU Encapsulation
All multi-byte values in ULE (including Length, Type, and
Destination fields) are transmitted in network byte order (most
significant byte first). Appendix A provides informative examples of
usage.
4.1 The Destination Address Present Field
<no change>
4.2 Extension Header Present Field
The 2nd most significant bit(i.e. 14th bit) of the Length Field
carries the value of the Extension Header Present Field, the E-bit.
A Value of 0 indicates the absence of extension header for ULE.
Otherwise a value of 1 indicates presence of extension header
(see section 4.6).
By default, the E-bit value MUST be set to a value 0. i.e.
extension header doesn't exist.
4.3 Length Field
<no change>
4.4 End Indicator
<no change>
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 MUST have the value of 0x0800 in case of IPv4
4.6 SNDU Destination Address Field
<no change>
4.7 SNDU Extension Header Field
The SNDU extension header format to be used is illustrated below:
< ----------------------- Ext. Header Field ---------------------- >
+-+---------------+-----+--------------+----// ....... //----------+
|P|Ext.Header Type|NEHB |Ext. H Length |Ext. Header Param Value |
+-+---------------+-----+--------------+---// ....... //-----------+
Figure 2: Extension header format
4.7.1 Drop/Process(P-Bit) Field
The most significant bit of Ext.Header Type carries the value of the
Drop/Process Field, the P-bit. A Value of ZERO indicates MUST process
this ext. header, If cannot drop the packet, otherwise the value of 1
is the recevier decision to process or skip and proceed further.
By default, the P-bit value MUST be set to a value 0. i.e.
MUST process the Ext. Header.
4.7.2 Extension Header Type Field
The 7-bits extension header type field indicates the additional
information for the SNDU header, which has to be considered in
decoding/encoding of the SNDU payload.
The extension header types are yet to be finialized. TBD
For example,
0 - Security Header
1 - Section Packing
2 - Section number
3 - Payload Start Pointer/offset
4 - Source Mac Address
etc.. TBD
4.7.3 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.
4.7.4 Extension header Length
The 7-bit value that indicates the extension header value length, in
bytes, for the Extension header of ULE, excluding Ext. Header type
and Length.
4.7.5 Extension Header Param Value
This is the varible length parameter value for extension header. The
length of this parameter is set by Extension header length
(Section 4.7.4) based on the extension header type(Section 4.7.2).
For example,
Extension header type is 4 - Destionation Mac Address then,
Extension header length is 6 - i.e. 6 bytes of ext. header value
extension header param value is 00:50:c2:2f:42:43
Extension header type is 3 - Payload Start Pointer/offset then,
Extension header length is 2 - i.e. 2 bytes of offset where payload
starts
extension header param value is 20
This is the typical example, if we say some of the extension headers
as Mandatory and some are optional. In that case, all mandatory
extension headers comes first, then follows payload start offset ext.
header and all optional ext. headers next, if the receiver wishes to
consider these optional, its well and fine otherwise, it can just
discard and jump to the payload.
<snip>
-----Original Message-----
From: owner-ip-dvb@erg.abdn.ac.uk [mailto:owner-ip-dvb@erg.abdn.ac.uk]On
Behalf Of William StanisLaus
Sent: Friday, March 12, 2004 4:26 PM
To: ip-dvb@erg.abdn.ac.uk
Subject: 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.
***************************************************************************
***************************************************************************
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.
***************************************************************************