[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Réf. : RE: ULE Extension Headers
Hi,
>The consequence of having no D and E bit but a Type value would be that
the
>Type field could be renamed to Next Header field, which it then
essentially
>is. It would, however, require a different assigment strategy.
I fully agree with this suggestion.
I'm in charge of ULE implementation in the IST-SatIP6 demonstrator (IPv6
interconnection thanks Satellite)
and the current ULE definition needs additionnal fields to be usable in a
meshed satellite system with on-board switching.
As a matter of fact, we use nether D nor E. Only a type field is needed.
Best regards,
Sébastien Josset
"Bernhard Collini-Nocker" <bnocker@cosy.sbg.ac.at>@erg.abdn.ac.uk on
12/03/2004 10:17:07
Veuillez répondre à ip-dvb@erg.abdn.ac.uk
Envoyé par : owner-ip-dvb@erg.abdn.ac.uk
Pour : <ip-dvb@erg.abdn.ac.uk>
cc :
Objet : RE: ULE Extension Headers
Hi,
in my opionion it is a good idea to think about both the D bit and the E
bit
again.
The D bit is useful in those cases where a destination MAC address is
requested for filtering/addressing purposes. It could be a Type value as
well, altough this adds duplicate Types wrt to functionality.
The E bit could instead be a Type value as well and only if the format of
the header fields of the Ext header is not the same it could become a
different Ext header.
The consequence of having no D and E bit but a Type value would be that the
Type field could be renamed to Next Header field, which it then
essentially
is. It would, however, require a different assigment strategy.
Other suggestions and/or opinions?
Regards,
Bernhard
>
> Hi everyone,
> I just started to draft the defintion for ULE extension headers, but i am
> becoming creative and crazy :), I have pasted the updation which
> i have done,
> though it is not complete, Wish to have your comments and views.
>
>
> <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 -----------------------------
>
>
+-+-------+------+---------------------+----------------+--------+
> |E|Length | Type | 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
> Can be removed and moved on to Extension Header
>
> 4.2 Extension Header Present Field
>
> The most significant bit of the Length Field carries the
> value of the
> Extension Header Present Field, the E-bit. A Value of 1
> indicates the
> absence of extension header for ULE. Otherwise a value of
> 0 indicates
> presence of extension header(see section 4.6).
>
> By default, the E-bit value MUST be set to a value 1. 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 SHOULD have the value of 0x0800 in case of IPv4
>
>
> 4.6 SNDU Extension Header Field
> The SNDU extension header format to be used is illustrated below:
>
> < ----------------------- Ext. Header Field
> ---------------------- >
> +----------------+-----+---------------+----// .......
> //----------+
> |Ext.Header Type |NEHB | Ext. H Length |Ext. Header Param
> Value |
> +----------------+-----+---------------+---// .......
> //-----------+
>
> Figure 2: Extension header format
>
> 4.6.1 Extension Header Type Field
> The 4-bit extension header type field indicates the additional
> information for the SNDU header, which has to be considered in
> decoding/encoding of the SNDU payload. But it is not MANDATORY
> to consider all the extension headers, again it is an
> implementation
> decision.
>
> The extension header types are yet to be finialized(MAX 15 different
> ext. header types). TBD
>
> For example,
>
> 0 - Security Header
> 1 - Section Packing
> 2 - Section number
> 3 - Payload Start Pointer/offset
> 4 - Source Mac Address
> 5 - Destination Mac Address
> etc.. TBD
>
> 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.
>
> 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.
>
> 4.6.4 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.6.3) based
> on the
> extension header type(Section 4.6.1).
>
> For example,
>
> Extension header type is 5 - 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.
>
> SNDU Destination Address Field
> <no change> will be moved on to 4.6 subsection at
> appropirate location.
>
>
> <snip>
>
>
ALCATEL SPACE
Research Department/Advanced Telecom Satellite Systems
Tel : +33 (0)53435 5104 / Fax : +33 (0)53435 5560
Porte : W218 / E-Mail : sebastien.josset@space.alcatel.fr
ALCATEL SPACE