draft-ietf-ipdvb-ule-ext-06.txt   draft-ietf-ipdvb-ule-ext-07.txt 
Internet Engineering Task Force G. Fairhurst Internet Engineering Task Force G. Fairhurst
Internet-Draft University of Aberdeen Internet-Draft University of Aberdeen
Intended status: Proposed Standard B. Collini-Nocker Intended status: Proposed Standard B. Collini-Nocker
Expires: April 2007 University of Salzburg Expires: June 2008 University of Salzburg
November 05, 2007 January 07, 2008
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-06.txt draft-ietf-ipdvb-ule-ext-07.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 2, line 18 skipping to change at page 2, line 18
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
3.3 TimeStamp Extension 3.3 TimeStamp Extension
4. IANA Considerations 4. IANA Considerations
5. Acknowledgements 5. Acknowledgments
6. Security Considerations 6. Security Considerations
7. References 7. References
7.1 Normative References 7.1 Normative References
7.2 Informative References 7.2 Informative References
Authors' Addresses Authors' Addresses
Appendix: The Second Generation DVB Transmission Specifications Appendix: The Second Generation DVB Transmission Specifications
1. Introduction 1. Introduction
This document describes three Header Extensions that may be used This document describes three Header Extensions that may be used
with both Unidirectional Lightweight Encapsulation, ULE, [RFC4326] with both the Unidirectional Lightweight Encapsulation, ULE,
and the Generic Stream Encapsulation (GSE) [GSE]. ULE is defined for [RFC4326] and the Generic Stream Encapsulation (GSE) [GSE]. ULE is
links that employ the MPEG-2 Transport Stream, and supports a wide defined for links that employ the MPEG-2 Transport Stream, and
variety of physical-layer bearers [RFC4259]. supports a wide 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 network interface that is common to that presented by ULE
similar construction for SubNetwork Data Unit (SNDUs). and uses a 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
the same ULE SNDU. This method is designed for cases where a large the same ULE SNDU. This method is designed for cases where a large
number of small PDUs are directed to the same Network Point of number of small PDUs are directed to the same Network Point of
Attachment (NPA) address. The method may improve transmission Attachment (NPA) address. The method may improve transmission
efficiency (by removing duplicated MAC layer overhead). It can also efficiency (by removing duplicated MAC layer overhead). It can also
reduce processing overhead for receivers that are not addressed by reduce processing overhead for a receiver that is not configured to
the NPA, since these receivers may then skip several PDUs in one receive the NPA address associated with an SNDU, allowing this
operation. The method is defined as a generic Extension Header and receiver to then skip several PDUs in one operation. The method is
may be used for IPv4 or IPv6 packets. If, and when, a compression defined as a generic Extension Header and may be used for IPv4 or
format is defined for ULE or Ethernet, the method may also be used IPv6 packets. If, and when, a compression format is defined for ULE
in combination with this method. or Ethernet, the method may also be used in combination with this
method.
A third Extension Header provides an optional timestamp value for an A third Extension Header provides an optional timestamp value for an
SNDU. Examples of the use of this timestamp option include SNDU. Examples of the use of this timestamp option include
monitoring and benchmarking of ULE and GSE links. Receivers that do monitoring and benchmarking of ULE and GSE links. Receivers that do
not wish to decode (or do not support) the timestamp extension may not wish to decode (or do not support) the timestamp extension may
discard the extension and process the remaining PDU or Extension discard the extension and process the remaining PDU or Extension
Headers. Headers.
An appendix includes a summary of key design issues and An appendix includes a summary of key design issues and
considerations relating to the GSE Specification defined by the DVB considerations relating to the GSE Specification defined by the DVB
skipping to change at page 4, line 19 skipping to change at page 4, line 19
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
RFC 2119 [RFC2119]. RFC 2119 [RFC2119].
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: The data field part of a Baseband frame [ETSI-S2] BBFrame payload: The data field part of a Baseband frame [ETSI-S2]
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 Forward Error Correction (FEC) in use.
DVB: Digital Video Broadcasting. A framework and set of associated DVB: Digital Video Broadcasting. A framework and set of associated
standards published by the European Telecommunications Standards standards published by the European Telecommunications Standards
Institute (ETSI) for the transmission of video, audio, and data. Institute (ETSI) for the transmission of video, audio, and data.
E: A one-bit flag field defined in GSE [GSE]. E: A one-bit flag field defined in GSE [GSE].
Encapsulator: A network device that receives PDUs and formats these Encapsulator: A network device [RFC4259] that receives PDUs and
into Payload Units (known here as SNDUs) for output in DVB-S or the formats these into Payload Units (known here as SNDUs) for output in
Generic Mode of DVB-S2 [RFC4259]. DVB-S or the Generic Mode of DVB-S2.
GS: Generic Stream. A stream of BBFrames identified by a common GS: Generic Stream. A stream of BBFrames identified by a common
Input Stream Identifier, and which does not use the MPEG-2 TS Input Stream Identifier, and which does not use the MPEG-2 TS format
format [ETSI-S2]. It represents layer 2 of the ISO/OSI reference [ETSI-S2]. It represents layer 2 of the ISO/OSI reference model.
model.
GSE: Generic Stream Encapsulation [GSE]. A method for encapsulating GSE: Generic Stream Encapsulation [GSE]. A method for encapsulating
PDUs to 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 [GSE]. LT: A two-bit flag field defined in GSE [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.
MPEG-2: A set of standards specified by the Motion Picture Experts MPEG-2: A set of standards specified by the Motion Picture Experts
Group (MPEG), and standardized by the International Standards Group (MPEG), and standardized by the International Organization for
Organisation (ISO/IEC 113818-1) [ISO-MPEG2], and ITU-T (in H.220). Standardization (ISO/IEC 113818-1) [ISO-MPEG2], and ITU-T (in
H.220).
Next-Header: A Type value indicating an Extension Header [RFC4326]. Next-Header: A Type value indicating an Extension Header [RFC4326].
NPA: Network Point of Attachment [RFC4326]. In this document, refers NPA: Network Point of Attachment [RFC4326]. In this document, refers
to a destination address (resembling an IEEE MAC address) within the to a destination address (resembling an IEEE MAC address) within the
DVB-S/S2 transmission network that is used to identify individual DVB-S/S2 transmission network that is used to identify individual
Receivers or groups of Receivers. Receivers or groups of Receivers.
PID: Packet Identifier [ISO-MPEG2]. A 13-bit field carried in the PID: Packet Identifier [ISO-MPEG2]. A 13-bit field carried in the
header of each TS Packet. This identifies the TS Logical Channel to header of each TS Packet. This identifies the TS Logical Channel to
skipping to change at page 5, line 36 skipping to change at page 5, line 36
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 in decimal
an Extension Header. This section describes a set of three indicates an Extension Header. This section describes a set of
extension formats for the ULE encapsulation. [GSE] uses a Type field three extension formats for the ULE encapsulation. [GSE] uses a Type
that adopts the same semantics as specified by RFC 4326. The field that adopts the same semantics as specified by RFC 4326. The
encapsulation format differs in that GSE does not include a CRC for encapsulation format differs in that GSE does not include a Cyclic
each SNDU, has different header flags, and utilises a different SNDU Redundancy Check (CRC) for each SNDU, has different header flags,
length calculation [GSE]. and utilizes a different SNDU 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 upon which the extension header operates. A determined by the fields upon which the extension header operates. A
suitable ordering for many applications is presented in the list suitable ordering for many applications is presented in the list
below (from first to last header within an SNDU). This does not below (from first to last header within an SNDU). This does not
imply that all types of Extensions should be present in a single imply that all types of Extensions should be present in a single
SNDU. The presented ordering may serve as a guideline for SNDU. The presented ordering may serve as a guideline for
optimisation of Receiver processing. optimization 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 |
+----------------------------------+-------------------------------+ +----------------------------------+-------------------------------+
skipping to change at page 6, line 55 skipping to change at page 6, line 54
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 the validity of the Length value prior to A Receiver MUST check the validity of the Length value prior to
processing the payload. A valid Length corresponds to an integral processing the payload. A valid Length corresponds to an integral
number of TS Packets. An invalid Length (a remainder from the number of TS Packets. An invalid Length (a remainder from the
division by 188) MUST result in the discard of all encapsulated division by 188) MUST result in the discard of all encapsulated TS
TS Packets and SHOULD be recorded as TS-Concat size mismatch error. 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 6 skipping to change at page 8, line 6
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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. After reassembly, this CRC-32 is removed and the resulting fragment. After reassembly, this CRC-32 is removed and the resulting
SNDU carries a Total Length field. The fields labelled S and E are SNDU carries a Total Length field. The fields labeled S and E are
defined by [GSE] and contain control flags used by the GSE link defined by [GSE] and contain control flags used by the GSE link
layer. The Label Type field (LT) specifies the presence and format layer. The Label Type field (LT) specifies the presence and format
of the GSE label. The LT field is only specified for the first of the GSE label. The LT field is only specified for the first
fragment (or a non-fragmented) GSE SNDU (i.e. when S=1). fragment (or a non-fragmented) 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 35
= = = =
| etc. | | etc. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (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
signaling [RFC4259]. [RFC4259].
NULL TS Packets [ISO-MPEG2] SHOULD NOT be sent using this NULL TS Packets [ISO-MPEG2] SHOULD NOT be sent using this
encapsulation. To reduce transmission overhead and processing, an encapsulation. To reduce transmission overhead and processing, an
Encapsulator SHOULD specify a maximum period of time that it can Encapsulator SHOULD specify a maximum period of time that it can
wait before sending all queued TS Packets. This is known as the TS wait before sending all queued TS Packets. This is known as the TS
Packing Threshold. This value MUST be bounded and SHOULD be Packing Threshold. This value MUST be bounded and SHOULD be
configurable in the Encapsulator. A larger value can improve configurable in the Encapsulator. A larger value can improve
efficiency, but incurs higher jitter and could increase the efficiency, but incurs higher jitter and could increase the
probability of corruption. If additional TS Packets are NOT received probability of corruption. If additional TS Packets are NOT received
within the TS Packing Threshold, the Encapsulator MUST immediately within the TS Packing Threshold, the Encapsulator MUST immediately
send any queued TS 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) over ULE/GSE framing raises timing Network Clock Reference, NCR) over ULE/GSE framing raises timing
considerations at the encapsulation gateway, including the need to considerations at the encapsulation gateway, including the need to
update/modify the timing information prior to transmission by the update/modify the timing information prior to transmission by the
physical layer. These issues are not considered here, but this physical layer. These issues are not considered here, but this
operation may be simplified in GSE by ensuring that all SNDUs that operation may be simplified in GSE by ensuring that all SNDUs that
carry this Extension Header are placed before other data within the carry this Extension Header are placed before other data within 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
skipping to change at page 9, line 26 skipping to change at page 9, line 26
The PDU-Concat Extension Header is specified by an IANA assigned H- The PDU-Concat Extension Header is specified by an IANA assigned H-
Type value of 0x0003 in hexadecimal. This is a Mandatory Next-Header Type value of 0x0003 in hexadecimal. This is a Mandatory Next-Header
Extension. It enables a sequence of (usually short) PDUs to be sent Extension. It enables a sequence of (usually short) PDUs to be sent
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, PDU-Concat-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 in the following
the following diagrams). Encapsulated PDUs are of arbitrary length diagrams as PDU-x-Length for the xth PDU). Encapsulated PDUs are of
(in bytes) and are not necessarily aligned to 16-bit or 32-bit arbitrary length (in bytes) and are not necessarily aligned to 16-
boundaries within the SNDU (as shown in the figure). The most bit or 32-bit boundaries within the SNDU (as shown in the figure).
significant bit of the first byte is reserved, R, and this The most significant bit of the first byte is reserved, R, and this
specification requires that this MUST be set to zero. Receivers MUST specification requires that this MUST be set to zero. Receivers MUST
ignore the value of the R bit. The length of each PDU MUST be less ignore the value of the R bit. The length of each PDU MUST be less
than 32758 bytes, but will generally be much 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,
field directly follows the fourth byte of the SNDU header. NPA 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) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | PDU-Concat-Type | | | PDU-Concat-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| PDU-Length-1 (15b) | | |R| PDU-1-Length (15b) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
= PDU-1 = = PDU-1 =
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| PDU-Length-2 (15b) | | |R| PDU-2-Length (15b) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
= PDU-2 = = PDU-2 =
| | | |
More PDUs as required More PDUs as required
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) | | (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | PDU-Concat-Type | | | PDU-Concat-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| PDU-Length-1 (15b) | | |R| PDU-1-Length (15b) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
= PDU-1 = = PDU-1 =
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| PDU-Length-2 (15b) | | |R| PDU-2-Length (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 When the SNDU header indicates the absence of an SNDU Destination
Address field (i.e. D=1 in ULE) all encapsulated PDUs MUST be Address field (i.e., D=1 in ULE) all encapsulated PDUs MUST be
processed as if they had been received without an NPA address. 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 (using the is in use [RFC4326]. A similar format is supported in GSE (using the
LT field). 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PDU-Concat-Type |R| PDU-Length-1 (15b) | | PDU-Concat-Type |R| PDU-1-Length (15b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= PDU-1 = = PDU-1 =
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| PDU-Length-2 (15b) | | |R| PDU-2-Length (15b) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
= PDU-2 = = PDU-2 =
| | | |
More PDUs as required More PDUs as required
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) | | (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: ULE/SNDU Format for a PDU-Concat Payload (D=1) Figure 6: ULE/SNDU Format for a PDU-Concat Payload (D=1)
skipping to change at page 12, line 15 skipping to change at page 12, line 15
3.3 Timestamp Extension 3.3 Timestamp Extension
The Timestamp Extension Header is an Optional Next-Header Extension The Timestamp Extension Header is an Optional Next-Header Extension
that permits an Encapsulator to add a timestamp field to an SNDU. that permits an Encapsulator to add a timestamp field to an SNDU.
The Timestamp Extension Header is specified by the IANA-assigned H- The Timestamp Extension Header is specified by the IANA-assigned H-
Type value of 257 decimal. This extension is an Optional Extension Type value of 257 decimal. This extension is an Optional Extension
Header ([RFC4326], Section 5). Header ([RFC4326], Section 5).
This extension is designed to support monitoring and measurement of This extension is designed to support monitoring and measurement of
the performance of a link to indicate the quality of an operational 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 ULE link. This may be useful for GSE links (e.g., where significant
complexity exists in the scheduling provided by the lower layers). 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 synchronized with the sender)
* Measurement of PDU Jitter introduced by the link, * Measurement of PDU Jitter introduced by the link,
* Measurement of PDU loss (with additional information from sender). * Measurement of PDU loss (with additional information from sender).
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 |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Figure 7 The format of the 32-bit Timestamp Extension Header Figure 7 Format of the 32-bit Timestamp Extension Header
The extension carries a 32-bit value (time stamp HI plus time stamp The extension carries a 32-bit value (time stamp HI plus time stamp
LO). The specified resolution is 1 microsecond. The value therefore LO). The specified resolution is 1 microsecond. The value therefore
indicates the number of 1 microsecond ticks past the hour in indicates the number of 1 microsecond ticks past the hour in
Universal Time when the PDU was encapsulated. This value may be Universal Time when the PDU was encapsulated. This value may be
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.
skipping to change at page 13, line 37 skipping to change at page 13, line 37
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-
header is defined by an IANA assigned H-Type value of 257 decimal. header is defined by an IANA assigned H-Type value of 257 decimal.
This documents defines format for a HLEN value of 0x3. This documents defines format for a HLEN value of 0x3.
5. Acknowledgements 5. Acknowledgments
The author gratefully acknowledges the inputs, comments and The authors gratefully acknowledge 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 appendix. 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
This document does not raise new security concerns.
Security considerations for ULE are described in [RFC4326] and Security considerations for ULE are described in [RFC4326] and
further information on security aspects of using ULE are described further information on security aspects of using ULE are described
in the security considerations of [RFC4259] and [ID-Sec-Req]. in the security considerations of [RFC4259] and [ID-Sec-Req].
An attacker that is able to inject arbitrary TS Packets in a ULE or
GSE Stream may modify layer 2 signalling information transmitted by
the MPEG-2 TS-Concat extension. Since this attack requires access to
the link and/or layer 2 equipment, such an attack could also
directly attack signalling information sent as native TS Packets
(not encapsulated by ULE/GSE). Security issues relating to the
transmission and interpretation of layer 2 signalling information
(including Address Resolution) within a TS Multiplex are described
in [RFC4947]. The use of security mechanisms to protect the MPEG-2
signalling information is discussed by [ID-Sec-Req].
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
over an MPEG-2 Transport Stream", RFC 4326, December 2005. over an MPEG-2 Transport Stream", RFC 4326, December 2005.
[GSE] TS 102 606 "Digital Video Broadcasting (DVB); Generic Stream [GSE] TS 102 606 "Digital Video Broadcasting (DVB); Generic Stream
Encapsulation (GSE) Protocol, "European Telecommunication Standards Encapsulation (GSE) Protocol, "European Telecommunication Standards,
Institute (ETSI). Institute (ETSI), 2007.
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.txt>, Work in S2", Internet-Draft <draft-cantillo-ipdvb-s2encaps-01.txt>, Work in
Progress. Progress.
[ID-Sec-Req] "Security requirements for the Unidirectional [ID-Sec-Req] "Security requirements for the Unidirectional
Lightweight Encapsulation (ULE) protocol", Internet-Draft < draft- Lightweight Encapsulation (ULE) protocol", Internet Draft < draft-
ietf-ipdvb-sec-req-04.txt>, Work in Progress. ietf-ipdvb-sec-req-04.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 Organization for Standardization (ISO).
[RFC4259] Montpetit, M.-J., Fairhurst, G., Clausen, H., Collini- [RFC4259] Montpetit, M.-J., Fairhurst, G., Clausen, H., Collini-
Nocker, B., and H. Linder, "A Framework for Transmission of IP Nocker, B., and H. Linder, "A Framework for Transmission of IP
Datagrams over MPEG-2 Networks", RFC 4259, November 2006. Datagrams over MPEG-2 Networks", RFC 4259, November 2006.
[RFC4947] Fairhurst, G. and M. Montpetit, "Address Resolution [RFC4947] Fairhurst, G. and M. Montpetit, "Address Resolution
Mechanisms for IP Datagrams over MPEG-2 Networks", RFC 4947, July Mechanisms for IP Datagrams over MPEG-2 Networks", RFC 4947, July
2007. 2007.
Authors' Addresses Authors' Addresses
Godred Fairhurst Godred Fairhurst
School of Engineering, School of Engineering,
University of Aberdeen, University of Aberdeen,
Aberdeen, AB24 3UE Aberdeen, AB24 3UE
UK UK
Email: gorry@erg.abdn.ac.uk Email: gorry@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk URI: http://www.erg.abdn.ac.uk/users/gorry
Bernhard Collini-Nocker Bernhard Collini-Nocker
Department of Computer Sciences, School of Computer Sciences,
University of Salzburg, University of Salzburg,
Jakob Haringer Str. 2, Jakob Haringer Str. 2,
5020 Salzburg, 5020 Salzburg,
Austria Austria
EMail: bnocker@cosy.sbg.ac.at Email: bnocker@cosy.sbg.ac.at
URI: http://www.cosy.sbg.ac.at URI: http://www.cosy.sbg.ac.at
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights. it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC Information on the procedures with respect to rights in RFC
skipping to change at page 17, line 45 skipping to change at page 17, line 5
of such proprietary rights by implementers or users of this of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr. at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
APPENDIX: The Second Generation DVB Transmission Specifications APPENDIX: The Second Generation DVB Transmission Specifications
This section provides informative background to the network-layer This section provides informative background to the network-layer
requirements of the second generation DVB Transmission requirements of the second generation DVB Transmission
Specifications. The second generation waveforms specified by the Specifications. The second generation waveforms specified by the
Digital Video Broadcasting project offer two main enhancements. Digital Video Broadcasting project offer two main enhancements.
First, more efficient physical layer methods that employ higher First, more efficient physical layer methods that employ higher
order modulation with stronger FEC and permit adaptive coding and order modulation with stronger FEC and permit adaptive coding and
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
skipping to change at page 18, line 32 skipping to change at page 17, line 32
For example, the DVB-S2 [ETSI-S2] transmission link sequentially For example, the DVB-S2 [ETSI-S2] transmission link sequentially
multiplexes a series of baseband frames (BBFrames). Each BBFrame multiplexes a series of baseband frames (BBFrames). Each BBFrame
comprises a fixed-size 10B header and a payload. The payload carries comprises a fixed-size 10B header and a payload. The payload carries
a DataField and uses padding to fill any unused space. A stream a DataField and uses padding to fill any unused space. A stream
comprises a sequence of BBFrames associated with an Input Stream comprises a sequence of BBFrames associated with an Input Stream
Identifier (ISI) that is carried in the header of each BBFrame. The Identifier (ISI) that is carried in the header of each BBFrame. The
simplest scheme uses a single stream (with just one ISI value), but simplest scheme uses a single stream (with just one ISI value), but
multiple streams are permitted. The BBFrames forming a stream may be multiple streams are permitted. The BBFrames forming a stream may be
of variable size (selected from a set of allowed sizes), and must of variable size (selected from a set of allowed sizes), and must
use the same stream format (e.g. TS or GSE). Each stream represents use the same stream format (i.e., TS or GSE). Each stream represents
an independent link with independent address resolution [RFC4947]. an independent link with independent address resolution [RFC4947].
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,
and support for Extension Headers. As in ULE, GSE permits multiple and support for Extension Headers. As in ULE, GSE permits multiple
address formats, indicated by the LT field (functionally equivalent address formats, indicated by the LT field (functionally equivalent
to the D field in ULE). The default addressing mode uses a 6-byte to the D field in ULE). The default addressing mode uses a 6-byte
skipping to change at page 19, line 26 skipping to change at page 18, line 26
Individual Draft 01 Individual Draft 01
Co-Author Added. Co-Author Added.
This draft updates the language and format. This draft updates the language and format.
This draft fixes problems with the concatenation mode, and defines a This draft fixes problems with the concatenation mode, and defines a
new header format that restricts the use of the Type field so that new header format that restricts the use of the Type field so that
all concatenated PDUs MUST have the same Type. all concatenated PDUs MUST have the same Type.
Future versions of this draft may define additional Extension Future versions of this draft may define additional Extension
Headers, proposals and ideas are welcome via the IETF ipdvb mailing Headers, proposals and ideas are welcome via the IETF ipdvb mailing
list. Possible extensions include those for encapsulation FEC, Link list. Possible extensions include those for encapsulation FEC, Link
parameter negotiation (e.g. for header compression), and support for parameter negotiation (e.g., for header compression), and support
ATM/ULE. for ATM/ULE.
Working Group Draft 00 Working Group Draft 00
Fixed editorial mistakes from Christian Praehauser and ID style for Fixed editorial mistakes from Christian Praehauser and ID style for
WG adoption. WG adoption.
Working Group Draft 01 Working Group Draft 01
Corrected contact info for Bernhard. Corrected contact info for Bernhard.
Added TimeStamp Options Added TimeStamp Options
Corrected NITS in draft Corrected NITS in draft
skipping to change at page 20, line 19 skipping to change at page 19, line 19
Working Group Draft 04 Working Group Draft 04
Editorial changes to prepare the document for WGLC. Editorial changes to prepare the document for WGLC.
Updated IANA section to comply with RFC4326 IANA Guidelines. Updated IANA section to comply with RFC4326 IANA Guidelines.
Reduced Security considerations section by reference to other Reduced Security considerations section by reference to other
documents that give a fuller discussion. documents that give a fuller discussion.
There were no intentional changes to the protocol specification. There were no intentional changes to the protocol specification.
Working Group Draft 06 Working Group Draft 05
Addressed review comments. Addressed review comments.
Working Group Draft 06 Working Group Draft 06
Updated reference to GSE (now an ETSI Spec) - This spec has a Updated reference to GSE (now an ETSI Spec) - This spec has a
normative reference to the current document. normative reference to the current document.
Minor editorial corrections to English Minor editorial corrections to English
Working Group Draft 07
Updated following Gen-Art Review & SECDIR Review by IETF.
[END of RFC EDITOR NOTE] [END of RFC EDITOR NOTE]
 End of changes. 52 change blocks. 
95 lines changed or deleted 101 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/