IPDVB Working Group                                          J. Cantillo
Internet-Draft                          ENSICA/TESA/Alcatel Alenia Space
Expires: March 24, 2006                                         J. Lacan
                                                               S. Combes
                                                    Alcatel Alenia Space
                                                      September 20, 2005

       Requirements for Transmission of IP Datagrams over DVB-S2

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   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
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as 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 Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on March 24, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).


   This document describes a framework for the transport of IP datagrams
   over DVB-S2, the second generation standard for Digital Video
   Broadcast over Satellite.  The new standard features an improved and
   adaptive physical layer, as well as a new framing structure at link
   level, the Generic Streams.  Combined use of adaptability and Generic

Cantillo, et al.         Expires March 24, 2006                 [Page 1]

Internet-Draft      draft-cantillo-ipdvb-s2encaps-01      September 2005

   Streams is expected to offer throughputs never achieved for IP
   services up to now, but no standard way to carry IP data using the
   specific features of DVB-S2 has been defined yet.  The present
   document analyzes these issues, and it identifies the requirements
   for the definition of a standard interface between the DVB-S2 link
   layer and an IP subnetwork.

Document history

      -v00 Original document presented at IETF-63

      -v01 Re-written version following IETF-63 discussions. 2 Figures
      and a glossary added.

   This draft is intended as a study item for proposed future work by
   the IETF in this area.  Comments relating to this document will be
   gratefully received by the authors and the ip-dvb mailing list at:

Cantillo, et al.         Expires March 24, 2006                 [Page 2]

Internet-Draft      draft-cantillo-ipdvb-s2encaps-01      September 2005

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  5
   3.  DVB-S2 Architecture  . . . . . . . . . . . . . . . . . . . . .  7
     3.1.  General Architecture . . . . . . . . . . . . . . . . . . .  7
       3.1.1.  Functional Blocks and Framing Overview . . . . . . . .  7
       3.1.2.  BBHEADER Fields  . . . . . . . . . . . . . . . . . . .  9
     3.2.  DVB-S2 Logical Channels  . . . . . . . . . . . . . . . . . 10
     3.3.  Transmission Networks Supported in DVB-S2  . . . . . . . . 11
     3.4.  Protocols to be Supported over DVB-S2  . . . . . . . . . . 11
   4.  Motivations for a New Approach . . . . . . . . . . . . . . . . 11
     4.1.  ACM and DVB-S2 Framing . . . . . . . . . . . . . . . . . . 11
     4.2.  IP over Generic Streams  . . . . . . . . . . . . . . . . . 12
   5.  General Framework Requirements . . . . . . . . . . . . . . . . 12
     5.1.  Use of Existing Encapsulation Capabilities . . . . . . . . 13
     5.2.  Adaptive Packing and Scheduling Optimization . . . . . . . 13
     5.3.  Next Level Protocol Type . . . . . . . . . . . . . . . . . 14
     5.4.  Precise Payload Unit Delineation and Reassembly  . . . . . 14
     5.5.  Integrity Check  . . . . . . . . . . . . . . . . . . . . . 15
     5.6.  Link Layer Addressing Capabilities . . . . . . . . . . . . 15
     5.7.  Flexibility for Future Extension . . . . . . . . . . . . . 16
     5.8.  Security Considerations  . . . . . . . . . . . . . . . . . 16
   6.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 17
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
   Intellectual Property and Copyright Statements . . . . . . . . . . 20

Cantillo, et al.         Expires March 24, 2006                 [Page 3]

Internet-Draft      draft-cantillo-ipdvb-s2encaps-01      September 2005

1.  Introduction

   DVB-S2, the second generation architecture of Digital Video Broadcast
   over Satellite links was recently specified by standards published by
   the European Telecommunications Standards Institute (ETSI) [1].  This
   architecture is designed for broadband satellite applications such as
   digital television or radio, as well as interactive services such as
   Internet access or content distribution.

   Compared to its predecessor DVB-S [2], DVB-S2 features two main
   enhancements.  First, higher order modulations and stronger FEC are
   teamed up with return channels to achieve real-time adaptability to
   the link and propagation conditions.  This novelty called Adaptive
   Coding and Modulation (ACM) might allow for an enhanced throughput by
   30% to 150%, which explains in part the genuine interest for this new
   standard.  DVB-S2 supports also Variable Coding and Modulation and of
   course, Constant Coding and Modulation (CCM) modes.

   Second, DVB-S2 offers a new link-layer framing structure called
   Generic Streams (GS) in addition to the classical packetized
   Transport Streams (TS).  GS can be packetized or continuous, and are
   intended to address the non-native way in which IP services are
   carried today over MPEG2-TS using the Multi Protocol Encapsulation
   (MPE) [4] or the Unidirectional Lightweight Encapsulation (ULE) [5].
   Indeed, MPEG2-TS constraints such as constant bit-rate and constant
   end-to-end delay are not a must for IP services, which added to the
   accumulation of multiple overheads undermine IP carriage efficiency.
   Since the use of TS is no longer mandatory in DVB-S2 for carrying IP
   data, IP over GS seems to offer new possibilities for satellite-based
   IP networks.

   Up to now, there is no standard procedure to carry IP datagrams over
   Generic Streams.  In order to take advantage of the new facilities
   provided by DVB-S2, the previously mentioned solutions to encapsulate
   IP over DVB-S should be adapted or new solutions should be proposed.
   The key goals are to reduce complexity when using the system while
   improving performance, increasing flexibility for IP services and
   providing opportunities for better integration of IP-based networks.

   This document presents the requirements for the transport of IP
   datagrams over DVB-S2, using the specific features of DVB-S2.  The
   proposed framework should minimize overhead and be simple enough to
   reduce processing while ensuring adequate network services, as well
   as be robust to errors and security threats while providing enough
   flexibility for future extension.  The general guidelines for this
   document are those exposed in RFC 3819 [6] and RFC XARCHX [7].

Cantillo, et al.         Expires March 24, 2006                 [Page 4]

Internet-Draft      draft-cantillo-ipdvb-s2encaps-01      September 2005

2.  Conventions Used in This Document

   ACM: Adaptive Coding and Modulation.  Dynamic adjustment of
   transmission parameters (FEC coding rate and modulation scheme) on a
   BBFRAME-by-BBFRAME and Receiver-per-Receiver basis, according to link
   and propagation conditions.  In order to implement ACM, feedback from
   each Receiver has to be provided by a return channel such as DVB-RCS

   b: bit.  For example, one byte consists of 8b.

   B: Byte.  Groups of bytes are represented in Internet byte order.

   BBFRAME: Main framing unit of the DVB-S2 protocol stack, consisting
   of a 10B BBHEADER, a variable size DATAFIELD and Padding (when
   necessary).  It may carry either Generic Streams (GS) or Transport
   Streams (TS).

   BBHEADER: 10B header of a BBFRAME.

   CCM: Constant Coding and Modulation.  In CCM transmission mode, the
   system uses a single type of pre-defined waveform for every Receiver.
   DVB-S is a CCM system.

   DATAFIELD: Payload transported by each BBFRAME.  Its maximum size
   determines the length of the BBFRAME that contains it.  For a given
   Receiver, this maximum size is allowed dynamically on a BBFRAME-by-
   BBFRAME basis among 21 possible sizes (ranging from 372B to 7264B) by
   the VCM/ACM command.  Each size is related to the FEC coding rate to
   be used for encoding each particular BBFRAME.  Lower BBFRAME sizes
   are used when low coding rates (i.e. stronger protection against
   channel errors) are needed, whereas longer sizes (i.e higher coding
   rates) are used under good channel conditions.

   DFL: One of the BBHEADER fields.  Length in bits of the DATAFIELD.

   DVB-S2: Second Generation of the Digital Video Broadcast for
   Satellite applications standard [1].  A framework and set of
   associated standards published by the European Telecommunications
   standards Institute (ETSI) for the transmission of video, audio, and
   data, intended to replace DVB-S [2].

   FEC: Forward Error Coding.  The scheme used in DVB-S2 relies upon the
   concatenation of Bose-Chaudhuri-Hocquenghem (BCH) and Low Density
   Parity Check (LDPC) codes.  For a given Receiver, its overall coding
   rate is adjusted on a BBFRAME-by-BBFRAME basis according to the needs
   specified for each BBFRAME by the VCM/ACM command.

Cantillo, et al.         Expires March 24, 2006                 [Page 5]

Internet-Draft      draft-cantillo-ipdvb-s2encaps-01      September 2005

   FECFRAME: Encoded BBFRAME, as seen at the output of the FEC encoder.
   FECFRAMEs have only two possible sizes, 2025B and 8100B, no matter
   the size of the BBFRAME to code.

   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 of packetized
   Generic Stream could be a flow of MPEG2 packets.

   GS: See Generic Stream.

   ISI: Input Stream Identifier, second byte of the BBHEADER field when
   for multiple input streams.  It provides a way to separate different
   BBFRAMEs within a single multiplex, defining logical channels for

   MPEG2: A set of standards specified by the Motion Picture Experts
   Group (MPEG), and standardized by the International Standards
   Organization (ISO) [3].

   MODCOD: Information provided by the VCM/ACM command to the BBFRAME
   assembler, specifying the coding rate (therefore the size of the
   maximum size of DATAFIELD to be allowed) and the modulation scheme to
   be used to encode and modulate each BBFRAME.

   NPA: Network Point of Attachment.  Addresses primarily used for
   station (Receiver) identification within a local network (e.g.  IEEE
   MAC address).  An address may identify individual Receivers or groups
   of Receivers.

   PID: Packet Identifier [3].  A 13 bit field carried in the header of
   TS Packets.  This is used to identify the TS Logical Channel to which
   a TS Packet belongs [3].  The TS Packets forming the parts of a Table
   Section, PES, or other Payload Unit must all carry the same PID
   value.  The all 1s 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.  Examples of a PDU include Ethernet frames,
   IPv4 or IPv6 datagrams, and other network packets.

   PLFRAME: Last framing unit of the Physical Layer of DVB-S2.

   PLHEADER: Header of a PLFRAME.  The PLHEADER contains synchronization
   information coded over 2b, as well as the MODCOD used for the current
   frame (5b).  Since it has to be demodulated and decoded for every

Cantillo, et al.         Expires March 24, 2006                 [Page 6]

Internet-Draft      draft-cantillo-ipdvb-s2encaps-01      September 2005

   Receiver without a priori knowledge of the carried MODCOD, it
   features an unique modulation and coding, no matter the payload's

   Receiver: An equipment that processes the signal from the satellite
   and performs filtering and forwarding of encapsulated PDUs to the
   network-layer service (or bridging module when operating at the link

   Return Channel: A way for end-users to interact with the transmitting
   Gateway, in order to establish a bi-directional communication.  Such
   technologies can make use of two-way satellite links [8] and/or
   terestrial links.

   SAR: Segmentation And Reassembly, generally for encapsulated SNDUs.

   SNDU: Sub Network Data Unit.  A framing entity created on the basis
   of a network-layer PDU by an adaptation layer protocol, allowing this
   PDU to travel along a L2 subnetwork.

   TS: Transport Stream [3], a method of transmission at the MPEG-2
   level using MPEG2 Packets.

   UPL: One of the BBHEADER fields.  It carries packets lengths in bits,
   in the case of packetized input streams.

   VCM: Variable Coding and Modulation.  Differentiated optimization of
   transmission parameters according to the physical characteristics of
   every Receiver, such as geographical position, size etc.

3.  DVB-S2 Architecture

3.1.  General Architecture

3.1.1.  Functional Blocks and Framing Overview

   DVB-S2 is organized as a sequence of functional blocks.

   The Mode Adaptation block processes input data structured either as
   TS or GS, single or multiple.  Input streams are sliced into
   DATAFIELDs to which a 10B BBHEADER is appended.  The maximum length
   of every DATAFIELD is chosen dynamically among 21 allowed sizes in
   the range [374B;7264B] by the VCM/ACM command, according to the
   protection required for everyone of them.  Basically the shorter they
   are, the more space there is for FEC redundancy protection.  Actual
   systems may only implement a subset of those 21 sizes.

Cantillo, et al.         Expires March 24, 2006                 [Page 7]

Internet-Draft      draft-cantillo-ipdvb-s2encaps-01      September 2005

   The Stream Adaptation block may complete every DATAFIELD with Padding
   in order to match the length of a valid BBFRAME.  BBFRAMEs therefore
   have one of 21 possible pre-defined sizes in the range [384B; 7274B].
   This is a major difference with DVB-S, since at this level there are
   only 188 Byte MPEG2 containers.  Note that DATAFIELDs sizes are not
   multiples of 188B: Transport Streams, as well as Generic Streams, are
   mapped asynchronously over BBFRAMEs.

   Adaptive FEC encoding constitutes the third block.  A set of coding
   schemes based on a concatenation of LDPC and BCH codes ensures a very
   efficient error protection, only 0.7 to 1 dB away from the Shannon
   limit (DVB-S FEC is around 2.5 dB from that margin).  In ACM mode,
   the ACM command dictates dynamically the coding rate to be used for
   every BBFRAME in order to provide a Quasi-Error Free (QEF) quality
   target at the input of the Receiver's DEMUX (roughly equivalent to
   PER < 1e-7 for a MPEG2 transmission).  FEC parity bits are calculated
   and appended systematically to each BBFRAME in order to provide
   fixed-length FECFRAMEs of 2025B or 8100B. This implies that shorter
   BBFRAMEs are completed with more redundancy than long BBFRAMEs, and
   are therefore more protected.

   Finally, FECFRAME bits are modulated and raised-cosine filtered, to
   provide the body of a PLFRAME. 4 different modulations with spectral
   efficiencies ranging from 2bits/s/Hz to 5 bits/s/Hz are available in
   DVB-S2.  Finally,information about the FEC coding rate and modulation
   used for every frame (MODCOD) is stored in a PLHEADER and appended to
   every PLFRAME.  Of course, DVB-S2 provides mechanisms to ensure
   proper reading of every PLHEADER for every Receiver without a priori
   knowledge of the contained MODCOD, so all PLHEADERs use a pre-
   determined coding and modulation.  The final PLFRAME is finally sent
   over the RF carrier using classical TDM and/or FDM techniques.

Cantillo, et al.         Expires March 24, 2006                 [Page 8]

Internet-Draft      draft-cantillo-ipdvb-s2encaps-01      September 2005

   L2                           :::|    TS   or   GS   |:::
      +--------------+             .                   .
   D  |              |             .                   .
   V  |     Mode     |       +-----+-------------------+
   B  |  Adaptation  |       |BBHDR|     DATAFIELD     |
   -  |              |       +-----+-------------------+
   S  +--------------+       . 10B     0B<DFL<7264B    .
   2  +--------------+       .                         .
      |              |       .                         .
   P  |    Stream    |       +-------------------------+-------+
   H  |  Adaptation  |       |                         |Padding|
   Y  |              |       +-------------------------+-------+
   S  +--------------+       <---- BBFRAME: [382B;7274B] ------>
   I  +--------------+       .                                 .
   C  |              |       .                                 .
   A  | Adaptive FEC |       +---------------------------------+-------+
   L  |   Encoding   |       |                                 |Parity |
      |              |       +---------------------------------+-------+
   L  +--------------+       <------- FECFRAME: 2050B or 81000B ------->
   A  +--------------+       .                                         .
   Y  |              |       .                                         .
   E  |   Adaptive   | +-----+--+--+--+--+-               -+--+--+--+--+
   R  |  Modulation  | |PLHDR|  |  |  |  | ::::::::::::::: |  |  |  |  |
      |& TDM Framing | +-----+--+--+--+--+-               -+--+--+--+--+
      +--------------+ <----- PLFRAME: complex modulated symbols ------>

   Figure 1: DVB-S2 architecture and framing structure overview

3.1.2.  BBHEADER Fields

   Several statements made in the following sections will refer to
   fields present in the 10B BBHEADER, so a very short description of
   this entity is presented here:

   |  MATYPE  2B |    UPL  2B  |DFL 1B |SYNC 1B|  SYNCD   2B | CRC-8 |

   Figure 2: A BBHEADER

   The first byte of the MATYPE field specifies whether TS or GS are
   used, and whether they are single or multiple.  In the multiple case,
   the second byte is an "Input Stream Identifier" (ISI).

Cantillo, et al.         Expires March 24, 2006                 [Page 9]

Internet-Draft      draft-cantillo-ipdvb-s2encaps-01      September 2005

   UPL specifies packets lengths in bits, in the case of packetized
   input streams.  As an example, a value of 0x05E0 (188*8 in
   hexadecimal notation) is characteristic of MPEG2 packets.  A value of
   0x0000 means a continuous GS.

   DFL specifies the length of the DATAFIELD actually used in bits, in
   the range [0b; 58112b] (58112 = 7264*8, 7264B being the maximum
   DATAFIELD length allowed).

   SYNC stores the synchronisation byte carried by all the packets of a
   packetized stream, when there is one (e.g. if MPEG2 packets are
   transported, SYNC=0x47).  Since the synchronisation byte is now
   carried by the BBHEADER, there is no need for every packet to carry
   it anymore.  A CRC-8 calculated for every packet replaces therefore
   the synchronisation byte in every packet (it will prove useful
   later).  SYNC is not relevant for continuous Generic Streams.

   SYNCD is the distance in bits, for a packetized stream, from the
   beginning of the DATAFIELD to the first start of packet contained in
   this DATAFIELD.  Its use is therefore similar to a Payload Pointer,
   as defined in ULE [5].  SYNCD is not relevant for continuous Generic

   Finally, a CRC-8 is calculated from the previous 9B of the BBHEADER.

   Note that BBHEADER fields natively support Segmentation And
   Reassembly (SAR) for MPEG2 packets and for any other packetized
   Generic Streams asynchronously mapped over a BBFRAME flow.  Indeed,
   perfect delineation and reassembly can be achieved by the exclusive
   use of UPL, DFL and SYNCD.  Finally, the CRC-8 stored in the 1B slot
   liberated by SYNC in every packet provides an end-to-end integrity
   check, achieving thus an encapsulation that does not produce any
   overhead at all (except when Padding is necessary).  In DVB-S2, a
   flow of MPEG2 packets can therefore be sent over a packetized Generic
   Stream using UPL=0x05E0 and SYNC=0x47.

3.2.  DVB-S2 Logical Channels

   In the same way the PID field allowed to distinguish TS Logical
   Channels for MPEG2, the ISI field of every BBHEADER can be used to
   support logical channels for BBFRAMEs.

   Up to now there is no standardized signalling associated to ISI (such
   as tables or reserved values), and further work has to be done in
   this direction in order to set a complete framework.  This includes
   mapping of upper layer QoS functions, or standards to associate the
   capabilities of these potential logical channels to upper layer

Cantillo, et al.         Expires March 24, 2006                [Page 10]

Internet-Draft      draft-cantillo-ipdvb-s2encaps-01      September 2005

3.3.  Transmission Networks Supported in DVB-S2

   As a successor to DVB-S, some compatibility at least, as well as
   enhancement of network capabilities are expected for DVB-S2.
   Transmission networks to be supported by DVB-S2 contain therefore
   basically those specified in RFC XARCHX [7].  Those are:

   Uni-directionnal scenarios such as:
      -Digital radio and TV broadcast
      -Broadcast networks used by an ISP
      -Uni-directionnal star IP scenarios
      -Datacast overlay

   Bi-directionnal scenarios such as:
      -Point-to-Point links
      -Two-way IP networks

   The growing demand for IP services and the increased availability of
   return channels are bound to play an important role in the
   development of the last 2 scenarios in the near future.

3.4.  Protocols to be Supported over DVB-S2

   The protocols to be supported over this architecture are basically
   the same as those specified in RFC XARCHX [7]
      -IPv4 Unicast datagrams
      -IPv4 Broadcast datagrams
      -IPv4 Multicast datagrams
      -IPv6 Unicast datagrams
      -IPv6 Multicast datagrams
      -Datagrams with compressed IPv4/IPv6 headers (e.g.  RFC 1114 [9],
      RFC 2507 [10] and RFC 3095 [11])
      -Bridged Ethernet Frames

4.  Motivations for a New Approach

   Even though many existing solutions used in DVB-S can be extended or
   adapted to the new standard, the new features of DVB-S2 raise a
   number of important and interesting issues worth consideration.

4.1.  ACM and DVB-S2 Framing

   Through the use of ACM, the dynamic variations of the RF channel will
   have a direct impact over the physical waveform to be used for every
   piece of data to be transmitted.  Analysis of MODCOD allocation
   policies due to channel variations might open field for IP carriage
   efficiency improvement, and several competing resource allocation

Cantillo, et al.         Expires March 24, 2006                [Page 11]

Internet-Draft      draft-cantillo-ipdvb-s2encaps-01      September 2005

   algorithms should be tested.

   On the other hand, BBFRAMEs sizes ranging from 382B to 7274B suggest
   several full IP packets will be able to fit in a single DATAFIELD.
   SNDU Segmentation and Reassembly (SAR) will then statistically occur
   less than in DVB-S, which raises other kind of questions and risks.
   For example a partially filled and sent BBFRAME will make worse use
   of the RF resource than a partially filled and sent MPEG2 packet.  In
   contrast, optimal BBFRAME filling should allow optimal resource use
   as it minimizes redundant overhead.  Indeed, available PDU
   encapsulations such as MPE/MPEG2-TS, ULE/MPEG2-TS or AAL5/ATM were
   designed for a relatively high probability of SAR use during SNDU
   processing.  The definition of a scheduling algorithm ensuring
   optimal BBFRAME filling will certainly be a key point for improving
   IP carriage efficiency.

4.2.  IP over Generic Streams

   TS constant end-to-end delay and constant bit-rate are not a must for
   IP services, and could be overridden if a GS solution were considered
   for IP carriage.  On top of that, the mandatory asynchronous mapping
   of MPEG2 over the BBFRAMEs directly constitutes a triple drawback
   from an IP point of view.  First, it adds significant complexity and
   processing to the overall process.  Second, the eventual overhead
   (here, padding) generated by this asynchronous mapping will add to
   the overall overhead of the IP encapsulation over MPEG2-TS,
   decreasing global efficiency.  Finally, unexpected hardware/software
   functioning that may affect proper reassembly of fragmented MPEG2
   packets will directly impact PER at IP level.

   The use of MPE and recently ULE to convey IP data over MPEG2-TS has
   contributed over the past years to its wide acceptance as a IP
   subnetwork technology.  However, despite the unquestionable services
   done by MPEG2-TS in the DVB-S context, the use of GS in a DVB-S2
   system for conveying IP data seems to offer better perspectives.  In
   order to take full advantage of the handy features of GS and ACM, and
   stick to the key goals specified in Section 1, new solutions have to
   be considered.  Those should rely on already available proved
   concepts when possible, but should also innovate where existing
   mechanisms do not offer a satisfactory solution.

5.  General Framework Requirements

   Detailed requirements for transmission of IP datagrams over MPEG2-TS
   networks have been defined in RFC XARCHX [7].  The present section
   will therefore focus on the requirements for transmission of IP
   datagrams over Generic Streams in ACM mode.  Note however, as stated

Cantillo, et al.         Expires March 24, 2006                [Page 12]

Internet-Draft      draft-cantillo-ipdvb-s2encaps-01      September 2005

   in Section 3.1.2, that seen from a BBFRAME, there is no difference
   between a MPEG2-TS and a packetized Generic Stream with packets of
   length 188B. Fundamental differences with a TS approach will be
   pointed out when possible.

5.1.  Use of Existing Encapsulation Capabilities

   In the general encapsulation case, PDUs are formatted one by one into
   SNDUs, by receiving an encapsulation header and an integrity check
   trailer such as a CRC.  The encapsulation header provides delineation
   information to the Receiver, and the end-to-end integrity check
   stands as a protection against re-assembly errors.

   However, MPEG2 packets are encapsulated into BBFRAMEs without the
   need of additional encapsulation headers, since BBHEADERs provide all
   the functionalities necessary to delineate and reassemble fragmented
   packetized streams.  BBHEADERs have therefore some inherent
   encapsulation capabilities, and a future framework intended to
   standardize an IP over GS interface should take advantage of this
   handy feature.

   Of course, IP streams are not composed of fixed-length packets and
   the above-mentioned encapsulation capabilities of BBHEADERs do not
   directly apply.  However, several concepts used in classical
   encapsulation headers (e.g.  Payload Pointer or Length Field for ULE)
   could be transposed if IP packets were to be mapped over Generic
   Streams, using available fields in BBHEADERs (e.g.  SYNC and UPL/

   Note finally that among the 10 bytes of BBHEADERs, at least 3 (SYNC
   and SYNCD) are not relevant for continuous GS.  Their re-definition
   and use in an "IP over continuous GS" context might prove useful as
   this would allow reducing the header length of a future

5.2.  Adaptive Packing and Scheduling Optimization

   In order to ensure optimum use of the available resources, it is
   required that several SNDUs fit in a BBFRAME addressed to a single
   NPA.  Since BBFRAMEs are considerably longer than classical
   containers, proper and optimal packing is a key point for achieving
   an efficient carriage of IP packets over GS.  This is a major
   difference with DVB-S.

   MODCOD allocation by the ACM command is closely related to this
   issue, since available DATAFIELD sizes will vary according to the
   dynamics of the channel.  A scheduling algorithm is required to
   optimize filling and minimize BBFRAME Padding, that may be up to

Cantillo, et al.         Expires March 24, 2006                [Page 13]

Internet-Draft      draft-cantillo-ipdvb-s2encaps-01      September 2005

   7264B for an empty DATAFIELD.  It should provide ways to fragment
   PDUs and delay them when necessary for the sake of optimal filling,
   but in the limits of an admissible complexity.  Such algorithm should
   take in account the statistical characteristics of the carried IP
   traffic, and its functioning should not be independent from the ACM
   command.  It should also provide BBFRAME Padding when necessary (when
   no PDU is available).

5.3.  Next Level Protocol Type

   A key feature of the required encapsulation is to identify the
   payload type being transported.  Such requirement is not specific to
   DVB-S2: most protocols use a type field to identify a specific
   process at the next higher layer that is the originator or the
   recipient of the payload.

   Given the length of BBFRAMEs, several PDUs will often be packed
   within the same BBFRAME.  In the case where there are PDUs from
   different protocols (e.g. a mix of IPv4 and IPv6 packets), it is
   required that every single PDU is labelled with a proper Type field.
   In another configuration, only homogeneous PDUs could be allowed to
   be together in a single BBFRAME.  In this latter case, a single Type
   header would be enough for the whole BBFRAME.  ISI channels could
   also be used to differentiate protocol PDU flows in a dynamic or
   static way.

5.4.  Precise Payload Unit Delineation and Reassembly

   Accurate delineation and identification of scattered fragments of
   packed IP packets must be done by every Receiver.  As an example, ULE
   achieves delineation with the joint use of MPEG2's PUSI, a Payload
   Pointer and a Length field.

   Precise PDU delineation is also required for a future encapsulation
   over Generic Streams.  The implemented solution may define a ULE-like
   header for this, but it may also re-use (partially at least) BBHEADER
   fields that already provide similar functionalities.  It should also
   be robust to synchronisation losses, for which a Payload Pointer
   approach could prove desirable.

   On the other hand, a future encapsulation must provide ways to ensure
   reassembly of a scattered PDU even in the case that its fragments are
   not "adjacent" within 2 consecutive BBFRAMEs, which could happen if
   advanced SNDU scheduling/fragmentation procedures are chosen.  In a
   ULE/MPEG2-TS scenario SNDU fragmentation is done over MPEG2 packets
   with MPEG2 Continuity Counters differing only by 1 (modulo 16),
   according to [3].  However, in a DVB-S2 context, the scheduling
   algorithm may chose to send PDU fragments at different times over the

Cantillo, et al.         Expires March 24, 2006                [Page 14]

Internet-Draft      draft-cantillo-ipdvb-s2encaps-01      September 2005

   same BBFRAME, or even over non-consecutive BBFRAMEs.  Since ULE
   relies on the MPEG2 Continuity Counter, it cannot be used directly in
   a GS context.  More advanced fragmentation procedures will certainly
   have to be studied.

5.5.  Integrity Check

   For the IP service, the probability of undetected packet error should
   be small or negligible, as stated in RFC 3819 [6].  There is
   therefore a need for a strong error control, either provided by FEC
   or by other means such as CRCs.  FEC has been greatly improved in
   DVB-S2, and it provides means to re-evaluate the way integrity check
   can be done.  The following considerations apply also for packetized

   The CRC-32 used in ULE relies on the use of a 32-bit redundancy for
   each SNDU, intended to stand as a protection against reassembly
   errors following corruption or loss of SNDU carriers, due to
   transmission errors or unexpected hardware/software operation.

   Concerning resilient channel errors, DVB-S2 FEC has reduced the
   probability of such event by several orders of magnitude compared to
   DVB-S.  Indeed, the implemented LDPC and BCH concatenated encoding
   provide error protection close to the theoretical limits established
   by Shannon in [12].  On top of that, outer BCH encoding provides a
   192-bit redundancy protection for each BBFRAME that can be used to
   detect and discard corrupted BBFRAMEs.  DVB-S2 FEC offers therefore
   the possibility to manage globally the SNDU error-detection problem,
   done classically on a SNDU-by-SNDU basis with CRCs.

   As for BBFRAME losses, only PDUs with fragments in lost BBFRAMEs will
   face reassembly problems.  A non-fragmented PDU within a lost BBFRAME
   will be simply lost, even if it had a CRC.  In this context it seems
   adequate to apply CRC integrity checks to the packets that may suffer

   Accurate estimation of PER at IP level with or without CRCs should
   drive the design decisions concerning this issue, and not legacy
   considerations based on different or less efficient systems.

5.6.  Link Layer Addressing Capabilities

   Individual Receivers are not addressable at a BBFRAME level.
   MPEG2-TS addressing considerations exposed in RFC XARCHX [7] apply
   therefore to BBFRAMEs too and should be used as guidelines for future
   work on this key topic.

   These considerations imply the use of an optional NPA field appended

Cantillo, et al.         Expires March 24, 2006                [Page 15]

Internet-Draft      draft-cantillo-ipdvb-s2encaps-01      September 2005

   to every PDU or group of PDUs sharing the same BBFRAME.  There are
   indeed cases where the use of a NPA is required (e.g. when link layer
   filtering is desired) and if present, it should be carried in a way
   to allow Receivers to pre-filter and discard unwanted PDUs.  There
   are other cases where an NPA is not required (e.g. when a Receiver is
   the end host), and network layer filtering may be used.

   An IP over GS interface should therefore support an optional NPA, as
   current encapsulations for IP over TS do.  The way to integrate it in
   the BBFRAME is to be analyzed, as well as the interactions and
   synergies that can be achieved with the use of BBFRAMEs channels
   defined by ISI.

5.7.  Flexibility for Future Extension

   The evolution of the Internet Service may in the future require
   additional functions.  A flexible protocol should therefore provide a
   way to introduce new features when required, without having to
   provide additional out-of-band configuration.  This is not a
   difference with TS.

5.8.  Security Considerations

   Security considerations are basically the same for GS and TS, and are
   based on those concerning wireless links, see RFC 3819 [6].  Although
   an analysis of specific security issues concerning GS is out of the
   scope of this document, it will provide helpful input for addressing
   this important topic in future work.

6.  Summary

   DVB-S2 physical adaptability and new framing structure motivate a new
   encapsulation for IP, much more efficient in terms of complexity and
   overhead than the classical MPEG2-TS approach.

   For this, some solutions developped for IP/MPEG2 can be simply
   transposed to DVB-S2, like the use of Type fields or the definition
   of logical channels.  DVB-S2 specificities imply also that new
   procedures will have to defined from scratch, such as datagram
   scheduling optimization and advanced fragmentation.  Finally, other
   issues like integrity check management might be re-evaluated in a
   DVB-S2 context, taking in account the enhanced error-control achieved
   by the new FEC.

   Finally, DVB-S2 BBFRAMEs are defined in such a way that BBHEADERs
   present some inherent encapsulation capabilities.  The definition of
   a new IP over DVB-S2 adaptation layer could take advantage of this

Cantillo, et al.         Expires March 24, 2006                [Page 16]

Internet-Draft      draft-cantillo-ipdvb-s2encaps-01      September 2005

   handy feature, and open the way for other cross-layer synergies in
   order to improve overall system efficiency.

7.  Acknowledgements

8.  References

8.1.  Normative References

   [1]  "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 Telecommunications
        Standards Institute (ETSI)".

   [2]  "EN 301 421, Digital Video Broadcasting (DVB); Modulation and
        Coding for DBS satellite systems at 11/12 GHz, European
        Telecommunications Standards Institute (ETSI)".

   [3]  "ISO/IEC  DIS  13818-1 Information  technology  --  Generic
        coding of moving pictures and associated audio information:
        Systems, International Standards Organisation (ISO)".

8.2.  Informative References

   [4]   "EN 301 192 Specifications for Data Broadcasting, European
         Telecommunications Standards Institute (ETSI)".

   [5]   Fairhurst, G. and B. Collini-Nocker, "Unidirectional
         Lightweight Encapsulation (ULE) for transmission of IP
         datagrams over an MPEG-2 Transport Stream, Work in progress",
         Internet Draft draft-ietf-ipdvb-ule-06.txt, June 2005.

   [6]   Karn, P., Borman, C., Fairhurst, G., Grossman, D., Ludwig, R.,
         Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice
         for Internet Subnetwork Designers", RFC 3819.

   [7]   Montpetit, M., Fairhurst, G., Clausen, H., and H. Linder, "A
         Framework for Transmission of IP Datagrams over MPEG-2
         Networks", RFC XARCHX, currently draft-ietf-ipdvb-arch-04,
         RFCEd queue, 2005.

   [8]   "EN 301 790, Digital Video Broadcasting (DVB); Interaction
         Channel for Satellite Distribution Systems. European
         Telecommunications Standards Institute (ETSI)".

Cantillo, et al.         Expires March 24, 2006                [Page 17]

Internet-Draft      draft-cantillo-ipdvb-s2encaps-01      September 2005

   [9]   Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial
         Links", RFC 1144.

   [10]  Degermark, M., Nordgren, B., and S. Pink, "IP Header
         Compression", RFC 2507.

   [11]  Bormann et al., C., "RObust Header Compression (ROHC):
         Framework and four profiles: RTP, UDP ESP and uncompressed",
         RFC 3095.

   [12]  Shannon, C., "A Mathematical Theory of Information", 1948.

Cantillo, et al.         Expires March 24, 2006                [Page 18]

Internet-Draft      draft-cantillo-ipdvb-s2encaps-01      September 2005

Authors' Addresses

   Juan Cantillo
   ENSICA/TESA/Alcatel Alenia Space
   1, place Emile Blouin
   Toulouse  31056

   Email: juan.cantillo@ensica.fr
   URI:   http://dmi.ensica.fr/auteur.php3?id_auteur=61

   Jerome Lacan
   1, place Emile Blouin
   Toulouse  31056

   Email: jerome.lacan@ensica.fr
   URI:   http://dmi.ensica.fr/auteur.php3?id_auteur=5

   Stephane Combes
   Alcatel Alenia Space
   26, avenue JF Champollion BP 1187
   Toulouse Cedex 1  31037

   Email: stephane.combes@alcatelaleniaspace.com
   URI:   http://www.alcatel.com/space/

Cantillo, et al.         Expires March 24, 2006                [Page 19]

Internet-Draft      draft-cantillo-ipdvb-s2encaps-01      September 2005

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Cantillo, et al.         Expires March 24, 2006                [Page 20]