[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: ULE Extension Headers
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: williams@future.futsoft.com | Telephone: +91 44 24330550 Extn: 282
Mobile: +91 98411 57902
www.futsoft.com
-----Original Message-----
From: owner-ip-dvb@erg.abdn.ac.uk [mailto:owner-ip-dvb@erg.abdn.ac.uk]On
Behalf Of Alain RITOUX
Sent: Friday, March 12, 2004 8:55 PM
To: ip-dvb@erg.abdn.ac.uk
Subject: Re: ULE Extension Headers
William StanisLaus wrote:
> Hi Alain,
> hope with this update your concerns are addressed. Also i am looking at
(c)
Thanks, with this updtae, evry thing seems fine for me.
> of Gorry's views. Definitly wish to draft the other vision as well. So
that
> we can discuss the pros n cons
goodn this will provide a solid ground for discusssion.
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
***************************************************************************
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.
***************************************************************************
<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 ----------------------------- > +-+-+-------+------+---------+-----------+--------------+--------+ |D|E|Length | Type |Dest.Mac*|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
The most significant bit of the Length Field carries the value of the Destination Address Present Field, the D-bit. A value of ZERO indicates the presence of the Destination Address Field (see section
4.6). A value of 1 indicates that a Destination Address Field is not
present (i.e. it is omitted).
By default, the D-bit value MUST be set to a value of ZERO, except for
the transmission of an End Indicator (see section 4.4), in which this
bit MUST be set to the value of 1.
4.2 Extension Header Present Field
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 1 indicates the absence of extension header for ULE.
Otherwise a value of ZERO indicates presence of extension header
(see section 4.6).
By default, the E-bit value MUST be set to a value of 1, i.e.
next extension header doesn't exist.
4.3 Length Field
A 14-bit value that indicates the length, in bytes, of the SNDU
(encapsulated Ethernet frame, IP datagram or other packet) PDU
length, counted from the byte, start of the payload and excluding
the CRC at the end.
Note the special case described in 4.4.
4.4 End Indicator
When the first two bytes of a SNDU has the value 0xFFFF, this
denotes an End Indicator (i.e., all 1 s length combined with D-bit and E-bit value of 1 s). It indicates to the Receiver that there are no further SNDU are present within the current TS packet (see
section 6), and that no Destination Address Field is present. The value 0xFF has specific semantics in MPEG-2 framing, where it is used to indicate the presence of padding. This use resembles
[ISO-DSMCC].
4.5 Type Field
The 16-bit Type field indicates the type of payload carried in a
SNDU. The set of values that may be assigned to this field is
divided into two parts, similar to the allocations for Ethernet.
Ethertypes were originally specified by Xerox under the DIX
framework for Ethernet. After specification of IEEE 802.3 [LLC], the
set of Ethertypes less than or equal to 1500 (0x05FC), assumed the role of a length indicator. Ethernet receivers use this feature to discriminate LLC format frames. Hence any IEEE Ethertype <= 1500 indicates an LLC frame, and the actual value indicates the length of
the LLC frame.
There is a potential security issue when a Receiver receives a PDU with two length fields: The Receiver would need to validate the actual length and the Length field and ensure that inconsistent
values are not propagated by the network. Specification of two
independent length fields is therefore undesirable. In the ULE
header, this avoided in the SNDU header by including only one length
value, but bridging of LLC frames re-introduces this consideration (section 4.9.5).
The Ethernet LLC mode of identification is not required in ULE,
since the SNDU format always carries an explicit Length Field, and therefore the procedure in ULE is modified, as below:
The first set of ULE Type Field values comprise the set of values <=
1500. These Type Field values are IANA assigned (see section 4.5.1).
The second set of ULE Type Field values comprise the set of values >
1500. In ULE, this indicates that the value is identical to the
corresponding type codes specified by the IEEE/DIX type assignments for Ethernet and recorded in the IANA EtherType registry.
4.5.1 Type 1: IANA Assigned Type Fields
The first part of the Type space corresponds to the values 0x0000 to
1500 Decimal. These values may be used to identify link-specific
protocols and/or to indicate the presence of extension headers that carry additional optional protocol fields (e.g. a bridging
encapsulation). Use of these values is co-ordinated by an IANA
registry.
The following types are defined:
[XXX IANA ACTION REQUIRED XXX]
0x0000: Test SNDU, discarded by the Receiver.
0x0001: Bridged Ethernet Frame (i.e. MAC source address follows)
[XXX END OF IANA ACTION REQUIRED XXX]
The remaining values within the first part of the Type space are
reserved for allocation by the IANA.
[Author NOTE: Type allocation and appropriate IANA Procedure to be determined.]
4.5.2 Type 2: Ethertype compatible Type Fields
The second part of the Type space corresponds to the values 1500
(0x05DC) and 0xFFFF. This set of type assignments follow DIX/IEEE assignments (but exclude use of this field as a frame length
indicator) [LLC]. The following types are defined in this document for part 2:
0x0800 : IPv4 Payload (according to IANA EtherTypes)
0x86DD : IPv6 Payload (according to IANA EtherTypes)
All other assignments in part two of this space should be
coordinated with the values defined for IANA EtherType
encapsulations.
4.6 SNDU Destination MAC Address Field
The SNDU Destination MAC Address Field is optional (see section 4.1).
This field MUST be carried for IP unicast packets destined to
routers(i.e. D=0). A sender MAY omit this field (D=1) for an IP unicast packet and/or multicast packets delivered to Receivers that
are able to utilise a discriminator field (e.g. the IPv4/IPv6
destination address), which in combination with the PID value, could
be interpreted as a Link-Level address.
When the SNDU header indicates the presence of a SNDU Destination MAC Address field (i.e. D=0), a Network Point of Attachment, NPA, field
directly follows the SNDU Type Field. NPA destination addresses are
6 B numbers, normally expressed in hexadecimal, used to identify the
Receiver(s) in a MPEG-2 transmission network that should process a received SNDU. The value 0x00:00:00:00:00:00, MUST NOT be used as a
destination address in a SNDU. The least significant bit of the
first byte of the address is set to 1 for multicast frames, and the remaining bytes specify the link layer multicast address. The
specific value 0xFF:FF:FF:FF:FF:FF is the link broadcast address, indicating this SNDU is to be delivered to all Receivers.
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 |
+-+---------------+-----+--------------+---// ....... //-----------+
Figure 2: Extension header format
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 process, drop the packet, otherwise the
value of 1 is the receivers decision to process or skip and proceed
further.
By default, the P-bit value MUST be set to a value ZERO. i.e.
MUST process the Ext. Header.
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
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 ZERO 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 ZERO. i.e.
next extension header does not exist.
4.7.4 Extension header Length
The 7-bit value that indicates the extension header value length, in
bytes for that extension header of ULE, excluding extension header type
and length.
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
<snip>