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