[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ULE Extension Headers



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