Subject: Re: ULE Extension Headers

From: [email-masked]
Date: Thu, 22 Apr 2004 10:58:11 +0200

William StanisLaus wrote:

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

Some more reflexions about extension headers

1) Location
============

I think that any extension header should be placed AFTER any non
optional header part. This would allow for hardware management of
Destination Field (if present).

So, IF L2 encryption is needed, and IF extension headers are used
to achieve this, then the piece of info will be stored AFTER mac addr.
Hence the MAC addr would be in clear text

2) Optional extension headers
===============================

I know, that's what I proposed ;-) but I had some other thought
about it, and I don't see real use-case for them. If I look into
IPv6 examples, what is optional is restricted to some options of
some extension headers (Destination, Hop by Hop). The Extension
headers themselves are NOT optionnal at all.

So I think that proposing such a flexible mech is maybe overkilling,
and I would make a second proposition of extension headers that don't
have the Drop/Process bit. In this case, There is no need for blind
parsing, therefore the length field is not mandatory any more, so the
extension header can then be :

   <-------- Ext. Header Field --------------- >
   +-+-------------+----// ....... //----------+
   |N|Ext.Hdr Type |Ext. Header Param Value    |
   +-+-------------+---// ....... //-----------+

With
   N:    Next Extension header present field,
         Reverse semantic as before : 1 for absence 0 for presence
         this is to be identical to the "Extension Header Present Field"
         in the SNDU header.
   Type: Type of exte header, separate namespace, IANA assigned,
         (same semantic as before)
   The param value is type dependat, and may include length if needed.
   This param value can be emty (i.e. 0 byte)

With this approach, we can still chain extension hearders, and have
for each ext header an overhead of 1 byte.

3) Examples
============

The examples in section 4.7.2 and 4.7.5 althought interesting, should be
removed from the ULE specs, and be in a separate I-D, hence keeping ULE
neat and make, it progress independantkly from discussion on extension
headers semantic.

Any comment welcome.
Alain.

> <snip>
>      4. SNDU Format 

> ... snip ...
>         4.7.2 Extension Header Type Field
>         The 7-bit extension header type field indicates the additional
>         information for the SNDU header, which MUST be considered in 
>         processing the SNDU payload, based on the P-Bit (see section 4.7.1)
> 	
>         The extension header types are yet to be finialized. TBD
> 	
>         For example,
> 	
>         0 - Security Header
>         1 - Section Packing
>         2 - Section number
>         3 - Source Mac Address
>         4 - Source Identifier
>         5 - QoS Classifier
>         etc.. TBD
>         
> ... snip ...
> 
>         4.7.5 Extension Header Param Value
>         This is the variable length parameter value for extension header. The
>         length of this parameter is set by extension header length (see section
>         4.7.4) based on the extension header type( see section 4.7.2).
> 
>         For example,
> 
>         a) Security Header
>         When security features are supported by ULE
>         TBD
> 
>         b) Section Packing
>         Provision to combine more than one PDU(IP/Bridged Packet) in single ULE
>         Header, provided packet identifier (Source PID and MAC, Destination PID
>         and MAC, if QoS not considered, otherwise packet identifier MAY differ
>         based on QoS) across these packets are identical.
> 
>         Three IP Packets has to be transmitted in a SNDU.
>         Extension header type is 01 i.e. P-Bit = 0 ( MUST Process) and type as
>         Section Packing.
>         Extension header length is 06 i.e. N-Bit = 0 (No more extension header)
>         and 6 bytes of ext. header value length
>         
>         Regarding extension header param value, for every PDU, first four bit
>         are used for index, next 12 bit are used for offset value in the SNDU
>         payload from start of the payload.
>         
> 
>              <---- Ext.Header ---><------------PDU--------------->  
>         ...//+--+--+-+--+-+--+-+--+------+------------+-----------+...//
>              |01|06|0|00|1|40|2|B2| IP1  |    IP2     |     IP3   |
>         ...//+--+--+-+--+-+--+-+--+------+------------+-----------+...//
>                        |____|____||      |            |
>                             |____|_______|            | 
>                                  |____________________|
> 
>         Figure 3: Section Packing example
>         In the above figure, in ext. header param value,
>         0  - indicates the first packet.
>         00 - indicates the first packet offset value in payload.
>         1  - indicates the second packet.
>         40 - indicates the second packet offset/start position value in HEX
>              i.e 64 decimal.
>         2  - indicates the third packet.
>         B2 - indicates the third packet offset/start position value in HEX
>              i.e 178 decimal
> 	
>         c) Section Number
>         In case,  support for connection oriented approach required and Error
>         Correction is needed. There MUST be an agreement with Transmitter and
>         Receiver to support Section Number. By which, LOST/ERROR SNDU’s can be
>         corrected by requesting to retransmit those SNDU’s alone, based on the
>         Section Number.
> 
>         <author note: new ULE type has to be defined to identify the request
>         from receiver to transmitter to retransmit the requested Section/SNDU>
> 
> 
>         d) Source Mac Address	
>         Extension header type is 04 i.e. P-Bit = 0 ( MUST Process) and type as
>         Source Mac Address.
>         Extension header length is 06 i.e. N-Bit = 0 (No more extension header)
>         and 6 bytes of ext. header value length
>         Extension header param value is 00:50:c2:2f:42:43
> 
> 
>         e) Source identifier
>         TBD
> 
>         e) QoS Classifier
>         TBD
> 

-- 
Alain RITOUX
Tel +33-1-39-30-92-32
Fax +33-1-39-30-92-11
visit our web http://www.6wind.com

---

From: "William StanisLaus" <[email-masked]>
Date: Thu, 22 Apr 2004 16:30:02 +0530

Please see my comments inlined.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On
> Behalf Of [email-masked]
> Sent: Thursday, April 22, 2004 2:28 PM
> To: IPDVB
> Subject: Re: ULE Extension Headers
>
>
>
>

William> Well, this was the initial proposal, so that we have full
backward compatibility even after addition of ext. headers.

But i really wonder, if we are going to support ULE chain Ext.
headers, it is a good idea to add ULE header length as mandatory,
since it will be useful for any decodes or analysis.. and also
if a receiver is not configured for extension headers he can
just set his offset to the start of the payload, after minimal
validation for which he is configured for.

> So, IF L2 encryption is needed,

William> L2 encryption is unclear to me still, are we going to add
encryption to entire SNDU i.e. including/full ULE header ( to put in simple
way, entire payload of MPEG2-TS) or partial  ULE header and ULE payload or
only ULE payload. i.e. entire IP/ARP/Bridged etc packet.

> and IF extension headers are used

William> Thats right, the extension headers are spiece to the actual header,
which describes more about how to interpret this particular packet. we
cannot
avoid processing such useful information to interpret the payload of ULE.

>    <-------- Ext. Header Field --------------- >

William> this appoarch is unclear, If the param value is type dependat,
Implementation has to have a type to length mapping table hardcoded.

say for example,
type 1 = 1 byte of length
type 2 = 0 byte of length
type 3 = 6 bytes of length
type 4 = 2 bytes of length etc...

> 3) Examples
William> i understand your concern here, these are jst an examples, the
requirement for these extension fields support should be taken as a
seperate I-D. and email thread.

> >         Extension header param value is 00:50:c2:2f:42:43

Best Regards,
William StanisLaus | Technical Consultant - CalSoft, Nortel Networks
email: [email-masked] | Telephone: +91 44 22541853, 22541464
Mobile: +91 98411 57902

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 22 Apr 2004 14:21:17 +0100

So... There are at least 3 (or is it 4) ways that
extension headers could be added.

I've seen text on the security extension header, which
I will try to summarise to the list next week. Is there
any text (2-3 paragraphs) on any of the other proposed
extension headers - this would be a great help to
establishing which of the many variants of extension
formats we should choose.

Any offers of text for extensions (other than security)?

Gorry Fairhurst.

William StanisLaus wrote:

>>>Few more updates..Please comment if you have any concerns
>>>      
>>>
>>:), Will post the
>>    
>>
>>>        The 7-bit extension header type field indicates the
>>>      
>>>
>>additional
>>    
>>
>>>        information for the SNDU header, which MUST be
>>>      
>>>
>>considered in
>>    
>>
>>>        processing the SNDU payload, based on the P-Bit
>>>      
>>>
>>(see section 4.7.1)
>>    
>>
>>>        This is the variable length parameter value for
>>>      
>>>
>>extension header. The
>>    
>>
>>>        length of this parameter is set by extension header
>>>      
>>>
>>length (see section
>>    
>>
>>>        4.7.4) based on the extension header type( see
>>>      
>>>
>>section 4.7.2).
>>    
>>
>>>        For example,
>>>
>>>        a) Security Header
>>>        Provision to combine more than one PDU(IP/Bridged
>>>      
>>>
>>Packet) in single ULE
>>    
>>
>>>        Header, provided packet identifier (Source PID and
>>>      
>>>
>>MAC, Destination PID
>>    
>>
>>>        and MAC, if QoS not considered, otherwise packet
>>>      
>>>
>>identifier MAY differ
>>    
>>
>>>        Extension header type is 01 i.e. P-Bit = 0 ( MUST
>>>      
>>>
>>Process) and type as
>>    
>>
>>>        Section Packing.
>>>        Extension header length is 06 i.e. N-Bit = 0 (No
>>>      
>>>
>>more extension header)
>>    
>>
>>>        Regarding extension header param value, for every
>>>      
>>>
>>PDU, first four bit
>>    
>>
>>>        are used for index, next 12 bit are used for offset
>>>      
>>>
>>value in the SNDU
>>    
>>
>>>        40 - indicates the second packet offset/start
>>>      
>>>
>>position value in HEX
>>    
>>
>>>             i.e 64 decimal.
>>>        B2 - indicates the third packet offset/start
>>>      
>>>
>>position value in HEX
>>    
>>
>>>             i.e 178 decimal
>>>
>>>        c) Section Number
>>>        In case,  support for connection oriented approach
>>>      
>>>
>>required and Error
>>    
>>
>>>        Correction is needed. There MUST be an agreement
>>>      
>>>
>>with Transmitter and
>>    
>>
>>>        Receiver to support Section Number. By which,
>>>      
>>>
>>LOST/ERROR SNDU’s can be
>>    
>>
>>>        corrected by requesting to retransmit those SNDU’s
>>>      
>>>
>>alone, based on the
>>    
>>
>>>        Section Number.
>>>
>>>        <author note: new ULE type has to be defined to
>>>      
>>>
>>identify the request
>>    
>>
>>>        from receiver to transmitter to retransmit the
>>>      
>>>
>>requested Section/SNDU>
>>    
>>
>>>        d) Source Mac Address
>>>        Extension header type is 04 i.e. P-Bit = 0 ( MUST
>>>      
>>>
>>Process) and type as
>>    
>>
>>>        Source Mac Address.
>>>        Extension header length is 06 i.e. N-Bit = 0 (No
>>>      
>>>
>>more extension header)
>>    
>>