Subject: Réf. : RE: ULE Extension Headers

From: [email-masked]
Date: Fri, 12 Mar 2004 11:24:21 +0100

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" <[email-masked]>@erg.abdn.ac.uk on
12/03/2004 10:17:07

Veuillez répondre à [email-masked]

Envoyé par :      [email-masked]

Pour : <[email-masked]>
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 : [email-masked]

ALCATEL SPACE