Subject: ULE Extension Headers

From: William StanisLaus <[email-masked]>
Date: Fri, 12 Mar 2004 01:01:09 -0500

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>

---

From: Alain RITOUX <[email-masked]>
Date: Fri, 12 Mar 2004 09:34:52 +0100

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 ...
==> it MUST have the value of 0x800 in case of IPv4

>         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.

>         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

---

From: "Bernhard Collini-Nocker" <[email-masked]>
Date: Fri, 12 Mar 2004 10:17:07 +0100

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

---

From: "William StanisLaus" <[email-masked]>
Date: Fri, 12 Mar 2004 16:25:41 +0530

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 = 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: [email-masked] [mailto:[email-masked]]On
Behalf Of Alain RITOUX
Sent: Friday, March 12, 2004 2:05 PM
To: [email-masked]
Subject: Re: ULE Extension Headers

Hi William,

- The Ext Header format

Cheers.
Alain.

***************************************************************************
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.
***************************************************************************

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 12 Mar 2004 11:22:14 +0000

There's lots of ideas in here.  Here are my thoughts for the melting pot...

> of ULE SNDU, it's an heavy cost.

I agree, it is common to have a destination address.
It also is one that could in future  be deserving of hardware support
- that's also a (small) motive for a fixed position within the header.

> ..) not aligned on byte boundary. 

Yes - there's a processor cost in this. Is there also cost in a one-bit flag
to indicate extensions present - which has to be parsed every SNDU?

> I would prefer 8 bits type. 

> dropped if type is not known). 

Yes - but we already have these (mandatory) extensions supported using
the private (IANA assigned) Type field, as in bridging.

I do like Bernhard's email suggesting a renaming of the current Type-1 
field as
"next-header", I was unhappy with the names Type-1 and Type-2.

---

From: "William StanisLaus" <[email-masked]>
Date: Fri, 12 Mar 2004 19:39:17 +0530

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

        <---------------------------- SNDU ----------------------------- >
        +-+-+-------+------+---------+-----------+--------------+--------+
        |D|E|Length | Type |Dest.Mac*|Ext.Header*|     PDU      | CRC-32 |
        +-+-+-------+------+---------+-----------+--------------+--------+

        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    |
        +-+---------------+-----+--------------+---// ....... //-----------+

        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

        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.

      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: [email-masked] [mailto:[email-masked]]On
Behalf Of William StanisLaus
Sent: Friday, March 12, 2004 4:26 PM
To: [email-masked]
Subject: RE: ULE Extension Headers

Hi Alain,

Best Regards,
William

-----Original Message-----

Hi William,

- The Ext Header format

Cheers.
Alain.

---

From: Alain RITOUX <[email-masked]>
Date: Fri, 12 Mar 2004 16:25:18 +0100

> hope with this update your concerns are addressed. Also i am looking at (c)
Thanks, with this updtae, evry thing seems fine for me.

> we can discuss the pros n cons
goodn this will provide a solid ground for discusssion.

Cheers.
Alain.

---

From: "William StanisLaus" <[email-masked]>
Date: Mon, 15 Mar 2004 10:45:54 +0530

Few more updates..Please comment if you have any concerns :), Will post the
other two((a) and (c)) versions soon :)
so that we can debate and take the best out of three approaches.

Smile,
William StanisLaus | Design Engineer - FS, Nera Dept
email: [email-masked] | Telephone: +91 44 24330550 Extn: 282
Mobile: +91 98411 57902
www.futsoft.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Alain RITOUX
Sent: Friday, March 12, 2004 8:55 PM
To: [email-masked]
Subject: Re: ULE Extension Headers

Cheers.
Alain.