[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: ULE Extension Headers
Please see my comments inlined.
> -----Original Message-----
> From: owner-ip-dvb@erg.abdn.ac.uk
> [mailto:owner-ip-dvb@erg.abdn.ac.uk]On
> Behalf Of alain.ritoux@6wind.com
> Sent: Thursday, April 22, 2004 2:28 PM
> To: IPDVB
> Subject: 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).
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
> 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.
>
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.
> 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.
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
> ============
>
> 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.
>
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.
>
> 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
>
Best Regards,
William StanisLaus | Technical Consultant - CalSoft, Nortel Networks
email: williams@calsoft.co.in | Telephone: +91 44 22541853, 22541464
Mobile: +91 98411 57902