IPDVB Working Group J. Cantillo Internet-Draft ENSICA/TESA/Alcatel Alenia Space Expires: March 24, 2006 J. Lacan ENSICA/LAAS-CNRS S. Combes Alcatel Alenia Space September 20, 2005 draft-cantillo-ipdvb-s2encaps-01 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- 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 March 24, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract 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: ip-dvb@erg.abdn.ac.uk 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 [8]. 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 BBFRAMEs. 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 MODCOD. 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 layer). 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 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 Streams. 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 flows. 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/ DFL). 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 encapsulation. 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 streams. 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 SAR. 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 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 Stephane Combes Alcatel Alenia Space 26, avenue JF Champollion BP 1187 Toulouse Cedex 1 31037 France 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 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 March 24, 2006 [Page 20]