draft-ietf-ipdvb-ule-ext-01.txt   draft-ietf-ipdvb-ule-ext-02.txt 
Internet Engineering Task Force Gorry Fairhurst Internet Engineering Task Force Gorry Fairhurst
Internet Draft University of Aberdeen Internet Draft University of Aberdeen
Expires July 2007 B. Collini-Nocker Expires November 2007 B. Collini-Nocker
University of Salzburg University of Salzburg
Extension Formats for Unidirectional Link 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-01.txt draft-ietf-ipdvb-ule-ext-02.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 34 skipping to change at page 1, line 34
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
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 Link Encapsulation (ULE) [RFC4236]. Unidirectional Lightweight Encapsulation (ULE), RFC4326.
The Extension Header formats defined in this document define new The Extension Header formats defined in this document define new
extensions that are common extensions to both ULE and the Generic extensions that are common extensions to both ULE and the Generic
Stream Encapsulation (GSE) [GSE] defined by the second generation Stream Encapsulation (GSE) defined to support the second generation
framing structure DVB-S2 standard [S2]. framing structure defined by Digital Video Broadcasting (DVB) family
of 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
3.3 TimeStamp Extension 3.3 TimeStamp Extension
4. Summary 4. IANA Considerations
5. IANA Considerations
6. Acknowledgments 5. Acknowledgements
7. Security Considerations 6. Security Considerations
8. References 7. References
8.1 Normative References 7.1 Normative References
8.2 Informative References 7.2 Informative References
9. Authors' Addresses 8. Authors' Addresses
10. IPR Notices 9. IPR Notices
10.1 Intellectual Property Statement 9.1 Intellectual Property Statement
10.2 Disclaimer of Validity 9.2 Disclaimer of Validity
11. Copyright Statement 10. Copyright Statement
11.1 Intellectual Property Statement
11.2 Disclaimer of Validity
Appendix A: Appendix: The Second Generation DVB Transmission Specifications
1. Introduction 1. Introduction
This document describes two new Header Extensions that may be used This document describes three new Header Extensions that may be used
with both Unidirectional Link Encapsulation, ULE, [RFC4236] and the with both Unidirectional Lightweight Encapsulation, ULE, [RFC4326]
Generic Stream Encapsulation (GSE) [GSE]. ULE is defined for links and the Generic Stream Encapsulation (GSE) [GSE]. ULE is defined for
that employ the MPEG-2 Transport Stream, and supports a wide variety links that employ the MPEG-2 Transport Stream, and supports a wide
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 specifically for DVB-S2 [ETSI-S2]. The requirements for layers, and in the first instance for DVB-S2 [ETSI-S2]. The
the Generic Stream are defined in [S2-REQ], [S2-REQ-RCS], and [ID- requirements for the Generic Stream are described in [ID-S2-REQ].
S2-REQ]. The important characteristics of this encapsulation are The important characteristics of this encapsulation are described in
described in an Appendix to this document. GSE maintains a design an Appendix to this document. GSE maintains a design philosophy that
philosophy that presents a common network interface to that of ULE presents a common network interface to that of ULE and uses a
and uses a similar construction for Subnetwork Data Unit (SNDUs). similar construction for Subnetwork Data Unit (SNDUs).
One extension header defines a method that allows one or more TS- The first Extension Header defines a method that allows one or more
Packets [ISO-MPEG] to be sent within a ULE SNDU. This method may be TS-Packets [ISO-MPEG2] to be sent within a ULE SNDU. This method may
used to provide control plane information including the transmission be used to provide control plane information including the
of MPEG-2 Program Specific Information (PSI) for the Multiplex. In transmission of MPEG-2 Program Specific Information (PSI) for the
GSE, there is no native support for transport stream packets and Multiplex. In GSE, there is no native support for transport stream
this method is therefore suitable for providing an MPEG-2 control packets and this method is therefore suitable for providing an MPEG-
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 receivers that are not addressed by
the NPA, since these receivers may then skip several PDUs in one the NPA, since these receivers may then skip several PDUs in one
operation. The method is defined as a generic extension header and operation. The method is defined as a generic Extension Header and
may be used for IPv4 or IPv6 packets. If and when a compression may be used for IPv4 or IPv6 packets. If and when a compression
format is defined for ULE or Ethernet, the method may also be used format is defined for ULE or Ethernet, the method may also be used
in combination with this method. 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.
The appendix includes a summary of key design issues and An appendix includes a summary of key design issues and
considerations based on the GSE Specification defined by the DVB considerations based on the GSE Specification defined by the DVB
Technical Module [GSE]. Technical Module [GSE].
2. Conventions used in this document 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"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 [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 Broadcast. A framework and set of DVB: Digital Video Broadcasting. A framework and set of
associated standards published by the European Telecommunications associated standards published by the European Telecommunications
Standards Institute (ETSI) for the transmission of video, audio, and Standards Institute (ETSI) for the transmission of video, audio, and
data. data.
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
into Payload Units (known here as SNDUs) for output in DVB-S or the into 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 [S2]. 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
format.
GSE: Generic Stream Encapsulation [GSE]. GSE: Generic Stream Encapsulation [GSE]. A method that encapsulates
PDUs that form a Generic Stream, which is sent using a sequence of
BBFrames. This encapsulation format shares the same extension
format, and basic processing rules of ULE and uses a common IANA
Registry.
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
Group (MPEG), and standardized by the International Standards Group (MPEG), and standardized by the International Standards
Organisation (ISO/IEC 113818-1) [ISO-MPEG], and ITU-T (in H.220). Organisation (ISO/IEC 113818-1) [ISO-MPEG2], and ITU-T (in H.220).
Next-Header: A Type value indicating an Extension Header [RFC4236]. Next-Header: A Type value indicating an Extension Header [RFC4326].
NPA: Network Point of Attachment [RFC4236]. 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
header of each TS Packet. This identifies the TS Logical Channel to
which a TS Packet belongs [ISO-MPEG2]. The TS Packets that form the
parts of a Table Section, or other Payload Unit must all carry the
same PID value. The all ones PID value indicates a Null TS Packet
introduced to maintain a constant bit rate of a TS Multiplex. There
is no required relationship between the PID values used for TS
Logical Channels transmitted using different TS Multiplexes.
PDU: Protocol Data Unit [RFC4259]. Examples of a PDU include PDU: Protocol Data Unit [RFC4259]. Examples of a PDU include
Ethernet frames, IPv4 or IPv6 datagrams, and other network packets. Ethernet frames, IPv4 or IPv6 datagrams, and other network packets.
PSI: Program Specific Information [ISO-MPEG]. PSI: Program Specific Information [ISO-MPEG2].
SI Table: Service Information Table [ISO-MPEG]. In this document, S: A one-bit flag field defined in [GSE].
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 carrier. 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-MPEG], 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 Link Encapsulation (ULE) [RFC4236]. A scheme ULE: Unidirectional Lightweight Encapsulation (ULE) [RFC4326]. A
that encapsulates PDUs, into SNDUs that are sent in a series of TS method that encapsulates PDUs, into SNDUs that are sent in a series
Packets using a single TS Logical Channel. The encapsulation format of TS Packets using a single TS Logical Channel. The encapsulation
defined by this document shares the same extension format, and basic defines an extension format and an associated IANA Registry.
processing rules and uses a common 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 two extension
formats for the ULE encapsulation. The GSE specification is defined formats for the ULE encapsulation. The GSE [GSE] follows the same
in [GSE] and follows these formats, but as in other SNDU formats, format as used in the ULE Type field. The encapsulation format
GSE does not include a per-SNDU CRC and utilises a different SNDU differs in that GSE does not include a per-SNDU CRC, has different
length calculation [GSE]. header flags, and utilises a different SNDU length calculation
[GSE].
3.1 MPEG-2 TS-Concat Extension 3.1 MPEG-2 TS-Concat Extension
>>> IANA Action required, please replace < #NH-TS-CAT> with assigned
value from the Next-Header Registry>>>
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 <#NH-TS-CAT>. This is a Mandatory Next- assigned H-Type value of 0x0002 in hexadecimal. This is a Mandatory
Header Extension. Next-Header Extension.
The extension is used to transport 1 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 specified by the remainder of the SNDU is determined from the size of the remainder of the payload
Payload following the MPEG-2 TS Extension. 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). A precede the MPEG-2 TS-Concat Extension (zero if there are none).
Receiver MUST check that the payload length is correct prior to
processing it. Any mismatch (remainder from the division) MUST
result in discard of all encapsulated PDUs and SHOULD be recorded as
TS-concat size mismatch error.
A value D=0 indicates the presence of a NPA address. In that case A Receiver MUST check that the validity of the value of the payload
the correct payload length for ULE is (Length-10) / 188, whereas in Length prior to processing. Any mismatch (remainder from the
case of GSE the correct payload length is (Length-6) / 188. division) MUST result in discard of all encapsulated PDUs and SHOULD
be recorded as TS-Concat size mismatch error.
>>> IANA Action required, please replace < #NH-TS-CAT> with assigned
value from the Next-Header Registry>>>
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 = 0x <#NH-TS-CAT> | |0| Length (15b) | Type = 0x0002 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Destination NPA Address (6B) | | Receiver Destination NPA Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| TS-Packet 1 | | TS-Packet 1 |
= = = =
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS-Packet 2 (if Length > 2*188) | | TS-Packet 2 (if Length > 2*188) |
= = = =
| etc. | | etc. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) | | (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ULE/SNDU Format for a TS-Packet Payload (D=0) Figure 1: ULE/SNDU Format for a TS-Packet Payload (D=0)
Figure 1 illustrates the format of this Extension Header for ULE
with a value D=0, which indicates the presence of a NPA address
[RFC4326]. In this case, the valid payload Length for a ULE SNDU
with no other extensions is (Length-10) / 188.
>>> IANA Action required, please replace <#NH-TS-CAT> with assigned The method used to define the Length in GSE differs to that of ULE.
value from the Next-Header Registry>>> The equivalent case for GSE would result in a payload Length value
of (Length-6) / 188 (Figure 2).
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 =0x <#NH-TS-CAT> | |S|E|0 0| Length (12b) | Type = 0x0002 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Destination NPA Address (6B) | | Receiver Destination NPA Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| TS-Packet 1 | | TS-Packet 1 |
= = = =
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 (D=0) Figure 2: GSE/SNDU Format for a TS-Packet Payload (LT=00)
Note that fragmented GSE SNDUs are protected by a CRC-32 carried in Note that fragmented GSE SNDUs are protected by a CRC-32 carried in
the final fragment, and that non-fragmented GSE SNDUs are protected the final fragment. The fields labelled S and E are defined by [GSE}
by a CRC-32 in the final bytes of the GS DataField. and contains control flags used by the GSE link layer. The Label
Type field (LT) specifies the presence and format of the GSE label.
A value of D=1, is also permitted and indicates the absence of a NPA
address, as defined in ULE. A similar format is supported in GSE.
>>> IANA Action required, please replace <#NH-TS-CAT> with assigned In ULE, a value of D=1, is also permitted and indicates the absence
value from the Next-Header Registry>>> 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 = 0x<#NH-TS-CAT> | |1| Length (15b) | Type = 0x0002 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS-Packet 1 | | TS-Packet 1 |
= = = =
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS-Packet 2 (if Length > 2*188) | | TS-Packet 2 (if Length > 2*188) |
= = = =
| 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)
The extension may be used to transport one or more MPEG-2 TS Packets This extension may be used to transport one or more MPEG-2 TS
of arbitrary content, interpreted according to [ISO-MPEG]. One Packets of arbitrary content, interpreted according to [ISO-MPEG2].
expected use is for the transmission of MPEG-2 SI/PSI signalling. One expected use is for the transmission of MPEG-2 SI/PSI
signalling.
NULL TS Packets are not normally sent using this encapsulation. To
reduce transmission overhead and processing, an Encapsulator SHOULD
specify a maximum period of time that it can wait before sending all
queued TS Packets. This is known as the TS Packing Threshold. This
value MUST be bounded and SHOULD be configurable in the
Encapsulator. A larger value can improve efficiency, but incurs
higher jitter and could increase the probability of corruption. If
additional TS Packets are NOT received within the TS Packing
Threshold, the Encapsulator MUST immediately 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, SI Table) over ULE/GSE framing raises
timing considerations at the encapsulation gateway, including the timing considerations at the encapsulation gateway, including the
need to update/modify the timing information prior to transmission need to update/modify the timing information prior to transmission
by the physical layer. These issues are not considered here, but it by the physical layer. These issues are not considered here, but
is noted that the operation may be simplified by ensuring that all this operation may be simplified in GSE by ensuring that all SNDUs
SNDUs that carry this Extension Header are placed before other data that carry this Extension Header are placed before other data within
within the GSE DataField [GSE]. the BBFrame DataField [GSE].
3.2 PDU-Concat Extension This document does not specify how TS Packets are to be handled at
the Receiver, however it notes that a poorly configured Encapsulator
could lead to a Multiplex carrying multiple (possibly conflicting)
sets of TS Logical Channels and SI information encapsulated at
different levels or with different NPA addresses. The need for
consistency in the use of PIDs and the related SI information is
described in [RFCxARx].
>>> IANA Action required, please replace <#NH-PDU-CAT> with assigned 3.2 PDU-Concat Extension
value from the Next-Header Registry>>>
The PDU-Concat Extension is specified by an IANA assigned H-Type The PDU-Concat Extension Header is specified by an IANA assigned H-
value of <#NH-PDU-CAT> This is a Mandatory Next-Header Extension. Type value of 0x0003 in hexadecimal. This is a Mandatory Next-Header
It enables a sequence of (usually short) PDUs to be sent within a Extension. It enables a sequence of (usually short) PDUs to be sent
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 also including each set of encapsulation headers. The base header MAY be
caries a 16-bit ULE Type field. Although any Type value specified in followed by one or more additional Extension Headers preceding the
the ULE Next-Header Registry may be assigned to the encapsulated PDU-Concat Extension Header. These Extension Headers (e.g. a
PDU, all PDUs included in the SNDU payload MUST have a common ULE TimeStamp Extension) apply to the composite concatenated PDU.
Type (i.e. all concatenated PDUs passed by the network layer must be
associated with the same Type value). This simplifies the receiver The Extension Header also conatains a 16-bit ULE Type field
design, and reduces the transmission overhead for common use cases. describing the encapsulated PDU, CONCAT-PDU-Type. Although any Type
value specified in the ULE Next-Header Registry (including Extension
Header Types) may be assigned to the encapsulated PDU, all
concatenated PDUs MUST have a common ULE Type (i.e. all concatenated
PDUs passed by the network layer must be associated with the same
Type value). This simplifies the receiver design, and reduces the
transmission overhead for 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 MUST be set to zero. The length of significant bit of the first byte is reserved, R, and this
specification requires that this MUST be set to zero. The length of
each PDU MUST be less than 32 758 bytes, but will generally be much each PDU MUST be less than 32 758 bytes, but will generally be much
smaller. 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), a Network Point of Attachment, NPA, field Address field (i.e. D=0 in ULE), a Network Point of Attachment, NPA,
directly follows the fourth byte of the SNDU header. NPA destination field directly follows the fourth byte of the SNDU header. NPA
addresses are 6 Byte numbers, normally expressed in hexadecimal, destination addresses are 6 Byte numbers, normally expressed in
used to identify the Receiver(s) in a transmission network that hexadecimal, used to identify the Receiver(s) in a transmission
should process a received SNDU. When present the Receiver MUST network that should process a received SNDU. When present the
associate the same specified MAC/NPA address with all PDUs within Receiver MUST associate the same specified MAC/NPA address with all
the SNDU Payload. This MAC/NPA address MUST also be forwarded with PDUs within the SNDU Payload. This MAC/NPA address MUST also be
each PDU, if required by the forwarding interface. forwarded with each PDU, if required by the forwarding interface.
>>> IANA Action required, please replace <#NH-PDU-CAT> with assigned
value from the Next-Header Registry in the next two figures>>>
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 = 0x<#NH-PDU-CAT> | |0| Length (15b) | Type = 0x0003 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Destination NPA Address (6B) | | Receiver Destination NPA Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | CONCAT-PDU-Type | | | CONCAT-PDU-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| PDU-Length-1 (15b) | | |R| PDU-Length-1 (15b) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
= PDU-1 = = PDU-1 =
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| PDU-Length-2 (15b) | | |R| PDU-Length-2 (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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 10, line 36 skipping to change at page 10, line 32
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Length (15b) | Type = 0x<#NH-PDU-CAT> | |S|E|0 0| Length (12b) | Type = 0x0003 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Destination NPA Address (6B) | | Receiver Destination NPA Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | CONCAT-PDU-Type | | | CONCAT-PDU-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| PDU-Length-1 (15b) | | |R| PDU-Length-1 (15b) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
= PDU-1 = = PDU-1 =
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| 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 (D=0)
A value of D=1 indicates there is no NPA/MAC address in use. This Figure 5: GSE/SNDU Format for a PDU-Concat Payload (LT=00)_
field MUST be carried (i.e. D=0) for IP unicast packets destined to
routers that are sent using shared links (i.e., where the same link The value of D in the ULE header idicates whether a NPA/MAC address
connects multiple Receivers). A sender MAY omit this field (D=1) for is in use [RFC4326]. A similar format is supported in GSE.
a set of packets delivered to a Receiver or group of receivers that
are able to utilise a discriminator field (e.g. the IPv4/IPv6
destination address, or a bridged MAC destination address), which in
combination with the PID value, could be interpreted as a Link-Level
address. A similar format is supported in GSE.
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 = 0x<#NH-PDU-CAT> | |1| Length (15b) | Type = 0x0003 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CONCAT-PDU-Type |0| PDU-Length-1 (15b) | | CONCAT-PDU-Type |R| PDU-Length-1 (15b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= PDU-1 = = PDU-1 =
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| PDU-Length-2 (15b) | | |R| PDU-Length-2 (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)
To reduce transmission overhead and processing, an Encapsulator
SHOULD specify a maximum period of time it will wait before sending
a Concatenated PDU. This is known as the PDU Packing Threshold. This
value MUST be bounded and SHOULD be configurable in the
Encapsulator. A larger value can improve efficiency, but incurs
higher jitter and could increase the probability of corruption. If
additional PDUs are NOT received within the PDU Packing Threshold,
the Encapsulator MUST immediately send any 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 CONCAT-PDU 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). It then
extracts each encapsulated PDU in turn. The Receiver MUST verify the extracts each encapsulated PDU in turn. The Receiver MUST verify the
Length of each PDU. It MUST also ensure the sum of the Lengths of Length of each PDU. It MUST also ensure that the sum of the Lengths
all processed PDUs is less than the Length specified in the SNDU of all processed PDUs equals the Length specified in the SNDU base
base header. A Receiver MUST discard the whole SNDU if the sizes do header. A Receiver SHOULD discard the whole SNDU if the total and
not match and this event SHOULD be recorded as a PDU-concat size PDU sizes are not consistent and this event SHOULD be recorded as a
mismatch error. PDU-Concat size mismatch error.
3.3 Timestamp Extension 3.3 Timestamp Extension
The timestamp extension header permits an Encapsulator to add a The Timestamp Extension Header permits an Encapsulator to add a
timestamp field to an SNDU. This is designed to support monitoring timestamp field to an SNDU. This is designed to support monitoring
and measurement of ULE performance over a link to indicate the and measurement of ULE performance over a link to indicate the
quality of an operational ULE link. This may be useful for GSE links quality of an operational ULE link. This may be useful for GSE links
(where significant complexity exists in the scheduling provided by (where significant complexity exists in the scheduling provided by
the lower layers). This extension may be (optionally) checked at the the lower layers). This extension may be (optionally) checked at the
Receiver. Receiver.
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). * PDU loss (with additional information from the sender).
>>> IANA please insert a value for the H-Type from the Optional part
of the Next-Header Registry, and replace <NH-TStamp> in the sentence
below, and the figure following <<<
The Timestamp Extension Header is specified by the IANA-assigned H- The Timestamp Extension Header is specified by the IANA-assigned H-
Type of <NH-TStamp>. This extension is an Optional Extension Header Type value of 257 decimal. This extension is an Optional Extension
([RFC4326], Section 5). Header ([RFC4326], Section 5).
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
implied byte-alignment).
0 7 15 23 31 0 7 15 23 31
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| 0x03 | <NH-TStamp> | 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 The format of the 32-bit Timestamp Extension Header
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
implied byte-alignment).
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 timestamp option was inserted, right- Universal Time when the PDU was encapsulated. This value may be
earlier than the time of transmission due for example to Packing,
queueing 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 that do not This is an Optional Extension Header. Receivers SHOULD process the
timestamp when the PDU is decapsulated. Receivers that do not
implement, or do not wish to process, the Timestamp Extension MAY implement, or do not wish to process, the Timestamp Extension MAY
skip this extension and continue to process the remainder of the skip this extension and continue to process the remainder of the
SNDU, forwarding the encapsulated PDU. SNDU, forwarding the encapsulated PDU.
4. Summary 4.. IANA Considerations
This document defines a set of Next_Header Extensions for the
Unidirectional Link Encapsulation (ULE).
5. IANA Considerations
This document requires IANA involvement for the assignment of two This document requires IANA involvement for the assignment of two
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 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 <#NH-TS-CAT>. 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 <#NH-PDU-CAT>. 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 <#NH-TStamp>. 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.
6. Acknowledgments 5. Acknowledgments
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 S2 assistance offered by the members of the DVB-GBS ad hoc group on
encapsulation, in particular contributions on transmission aspects DVB-S2 encapsulation, in particular contributions on DVB-S2
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
annexe. The authors thank Christian Praehauser for his insight and
contribution on header extension processing issues.
7. Security Considerations 6. Security Considerations
No specific security issues are raised within this document. No specific security issues are raised within this document.
Additional security control fields may be provided as a part of a Additional security control fields may be provided as a part of a
link encryption Extension Header, e.g. to associate a PFU with one link encryption Extension Header, e.g. to associate an SNDU with one
of a set of Security Association (SA) parameters. As a part of the of a set of Security Association (SA) parameters. As a part of the
encryption process, it may also be desirable to authenticate encryption process, it may also be desirable to authenticate
some/all of the headers. The method of encryption and the way in some/all of the headers. The method of encryption and the way in
which keys are exchanged is beyond the scope of this specification, 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 as also are the definition of the SA format and that of the related
encryption keys. encryption keys.
8. References 7. References
8.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.
[RFC4236] Fairhurst, G. and B. Collini-Nocker, "Unidirectional [RFC4326] Fairhurst, G. and B. Collini-Nocker, "Unidirectional
Link Encapsulation (ULE) for transmission of IP datagrams over an Lightweight Encapsulation (ULE) for transmission of IP datagrams
MPEG-2 Transport Stream", RFC 4236, December 2006. over an MPEG-2 Transport Stream", RFC 4326, December 2005.
8.2 Informative References [GSE] "Generic Stream Encapsulation", DVB Document A116, DVB
Technical Module (GBS Group), May 2007.
[ETSI-DAT] EN 301 192, "Specifications for Data Broadcasting", 7.2 Informative References
European Telecommunications Standards Institute (ETSI).
[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).
[GSE] "Generic Stream Encapsulation", Work in Progress, DVB
Technical Module (GBS Group), 2006.
[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.rxr>, Work in
Progress. Progress.
[ISO-MPEG] ISO/IEC DIS 13818-1:2000, "Information Technology; [IEEE-802.3] "Local and metropolitan area networks - Specific
requirements Part 3: Carrier sense multiple access with collision
detection (CSMA/CD) access method and physical layer
specifications", IEEE 802.3, IEEE Computer Society, (also ISO/IEC
8802-3), 2002.
[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).
[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.
[S2] EN 302 307, "Digital Video Broadcasting (DVB); Second [RFCxARx] Montpetit, M.-J., Fairhurst, G., "Address Resolution
generation framing structure, channel coding and modulation systems Mechanisms for IP Datagrams over MPEG-2 Networks", RFC Ed Queue,
for Broadcasting, Interactive Services, News Gathering and other <draft-ietf-ipdvb-ar-xx.txt>, 2007.
broadband satellite applications", European Telecommunication
Standards Institute (ETSI).
[S2-REQ] GBS0339, "Functional and performance requirements for
IP/S2", DVB-TM (GBS WG).
[S2-REQ-RCS] "Requirements for S2", Document 529r1, DVB Technical
Module (RCS WG).
9. Authors' Addresses 8. Authors' Addresses
Godred Fairhurst Godred Fairhurst
Department of Engineering Department 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
Web: http://www.erg.abdn.ac.uk/users/Gorry Web: http://www.erg.abdn.ac.uk/users/Gorry
Bernhard Collini-Nocker Bernhard Collini-Nocker
skipping to change at page 15, line 30 skipping to change at page 15, line 7
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
Web: http://www.cosy.sbg.ac.at/ Web: http://www.cosy.sbg.ac.at/
10. IPR Notices 10. IPR Notices
10.1 Intellectual Property Statement 9.1 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
documents can be found in BCP 78 and BCP 79. documents can be found in BCP 78 and BCP 79.
skipping to change at page 16, line 5 skipping to change at page 15, line 31
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.
10.2 Disclaimer of Validity 9.2 Disclaimer of Validity
This document and the information contained herein are provided on This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE. FOR A PARTICULAR PURPOSE.
11. Copyright Statement 10. Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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.
APPENDIX: DVB-S.2 APPENDIX: The Second Generation DVB Transmission Specifications
PDUs, (Ethernet Frames, IP datagrams or other network layer packets) This section provides informative background to the network layer
are encapsulated to form a Subnetwork Data Unit (SNDU) [RFC4236] requirements of the second generation DVB Transmission
associated with a specific Stream at the link layer. The SNDU is Specifications. The second generation waveforms specified by the
transmitted over an DVB-S2 link by placing it either in a single Digital Video Broadcasting project offer two main enhancements.
BBFrame, or if required, an SNDU may be fragmented into a series of First, more efficient physical layer methods that employ higher
BBFrames [ID-S2-REQ]. A mode also permits an SNDU to be fragmented order modulation with stronger FEC and permit adaptive coding and
with the remaining fragments sent in a later BBFrame(s), while modulation response to changes in traffic and propagation
preserving the original order of each SNDU sent to a specific conditions. Second, at the link layer, they offer greater
MAC/NPA address over a Stream. Where there is sufficient space, the flexibility in framing. Support is provided for a range of stream
method permits a BBFrame to carry more than one SNDU (or part there formats including the classical Transport Stream (TS) [RFC4259]. In
of), sometimes known as Packing. All parts comprising an SNDU are addition, a new method called Generic Streams (GS) (or the Generic
assigned to the same Stream. Mode) is supported. A GS can be packetized or continuous and is
intended to provide native transport of other network-layer
services. One such method is that provided by the Generic Stream
Encapsulation (GSE) [GSE].
In ULE and MPE [ETSI-DAT], each SNDU carries a 32-bit CRC field in A transmission link sequentially multiplexes a series of baseband
the last four bytes of the SNDU. The purpose of this CRC is to frames (BBFrames). Each BBFrame comprises a fixed-size 10B header
protect the SNDU (header, and payload) from undetected reassembly and a payload. The payload carries a DataField and uses padding to
errors and errors introduced by unexpected software / hardware fill any unused space. A stream comprises a sequence of BBFrames
operation. This also serves to verify the delineation (framing) of associated with an Input Stream Identifier (ISI) that is carried in
PDUs and may detect the presence of uncorrected errors from the the header of each BBFrame. The simplest scheme uses a single
physical link stream (with just one ISI value), but multiple streams are
permitted. The BBFrames forming a stream may be 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 an independently
link with independent address resolution [RFCxARx].
When an SNDU is sent over a DVB-S2 subnetwork using GSE, the GSE provides functions that are equivalent to those of the
Integrity protection is provided by a CRC at the baseband frame Unidirectional Lightweight Encapsulation (ULE) [RFC4326]. It
level, using a CRC in the final bytes of the DataField. supports the transmission of IP packets and other network-layer
protocols. The network-layer interface resembles that of ULE, where
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
a suppressed NPA address (functionally equivalent to D=1 in ULE). In
addition GSE also supports other addressing modes. It employs a CRC
method in which a CRC is placed at the end of a BBFrame, covering
multiples SNDUs. This is a result of more advanced physical layer
coding and a larger link frame size differ 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
the physical layer. This adapts the SNDUs to a variable-sized link-
layer frame, and reflects the more complex requirements in terms of
fragmentation and assembly that arise when using point-to-multipoint
adaptive physical layers.
[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 30 skipping to change at page 17, line 30
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 for
ATM/ULE. 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
Working Group Draft 01
Amended diagrams and text to follow tentative IANA assignments for
the codepoints.
Working Group Draft 01
Ammended text to follow IANA assignments for the codepoints.
Added issues raised at ipdvb meeting by C Praehauser.
Revised annexe with text from GSE Spec, J Cantillo, et al.
Revised wording to clarify corner cases.
Removed references to documents not in public domain.
Updated conventions and abbreviations for consistency.
Updated text referencing ULE.
[END of RFC EDITOR NOTE] [END of RFC EDITOR NOTE]
 End of changes. 112 change blocks. 
241 lines changed or deleted 301 lines changed or added

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