GSE: DVB-S2 GENERIC STREAM IP ENCAPSULATION PROTOCOL

Authors: Ulrik De Bie, Bernhard Collini-Nocker, Gorry Fairhurst, Alberto Ginesi, Axel Jahn, Rita Rinaldo, Oscar Del Rio Abstract The “Second generation framing structure, channel coding and modulation systems for Broadcasting, Interactive Services, News Gathering and other broadband satellite applications” DVB-S2 standard introduces a Generic Stream transport method not only for providing digital TV services, but also as technology for building IP networks and dedicated data streaming. This document describes the Generic Stream Encapsulation (GSE) protocol for the transmission of IPv4 Datagrams and other network protocol packets directly over the DVB S2 Generic Stream. The protocol specifies an encapsulation format and fragmentation over DVB-S2 baseband frames. The encapsulation part of GSE relies in some fundamental design choices on the Unidirectional Lightweight Encapsulation (ULE). GSE uses the same Type Field as ULE that allows it to carry additional header information to assist in network/Receiver processing, but specifies a generic fragmentation method, a different base encapsulation format and another processing method because of the substantially different underlying link-layer.

1

1 Table of Contents 1 Table of Contents...................................................................................................2 2 Conventions used in this document .......................................................................2 3 Introduction............................................................................................................4 4 SNDU and PDU Processing...................................................................................6

4.1 Fragmentation Considerations .......................................................................8 4.2 Protocol Description ......................................................................................9 4.3 SNDU Format ..............................................................................................10

4.3.1 Start (S)/End (E) Indicator Bits............................................................11 4.3.2 Label Bits .............................................................................................11 4.3.3 Length Field .........................................................................................11 4.3.4 Total PDU Length Field.......................................................................12 4.3.5 Label Field ...........................................................................................14 4.3.6 Fragmentation ID Field........................Error! Bookmark not defined. 4.3.7 Protocol Type Field..............................................................................12 4.3.8 GSE CRC-32 Trailer............................................................................15

4.4 Examples of SNDU formats ........................................................................16 5 Encapsulator processing.......................................................................................18 6 Receiver processing .............................................................................................19 7 References............................................................................................................21

7.1 Normative References..................................................................................21 7.2 Informative References................................................................................22

8 Annex 1: Addressing and Binding (Informative) ................................................23

2 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. ACM: Adaptive Coding and Modulation (see ModCod). b: bit. For example, one byte consists of 8b. B: Byte. Groups of bytes are represented in Internet byte order. BB: Baseband. BBFrame payload [ETSI-S2]:

The data field part of a Baseband frame that may be used for the communication of data. Typical BBFrames range in size from 3072 to 58192 bits according to the choice of modulation format and FEC in use.

2

BBH, Baseband Header [ETSI-S2]:

A fixed format 10 byte header that starts each BBFrame. DF: Data Field [ETSI-S2]. The BBFrame payload. Note this abbreviation is

also used for a different function at the IP layer. DFL: Data Field Length [ETSI-S2].

The size of the BBFrame payload measured in bits. A set of DFL values have been specified by S2, corresponding to the set of specified ModCod formats.

DVB: Digital Video Broadcast [ETSI-DVB]. A framework and set of

associated standards published by the European Telecommunications Standards Institute (ETSI) for the transmission of video, audio, and data.

Encapsulator: A network device that receives PDUs and formats these into Payload

Units (known here as SNDUs) for transmission in the BBFRAMEs of DVB-S2/GS. The encapsulator output is sent to the DVB-S2 modulator.

EPU: Encapsulated Payload Unit. A packet defined in this GSE specification

that carries a full PDU or a fragment of a PDU. An EPU consists of a GSE header, the PDU payload and – if the EPU is the last EPU of a series of EPUs belonging to a fragmented PDU - a CRC-32.

FragID Fragmentation ID: an identifier that identifies a series of EPUs

belonging to the same PDU. Each EPU carries a fragment of the PDU. Generic Stream: One of the 2 possible input streams in DVB-S2, the other one

being Transport Streams. Generic Streams can be packetized or continuous, and are intended to be used especially for carrying data services such as IP distribution. An example for a packetized Generic Stream is again a Transport Stream.

GS: See Generic Stream. GSE Header: The logical group of fields that carry the protocol control information

for the encapsulation protocol. GSE: Generic Stream Encapsulation. The protocol defined in this document. GS: Generic Stream. ISI: Input Stream Identifier, the second byte of the header of a BBFrame.

This value uniquely identifies a specific logical channel within a DVB-S2 multiplex.

3

ModCod: Modulation/Coding. A combination of Modulation format and FEC Coding rate that together determine the size of a BBFrame.

MPEG-2: A set of standards specified by the Motion Picture Experts Group

(MPEG), and standardized by the International Standards Organisation (ISO/IEC 113818-1) [ISO-MPEG], and ITU-T (in H.220).

Next-Header: A Type value indicating an Extension Header [RFC4236]. NPA: Network Point of Attachment [RFC4236].

In this document, refers to a destination address (resembling an IEEE MAC address) within the DVB-S2 transmission network that is used to identify individual Receivers or groups of Receivers.

Padding: A sequence of bytes with the value 0x00 that are used to occupy the

unused portion of a BBFrame payload, as from [ETSI-S2]. The DFL field indicates the actual length of the BBFRAME data field.

PDU: Protocol Data Unit [RFC4259]. Examples of a PDU include Ethernet

frames, IPv4 or IPv6 datagrams, and other network packets. PDUs are carried as payload in SNDUs of the GSE protocol.

SNDU: Subnetwork Data Unit [RFC4259]. In this document this is an

encapsulated PDU consisting of a TypeField, a label (if present) and a PDU. An SNDU can be carried as a whole in an EPU or it can be fragmented into a series of EPUs.

Stream: A logical flow from an Encapsulator to a set of Receivers. The

addresses at the MAC/NPA level and IP level need to be unique within a specific stream (i.e. denoted by a common S2 ISI value).

TS: Transport Stream [ISO-MPEG], a method of transmission at the

MPEG-2 level using TS Packets; it represents layer 2 of the ISO/OSI reference model.

ULE: Unidirectional Lightweight Encapsulation (ULE) [RFC4236]. A

scheme that encapsulates PDUs, into SNDUs that are sent in a series in a BBFrame of several BBFrames. The encapsulation format defined by this document shares the same extension format, and basic processing rules and uses a common IANA Registry.

3 Introduction This document describes an encapsulation and fragmentation for the transport of IP datagrams, or other network layer packets, over ETSI DVB-S2 Generic Streams [ETSI-DVBS2]. Protocol requirements have been defined in [S2-REQ], including [S2-REQ-GBS] and [S2-REQ-RCS]. Among other network protocols, the GSE

4

method also allows TS-Packets [ISO-MPEG] to be sent as GSE SNDUs. This may be used to provide control information and/or Program Specific Information (PSI) for a Multiplex. The design rationales for the protocol were driven by the peculiarities of DVB-S2 Generic Streams which carries both several fixed sized packets as well as variable sized packets in baseband frames (BBframe) of variable length, whose length is determined by the amount of forward error correction information being added onto physical layer frames. BB-frame sizes vary from 384 bytes to 7274 bytes. Adaptive Coding and Modulation (ACM) allows for changing coding and modulation (MODCOD) on-the-fly and in accordance with the link quality perceived at a certain Receiver or group of Receivers. Consequently a specific Receiver will be able to demodulate and decode only those BBframes whose MODCOD matches the perceived link quality. Receivers that are able to demodulate and decode all BBframes of the Generic Stream receive the same Generic Stream as continuous stream of BB-frames as being sent from the Encapsulator, whereas Receivers with worse reception will receive only reasonable protected BB-frames, hence, each MODCOD forms a sort of virtual channel. However, Receiver hardware perceives these virtual channels as a continuous stream of BBframes, potentially with different sizes. The DVB-S2 standard permits an Encapsulator to transmit different network layer packets destined to a specific Receiver into BBframes with different MODCOD, and feedback from the Receiver about its link quality may trigger MODCOD changes at any time. The 10B header of a BB-frame carries the length of the DataField, but, in difference to the 4B header of a Transport Stream Packet, does neither include a Payload Unit Start Indicator (PUSI) nor a Transport Error Indicator (TEI), GSE will resemble its own Start and End Indicator for reassembly of encapsulated units instead. GSE can transport payload data units (PDUs) over DVB-S2. For this the PDU is encapsulated with a TypeField and an optional label which can be used for receiver filtering (e.g., a 6-byte MAC address). The GSE protocol defines Encapsulated Payload Units (EPUs) consisting of a GSE header, a or fragment of a PDU/SNDU, and a CRC-32 (in case that the EPU is the last EPU of a fragmented PDU/SNDU. GSE can fragment an payload data units (PDUs) into fragments of any size. A DVB-S2 DataField can carry several EPUs with typically sized network packets. Fragmentation across BBframe boundaries in principle allows for cutting a network packet at BB-frame border and for resuming it in the next BB-frame. Because the ACM allows MODCOD changes at any time, a BB-frame fragmentation requires a different MODCOD and some or all Receivers will not be able to decode it. Manufacturer, hence, have requested to allow for arbitrary placement of complete or fragmented network packets within BB-frames in order to meet potential QoS requirements of specific IP flows and in order to optimize link utilization. Since arbitrary fragment placements does not necessarily preserve fragment order, except maybe within the same MODCOD, the identification of fragments is subtle. It shall be noted that the maximum possible number of incomplete fragments may require significant buffer space to be maintained in a receiver. In ULE, the receiver only has the states IDLE or REASSEMBLING, whereas arbitrary placement in the worst case requires N simultaneous REASSEMBLING states, where N is the number of not yet completely reassembled PDUs.

5

Apart from fragmentation, the protocol supports several addressing possibilities. GSE provides support for hardware filtering in the receiver with two Label bits signalling the absence/presence of a 6B label (e.g., a IEEE MAC address), a 3 Byte label (e.g., a RCS group/logon ID) or any other Network Point of Attachment (NPA) address. In addition broadcasting to all terminals without the provision of a specific label and the concatenation of PDUs in subsequent EPUs (without the repetition of a label) is provided in GSE. The basic GSE header provides the required set of protocol fields to separate fragmentation and encapsulation. Extension headers may be defined as for ULE. The GSE header structure is simple to parse and process. Protocol Data Units, PDUs, (Ethernet Frames, IP datagrams or other network layer packets) for transmission over an DVB-S2 Multiplex are passed to an Encapsulator. This formats each PDU into a SNDU or a series thereof by adding an encapsulation and optional fragmentation header. The identification field of the fragmentation header allows to interleave several fragments in a series of BBframes. A check trailer is added in the last fragment of a PDU to protect from reassembly errors. Another integrity check is placed at the end of each DataField to protect all EPUs in one BB-frame from transmission errors. The EPUs are placed into BB-frames that are sent over a single GS Logical Channel characterized by its Input Stream Identifier (ISI).

4 EPU and PDU Processing Protocol Data Units, PDUs, (Ethernet Frames, IP datagrams or other network layer packets) for transmission are passed to an Encapsulator. This formats each PDU into a SubNetwork Data Unit (SNDU) by encapsulating it with a TypeField and Label. The TypeField field and label is considered part of the GSE header. GSE can send the PDU as a whole. Encapsulator may also fragment the PDU into PDU fragments, which can be then sent in a series of PDU fragments sent in one or more BaseBand (BB) frames that are transmitted over the DVB S2 link. Depending on the need, an integrity check trailer [RFC4259] for the entire PDU is added. BB-frames of GS may carry several EPUs. All EPUs in one single BB-frame are protected against transmission errors by a CRC-32 in the last four bytes of the DataField. The Receiver MUST calculate this CRC and discard BB-frames that do not have a matching CRC. In principle the GSE method is not limited to DVB-S2 GS only. GSE may work for any transport of network layer packets over a stream of sequential, yet variable sized link layer frames, where a Receiver may only receive a portion of it. Therefore GSE supports generic fragmentation and arbitrary placement of fragments within frames. As long as the number of outstanding fragmented PDUs is smaller than the maximum Identification Field value, a reassembly is possible. The header of each EPU carries a one bit Start Indicator (S bit) in the top-most bit. An S bit with a value of 1 indicates the start of a PDU after the GSE header. Additionally the GSE header has an End Indicator (E bit) as second-top-most bit in the header. An E bit with a value of 1 indicates the end of a PDU within the EPU. Note that in case both bits have the value 1 in a particular EPU then this GSE MUST carry a complete PDU. A PDU that cannot be carried in a non-fragmented PDU is fragmented into a series of at least two EPU. Each EPU belonging to the same PDU is identified by a

6

particular identification field value. An additional CRC-32 in the last four bytes of the last EPU (S-bit = 0, E-bit = 1) protects from reassembly errors. The Receiver MUST calculate this CRC and MUST discard a reassembled PDU whose CRC does not match. The GSE header includes a 2 Byte Protocol Type/Extension field indicating the protocol of the carried PDU payload. The Protocol Type field is given in the GSE header for each complete PDU or first fragment of a PDU. Although GSE defines a different framing method to ULE [RFC4236], it maintains the same encapsulation philosophy as ULE for construction of the SNDUs. This will allow subsequent extension of ULE by definition of additional Type Fields that may also be supported within GSE. The Protocol Type field uses an extension header processing in place of flag-parsing to support optional PDU formats, providing a method for efficient option support. This field also permits the use of any IEEE format frame, including those that control L2 infrastructure (QoS, VLAN, Network Management, ST, etc), bridging, and IETF-defined methods such as IPv4, IPv6, MPLS, arp, etc. The final use of this field is as a discriminator for IETF-defined encapsulation extensions. Currently envisaged extensions are (a) Security extensions providing functions such as: encryption, identity hiding, and authentication methods; (b) Header compression methods for various formats of payloads. The GSE header contains two Label (L1, L2) bit signals. The bits indicate whether the PDU carries labels for filtering purposes. The Receiver MUST check whether a Label is present and discard any EPU, whose Label does not match. Four possible combinations of L1 and L2 are interpreted:

L1, L2: 00 the label has a length of 6 Bytes L1, L2: 01 the label has a length of 3 Bytes L1, L2: 10 No label given, all Receivers MUST process the EPU L1, L2: 11 No address present, all Receivers MUST process the EPU, if the last previously provided address was matching the receivers filter. This option allows concatenating sequences of PDUs within a BBFRAME to the same receiver without repeating the label (sometimes also called concatenation).

The Receiver MUST calculate from the first two bytes of the GSE header the 12 bits EPU Length field to examine the length of the EPU and either read the EPU or skip the Length bytes to the next EPU. In case that a PDU is fragmented, the first EPU (S-bit = 1, E-bit = 0) will carry an additional Total Length Field of the PDU. The total length is used by the Receiver to allocate buffer space for the re-assembly process and as an additional integrity check by comparing the length of the received EPUs belonging to one PDU with the total PDU length provided in the GSE header. A Receiver MUST discard a fragmented PDU if the received PDU length does not match the length signalled in the Total Length Field. If transmission efficiency is an important consideration, the duplicate protocol fields should be compressed at the PDU-level not at the SNDU-level. This approach ensures protocol-independent framing of SNDUs; enables protocol-dependent compression (allowing the context of a particular protocol associations to provide sophisticated compression where needed); requires decompression only of those PDUs to be processed by the receiver; and finally allows the decompression function to be off-loaded from the SNDU framing function and encapsulation (e.g. a design that does

7

this as part of the Internet driver interface, rather than the device driver). The recommended approach is therefore to define well-founded and robust compression methods that may be used with both ULE and GSE.

4.1 Fragmentation Considerations This section discusses the different possible ways to perform PDU fragmentation (it makes the simplifying assumption of only 2 fragments per PDU) which are supported in this GSE encapsulation method. The scheduler/Encapsulator in the DVB-S2 system can select the appropriate fragmentation depending on application scenario, traffic load and channel conditions, and – as an important resource issue - the MODCOD for the BBFrames, taking into account the minimal protection required for a PDU destined to a given receiver terminal (or group of terminals). In the following study cases a single stream is considered. When multiple generic streams with different Input Stream Identifiers (ISIs) are multiplexed, the following definitions still apply assuming a sequence of BBFRAMEs is identified by the same ISI value. In case of fragmentation, EPUs are transmitted in different GSE packets. The receiver re-assembles data included in the GSE data fields of EPUs with the same Fragmentation ID. All information related to fragmentation is signalled in the GSE Headers.

1. The simplest (default) mode provides the transmission of a full (un-fragmented PDU) in one EPU. The EPU is sent in one BBFrame.

2. Generic PDU fragmentation: A EPU may start in any position of a BBFRAME with an arbitrary PDU fragment length (and therefore SNDU length). In addition, the total PDU length is carried in a GSE header. The remainder of the PDU is sent in EPUs, which are scheduled later. This EPUs may be sent in any position of one of the following BBFRAMEs (note: it could be sent also in the same BBFrame if there is a use case for it). Using this method, a BBFrame may contain up to 256 fragmented PDUs, which is also the maximum of fragments on system level.

BBFRAME 1 BBFRAME 2 BBFRAME 3 BBFRAME 4

MODCOD 1 MODCOD 2 MODCOD 3 MODCOD 1

The Cases 1 (EPU with full PDU) and 2 (generic fragmentation) are mandatory for GSE. The GSE fragmentation mechanism supports these methods in an efficient manner.

8

4.2 Protocol Description The protocol is used for DVB-S2 forward links using Generic Streams (GS) [ETSI-S2]. A single GS or multiple GS are used for data transmission. ACM commands can be sent for each BBFrame. The Encapsulator delivers complete DataFields (of size indicated by the DataField Length (DFL) value) to the S2 modulator. A DataField can consist of single or several SNDUs, up to the maximum DFL which is supported by DVB-S2 in a given ModCod. PDUs (IP packets, Ethernet frames or packets from other network protocols) are encapsulated to form a Subnetwork Data Unit (SNDU). The SNDU is transmitted over a DVB-S2 link by placing it either in a single EPU which is sent in one BBFrame, or if required, a PDU may be fragmented into several EPUs, which are sent in (one or) a series of BBFrames. GSE does not provide flow control or re-ordering .Thus, the original order of PDUs including EPUs sent to a specific address over a Stream shall be preserved. Where there is sufficient space, the GSE permits to carry more than one PDU in a BBFrame. All BBFrames comprising PDUs or their fragments MUST be assigned to the same Stream. Such BBFRAME(s) are identified by the corresponding Input Stream Identifier (ISI). EPUs scheduled in BBFRAMEs with different ISIs have to be considered as belonging to different logical data flows and are independently processed. At the end of BBframes, only EPUs containing at least the GSE header shall be transmitted. The remaining of the BBFRAME shall be padded following the procedure outlined in the DVB-S2 standard, which fills the remainder of the DVB-S2 Physical Layer Frame (PLFrame) with padding bits. The DataField length (DFL) in combination with the ACM command indicates if a DataField is not completely used for SNDU transmission.

A Receiver receives the BBFrames from the S2 forward link and processes the data field part of the frame indicated by the BBFrame header DFL value. Padded parts of the PLFrame (at an offset larger than the DFL value) are silently discarded. In the DVB-S2 forward link, a LDPC/BCH is used to protect the Baseband frame. The primary target of the LDPC/BCH is as a forward error correction mechanism allowing decreasing the required signal-to-noise ratio of a DVB-S2 reception. The S.2 specification has the possibility that a receiver may detect errors after FEC correction.

9

If this information is available it should be passed to the GSE layer. Currently available information about planned implementations indicates that many of these do not provide a guarantee that the undetected error detection capability is anywhere near the required strength of a 32-bit CRC. Since ACM will be used intensively in DVB-S2, the probability that a baseband frame is received in less than quasi error free conditions is imaginable. Thus, additional error protection is required. For this purpose, the GSE protocol MUST protect each DataField with a CRC-32 in the last 4 Bytes of the BBFrame. The CRC-32 shall be calculated over all bits of the DataField, except for the last 4 Byte of the DataField. The CRC-32 value shall then be sent in the last 4 Byte of the DataField. Receivers shall calculate the CRC-32 of all bits of the DataField except for the last 4 Byte and compare the calculated value with the transmitted CRC-32. In the case of a mismatch, the complete BBFrame shall be discarded. For fragmented PDUs, GSE provides additional integrity check on PDU level through a CRC-32 calculation.

4.3 EPU Format The EPU is composed by

• GSE Header • (fragments of) the PDU, and • CRC-32, in case that the PDU is fragmented and the EPU contains the last

PDU fragment

The GSE header is composed of several fields:

All multi-byte values in GSE (including the Length Indicator, Type, Label, and Extension Headers) are transmitted in network byte order (most significant byte first). The most significant bit of each byte is placed in the left-most position of the 8-bit field.

10

4.3.1 Start (S)/End (E) Indicator Bits The most significant bit of the Length Field carries the value of the Start Indicator Field, the S-bit. A value of 1 indicates the start of a PDU after the GSE header. A value of 0 indicates that a PDU fragment is carried. The second most significant bit of the Length Field carries the value of the End Indicator Field, the E-bit. A value of 1 indicates the that a PDU ends within this GSE packet. A value of 0 indicates that a PDU fragment is carried. If the GSE packet carries a fragment (i.e., all combinations of S-bit and E-bit values except (S=1, E=1)), the GSE header MUST have a Fragmentation ID field following the Length Field.

4.3.2 Label Bits The third and fourth most significant bits of the GSE header carries the values of the Label Bit Field, the L-bits. A receiver MUST interpret the label bits if the S-bit is S=1, i.e. for a unfragmented PDU or for the start of a fragmented PDU. If S=0, the label bits shall be set to 00 and omit the label field, and the receiver MUST ignore the Label Bits and the Label Field. The following combinations of the Label Bits are possible:

00b value: indicates the presence of a 6 Byte Label Field 01b value: indicates the presence of a 3 Byte Label Field 10b value: indicates that no Label Field is present; all receivers MUST process

the GSE header. The receiver shall interpret the address in the PDU (higher layer protocol address, e.g., IP address) by re-assembling all fragments belonging to the PDU and determining whether the packet is addressed to itself by the addressing contained in the PDU.

11b value: indicates that no Label Field is present, receivers SHALL use the last given Label Field in previous GSE packets. This method can be used to transmit a sequence of EPUs to the same receiver without repeating the label.

4.3.3 Length Field The 12-bit Length Field value indicates the length, in bytes, of the EPU counted from the byte following the Length field. The CRC-32 is included only if S bit has value 0 and E bit has value 1. The Length Field allows for a length up to 4 kByte.

4.3.4 Fragmentation ID Field If the EPU carries a fragment (i.e., all combinations of S-bit and E-bit values except (S=1, E=1)), the GSE header MUST have a Fragmentation ID field following the Length Field. The 8-bit Length Fragment Identification value carries a 8 bit identification (ID) for a series of fragmented PDUs that are part of the same PDU. As soon as a PDU has to be

11

fragmented this ID MUST be carried by all EPUs belonging to it. The unsigned 8 bit value MUST wrap around to 0 after incrementing its high possible value (255). The fragmentation ID allows for the simultaneous presence of up to 256 fragmented PDUs in a system. Apart from fragmentation support, it can serve many other use cases, such as support of fragmented QoS flows to the same receiver.

4.3.5 Total PDU Length Field The Total PDU Length Field is 2 Byte. It contains the PDU length in Bytes. GSE header fields are not included in the calculation of the total PDU length. The Total PDU Length Field MUST given for start of PDU fragments (S-bit value 1, E-bit value 0) after the FragID. The length field is always used for providing an easy pointing to the following EPU, independently from the EPU type and fragmentation method. The Total PDU Length field is an extension, present only in the case of fragmentation. It allows the receiver a PDU length check after the re-assembly operation has been completed and allocation of buffer space. For EPU carrying a full PDU (S-bit and E-bit values are 1), the Length Field can be interpreted as total length of the PDU. Although the length of a single EPU is limited to 4 kByte, larger PDUs up to a total length of 64 kByte are supported through fragmentation.

4.3.6 Protocol Type Field The 16-bit Type field indicates the type of payload carried in a PDU, or the presence of a Next-Header. The set of values that may be assigned to this field is divided into two parts, similar to the allocations for Ethernet and MUST follow the rules described in ULE.

Type 1: Next-Header Type Fields The first part of the Type space corresponds to the values 0 to 1535 Decimal. These values may be used to identify link-specific protocols and/or to indicate the presence of Extension Headers that carry additional optional protocol fields (e.g. a bridging encapsulation). Use of these values is co-ordinated by an IANA registry. The remaining values within the first part of the Type space are reserved for Next-Header values allocated by the IANA.

Type 2: EtherType Compatible Type Fields The second part of the Type space corresponds to the values between 0x600 (1536 decimal) and 0xFFFF. This set of type assignments follow DIX/IEEE assignments (but exclude use of this field as a frame length indicator). All assignments in this space MUST use the values defined for IANA EtherType, the following two Type values are used as examples (taken from the IANA EtherTypes registry):

12

0x0800: IPv4 Payload (see 4.10.1) 0x86DD: IPv6 Payload (see 4.10.2)

In addition to the above Types, a MPEG-2 Extension Type is supported.

Extension Headers This section describes an extension format following the ULE format. In ULE, a Type field value less than 1536 Decimal indicates an Extension Header. These values are assigned from a separate IANA registry defined for ULE [RFC4236]. The use of a single Type/Next-Header field simplifies processing and eliminates the need to maintain multiple IANA registries. The cost is that each Extension Header requires at least 2 bytes. This is justified, on the basis of simplified processing and maintaining a simple lightweight header for the common case when no extensions are present. A ULE [RFC4236] Extension Header is identified by a 16-bit value in the Type field. This field is organised as a 5-bit zero prefix, a 3-bit H-LEN field and an 8-bit H-Type field, as follows: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0|H-LEN| H-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The H-LEN value indicates the total number of bytes in an Optional Extension Header (including the 2B Type field) [RFC4236]. An H-LEN value of zero indicates a Mandatory Extension Header. Each Mandatory Extension Header has a pre-defined length that is not communicated in the H-LEN field. No additional limit is placed on the maximum length of a Mandatory Extension Header. A Mandatory Extension Header MAY modify the format or encoding of the enclosed PDU (e.g. to perform encryption and/or compression). The H-Type is a one byte field that is either one of 256 Mandatory Header Extensions or one of 256 Optional Header Extensions. This is defined by ULE [RFC4236]. MPEG-2 TS Extension The MPEG-2 TS Extension Header is specified by an IANA assigned H-Type value of <tbd>. This is a Mandatory Extension. The extension is used to communicate 1 or more MPEG-2 TS Packets over the DVB-S2 link when utilising the Generic Mode. The number of TS Packets carried in a specific SNDU is determined from the size specified by the remainder of the Payload following the MPEG-2 TS Extension. A Receiver MUST silently discard any data, if present, between the last complete encapsulated MPEG-2 TS Packet and the PDU length. The extension may be used to communicate one or more MPEG-2 TS Packets of arbitrary content, interpreted according to [ISO-MPEG]. One expected use is for the transmission of MPEG-2 SI/PSI signalling and clock references.

13

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0|FF| Length (13b) | Type = 0xtbd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TS-Packet 1 | = = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TS-Packet 2 (if Length > 2*188) | = = | etc. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

ATM Extension The ATM Extension Header is specified by an IANA assigned H-Type value of <tbd>. This is a Mandatory Extension. The extension is used to communicate 1 or more ATM Packets over the DVB-S2 link when utilising the Generic Mode. The number of ATM Packets carried in a specific SNDU is determined from the size specified by the remainder of the Payload following the MPEG-2 TS Extension. A Receiver MUST silently discard any data, if present, between the last complete encapsulated ATM Packet and the PDU length. The extension may be used to communicate one or more ATM Packets of arbitrary content, interpreted according to [ATM]. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0|FF| Length (13b) | Type = 0xtbd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ATM cell 1 | = = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ATM cell 2 (if Length > 2*53) | = = | etc. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.3.7 Label Field The GSE Label Field is optional. Depending on the L-bits of the GSE header, the Label field can have a length of 6 Byte, 3 Byte, or be omitted. This field MUST be carried(i.e. L=00 or 01) for IP unicast packets destined to routers that are sent using shared links (i.e., where the same link connects multiple Receivers). A sender MAY omit this field (L=10) for an IP unicast packet and/or multicast packets delivered to Receivers that are able to utilise a discriminator field (e.g. the IPv4/IPv6 destination address, or a bridged MAC destination address), which could be interpreted as a Link-Level address. When the GSE header indicates the presence of a Label field (i.e. L=00), a 6 Byte Label (e.g. a Network Point of Attachment NPA field) directly follows the Protocol Type Field of the GSE header.

14

When the GSE header indicates the presence of a Label field (i.e. L=01), a 3 Byte Label (e.g. a Network Point of Attachment NPA field) directly follows the Protocol Type Field of the GSE header. Receiver support of 3-Byte labels is optional. Normally, Labels will correspond to NPA destination addresses that are 6 Byte numbers, normally expressed in hexadecimal. Labels can be used to identify those Receiver(s) in a DVB-S2 transmission network that should process a received EPU. The 3-Byte labels can be used as an alternative addressing, for instance in DVB-RCS networks where the 3 Byte label can represent the 1-Byte group ID and 2 Byte logon ID. Binding mechanism for labels or addresses are not covered by GSE specifications, but Annex 1 provides a discussion of possible binding mechanisms. The value 0x00:00:00:00:00:00, MUST NOT be used as a Label in an EPU. The least significant bit of the first byte of the Label is set to 1 for multicast frames, and the remaining bytes specify the link layer multicast address. The specific value 0xFF:FF:FF:FF:FF:FF is the link broadcast address, indicating that the reassembled (if fragmented) PDU is to be delivered to all Receivers. Note that Receivers that obtain a Label in the first fragment of a PDU, whose Label does not match, MUST discard all subsequent EPUs with the same Fragmentation ID, until a EPU with that FragID and E-bit equal 1 is obtained. Receiver processing is detailed in section 6. IPv4 packets carrying an IPv4 subnetwork broadcast address need to be delivered to all systems with the same network prefix. When a GSE Label is present (L=00) the value MUST be set to the NPA link broadcast address (0xFF:FF:FF:FF:FF:FF). When the PDU is an IP multicast packet and a GSE Label is present (L=00), the IP group destination address of the multicast packet MUST be mapped to the multicast GSE Label (following the method used to generate a destination MAC address in Ethernet). The method for mapping IPv4 multicast addresses is specified in [RFC1112]. The method for mapping IPv6 multicast addresses is specified in [RFC2464]. Concatenation can save overhead if several consecutive PDUs are sent to the same destination. In this case, the Label field of all concatenated EPUs except the first one can be omitted and the L=11 bits are set. A receiver which receives a EPU in concatenation mode assumes that the label of the previously received EPU is still valid. Concatenation is allowed in the following cases:

• Concatenation MAY be used optionally for subsequent EPUs within one BBFrame if the EPUs contain an unfragmented PDU (S=1, E=1).

• In all other cases, concatenation shall not be used.

4.3.8 GSE CRC-32 Trailer When a receiver reassembles a fragmented PDU with fragments scattered over multiple baseband frames, there is a non-negligible probability that a missing fragment may be in-between. The error detection capability of GSE must therefore be

15

sufficiently strong to detect a wrong reassembly with a high probability. This is achieved in GSE by a CRC-32 on PDU level for fragmented PDUs. Each EPU where the S-bit value is 0 and E-bit value is 1 MUST carry a 32-bit CRC field in the last four bytes of the EPU. This position eases CRC computation by hardware. The CRC-32 polynomial is to be used. This is a 32 bit value calculated according to the generator polynomial represented 0x104C11DB7 in hexadecimal: x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x^1+x^0. The Encapsulator initialises the CRC-32 accumulator register to the value 0xFFFF FFFF. It then accumulates a transmit value for the CRC32 that includes all bytes from the start of the first EPU header to the end of the last EPU (excluding the 32-bit trailer holding the CRC-32), and places this in the CRC Field. In GSE, the bytes are processed in order of increasing position within the PDU, the order of processing bits is NOT reversed. This use resembles, but is different to that in SCTP [RFC3309]. In the reassembly state the Receiver performs an integrity check by independently calculating the same CRC value and comparing this with the transmitted value in the PDU trailer. PDUs that do not have a valid CRC, are discarded, causing the Receiver to enter the Idle State. This description may be suited for hardware implementation, but this document does not imply any specific implementation. Software-based table-lookup or hardware-assisted software-based implementations are also possible. The only purpose of this CRC is to protect fragmented PDUs (header, and payload) from undetected reassembly errors and errors introduced by unexpected software / hardware operation while the PDU is in transit across the DVB-S2 subnetwork and during processing at the Encapsulator and/or the Receiver. It may also detect the presence of uncorrected errors from the physical link (however, these may also be detected by other means).

4.4 Examples of EPU formats This section shows exemplarily some GSE packets. This example uses only 6 Byte addressing. Full Unfragmented PDU

Figure 1: complete PDU

GSE Header overhead: 10B. Note: for a complete PDUs, no CRC-32 is provided.

16

Fragmented PDU

Figure 2: fragmented PDUs,

GSE overhead: is 13B for the first PDU fragment, 7 Byte for the last fragment including CRC-32, and 3 Byte for intermediate fragments. Full and Fragmented PDU in no-label mode

Figure 3: fragmented PDU in no-label-mode

17

GSE overhead: is 4B for a full PDU, and for fragmented PDUs 7 Byte for the first EPU, 7 Byte for the last EPU including CRC-32, and 3 Byte for intermediate EPUs. Concatenated PDUs This example shows the concatenation of PDUs to the same receiver. It is noted that concatenation is only allowed for unfragmented PDUs in the same BBFrame

Figure 4: Concatenated PDUs

GSE overhead: is 10B for the first EPU, and 4 Bytes for subsequent EPUs in concatenated mode.

5 Encapsulator processing

5.1 Use of the Label Type Indicator With the Label Type Indicator an Encapsulator notifies the Receivers about filtering information being present. The presence of a Label Field in each EPU for a series a EPUs destined for the same destinations may waste precious bits. Hence, the LT value 11 is reserved for this special case and MUST respect the following rules: - The Encapsulator MUST use the Label Type value of 3 only within the scope of

one single BB-frame. This rule prevents from many corner case in the case of BB-frame losses.

- The Encapsulator MUST avoid using a Label Type value of 11 for PDUs which require fragmentation. Again, that rule shall make reassembly reasonably robust against reception problems.

18

5.2 Generic Fragmentation When an Encapsulator has several complete or partly sent PDUs in its buffers it may decide upon various criteria which of these PDUs need to be continued or completed. It is out of the scope of this document to discuss and suggest optimal scheduling and placement algorithms. Note that EPUs with the same FragID MUST NOT be reordered, but EPUs with different FragID MAY be interleaved and reordered. The following rules apply: 1. All EPUs carrying data for the same PDU must have the same FragID 2. FragID MUST be incremented by 1 for each new PDU to be fragmented 3. FragID wraps around to 0 after the maximum unsigned value 4. Last EPUs with a given FragID MUST have S equal 0 and E bit 1. 5. FragID MUST NOT be reused if the previous PDU is still uncompleted 6. EPUs with the same FragID MUST NOT be reordered Whenever fragmentation is necessary or desirable, the Encapsulator takes the first N bytes of the PDU and forms a EPU with S bit set to value 1, E bit set to value 0, LengthField is set to length of Type field plus N plus optional Label Length, ID set to value X+1, adds the Total Length, adds an appropriate Type field, and N bytes from PDU, and places this EPU into the current DataField at the beginning or after any other EPU. Note that the Total Length is the sum of number of bytes following the Total Length Field of the first EPU plus payload length (i.e. bytes of PDU) of all subsequent EPUs plus the CRC-32 in last EPU. If an PDU fragment with FragID equal to X, here named EPU(X), is pending that the Encapsulator wants to place at a given position of a DataField and which fits into the current DataField, the Encapsulator frames the remainder of the corresponding PDU into an EPU with S bit value set to 0, E bit value set to 1, calculates and inserts the LengthField (see below), adds an ID with value X, inserts the remaining PDU data and appends the EPU(X) CRC-32 before placing that EPU into the current DataField. Above LengthField is calculated as length of (remaining) PDU data plus length of FragID field plus length of CRC-32 field.

6 Receiver processing A Receiver tunes to a specific GS ISI and sets a receive filter to accept all BB-frames. These BB-frames are reassembled to form a stream of EPUs. A single Receiver may be able to receive multiple GS ISIs. In each case, reassembly MUST be performed independently for each GS ISI and each fragmented PDU. To perform this reassembly, the Receiver may use a buffer to hold the partially assembled PDU, referred to here as the Current PDU buffer. Other implementations may choose to use other data structures, but MUST provide equivalent operations. Upon reception of a BBFrame, the Receiver MUST calculate the BBFrame CRC. If this check fails the receivers MUST discard the BBFrame. It is noted that the presence

19

of possible padding at the end of the BBFRAME is derived from the information on the DFL included in the BBH. Such padding is then removed as part of the BBFRAME processing, and the DF is extracted. The receiver processes the first EPU which starts directly after the BBHeader, and subsequently all following EPUs. EPUs are chained one after another; the receiver can determine the start of the next EPU by calculating the length of the EPU from the length field in the GSE header. In the GSE header the 12 bit Length field indicates the number of bytes to the start of the next EPU in the BB-frame currently being processed. It is illegal to receive a Length field value greater than 4088 (4096 minus GSE minimum header length of 4B minus 4B DataField CRC), and this MUST cause the BB-frame processing to be aborted and the Receiver MUST discard the BBFrame. The receiver shall provide independent re-reassembly buffers for a maximum of 256 reassembly buffers (determined by the maximum number of open fragments indicated by the FragID field). The receiver MUST filter on all of the following modes of operation and labels which the receiver has assigned for its filters:

• No labels provided (L=10) • 3 Byte labels • 6 Byte labels

For each EPU, the receiver examines the GSE header. If the S is 1 then the receiver must interpret the label bits. The receiver checks the label bits, and determines the Label Type. If the GSE header contains a 6-byte or 3-Byte label matching any of the receiver assigned labels, the receiver continues with the processing, otherwise the receiver MUST discard the EPU and continue processing with the next EPU. If the GSE header has set the L-bits to 10 (no label present, EPU destined to all receivers), the receiver continues with processing. If the GSE header has set the L-bits to 11 (concatenation mode), the receiver checks if the last received EPU in the BBFrame was destined to the receiver. In this case, the receiver continues with processing, otherwise the receiver MUST discard the EPU. As a next step, if the S and E bit values are 1 then the EPU contains one single PDU and the receiver extracts Length bytes and continues with the processing. If the S value is 1 and the E bit value is 0 then the EPU contains the first fragment for PDU with FragmentationID. Prior to entering the reassembly state for this ID, the Receiver MUST check whether the ID is free, i.e. no outstanding fragments for that ID exist. If the ID is in use, the receiver MUST discard the already buffered fragments belonging to the ID. The receiver MUST then continue with the current EPU processing. If the ID is unused the Receiver enters the Reassembly State for ID, and starts reassembly of a new PDU at this point. The receiver reserves a buffer space indicated in the Total Length Field.

20

In case that S=0, the EPU contains a fragment. The receiver must check, if the receiver has a buffer in re-assembly state for the FragID in the GSE header. In this case, the receiver continues with processing, in all other cases, the EPU is discarded. If the S value is 0 and the E bit value is 0 then the EPU contains a fragment for PDU with identification ID. The receiver adds the fragment to the re-assembly buffer. If the S value is 0 and the E bit value is 1 then the EPU contains the last fragment for PDU with identification ID. The receiver adds the fragment to the re-assembly buffer. The receiver checks if the total length corresponds to the reserved buffer space. If the length of the re-assembled PDU does not correspond to the Total Length, the receiver MUST discard the PDU. Finally it checks the CRC (last 4 bytes of the current SNDU) against the CRC of the current PDU buffer. If the CRC does not matches the Receiver MUST flush the current PDU buffer and MUST enter the Idle State. If the CRC matches the Receivers enters the Processing state and frees the Fragmentation ID. TIME-OUT: If a PDU belonging to a given Fragmentation ID can no be re-assembled within 255 BBFrames, the receiver MUST discard the buffer and free the Fragmentation ID. Processing of a Received PDU After receiving a valid and complete SNDU, the Receiver MUST check the Type Field (and process any Type 1 Extension Headers). The PDU payload is then passed to the next protocol layer specified. A SNDU with an unknown Type value < 1536 MUST be discarded. This error event SHOULD be recorded as a PDU type error.

7 References

7.1 Normative References [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, 1997. [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989. [RFC4236] Fairhurst, G. and B. Collini-Nocker, "Unidirectional Lightweight Encapsulation (ULE) for transmission of IP datagrams over an MPEG-2 Transport Stream", RFC 4236, December 2005. [ETSI-S2] EN 302 307, "Digital Video Broadcasting (DVB); Second generation framing structure, channel coding and modulation systems for Broadcasting, Interactive Services, News Gathering and other broadband satellite applications", European Telecommunication Standards Institute (ETSI). [MPE] ETSI: EN 301 192 "Digital Video Broadcasting (DVB): Specification for data broadcasting”

21

7.2 Informative References [ATM] ATM Layer- B-ISDN ATM LAYER SPECIFICATION, ITU-T Recommendation I.361 [ETSI-DAT] EN 301 192, "Specifications for Data Broadcasting", European Telecommunications Standards Institute (ETSI). [ISO-MPEG] ISO/IEC DIS 13818-1:2000, "Information Technology; Generic Coding of Moving Pictures and Associated Audio Information Systems", International Standards Organisation (ISO). [RFC3309] Stone, J., R. Stewart, D. Otis. "Stream Control Transmission Protocol (SCTP) Checksum Change". RFC3095, Proposed Standard, 2001.. [RFC4259] Montpetit, M.-J., Fairhurst, G., Clausen, H., Collini-Nocker, B., and H. Linder, "A Framework for Transmission of IP Datagrams over MPEG-2 Networks", RFC 4259, November 2005. [S2-REQ] "Procedure for Comparative Evaluation of IP/DVB-S2 Encapsulation Protocol over Generic Streams", Technical Note GBS 05311, DVB TM-GBS. [S2-REQ-GBS] GBS0339, "Functional and performance requirements for IP/S2", DVB-TM GBS WG. [S2-REQ-RCS] "Requirements for S2", Document 529r1, DVB TM RCS WG.

22

8 Annex 1: Addressing and Binding (Informative) 3-Byte Labels Background: The DVB-RCS standard ETSI EN 301 790 V1.4.1 (2005-09) requires the RCST to be uniquely identified by a logical address. The logical address is composed of two fields, the Group_ID and Logon_ID, which are assigned to each RCST during logon. This logical address is used on the forward link in TIM messages (e.g., TBTP) and on the return link (e.g., DULM messages). Group and Logon ID are mandatory for RCSTs. They are used for addressing individual RCSTs until logoff. The group_ID is 1 Byte, the logon_ID is 2 Byte. The group/logon ID are unique for all terminals listening in the same ISI and same spotbeam (or several spotbeams in regenerative satellites), as they are used for receiving broadcast TBTPs identifying the terminal reserved slots for the return link transmission. A DVB-S2/GS link utilizing the GSE protocol can utilize this light-weight addressing scheme in the forward link. Several possibilities can be envisaged for use:

Use of group/logon_ID for the 3 Byte address; the 3 Byte address is used solely after successful logon to 3-Byte addressing.

Use of a 3 Byte address as Connection_ID without MAC addressing, allowing STs to discriminate between more than one simultaneously open connections. Assignment of Connection_IDs has to be done via dedicated signaling (during session set-up).

In both cases, this usage defines a private address range, and address allocation methods have to be specified, and their scoping rules defined. Identification of correct address binding. In GSE the simultaneous use of several 6-Byte and one 3-Byte addresses is supported. For each address a binding mechanism needs to be devised (TBD). Compared to MPEG/MPE, the procedure to find an IP stream is different. With MPEG/MPE the PID containing the IP stream was identified, combined with some information about the semantics of the MPE in the data_broadcast_descriptor, plus the fact that MPE encapsulation is is use. For GSE, the minimum information needed would be an ISI and the fact that GSE is being used on that ISI. This could easily be extended with a loop of address mappings that are in effect, 1 byte for every mapping, of which are already defined:

• 0x00 No 3 byte addresses used • 0x01 DVB-RCS group id/logon id is a 3byte address • 0x02-0xBF Reserved for future use in standardization • 0xc0-0xFF User-defined

A terminal shall use the following bindings:

23

• All S2 terminals shall bind their MAC hardware address to the 6-Byte address;

this binding shall be valid for all terminal types (e.g., S2-receive-only, DVB-RCS, terrestrial return link, etc.)

• DVB-RCS terminals shall bind their group/logon-ID to the 3-Byte address • Binding to be defined for 6-Byte multicast addresses as in [RFC4236] • Binding to be defined for 3-Byte multicast and broadcast addresses • Binding to be defined for IP addresses (no-address-mode) • Binding to be defined for other terminal types:

• E.g., • RCS regenerative terminals with ATM: binding to VCI/VPI connection ID (ETSI BSM protocol C2P) VLAN extension (3 byte MAC address as VLAN ID for simple cases,

implicit binding with dedicated group marker, e.g., 0xFFFF) • Provision of explicit binding process with higher layer protocols (TBD)

24