[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04

IPDVB Working Group                                          J. Cantillo
Internet-Draft                                              ENSICA/TeSA,
Expires: January 9, 2006                                        J. Lacan
                                                        ENSICA/LAAS-CNRS
                                                               S. Combes
                                                           Alcatel Space
                                                            July 8, 2005


                    draft-cantillo-ipdvb-s2encaps-00
       Requirements for transmission of IP datagrams over DVB-S.2

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-
   Drafts.

   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
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 9, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document contains requirements for a framework for transport of
   IP Datagrams over the second generation of DVB-S, namely DVB-S.2,
   recently specified by standards published by the European



Cantillo, et al.         Expires January 9, 2006                [Page 1]


Internet-Draft      draft-cantillo-ipdvb-S2encaps-00           July 2005


   Telecommunications Standards Institute (ETSI).  DVB-S.2 is optimized
   for broadband satellite applications such digital television,
   Internet access or data content distribution.

   The document identifies the requirements for the definition of a set
   of network protocols to standardise the interface between the DVB-S.2
   streams (Transport Stream and Generic Stream) and an IP subnetwork.

Document history

      -00 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: ip-dvb@erg.abdn.ac.uk

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.   Terminology  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.   DVB-S.2 Overview  and Motivations. . . . . . . . . . . . . . . 3
   4.   General Framework Requirements . . . . . . . . . . . . . . . . 4
   5.   Requirements for IP datagrams  . . . . . . . . . . . . . . . . 5
   6.   Normative References . . . . . . . . . . . . . . . . . . . . . 6
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
        Intellectual Property and Copyright Statements . . . . . . . . 9


























Cantillo, et al.         Expires January 9, 2006                [Page 2]


Internet-Draft      draft-cantillo-ipdvb-S2encaps-00           July 2005


1.  Introduction

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

   The first generation DVB-S architecture [2] was designed to
   transport exclusively MPEG2-TS packets [3], and was not intended to
   carry IP data. The transport of IP datagrams over DVB-S was later
   introduced by encapsulating them into MPEG2-TS packets through the
   use of the Multi-Protocol Encapsulation (MPE) protocol [4] or the
   Unidirectional Lightweight Encapsulation (ULE) protocol [5].

   In contrast, the transport of IP datagrams over DVB-S.2 is
   still an open research issue. Like DVB-S, DVB-S.2 is able to
   transport MPEG2 Transport Streams, especially for Digital television,
   but it also supports a new kind of input streams, called
   Generic Streams (GS). GS can be used either in Packetized mode, i.e.
   with fixed-size packets, or in Continuous mode, i.e. with variable
   size packets or for continuous bitstreams.  All these modes use
   transport containers whose length can vary from 3072 to 58192 bits.
   In order to take advantage of these new facilities provided by
   DVB-S.2, the previously mentioned solutions to encapsulate IP
   over MPEG2-TS/DVB-S should be adapted or new solutions should be
   proposed.

   This document presents the requirements for the transport of IP
   datagrams over DVB-S.2, using the specific features of DVB-S.2.

2.  Terminology

   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 RFC 2119 [6].

3.  DVB-S.2 Overview and Motivations

   The main improvement of DVB-S.2 compared to DVB-S [2] is the use of
   a powerful FEC system based on LDPC codes concatenated with BCH codes,
   designed to provide a "Quasi-Error Free" (QEF) quality target (PER <
   10E-7) at the input of the DEMUX. It supports an Adaptive and Coding
   Modulation (ACM) functionality, that allows to optimize the channel
   coding and modulation on a frame-by-frame basis.  The main consequence
   of ACM is that the frames at the input of the FEC subsystem (BBFrames)
   have variable length, spanning from 3072 to 58192 bits (their header
   being fixed to 80 bits, the total payload or DATAFIELD varies between
   2992 and 58112 bits) depending on the code rate and modulation .



Cantillo, et al.         Expires January 9, 2006                [Page 3]


Internet-Draft      draft-cantillo-ipdvb-S2encaps-00           July 2005


   DVB-S.2 is organized as a sequence of functional blocks.  The first
   ones are represented on Figure 1:

       *****************   *******************   *************
       |               |   |                 |   |           |
       |Mode Adaptation|-->|Stream Adaptation|-->|FEC Coding |-->...
       |               |   |    (padder)     |   |           |
       *****************   *******************   *************

   +--+---------+-   +---+---------+   +---+---------+-+
   | input data |    |BBH|Datafield|   |    BBFrame    |
   +--+---------+-   +---+---------+   +---+---------+-+


                    Figure 1: Functional Blocks Diagram

    The "Mode Adaptation" functionnal block
    processes  the input data to produce BBFrames composed of :

      - a DataField
      - a Base Band Header (BBHeader) of length 80 bits


   The maximum Data Field Length (DFL) and thus the length of the BBFrame
   is fixed by the ACM mechanism according to external parameters such e.g
   the propagation conditions.

   To compose the Data Fields, the Mode Adapter can take two types of
   input streams : Transport Stream (TS)  and Generic Streams (GS).
   Transport Stream (TS) are composed of packets of length 188 bytes
   (typically MPEG2-TS packets). Generic Streams (GS) can either be in
   Packetized mode (fixed-length packets) or
   Continuous mode (variable size packets or continuous bitstreams).

   These frames are possibly padded by the Stream Adaptation block to
   obtain Base Band Frames (BBFrames) which are then encoded by the FEC
   coding sub-system.  The BBFrames size varies from 3072 to 58192 bits
   according to the FEC being used.

   To date, there is no standard method to transport IP datagrams over
   DVB-S.2 in GS mode. The main advantage of using GS mode is to avoid
   the use of any intermediary protocol such MPEG2-TS, thereby saving
   the protocol header and processing (including segmentation and
   reassembly) overhead.

4.  General Framework Requirements


   This Section describes the requirements for a framework to transport
   IP datagrams over DVB-S.2 subnetworks. This framework may be used over
   a link in the forward and/or the reverse direction.  The protocols to
   be supported over a link are:






Cantillo, et al.         Expires January 9, 2006                [Page 4]


Internet-Draft      draft-cantillo-ipdvb-S2encaps-00           July 2005


   1.  IPv4 Unicast datagrams, destined for a single end host
   2.  IPv4 Broadcast datagrams, sent to all end systems in an IP
       network
   3.  IPv4 Multicast datagrams
   4.  IPv6 Unicast datagrams, destined for a single end host
   5.  IPv6 Multicast datagrams
   6.  Datagrams with compressed IPv4 / IPv6 packet headers (e.g.
       [8][9]


   The main goal  is to provide an efficient encapsulation scheme
   for IP over GS/DVB-S.2 which may be easily implemented in IP-based
   transmitters and receivers.  The following
   principles are suggested towards this end :

   1.  Ubiquity.  The framework operates below the IP network layer.  It
       MUST not require modifications to existing IP
       (IPv4 or IPv6), UDP, TCP implementations.
   2.  Minimal overhead.  The framework SHOULD minimize protocol
       overhead, in terms of the number of additional bytes to be sent
       in addition to the IP datagram and processing overhead in terms
       of parsing effort of variable length headers or options fields.
       This is important for bandwidth-limited systems (such as
       satellite, terrestrial radio/TV links).
   3.  Minimal set of required options.  Reducing the number and type of
       optional parameters reduces the receiver processing overhead.
       Importantly, it also simplifies receiver implementation, allowing
       easier implementation and promoting better interoperability
       between vendor implementations.
   4.  Flexibility.  The framework SHOULD provide sufficient flexibility
       to allow future inclusion of other mechanisms for specific
       applications.
   5.  Compatibility.  If new protocols are defined by the framework,
       they SHOULD allow co-existence with existing schemes,
       such as MPE or ULE, to allow continued use of the broad-base of
       existing equipment.

5.  Requirements for IP datagrams

   This section describes the requirements for transporting IPv4 and
   IPv6 over DVB-S.2 links.  The section identifies key needs and
   provides examples of mechanisms that may be used to implement these.

   1.  DVB-S.2 stream.  The framework SHOULD provide mechanisms to
       access the DVB-S.2 features (DFL, type of coding and
       modulation, ...). It should also offer guidance on the use
       of compulsory or optional specific features
       which impact performance operation of the IP encapsulation.




Cantillo, et al.         Expires January 9, 2006                [Page 5]


Internet-Draft      draft-cantillo-ipdvb-S2encaps-00           July 2005


   2.  Probability of undetected packet error.  The framework SHOULD
        attempt to minimize the probability of an undetected packet error.
       The scheme therefore MUST be robust to hardware or software failures
       and link loss. The need (or not) for an appropriate error detection
       mechanisms will be determined.
   3.  IPv4 and IPv6.  The framework MUST support IPv4 and IPv6 network
       protocols.  To do this, the payload encapsulation MAY require a
       type field in the subnetwork PDU to indicate the type of the PDU
       being carried (e.g.  IPv4, IPv6).
   4.  Compressed Headers.  The framework MUST address the need in
       certain applications for the support of header compression
       schemes.  This may require a type field in the subnetwork PDU to
       indicate the type of the PDU being carried (e.g.  IPv4, IPv6,
       Compressed Header).
   5.  Multicast.  The framework MUST support IP multicast transmission
       of IPv4 and IPv6 datagrams.  Support for broadcast must also be
       considered for IPv4.
   6.  Diffserv and QoS.  The mapping of IP QoS functions MUST  be
       addressed.
   7.  Identification of subnetwork source/destination.  DVB-S.2 did not
       define the notion of flows, i.e. all the frames sent to the same
       receiver do not have an unique DVB-S.2 identifier/address.  Even
       if the algorithm ACM allocating the frames modulation and coding
       according to the requests of the receivers is not clearly
       defined, this algorithm MAY make use of the
       address defined in the encapsulation scheme.
   8.  Security.  The framework MUST permit use of IPSEC and clearly
       identify any security issues concerning the specified protocols.
       The security issues need to consider two cases: unidirectional
       transfer (in which communication is only from the sending IP end
       host to the receiving IP end host) and bi- directional transfer
       (i.e. where there is also a reverse direction path between the
        receiving IP end host and the sending IP end host).


6. Acknowledgements

        The authors wish to thank Sebastien Ardon for his help.


7.  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).".



Cantillo, et al.         Expires January 9, 2006                [Page 6]


Internet-Draft      draft-cantillo-ipdvb-S2encaps-00           July 2005


   [3]  "[ISO-MPEG] ISO/IEC  DIS  13818-1 Information  technology  --
        Generic  coding of moving pictures and associated audio
        information:  Systems,  International Standards Organisation
        (ISO).".
   [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]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", RFC 2119.

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

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

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


Authors' Addresses

   Juan Cantillo
   ENSICA/TeSA,
   1, place Emile Blouin
   Toulouse  31056
   France

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


   Jerome Lacan
   ENSICA/LAAS-CNRS
   1, place Emile Blouin
   Toulouse  31056
   France

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





Cantillo, et al.         Expires January 9, 2006                [Page 7]


Internet-Draft      draft-cantillo-ipdvb-S2encaps-00           July 2005


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

   Email: Stephane.Combes@space.alcatel.fr
   URI:   http://www.alcatel.com/space/











































Cantillo, et al.         Expires January 9, 2006                [Page 8]


Internet-Draft      draft-cantillo-ipdvb-S2encaps-00           July 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
   http://www.ietf.org/ipr.

   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
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


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.


Acknowledgment

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




Cantillo, et al.         Expires January 9, 2006                [Page 9]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/