draft-ietf-ipdvb-ule-ext-03.txt   draft-ietf-ipdvb-ule-ext-04.txt 
Internet Engineering Task Force Gorry Fairhurst Internet Engineering Task Force Gorry Fairhurst
Internet Draft University of Aberdeen Internet Draft University of Aberdeen
Expires November 2007 B. Collini-Nocker Expires February 2008 B. Collini-Nocker
University of Salzburg University of Salzburg
Category: WG Draft intended for PS August 2007
Extension Formats for Unidirectional Lightweight Encapsulation (ULE) Extension Formats for Unidirectional Lightweight Encapsulation (ULE)
and the Generic Stream Encapsulation (GSE) and the Generic Stream Encapsulation (GSE)
draft-ietf-ipdvb-ule-ext-03.txt draft-ietf-ipdvb-ule-ext-04.txt
Status of this Draft Status of this Draft
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 39
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document describes a set of Extension Headers for the This document describes a set of Extension Headers for the
Unidirectional Lightweight Encapsulation (ULE), RFC4326. Unidirectional Lightweight Encapsulation (ULE), RFC4326.
The Extension Header formats defined in this document define new The Extension Header formats specified in this document define
extensions that are common extensions to both ULE and the Generic extensions appropriate to both ULE and the Generic Stream
Stream Encapsulation (GSE) defined to support the second generation Encapsulation (GSE) defined to support the second generation framing
framing structure defined by Digital Video Broadcasting (DVB) family structure defined by Digital Video Broadcasting (DVB) family of
of specifications. specifications.
Table of Contents Table of Contents
1. Introduction 1. Introduction
2. Conventions used in this document 2. Conventions used in this document
3. Description of method 3. Description of method
3.1 MPEG-2 TS-Concat Extension 3.1 MPEG-2 TS-Concat Extension
3.2 PDU-Concat Extension 3.2 PDU-Concat Extension
skipping to change at page 3, line 20 skipping to change at page 3, line 20
links that employ the MPEG-2 Transport Stream, and supports a wide links that employ the MPEG-2 Transport Stream, and supports a wide
variety of physical-layer bearers [RFC4259]. variety of physical-layer bearers [RFC4259].
GSE has been designed for the Generic Mode (also known as the GSE has been designed for the Generic Mode (also known as the
Generic Stream (GS)), offered by second-generation DVB physical Generic Stream (GS)), offered by second-generation DVB physical
layers, and in the first instance for DVB-S2 [ETSI-S2]. The layers, and in the first instance for DVB-S2 [ETSI-S2]. The
requirements for the Generic Stream are described in [ID-S2-REQ]. requirements for the Generic Stream are described in [ID-S2-REQ].
The important characteristics of this encapsulation are described in The important characteristics of this encapsulation are described in
an Appendix to this document. GSE maintains a design philosophy that an Appendix to this document. GSE maintains a design philosophy that
presents a common network interface to that of ULE and uses a presents a common network interface to that of ULE and uses a
similar construction for Subnetwork Data Unit (SNDUs). similar construction for SubNetwork Data Unit (SNDUs).
The first Extension Header defines a method that allows one or more The first Extension Header defines a method that allows one or more
TS-Packets [ISO-MPEG2] to be sent within a ULE SNDU. This method may TS-Packets [ISO-MPEG2] to be sent within a ULE SNDU. This method may
be used to provide control plane information including the be used to provide control plane information including the
transmission of MPEG-2 Program Specific Information (PSI) for the transmission of MPEG-2 Program Specific Information (PSI) for the
Multiplex. In GSE, there is no native support for transport stream Multiplex. In GSE, there is no native support for transport stream
packets and this method is therefore suitable for providing an MPEG- packets and this method is therefore suitable for providing an MPEG-
2 control plane. 2 control plane.
A second Extension Header allows one or more PDUs to be sent within A second Extension Header allows one or more PDUs to be sent within
skipping to change at page 4, line 21 skipping to change at page 4, line 21
b: bit. For example, one byte consists of 8b. b: bit. For example, one byte consists of 8b.
B: Byte. Groups of bytes are represented in Internet byte order. B: Byte. Groups of bytes are represented in Internet byte order.
BBFrame payload [ETSI-S2]: The data field part of a Baseband frame BBFrame payload [ETSI-S2]: The data field part of a Baseband frame
that may be used for the communication of data. Typical BBFrames that may be used for the communication of data. Typical BBFrames
range in size from 3072 to 58192 bits according to the choice of range in size from 3072 to 58192 bits according to the choice of
modulation format and FEC in use. modulation format and FEC in use.
DVB: Digital Video Broadcasting. A framework and set of DVB: Digital Video Broadcasting. A framework and set of associated
associated standards published by the European Telecommunications standards published by the European Telecommunications Standards
Standards Institute (ETSI) for the transmission of video, audio, and Institute (ETSI) for the transmission of video, audio, and data.
data.
E: A one-bit flag field defined in [GSE]. E: A one-bit flag field defined in [GSE].
Encapsulator: A network device that receives PDUs and formats these Encapsulator: A network device that receives PDUs and formats these
in to Payload Units (known here as SNDUs) for output in DVB-S or the in to Payload Units (known here as SNDUs) for output in DVB-S or the
Generic Mode of DVB-S2. Generic Mode of DVB-S2.
GS: Generic Stream [ETSI-S2]. A stream of BBFrames identified by a GS: Generic Stream [ETSI-S2]. A stream of BBFrames identified by a
common Input Stream Identifier, and which does not use the MPEG-2 TS common Input Stream Identifier, and which does not use the MPEG-2 TS
format. format. It represents layer 2 of the ISO/OSI reference model.
GSE: Generic Stream Encapsulation [GSE]. A method that encapsulates GSE: Generic Stream Encapsulation [GSE]. A method for encapsulating
PDUs that form a Generic Stream, which is sent using a sequence of PDUs to form a Generic Stream, which is sent using a sequence of
BBFrames. This encapsulation format shares the same extension BBFrames. This encapsulation format shares the same extension
format, and basic processing rules of ULE and uses a common IANA format, and basic processing rules of ULE and uses a common IANA
Registry. Registry.
LT: A two-bit flag field defined in [GSE]. LT: A two-bit flag field defined in [GSE].
MAC: Medium Access Control [IEEE-802.3]. A link layer protocol MAC: Medium Access Control [IEEE-802.3]. A link layer protocol
defined by the IEEE 802.3 standard (or by Ethernet v2). defined by the IEEE 802.3 standard (or by Ethernet v2).
MPEG-2: A set of standards specified by the Motion Picture Experts MPEG-2: A set of standards specified by the Motion Picture Experts
skipping to change at page 5, line 26 skipping to change at page 5, line 26
PSI: Program Specific Information [ISO-MPEG2]. PSI: Program Specific Information [ISO-MPEG2].
S: A one-bit flag field defined in [GSE]. S: A one-bit flag field defined in [GSE].
SI Table: Service Information Table [ISO-MPEG2]. In this document, SI Table: Service Information Table [ISO-MPEG2]. In this document,
this term describes a table that is been defined by another this term describes a table that is been defined by another
standards body to convey information about the services carried on a standards body to convey information about the services carried on a
DVB Multiplex. DVB Multiplex.
SNDU: Subnetwork Data Unit [RFC4259]. In this document this is an SNDU: SubNetwork Data Unit [RFC4259]. In this document this is an
encapsulated PDU sent using ULE or GSE. encapsulated PDU sent using ULE or GSE.
Stream: A logical flow from an Encapsulator to a set of Receivers. Stream: A logical flow from an Encapsulator to a set of Receivers.
TS: Transport Stream [ISO-MPEG2], a method of transmission at the TS: Transport Stream [ISO-MPEG2], a method of transmission at the
MPEG-2 level using TS Packets; it represents layer 2 of the ISO/OSI MPEG-2 level using TS Packets; it represents layer 2 of the ISO/OSI
reference model. reference model.
ULE: Unidirectional Lightweight Encapsulation (ULE) [RFC4326]. A ULE: Unidirectional Lightweight Encapsulation (ULE) [RFC4326]. A
method that encapsulates PDUs, into SNDUs that are sent in a series method that encapsulates PDUs, into SNDUs that are sent in a series
of TS Packets using a single TS Logical Channel. The encapsulation of TS Packets using a single TS Logical Channel. The encapsulation
defines an extension format and an associated IANA Registry. defines an extension format and an associated IANA Registry.
3. Description of the Method 3. Description of the Method
In ULE, a Type field value that is less than 1536 Decimal indicates In ULE, a Type field value that is less than 1536 Decimal indicates
an Extension Header. This section describes a set of two extension an Extension Header. This section describes a set of three
formats for the ULE encapsulation. The GSE [GSE] follows the same extension formats for the ULE encapsulation. [GSE] uses a Type field
format as used in the ULE Type field. The encapsulation format that adopts the same semantics as specified by RFC 4326. The
differs in that GSE does not include a per-SNDU CRC, has different encapsulation format differs in that GSE does not include a per-SNDU
header flags, and utilises a different SNDU length calculation CRC, has different header flags, and utilises a different SNDU
[GSE]. length calculation [GSE].
There is a natural ordering of Extension Headers, which is There is a natural ordering of extension headers, which is
determined by the fields that they are associated with. A suitable determined by the fields upon which the extension header operates. A
ordering for many applications is presented in the list below (from suitable ordering for many applications is presented in the list
first to last header within an SNDU). This does not imply that all below (from first to last header within an SNDU). This does not
types of Extensions should be present in a single SNDU. The imply that all types of Extensions should be present in a single
presented ordering may serve as a guideline for optimisation of SNDU. The presented ordering may serve as a guideline for
Receiver processing. optimisation of Receiver processing.
+----------------------------------+-------------------------------+ +----------------------------------+-------------------------------+
|Fields related to Extension Header| Example Extension Headers | |Fields related to Extension Header| Example Extension Headers |
+----------------------------------+-------------------------------+ +----------------------------------+-------------------------------+
| Link framing and transmission | Timestamp Extension | | Link framing and transmission | Timestamp Extension |
+----------------------------------+-------------------------------+ +----------------------------------+-------------------------------+
| Entire remaining SNDU Payload | Encryption Extension | | Entire remaining SNDU Payload | Encryption Extension |
+----------------------------------+-------------------------------+ +----------------------------------+-------------------------------+
| Group of encapsulated PDUs | PDU-Concat or TS-Concat | | Group of encapsulated PDUs | PDU-Concat or TS-Concat |
+-----------------------------------+------------------------------+ +----------------------------------+-------------------------------+
| Specific encapsulated PDU | IEEE-defined type | | Specific encapsulated PDU | IEEE-defined type |
| | Test or MAC bridging Extension| | | Test or MAC bridging Extension|
+-----------------------------------+------------------------------+ +----------------------------------+-------------------------------+
Table 1: Recommended ordering of Extension Headers Table 1: Recommended ordering of Extension Headers
3.1 MPEG-2 TS-Concat Extension 3.1 MPEG-2 TS-Concat Extension
The MPEG-2 TS-Concat Extension Header is specified by an IANA The MPEG-2 TS-Concat Extension Header is specified by an IANA
assigned H-Type value of 0x0002 in hexadecimal. This is a Mandatory assigned H-Type value of 0x0002 in hexadecimal. This is a Mandatory
Next-Header Extension. Next-Header Extension.
The extension is used to transport one or more MPEG-2 TS Packets The extension is used to transport one or more MPEG-2 TS Packets
within a ULE SNDU. The number of TS Packets carried in a specific within a ULE SNDU. The number of TS Packets carried in a specific
SNDU is determined from the size of the remainder of the payload SNDU is determined from the size of the remainder of the payload
following the MPEG-2 TS Extension Header. The number of TS Packets following the MPEG-2 TS Extension Header. The number of TS Packets
contained in the SNDU is therefore (Length-N-10+D*6) / 188, where N contained in the SNDU is therefore (Length-N-10+D*6) / 188, where N
is the number of bytes associated with Extension Headers that is the number of bytes associated with Extension Headers that
precede the MPEG-2 TS-Concat Extension (zero if there are none). precede the MPEG-2 TS-Concat Extension (zero if there are none).
A Receiver MUST check that the validity of the value of the payload A Receiver MUST check the validity of the Length value prior to
Length prior to processing. Any mismatch (remainder from the processing the payload. A valid Length contains an integral number
division) MUST result in discard of all encapsulated PDUs and SHOULD of TS Packets. An invalid Length (a remainder from the division by
be recorded as TS-Concat size mismatch error. 188) MUST result in the discard of all encapsulated TS Packets and
SHOULD be recorded as TS-Concat size mismatch error.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Length (15b) | Type = 0x0002 | |0| Length (15b) | Type = 0x0002 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Destination NPA Address (6B) | | Receiver Destination NPA Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| TS-Packet 1 | | TS-Packet 1 |
skipping to change at page 8, line 5 skipping to change at page 8, line 5
= = = =
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS-Packet 2 (if Length > 2*188) | | TS-Packet 2 (if Length > 2*188) |
= = = =
| etc. | | etc. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: GSE/SNDU Format for a TS-Packet Payload (LT=00) Figure 2: GSE/SNDU Format for a TS-Packet Payload (LT=00)
Fragmented GSE SNDUs are protected by a CRC-32 carried in the final Fragmented GSE SNDUs are protected by a CRC-32 carried in the final
fragment. The fields labelled S and E are defined by [GSE} and fragment. After defragmentation, this CRC-32 is removed and the
contains control flags used by the GSE link layer. The Label Type resulting SNDU carries a Total Length field. The fields labelled S
field (LT) specifies the presence and format of the GSE label. and E are defined by [GSE] and contain control flags used by the GSE
link layer. The Label Type field (LT) specifies the presence and
format of the GSE label. The LT field is only specified for the
first fragment (or an unfragmented) GSE SNDU (i.e. when S=1).
In ULE, a value of D=1, is also permitted and indicates the absence In ULE, a value of D=1, is also permitted and indicates the absence
of a NPA address (Figure 3). A similar format is supported in GSE. of a NPA address (Figure 3). A similar format is supported in GSE.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Length (15b) | Type = 0x0002 | |1| Length (15b) | Type = 0x0002 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS-Packet 1 | | TS-Packet 1 |
skipping to change at page 8, line 35 skipping to change at page 8, line 38
| (CRC-32) | | (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: ULE/SNDU Format for a TS-Packet Payload (D=1) Figure 3: ULE/SNDU Format for a TS-Packet Payload (D=1)
This extension may be used to transport one or more MPEG-2 TS This extension may be used to transport one or more MPEG-2 TS
Packets of arbitrary content, interpreted according to [ISO-MPEG2]. Packets of arbitrary content, interpreted according to [ISO-MPEG2].
One expected use is for the transmission of MPEG-2 SI/PSI One expected use is for the transmission of MPEG-2 SI/PSI
signalling. signalling.
Null TS Packets are not normally sent using this encapsulation. To NULL TS Packets [ISO-MPEG2] SHOULD NOT be sent using this
reduce transmission overhead and processing, an Encapsulator SHOULD encapsulation. To reduce transmission overhead and processing, an
specify a maximum period of time that it can wait before sending all Encapsulator SHOULD specify a maximum period of time that it can
queued TS Packets. This is known as the TS Packing Threshold. This wait before sending all queued TS Packets. This is known as the TS
value MUST be bounded and SHOULD be configurable in the Packing Threshold. This value MUST be bounded and SHOULD be
Encapsulator. A larger value can improve efficiency, but incurs configurable in the Encapsulator. A larger value can improve
higher jitter and could increase the probability of corruption. If efficiency, but incurs higher jitter and could increase the
additional TS Packets are NOT received within the TS Packing probability of corruption. If additional TS Packets are NOT received
Threshold, the Encapsulator MUST immediately send any queued TS within the TS Packing Threshold, the Encapsulator MUST immediately
Packets. send any queued TS Packets.
The use of this format to transfer MPEG-2 clock references (e.g. a The use of this format to transfer MPEG-2 clock references (e.g. a
Network Clock Reference, NCR, SI Table) over ULE/GSE framing raises Network Clock Reference, NCR) over ULE/GSE framing raises timing
timing considerations at the encapsulation gateway, including the considerations at the encapsulation gateway, including the need to
need to update/modify the timing information prior to transmission update/modify the timing information prior to transmission by the
by the physical layer. These issues are not considered here, but physical layer. These issues are not considered here, but this
this operation may be simplified in GSE by ensuring that all SNDUs operation may be simplified in GSE by ensuring that all SNDUs that
that carry this Extension Header are placed before other data within carry this Extension Header are placed before other data within the
the BBFrame DataField [GSE]. BBFrame DataField [GSE].
This document does not specify how TS Packets are to be handled at This document does not specify how TS Packets are to be handled at
the Receiver, however it notes that a poorly configured Encapsulator the Receiver, however it notes that a poorly configured Encapsulator
could lead to a Multiplex carrying multiple (possibly conflicting) could lead to a Multiplex carrying multiple (possibly conflicting)
sets of TS Logical Channels and SI information encapsulated at sets of TS Logical Channels and SI information encapsulated at
different levels or with different NPA addresses. The need for different levels or with different NPA addresses. The need for
consistency in the use of PIDs and the related SI information is consistency in the use of PIDs and the related SI information is
described in [RFCxARx]. described in [RFCxARx].
3.2 PDU-Concat Extension 3.2 PDU-Concat Extension
skipping to change at page 9, line 28 skipping to change at page 9, line 30
within a single SNDU payload. within a single SNDU payload.
The base header contains the Length of the entire SNDU. This carries The base header contains the Length of the entire SNDU. This carries
the value of the combined length of all PDUs to be encapsulated, the value of the combined length of all PDUs to be encapsulated,
including each set of encapsulation headers. The base header MAY be including each set of encapsulation headers. The base header MAY be
followed by one or more additional Extension Headers that precede followed by one or more additional Extension Headers that precede
the PDU-Concat Extension Header. These Extension Headers (e.g. a the PDU-Concat Extension Header. These Extension Headers (e.g. a
TimeStamp Extension) apply to the composite concatenated PDU. TimeStamp Extension) apply to the composite concatenated PDU.
The Extension Header also contains a 16-bit ULE Type field The Extension Header also contains a 16-bit ULE Type field
describing the encapsulated PDU, CONCAT-PDU-Type. Although any Type describing the encapsulated PDU, PDU-Concat-Type. Although any Type
value specified in the ULE Next-Header Registry (including Extension value specified in the ULE Next-Header Registry (including Extension
Header Types) may be assigned to the encapsulated PDU (except the Header Types) may be assigned to the encapsulated PDU (except the
recursive use of a PDU-Concat type), all concatenated PDUs MUST have recursive use of a PDU-Concat type), all concatenated PDUs MUST have
a common ULE Type (i.e. all concatenated PDUs passed by the network a common ULE Type (i.e. all concatenated PDUs passed by the network
layer must be associated with the same Type value). This simplifies layer must be associated with the same Type value). This simplifies
the receiver design, and reduces the transmission overhead for the receiver design, and reduces the transmission overhead for
common use cases. common use cases.
Each PDU is prefixed by its length in bytes (shown as PDU-Length in Each PDU is prefixed by its length in bytes (shown as PDU-Length in
the following diagrams). Encapsulated PDUs are of arbitrary length the following diagrams). Encapsulated PDUs are of arbitrary length
(in bytes) and are not necessarily aligned to 16-bit or 32-bit (in bytes) and are not necessarily aligned to 16-bit or 32-bit
boundaries within the SNDU (as shown in the figure). The most boundaries within the SNDU (as shown in the figure). The most
significant bit of the first byte is reserved, R, and this significant bit of the first byte is reserved, R, and this
specification requires that this MUST be set to zero. The length of specification requires that this MUST be set to zero. Receivers MUST
each PDU MUST be less than 32758 bytes, but will generally be much ignore the value of the R bit. The length of each PDU MUST be less
smaller. than 32758 bytes, but will generally be much smaller.
When the SNDU header indicates the presence of an SNDU Destination When the SNDU header indicates the presence of an SNDU Destination
Address field (i.e. D=0 in ULE), a Network Point of Attachment, NPA, Address field (i.e. D=0 in ULE), a Network Point of Attachment, NPA,
field directly follows the fourth byte of the SNDU header. NPA field directly follows the fourth byte of the SNDU header. NPA
destination addresses are 6 Byte numbers, normally expressed in destination addresses are 6 Byte numbers, normally expressed in
hexadecimal, used to identify the Receiver(s) in a transmission hexadecimal, used to identify the Receiver(s) in a transmission
network that should process a received SNDU. When present the network that should process a received SNDU. When present the
Receiver MUST associate the same specified MAC/NPA address with all Receiver MUST associate the same specified MAC/NPA address with all
PDUs within the SNDU Payload. This MAC/NPA address MUST also be PDUs within the SNDU Payload. This MAC/NPA address MUST also be
forwarded with each PDU, if required by the forwarding interface. forwarded with each PDU, if required by the forwarding interface.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Length (15b) | Type = 0x0003 | |0| Length (15b) | Type = 0x0003 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Destination NPA Address (6B) | | Receiver Destination NPA Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | CONCAT-PDU-Type | | | PDU-Concat-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| PDU-Length-1 (15b) | | |R| PDU-Length-1 (15b) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
= PDU-1 = = PDU-1 =
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| PDU-Length-2 (15b) | | |R| PDU-Length-2 (15b) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
= PDU-2 = = PDU-2 =
| | | |
skipping to change at page 10, line 36 skipping to change at page 10, line 38
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: ULE/SNDU Format for a PDU-Concat Payload (D=0) Figure 4: ULE/SNDU Format for a PDU-Concat Payload (D=0)
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|E|0 0| Length (12b) | Type = 0x0003 | |S|E|0 0| Length (12b) | Type = 0x0003 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Destination NPA Address (6B) | | Receiver Destination NPA Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | CONCAT-PDU-Type | | | PDU-Concat-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| PDU-Length-1 (15b) | | |R| PDU-Length-1 (15b) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
= PDU-1 = = PDU-1 =
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| PDU-Length-2 (15b) | | |R| PDU-Length-2 (15b) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
= PDU-2 = = PDU-2 =
| | | |
More PDUs as required More PDUs as required
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: GSE/SNDU Format for a PDU-Concat Payload (LT=00)_ Figure 5: GSE/SNDU Format for a PDU-Concat Payload (LT=00)_
When the SNDU header indicates the absence of an SNDU Destination
Address field (i.e. D=1 in ULE) all encapsulated PDUs MUST be
processed as if they had been received without an NPA address.
The value of D in the ULE header indicates whether a NPA/MAC address The value of D in the ULE header indicates whether a NPA/MAC address
is in use [RFC4326]. A similar format is supported in GSE. is in use [RFC4326]. A similar format is supported in GSE (using the
LT field).
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Length (15b) | Type = 0x0003 | |1| Length (15b) | Type = 0x0003 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CONCAT-PDU-Type |R| PDU-Length-1 (15b) | | PDU-Concat-Type |R| PDU-Length-1 (15b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= PDU-1 = = PDU-1 =
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| PDU-Length-2 (15b) | | |R| PDU-Length-2 (15b) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
= PDU-2 = = PDU-2 =
| | | |
More PDUs as required More PDUs as required
skipping to change at page 11, line 35 skipping to change at page 11, line 40
Figure 6: ULE/SNDU Format for a PDU-Concat Payload (D=1) Figure 6: ULE/SNDU Format for a PDU-Concat Payload (D=1)
To reduce transmission overhead and processing, an Encapsulator To reduce transmission overhead and processing, an Encapsulator
SHOULD specify a maximum period of time it will wait before sending SHOULD specify a maximum period of time it will wait before sending
a Concatenated PDU. This is known as the PDU Packing Threshold. This a Concatenated PDU. This is known as the PDU Packing Threshold. This
value MUST be bounded and SHOULD be configurable in the value MUST be bounded and SHOULD be configurable in the
Encapsulator. A larger value can improve efficiency, but incurs Encapsulator. A larger value can improve efficiency, but incurs
higher jitter and could increase the probability of corruption. If higher jitter and could increase the probability of corruption. If
additional PDUs are NOT received within the PDU Packing Threshold, additional PDUs are NOT received within the PDU Packing Threshold,
the Encapsulator MUST immediately send any queued PDUs. the Encapsulator MUST immediately send all queued PDUs.
The Receiver processes this Extension Header by verifying that it The Receiver processes this Extension Header by verifying that it
supports the specified CONCAT-PDU Type (unsupported Types MUST be supports the specified PDU-Concat Type (unsupported Types MUST be
discarded but the receiver SHOULD record a PDU-Type error). It then discarded, but the receiver SHOULD record a PDU-Type error
extracts each encapsulated PDU in turn. The Receiver MUST verify the [RFC4326]). It then extracts each encapsulated PDU in turn. The
Length of each PDU. It MUST also ensure that the sum of the Lengths Receiver MUST verify the Length of each PDU. It MUST also ensure
of all processed PDUs equals the Length specified in the SNDU base that the sum of the Lengths of all processed PDUs equals the Length
header. A Receiver SHOULD discard the whole SNDU if the total and specified in the SNDU base header. A Receiver SHOULD discard the
PDU sizes are not consistent and this event SHOULD be recorded as a whole SNDU if the total and PDU sizes are not consistent and this
PDU-Concat size mismatch error. event SHOULD be recorded as a PDU-Concat size mismatch error. A
receiver MUST NOT forward a partial PDU with an indicated PDU-Length
greater than the number of unprocessed bytes remaining in the SNDU
payload field.
3.3 Timestamp Extension 3.3 Timestamp Extension
The Timestamp Extension Header permits an Encapsulator to add a The Timestamp Extension Header is an Optional Next-Header Extension
timestamp field to an SNDU. This is designed to support monitoring that permits an Encapsulator to add a timestamp field to an SNDU.
and measurement of ULE performance over a link to indicate the The Timestamp Extension Header is specified by the IANA-assigned H-
quality of an operational ULE link. This may be useful for GSE links Type value of 257 decimal. This extension is an Optional Extension
(where significant complexity exists in the scheduling provided by Header ([RFC4326], Section 5).
the lower layers). This extension may be (optionally) checked at the
Receiver.
This extension is designed to support monitoring and measurement of
the performance of a link to indicate the quality of an operational
ULE link. This may be useful for GSE links (e.g. where significant
complexity exists in the scheduling provided by the lower layers).
Possible uses of this extension include: Possible uses of this extension include:
* Validation of in-sequence ordering per Logical Channel, * Validation of in-sequence ordering per Logical Channel,
* Measurement of one-way delay (when synchronised with the sender), * Measurement of one-way delay (when synchronised with the sender)
* Measurement of PDU Jitter introduced by the link, * Measurement of PDU Jitter introduced by the link,
* PDU loss (with additional information from the sender). * Measurement of PDU loss (with additional information from sender).
The Timestamp Extension Header is specified by the IANA-assigned H-
Type value of 257 decimal. This extension is an Optional Extension
Header ([RFC4326], Section 5).
Figure 7 shows the format of this extension with a HLEN value of 3 Figure 7 shows the format of this extension with a HLEN value of 3
indicating a timestamp of length 4B with a Type field (there is no indicating a timestamp of length 4B with a Type field (there is no
implied byte-alignment). implied byte-alignment).
0 7 15 23 31 0 7 15 23 31
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| 0x03 | 0x01 | time stamp HI | | 0x03 | 0x01 | time stamp HI |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| time stamp LO | Type | | time stamp LO | Type |
skipping to change at page 12, line 45 skipping to change at page 12, line 51
earlier than the time of transmission due for example to Packing, earlier than the time of transmission due for example to Packing,
queuing and other Encapsulator processing. The value is right- queuing and other Encapsulator processing. The value is right-
justified to the 32-bit field. Systems unable to insert timestamps justified to the 32-bit field. Systems unable to insert timestamps
at the specified resolution may use an arbitrary (and varying) value at the specified resolution may use an arbitrary (and varying) value
to pad the unused least-significant bits. to pad the unused least-significant bits.
The last two bytes carry a 16-bit Type field that indicates the type The last two bytes carry a 16-bit Type field that indicates the type
of payload carried in the SNDU, or the presence of a further Next- of payload carried in the SNDU, or the presence of a further Next-
Header ([RFC4326], Section 4.4). Header ([RFC4326], Section 4.4).
This is an Optional Extension Header. Receivers SHOULD process the Receivers MAY process the Optional Extension Header timestamp
timestamp when the PDU is decapsulated. Receivers that do not when the PDU is decapsulated. Receivers that do not implement,
implement, or do not wish to process, the Timestamp Extension MAY or do not wish to process, the Timestamp Extension MAY skip this
skip this extension and continue to process the remainder of the extension header. Receivers MUST continue to process the remainder
SNDU, forwarding the encapsulated PDU. of the SNDU, forwarding the encapsulated PDU.
4. IANA Considerations 4. IANA Considerations
This document requires IANA involvement for the assignment of two This document requires IANA involvement for the assignment of three
new Next-Header Type values from the IANA ULE Next-Header Registry. new Next-Header Type values from the IANA ULE Next-Header Registry.
These options are defined for specific use cases envisaged by GSE, These options are defined for specific use cases envisaged by GSE,
but are compatible with ULE. but are compatible with ULE.
The following assignments have been made in this document, and
registered by IANA:
Type Name Reference
2: TS-Concat Section 3.1
3: PDU-Concat Section 3.2
Type Name H-LEN Reference
257: Timestamp 3 Section 3.3
The TS-Concat Extension is a Mandatory next-type Extension Header, The TS-Concat Extension is a Mandatory next-type Extension Header,
specified in section 3.1 of this document. The value of this next- specified in section 3.1 of this document. The value of this next-
header is defined by an IANA assigned H-Type value of 0x0002. header is defined by an IANA assigned H-Type value of 0x0002.
The PDU-Concat Extension is a Mandatory next-type Extension Header The PDU-Concat Extension is a Mandatory next-type Extension Header
specified in section 3.2 of this document. The value of this next- specified in section 3.2 of this document. The value of this next-
header is defined by an IANA assigned H-Type value of 0x0003. header is defined by an IANA assigned H-Type value of 0x0003.
The Timestamp Extension is an Optional next-type Extension Header The Timestamp Extension is an Optional next-type Extension Header
specified in section 3.3 of this document. The value of this next- specified in section 3.3 of this document. The value of this next-
skipping to change at page 13, line 33 skipping to change at page 14, line 7
The author gratefully acknowledges the inputs, comments and The author gratefully acknowledges the inputs, comments and
assistance offered by the members of the DVB-GBS ad hoc group on assistance offered by the members of the DVB-GBS ad hoc group on
DVB-S2 encapsulation, in particular contributions on DVB-S2 DVB-S2 encapsulation, in particular contributions on DVB-S2
transmission aspects from Rita Rinaldo, Axel Jahn, and Ulrik De Bie. transmission aspects from Rita Rinaldo, Axel Jahn, and Ulrik De Bie.
Juan Cantillo provided a significant contribution to the informative Juan Cantillo provided a significant contribution to the informative
annexe. The authors thank Christian Praehauser for his insight and annexe. The authors thank Christian Praehauser for his insight and
contribution on header extension processing issues. contribution on header extension processing issues.
6. Security Considerations 6. Security Considerations
No specific security issues are raised within this document. This document does not raise new security concerns.
Additional security control fields may be provided as a part of a Security considerations for ULE are described in [RFC4326] and
link encryption Extension Header, e.g. to associate an SNDU with one further information on security aspects of using ULE are described
of a set of Security Association (SA) parameters. As a part of the in the security considerations of [RFC4259] and [ID-Sec-Req].
encryption process, it may also be desirable to authenticate
some/all of the headers. The method of encryption and the way in
which keys are exchanged is beyond the scope of this specification,
as also are the definition of the SA format and that of the related
encryption keys.
7. References 7. References
7.1 Normative References 7.1 Normative References
[RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, 1997. Requirement Levels", BCP 14, RFC 2119, 1997.
[RFC4326] Fairhurst, G. and B. Collini-Nocker, "Unidirectional [RFC4326] Fairhurst, G. and B. Collini-Nocker, "Unidirectional
Lightweight Encapsulation (ULE) for transmission of IP datagrams Lightweight Encapsulation (ULE) for transmission of IP datagrams
skipping to change at page 14, line 17 skipping to change at page 14, line 36
7.2 Informative References 7.2 Informative References
[ETSI-S2] EN 302 307, "Digital Video Broadcasting (DVB); Second [ETSI-S2] EN 302 307, "Digital Video Broadcasting (DVB); Second
generation framing structure, channel coding and modulation systems generation framing structure, channel coding and modulation systems
for Broadcasting, Interactive Services, News Gathering and other for Broadcasting, Interactive Services, News Gathering and other
broadband satellite applications", European Telecommunication broadband satellite applications", European Telecommunication
Standards Institute (ETSI). Standards Institute (ETSI).
[ID-S2-REQ] "Requirements for transmission of IP datagrams over DVB- [ID-S2-REQ] "Requirements for transmission of IP datagrams over DVB-
S2", Internet Draft <draft-cantillo-ipdvb-s2encaps-01.rxr>, Work in S2", Internet Draft <draft-cantillo-ipdvb-s2encaps-01.txt>, Work in
Progress. Progress.
[ID-Sec-Req] "Security requirements for the Unidirectional
Lightweight Encapsulation (ULE) protocol", Internet Draft < draft-
ietf-ipdvb-sec-req-03.txt>, Work in Progress.
[IEEE-802.3] "Local and metropolitan area networks - Specific [IEEE-802.3] "Local and metropolitan area networks - Specific
requirements Part 3: Carrier sense multiple access with collision requirements Part 3: Carrier sense multiple access with collision
detection (CSMA/CD) access method and physical layer detection (CSMA/CD) access method and physical layer
specifications", IEEE 802.3, IEEE Computer Society, (also ISO/IEC specifications", IEEE 802.3, IEEE Computer Society, (also ISO/IEC
8802-3), 2002. 8802-3), 2002.
[ISO-MPEG2] ISO/IEC DIS 13818-1:2000, "Information Technology; [ISO-MPEG2] ISO/IEC DIS 13818-1:2000, "Information Technology;
Generic Coding of Moving Pictures and Associated Audio Information Generic Coding of Moving Pictures and Associated Audio Information
Systems", International Standards Organisation (ISO). Systems", International Standards Organisation (ISO).
skipping to change at page 16, line 23 skipping to change at page 17, line 23
modulation response to changes in traffic and propagation modulation response to changes in traffic and propagation
conditions. Second, at the link layer, they offer greater conditions. Second, at the link layer, they offer greater
flexibility in framing. Support is provided for a range of stream flexibility in framing. Support is provided for a range of stream
formats including the classical Transport Stream (TS) [RFC4259]. In formats including the classical Transport Stream (TS) [RFC4259]. In
addition, a new method called Generic Streams (GS) (or the Generic addition, a new method called Generic Streams (GS) (or the Generic
Mode) is supported. A GS can be packetized or continuous and is Mode) is supported. A GS can be packetized or continuous and is
intended to provide native transport of other network-layer intended to provide native transport of other network-layer
services. One such method is that provided by the Generic Stream services. One such method is that provided by the Generic Stream
Encapsulation (GSE) [GSE]. Encapsulation (GSE) [GSE].
A transmission link sequentially multiplexes a series of baseband For example, the DVB-S2 [ETSI-S2] transmission link sequentially
frames (BBFrames). Each BBFrame comprises a fixed-size 10B header multiplexes a series of baseband frames (BBFrames). Each BBFrame
and a payload. The payload carries a DataField and uses padding to comprises a fixed-size 10B header and a payload. The payload carries
fill any unused space. A stream comprises a sequence of BBFrames a DataField and uses padding to fill any unused space. A stream
associated with an Input Stream Identifier (ISI) that is carried in comprises a sequence of BBFrames associated with an Input Stream
the header of each BBFrame. The simplest scheme uses a single Identifier (ISI) that is carried in the header of each BBFrame. The
stream (with just one ISI value), but multiple streams are simplest scheme uses a single stream (with just one ISI value), but
permitted. The BBFrames forming a stream may be of variable size multiple streams are permitted. The BBFrames forming a stream may be
(selected from a set of allowed sizes), and must use the same stream of variable size (selected from a set of allowed sizes), and must
format (e.g. TS or GSE). Each stream represents an independently use the same stream format (e.g. TS or GSE). Each stream represents
link with independent address resolution [RFCxARx]. an independent link with independent address resolution [RFCxARx].
GSE provides functions that are equivalent to those of the GSE provides functions that are equivalent to those of the
Unidirectional Lightweight Encapsulation (ULE) [RFC4326]. It Unidirectional Lightweight Encapsulation (ULE) [RFC4326]. It
supports the transmission of IP packets and other network-layer supports the transmission of IP packets and other network-layer
protocols. The network-layer interface resembles that of ULE, where protocols. The network-layer interface resembles that of ULE, where
it adopts common mechanisms for a Length field, a 16-bit Type field, it adopts common mechanisms for a Length field, a 16-bit Type field,
support for Extension Headers, and addressing using a 6-byte NPA and and support for Extension Headers. As in ULE, GSE permits multiple
a suppressed NPA address (functionally equivalent to D=1 in ULE). In address formats, indicated by the LT field (functionally equivalent
addition GSE also supports other addressing modes. It employs a CRC to the D field in ULE). The default addressing mode uses a 6-byte
method in which a CRC is placed at the end of a BBFrame, covering NPA and a suppressed NPA address (functionally equivalent to D=1 in
multiples SNDUs. This is a result of more advanced physical layer ULE).
coding and a larger link frame size that differs to than used by the
MPEG-2 TS. In some systems the CRC may be suppressed and replaced by
cross-layer signalling from the physical layer.
GSE also provides more flexible fragmentation at the interface to GSE also provides more flexible fragmentation at the interface to
the physical layer. This adapts the SNDUs to a variable-sized link- the physical layer (using the S and E flags). This adapts the SNDUs
layer frame, and reflects the more complex requirements in terms of to a variable-sized link-layer frame, and reflects the more complex
fragmentation and assembly that arise when using point-to-multipoint requirements in terms of fragmentation and assembly that arise when
adaptive physical layers. using point-to-multipoint adaptive physical layers. The integrity of
a reassembled SNDUs is provided by a CRC-32 in the last fragment for
the corresponding PDU.
[RFC EDITOR NOTE: [RFC EDITOR NOTE:
This section must be deleted prior to publication] This section must be deleted prior to publication]
DOCUMENT HISTORY DOCUMENT HISTORY
Individual Draft 00 Individual Draft 00
This draft complements a study item in the DVB-GBS in this area to This draft complements a study item in the DVB-GBS in this area to
define a Generic Stream Encapsulation (GSE). Comments relating to define a Generic Stream Encapsulation (GSE). Comments relating to
this document will be gratefully received by the author(s) and may this document will be gratefully received by the author(s) and may
skipping to change at page 17, line 52 skipping to change at page 18, line 52
Working Group Draft 01 Working Group Draft 01
Ammended text to follow IANA assignments for the codepoints. Ammended text to follow IANA assignments for the codepoints.
Added issues raised at ipdvb meeting by C Praehauser. Added issues raised at ipdvb meeting by C Praehauser.
Revised annexe with text from GSE Spec, J Cantillo, et al. Revised annexe with text from GSE Spec, J Cantillo, et al.
Revised wording to clarify corner cases. Revised wording to clarify corner cases.
Removed references to documents not in public domain. Removed references to documents not in public domain.
Updated conventions and abbreviations for consistency. Updated conventions and abbreviations for consistency.
Updated text referencing ULE. Updated text referencing ULE.
Working Group Draft 02 Working Group Draft 02
Added rules for Types of PDUs in PDU-Concat
Added appendix on DVB 2 nd generation Added rules for Types of PDUs in PDU-Concat.
Added new text on timers to control concat (from list) Added appendix on DVB 2 nd generation.
Added new text on timers to control concat (from list).
Working Group Draft 03 Working Group Draft 03
Added a table to the start of the method defining recommended
ordering Added a table to the start of the method defining recommended.
Fixed NiTs Fixed NiTs.
Working Group Draft 04 Draft
Editorial changes to prepare the document for WGLC.
Updated IANA section to comply with RFC4326 IANA Guidelines.
Reduced Security considerations section by reference to other
documents that give a fuller discussion.
There were no intentional changes to the protocol specification.
[END of RFC EDITOR NOTE] [END of RFC EDITOR NOTE]
 End of changes. 43 change blocks. 
131 lines changed or deleted 162 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/