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]