idnits 2.17.1 draft-cantillo-ipdvb-s2encaps-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1118. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1095. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1102. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1108. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1010 has weird spacing: '...ing and modul...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 6, 2006) is 6350 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. '12') (Obsoleted by RFC 4301) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPDVB Working Group J. Cantillo 3 Internet-Draft ENSICA/TESA/Alcatel Alenia Space 4 Expires: June 9, 2007 J. Lacan 5 ENSICA/LAAS-CNRS 6 December 6, 2006 8 draft-cantillo-ipdvb-s2encaps-04 9 A Design Rationale for Providing IP Services Over DVB-S2 Links 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on June 9, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document describes a framework for the transmission of IP 43 datagrams over DVB-S2, the second generation standard for Digital 44 Video Broadcasting over Satellite. The new standard features an 45 improved and adaptive physical layer, as well as a new framing 46 structure at link level, the Generic Streams. Combined use of 47 adaptability and Generic Streams is expected to offer throughputs 48 never achieved for IP services up to now, but no standard way to 49 carry IP data using the specific features of DVB-S2 has been 50 published up to date. The present document analyzes these issues, 51 and it identifies the requirements for the definition of a standard 52 interface between the DVB-S2 link layer and an IP subnetwork. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 58 3. DVB-S2 Architecture . . . . . . . . . . . . . . . . . . . . . 6 59 3.1. Functional Blocks and Framing Overview . . . . . . . . . . 6 60 3.2. BBHEADER Fields . . . . . . . . . . . . . . . . . . . . . 8 61 4. Providing IP services over DVB-S2 . . . . . . . . . . . . . . 9 62 4.1. Basic Architecture Considerations . . . . . . . . . . . . 10 63 4.1.1. Protocols Supported . . . . . . . . . . . . . . . . . 10 64 4.1.2. Encapsulation . . . . . . . . . . . . . . . . . . . . 10 65 4.1.3. DVB-S2 Network Topologies . . . . . . . . . . . . . . 10 66 4.2. DVB-S2 Logical Channels and ISI . . . . . . . . . . . . . 11 67 4.3. Address Resolution Issues . . . . . . . . . . . . . . . . 11 68 4.4. QoS Mapping and MODCOD Selection . . . . . . . . . . . . . 12 69 4.4.1. Cross-Layer Optimizations for QoS Scheduling 70 Policies . . . . . . . . . . . . . . . . . . . . . . . 12 71 4.4.2. Differentiated QoS over Logical Channels . . . . . . . 13 72 5. Motivations for a New Approach . . . . . . . . . . . . . . . . 13 73 5.1. ACM and DVB-S2 Framing . . . . . . . . . . . . . . . . . . 13 74 5.2. IP over Generic Streams . . . . . . . . . . . . . . . . . 14 75 6. General Framework Requirements . . . . . . . . . . . . . . . . 14 76 6.1. Use of Existing Encapsulation Capabilities . . . . . . . . 15 77 6.2. Fragmentation Issues. Adaptive Packing and Scheduling 78 Optimization . . . . . . . . . . . . . . . . . . . . . . . 15 79 6.2.1. Fragmentation Schemes to be Supported . . . . . . . . 16 80 6.2.2. Packing Optimization . . . . . . . . . . . . . . . . . 17 81 6.3. Next Level Protocol Type . . . . . . . . . . . . . . . . . 18 82 6.4. Precise Payload Unit Delineation and Reassembly . . . . . 19 83 6.5. Integrity Check . . . . . . . . . . . . . . . . . . . . . 19 84 6.6. Link Layer Addressing Capabilities . . . . . . . . . . . . 20 85 6.7. Flexibility for Future Extension . . . . . . . . . . . . . 20 86 6.8. Security Considerations . . . . . . . . . . . . . . . . . 21 87 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 88 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 89 9. Document History . . . . . . . . . . . . . . . . . . . . . . . 22 90 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 91 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22 92 10.2. Informative References . . . . . . . . . . . . . . . . . . 23 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 94 Intellectual Property and Copyright Statements . . . . . . . . . . 25 96 1. Introduction 98 This document defines a framework that may be used to send/receive IP 99 datagrams and packets of other network protocols using DVB-S2, the 100 new physical layer and framing specification for satellite links 101 defined by the Digital Video Broadcasting project [1]. Recently 102 approved by the European Telecommunications Standards Institute 103 (ETSI), this architecture is designed for broadband satellite 104 applications such as digital television or radio, as well as 105 interactive services such as Internet access or content distribution. 107 Compared to its predecessor DVB-S [2], DVB-S2 features two main 108 enhancements. First, higher order modulations and stronger FEC are 109 teamed up with return channels to achieve real-time adaptability to 110 the link and propagation conditions. This novelty called Adaptive 111 Coding and Modulation (ACM) might allow for an enhanced throughput by 112 30% to 150%, which explains in part the genuine interest for this new 113 standard. DVB-S2 supports also Variable Coding and Modulation and of 114 course, Constant Coding and Modulation (CCM) modes. 116 Second, DVB-S2 offers a new link-layer framing structure called 117 Generic Streams (GS) in addition to the classical packetized 118 Transport Streams (TS). GS can be packetized or continuous, and are 119 intended to address the non-native way in which IP services are 120 carried today over MPEG2-TS using the Multi Protocol Encapsulation 121 (MPE) [5] or the Unidirectional Lightweight Encapsulation (ULE) [4]. 122 Indeed, MPEG2-TS constraints such as constant bit-rate and constant 123 end-to-end delay are not a must for IP services, which added to the 124 accumulation of multiple overheads undermine IP carriage efficiency. 125 Since the use of TS is no longer mandatory in DVB-S2 for carrying IP 126 data, IP over GS seems to offer new possibilities for satellite-based 127 IP networks. 129 Up to now, no standard procedure to carry IP datagrams over Generic 130 Streams has been published yet. The proposal named Generic Stream 131 Encapsulation (GSE) however, is the most likely to achieve 132 convergence among the different solutions proposed. In order to take 133 advantage of the new facilities provided by DVB-S2, the previously 134 mentioned solutions to encapsulate IP over DVB-S should be adapted or 135 new solutions should be proposed. The key goals are to reduce 136 complexity when using the system while improving performance, 137 increasing flexibility for IP services and providing opportunities 138 for better integration of IP-based networks. 140 After a detailed introduction to DVB-S2 architecture, Section 4 141 describes how a DVB-S2 link can be used to provide the Internet 142 service. Finally, guidelines for the definition of a standard 143 interface between the new link layer and an IP subnetwork are 144 exposed. When defined, the proposed interface should minimize 145 overhead and be simple enough to reduce processing while ensuring 146 adequate network services, as well as be robust to errors and 147 security threats while providing enough flexibility for future 148 extension, as exposed in RFC 3819 [6]. 150 2. Conventions Used in This Document 152 ACM: Adaptive Coding and Modulation. Dynamic adjustment of 153 transmission parameters (FEC coding rate and modulation scheme) on a 154 BBFRAME-by-BBFRAME and Receiver-per-Receiver basis, according to link 155 and propagation conditions. In order to implement ACM, feedback from 156 each Receiver has to be provided by a return channel such as DVB-RCS 157 [8]. 159 b: bit. For example, one byte consists of 8b. 161 B: Byte. Groups of bytes are represented in Internet byte order. 163 BBFRAME: Main framing unit of the DVB-S2 protocol stack, consisting 164 of a 10B BBHEADER, a variable size DATAFIELD and Padding (when 165 necessary). It may carry either Generic Streams (GS) or Transport 166 Streams (TS). 168 BBHEADER: 10B header of a BBFRAME. 170 CCM: Constant Coding and Modulation. In CCM transmission mode, the 171 system uses a single type of pre-defined waveform for every Receiver. 172 DVB-S is a CCM system. 174 DATAFIELD: Payload transported by each BBFRAME. Its maximum size 175 determines the length of the BBFRAME that contains it. For a given 176 Receiver, this maximum size is allowed dynamically on a BBFRAME-by- 177 BBFRAME basis among 21 possible sizes (ranging from 372B to 7264B) by 178 the VCM/ACM command. Each size is related to the FEC coding rate to 179 be used for encoding each particular BBFRAME. Lower BBFRAME sizes 180 are used when low coding rates (i.e. stronger protection against 181 channel errors) are needed, whereas longer sizes (i.e higher coding 182 rates) are used under good channel conditions. 184 DFL: One of the BBHEADER fields. Length in bits of the DATAFIELD. 186 DVB-S2: Second Generation of the Digital Video Broadcast for 187 Satellite applications standard [1]. A framework and set of 188 associated standards published by the European Telecommunications 189 standards Institute (ETSI) for the transmission of video, audio, and 190 data, intended to replace DVB-S [2]. 192 FEC: Forward Error Correction. The scheme used in DVB-S2 relies upon 193 the concatenation of Bose-Chaudhuri-Hocquenghem (BCH) and Low Density 194 Parity Check (LDPC) codes. For a given Receiver, its overall coding 195 rate is adjusted on a BBFRAME-by-BBFRAME basis according to the needs 196 specified for each BBFRAME by the VCM/ACM command. 198 FECFRAME: Encoded BBFRAME, as seen at the output of the FEC encoder. 199 FECFRAMEs have only two possible sizes, 2025B and 8100B, no matter 200 the size of the BBFRAME to code. 202 Generic Stream: One of the 2 possible input streams in DVB-S2, the 203 other one being Transport Streams. Generic Streams can be packetized 204 or continuous, and are intended to be used especially for carrying 205 data services such as IP distribution. An example of packetized 206 Generic Stream could be a flow of MPEG2 packets. 208 GS: See Generic Stream. 210 ISI: Input Stream Identifier, second byte of the BBHEADER field for 211 multiple input streams. It provides a way to separate different 212 BBFRAMEs within a single multiplex, defining logical channels for 213 BBFRAMEs. 215 MPEG2: A set of standards specified by the Motion Picture Experts 216 Group (MPEG), and standardized by the International Standards 217 Organization (ISO) [3]. 219 MODCOD: Information provided by the VCM/ACM command to the BBFRAME 220 assembler, specifying the coding rate (therefore the size of the 221 maximum size of DATAFIELD to be allowed) and the modulation scheme to 222 be used for encoding and modulating each BBFRAME. 224 NPA: Network Point of Attachment. Addresses primarily used for 225 station (Receiver) identification within a local network (e.g. IEEE 226 MAC address). An address may identify individual Receivers or groups 227 of Receivers. 229 PID: Packet Identifier [3]. A 13 bit field carried in the header of 230 TS Packets. This is used to identify the TS Logical Channel to which 231 a TS Packet belongs [3]. The TS Packets forming the parts of a Table 232 Section, PES, or other Payload Unit must all carry the same PID 233 value. The all 1s PID value indicates a Null TS Packet introduced to 234 maintain a constant bit rate of a TS Multiplex. There is no required 235 relationship between the PID values used for TS Logical Channels 236 transmitted using different TS Multiplexes. 238 PDU: Protocol Data Unit. Examples of a PDU include Ethernet frames, 239 IPv4 or IPv6 datagrams, and other network packets. 241 PLFRAME: Last framing unit of the Physical Layer of DVB-S2. 243 PLHEADER: Header of a PLFRAME. The PLHEADER contains synchronization 244 information coded over 2b, as well as the MODCOD used for the current 245 frame (5b). Since it has to be demodulated and decoded for every 246 Receiver without a priori knowledge of the carried MODCOD, it 247 features an unique modulation and coding, no matter the payload's 248 MODCOD. 250 Receiver: An equipment that processes the signal from the satellite 251 and performs filtering and forwarding of encapsulated PDUs to the 252 network-layer service (or bridging module when operating at the link 253 layer). 255 Return Channel: A way for end-users to interact with the transmitting 256 Gateway, in order to establish a bi-directional communication. Such 257 technologies can make use of two-way satellite links [8] and/or 258 terestrial links. 260 SAR: Segmentation And Reassembly, generally for encapsulated SNDUs. 262 SNDU: Sub Network Data Unit. A framing entity created on the basis 263 of a network-layer PDU by an adaptation layer protocol, allowing this 264 PDU to travel along a L2 subnetwork. 266 TS: Transport Stream [3], a method of transmission at the MPEG2 level 267 using MPEG2 Packets. 269 UPL: One of the BBHEADER fields. It carries packets lengths in bits, 270 in the case of packetized input streams. 272 VCM: Variable Coding and Modulation. Differentiated optimization of 273 transmission parameters according to the physical characteristics of 274 every Receiver, such as geographical position, size etc. 276 3. DVB-S2 Architecture 278 3.1. Functional Blocks and Framing Overview 280 DVB-S2 is organized as a sequence of functional blocks. 282 The Mode Adaptation block processes input data structured either as 283 TS or GS, single or multiple. Input streams are sliced into 284 DATAFIELDs to which a 10B BBHEADER is appended. The maximum length 285 of every DATAFIELD is chosen dynamically among 21 allowed sizes in 286 the range [374B; 7264B] by the VCM/ACM command, according to the 287 protection required for everyone of them. Basically the shorter they 288 are, the more space there is for FEC redundancy protection. Actual 289 systems may only implement a subset of those 21 sizes. 291 The Stream Adaptation block may complete every DATAFIELD with Padding 292 in order to match the length of a valid BBFRAME. BBFRAMEs therefore 293 have one of 21 possible pre-defined sizes in the range [384B; 7274B]. 294 This is a major difference with DVB-S, since at this level there are 295 only 188 Byte MPEG2 containers. Note that DATAFIELDs sizes are not 296 multiples of 188B: Transport Streams, as well as Generic Streams, are 297 mapped asynchronously over BBFRAMEs. 299 Adaptive FEC encoding constitutes the third block. A set of coding 300 schemes based on a concatenation of LDPC and BCH codes ensures a very 301 efficient error protection, only 0.7 to 1 dB away from the Shannon 302 limit (DVB-S FEC is around 2.5 dB from that margin). In ACM mode, 303 the ACM command dictates dynamically the coding rate to be used for 304 every BBFRAME in order to provide a Quasi-Error Free (QEF) quality 305 target at the input of the Receiver's DEMUX (roughly equivalent to 306 PER < 1e-7 for a MPEG2 transmission). FEC parity bits are calculated 307 and appended systematically to each BBFRAME in order to provide 308 fixed-length FECFRAMEs of 2025B or 8100B. This implies that shorter 309 BBFRAMEs are completed with more redundancy than long BBFRAMEs, and 310 are therefore more protected. 312 Finally, FECFRAME bits are modulated and raised-cosine filtered, to 313 provide the body of a PLFRAME. 4 different modulations with spectral 314 efficiencies ranging from 2bits/s/Hz to 5 bits/s/Hz are available in 315 DVB-S2. Finally, information about the FEC coding rate and 316 modulation used for every frame (MODCOD) is stored in a PLHEADER and 317 appended to every PLFRAME. Of course, DVB-S2 provides mechanisms to 318 ensure proper reading of every PLHEADER for every Receiver without a 319 priori knowledge of the contained MODCOD, so all PLHEADERs use a pre- 320 determined coding and modulation. The final PLFRAME is finally sent 321 over the RF carrier using classical TDM and/or FDM techniques. 323 --------------------------------- 324 L2 :::| TS or GS |::: 325 --------------------------------- 326 +--------------+ . . 327 D | | . . 328 V | Mode | +-----+-------------------+ 329 B | Adaptation | |BBHDR| DATAFIELD | 330 - | | +-----+-------------------+ 331 S +--------------+ . 10B 0B 338 I +--------------+ . . 339 C | | . . 340 A | Adaptive FEC | +---------------------------------+-------+ 341 L | Encoding | | |Parity | 342 | | +---------------------------------+-------+ 343 L +--------------+ <------- FECFRAME: 2050B or 81000B -------> 344 A +--------------+ . . 345 Y | | . . 346 E | Adaptive | +-----+--+--+--+--+- -+--+--+--+--+ 347 R | Modulation | |PLHDR| | | | | ::::::::::::::: | | | | | 348 |& TDM Framing | +-----+--+--+--+--+- -+--+--+--+--+ 349 +--------------+ <----- PLFRAME: complex modulated symbols ------> 351 Figure 1: DVB-S2 architecture and framing structure overview 353 3.2. BBHEADER Fields 355 Several statements made in the following sections will refer to 356 fields present in the 10B BBHEADER, so a very short description of 357 this entity is presented here: 359 +------------+------------+------------+-------+------------+-------+ 360 | MATYPE 2B | UPL 2B | DFL 2B |SYNC 1B| SYNCD 2B | CRC-8 | 361 +------------+------------+------------+-------+------------+-------+ 363 Figure 2: A BBHEADER 365 The first byte of the MATYPE field specifies whether TS or GS are 366 used, and whether they are single or multiple. In the multiple case, 367 the second byte is an "Input Stream Identifier" (ISI). 369 UPL specifies packet lengths in bits, in the case of packetized input 370 streams. As an example, a value of 0x05E0 (188*8 hexadecimal) is 371 characteristic of MPEG2 packets. A value of 0x0000 means a 372 continuous GS. 374 DFL specifies the length of the DATAFIELD actually used in bits, in 375 the range [0b; 58112b] (58112 = 7264*8, 7264B being the maximum 376 DATAFIELD length allowed). 378 SYNC stores the synchronization byte carried by all the packets of a 379 packetized stream, when there is one (e.g. if MPEG2 packets are 380 transported, SYNC=0x47). Since the synchronization byte is carried 381 by BBHEADERs, there is no need for every packet to carry it anymore. 382 A CRC-8 calculated for every packet replaces therefore the 383 synchronization byte in every packet : it is used to validate 384 Segmentation And Reassembly (SAR) applied on them. SYNC is not 385 relevant for continuous Generic Streams. 387 SYNCD is the distance in bits, for a packetized stream, from the 388 beginning of the DATAFIELD to the first start of packet contained in 389 this DATAFIELD. Its use is therefore similar to a Payload Pointer, 390 as defined in ULE [4]. SYNCD is not relevant for continuous Generic 391 Streams. 393 Finally, a CRC-8 is calculated from the previous 9B of the BBHEADER. 395 Note that BBHEADER fields natively support SAR applied to MPEG2 396 packets or any other fixed-length packets asynchronously mapped over 397 a BBFRAME flow. Indeed, perfect delineation and reassembly can be 398 achieved by the exclusive use of UPL, DFL and SYNCD for packetized 399 Generic Streams. Finally, the CRC-8 stored in the 1B slot liberated 400 by SYNC in every packet provides an end-to-end integrity check, 401 achieving thus an encapsulation that does not produce any overhead at 402 all (except when Padding is necessary). In DVB-S2, a flow of MPEG2 403 packets can therefore be sent over a packetized Generic Stream using 404 UPL=0x05E0 and SYNC=0x47. 406 4. Providing IP services over DVB-S2 408 The purpose of this section is to describe how a DVB-S2 link can be 409 used to deliver the Internet service. DVB-S2 not only provides all 410 the tools necessary for a reliable and efficient transmission/ 411 reception of network layer datagrams, but it also allows to improve 412 the way their delivery is classically done over satellite links. 414 4.1. Basic Architecture Considerations 416 4.1.1. Protocols Supported 418 This document focuses mainly on the transmission and reception of 419 IPv4 and IPv6 unicast, multicast and braodcast/anycast datagrams. 420 This includes datagrams with compressed or encrypted IPv4/IPv6 421 headers (e.g. RFC 1144 [9], RFC 2507 [10], RFC 3095 [11] and RFC 422 2401 [12]). However, the scope of the proposed framework is general 423 enough to support a wide range of other network layer protocols, such 424 as the ones recorded in the IANA EtherType registry. 426 4.1.2. Encapsulation 428 PDUs arrive to the transmission Gateway using the existing 429 infrastructure, as e.g. IP datagrams, Ethernet frames etc. They are 430 then shaped by an Encapsulator into SNDUs, fragmented when necessary 431 and packed into BBFRAMES, either directly (Generic Streams) or via an 432 additional layer (MPEG2-TS). BBFRAMEs are coded, modulated and sent 433 through the RF channel to the satellite. 435 Encapsulation allows PDUs to travel along an L2 subnetwork, and 436 provides mapping of network-level functionalities over L2 entities. 438 4.1.3. DVB-S2 Network Topologies 440 As a successor to DVB-S, some compatibility at least, as well as 441 enhancement of network capabilities are expected for DVB-S2. 442 Transmission networks to be supported by DVB-S2 contain therefore 443 basically those specified in RFC 4259 [7]. Those are: 445 Uni-directionnal scenarios such as: 446 -Digital radio and TV broadcast 447 -Broadcast networks used by an ISP 448 -Uni-directionnal star IP scenarios 449 -Datacast overlay 451 Bi-directionnal scenarios such as: 452 -Point-to-Point links 453 -Two-way IP networks 455 The growing demand for IP services and the increased availability of 456 return channels are bound to play an important role in the 457 development of the last 2 scenarios. In addition, the enhanced 458 throughput capabilities of the new standard will most likely 459 influence positively this development. 461 4.2. DVB-S2 Logical Channels and ISI 463 In the same way the PID field allowed to distinguish TS logical 464 Channels for MPEG2, the ISI byte of every BBHEADER (see comment on 465 the MATYPE field in Section 3.2) can be used to support logical 466 channels for BBFRAMEs. This would provide a powerful discriminating 467 tool within a single multiplex of BBFRAMEs, that could be used e.g. 468 for efficient address resolution, QoS differentiation or to provide 469 other services. However, up to now there is no standardized 470 signalling associated to ISI (such as tables or reserved values), and 471 further work has to be done in this direction in order to set a 472 complete framework. This important point includes precise mapping of 473 upper layer QoS functions, or standards to associate the capabilities 474 of these potential logical channels to upper layer flows. 476 Note that other methods could be imagined to set up logical channels 477 in DVB-S2. However, the use of ISI, although not described in detail 478 in the DVB-S2 specification, seems naturally adapted to this 479 particular task. 481 If MPEG2 packets are to be mapped into BBFRAMEs, there are no 482 indications either in DVB-S2 about the way PIDs and ISI have to be 483 related to each other. Since PID already defines logical channels at 484 MPEG2 level, the simplest solution would be to keep the ISI field 485 unused, and filter at MPEG2 level. In another figure case, ISI could 486 be used to define meta-channels of PIDs. The last possibility is ISI 487 beeing just a copy of the transported PIDs, which supposes that only 488 MPEG2 packets sharing the same PID are allowed to travel together. 489 Note that even though the original PID is 13b long and ISI is only 490 8b, actual hardware filters limit the maximum number of active PIDs 491 per multiplex (e.g. to 32), thus making this mapping possible in some 492 cases. 494 If Generic Streams are to be mapped into BBFRAMEs, ISI allocation and 495 use will have to be defined from scratch. For this, static or 496 dynamic tables must be specified, using when possible the basis and 497 the experience of those in use over MPEG2. ISI signalling for 498 Generic Streams is a key issue for building an IP sub-network over a 499 DVB-S2 link, since GS are a very strong candidate to replace MPEG2 500 bearers for the carriage of IP datagrams over satellite links. 502 4.3. Address Resolution Issues 504 Logical channels allow differentiation of upper layer flows within a 505 BBFRAME multiplex. A mapping function -to be defined- can provide 506 the means to associate dynamically a network flow to a particular 507 logical channel of a single multiplex. This mapping function will be 508 the main basis over which Address Resolution will be done in IP/ 509 DVB-S2 networks. 511 Precise address resolution considerations are out of the scope of the 512 present document, but previous work done on DVB-S encapsulation 513 procedures can provide valuable input here. Furthermore, since 514 BBHEADERs provide similar functionalities to the ones given by MPEG2 515 headers, it is highly probable that existing considerations for PIDs 516 can be transposed directly to ISI. 518 4.4. QoS Mapping and MODCOD Selection 520 Under ACM mode, every Receiver will be able to adjust its reception 521 parameters by the choice of a minimum protection MODCOD, in order to 522 cope with rapid link fading (due to e.g. rain or interference) and 523 ensure data reception under any condition. 525 From an IP point of view, MODCOD variations will only change the 526 available bandwidth for the overall transmission. The ACM command 527 will therefore have to schedule packets according to QoS 528 considerations, filling in an optimal way the available BBFRAMES. 529 This might imply rapid changes of packets queues, delaying and/or 530 dropping PDUs. 532 Under DVB-S2 links, QoS will be a mix of 2 aspects: minimum 533 protection required (MODCOD), and priority of transmission over other 534 PDUs. Proper mapping of QoS requirements over MODCODs has not been 535 done yet and this is a topic in which comments and suggestions are 536 most welcome. In particular, there are many ways in which QoS 537 requirements for every PDU can be passed to the scheduler. This 538 information could be added to every encapsulation header, or IP flows 539 could be distributed over different queues (each one having different 540 QoS requirements) prior to encapsulation and packing. A less 541 classical method could consist on making instant scheduling decisions 542 at link layer with basis on information directly provided by every IP 543 header. 545 Other basic and non-exhaustive ideas are presented here: 547 4.4.1. Cross-Layer Optimizations for QoS Scheduling Policies 549 The value of the TOS (Type Of Service) field in the IP header will 550 certainly be taken in account for QoS mapping, but QoS 551 differentiation procedures can also rely on complementary 552 information. 554 A promising research possibility is to add specific application-level 555 information to every single network packet (e.g. in the encapsulation 556 header, complementing or overriding TOS), to determine the particular 557 BBFRAME in which it will be packed (that is, the particular MODCOD 558 assigned to it) or its priority over other PDUs. It has been pointed 559 out that using application-level information for link-level 560 scheduling and MODCOD protection might prove interesting. An example 561 of this could be an error-tolerant application (e.g. streaming), that 562 simply may not need the maximal protection available at a given time 563 for its particular Receiver: lowering its protection might free 564 needed resources elsewhere and allow for processing and overhead 565 saves. Research lead on the relation between link-level FEC and 566 application-level FEC will certainly provide interesting input to 567 this particular issue. 569 4.4.2. Differentiated QoS over Logical Channels 571 Instead of assigning an optimal MODCOD to every single PDU, a simpler 572 idea is to associate a given QoS level with a particular Logical 573 channel, in a static or dynamic way. Equivalent QoS levels could 574 therefore have different instances according to the MODCOD they use. 576 Again, input concerning thse particular issues is most welcome. 578 5. Motivations for a New Approach 580 Even though many existing solutions used in DVB-S can be extended or 581 adapted to the new standard, the new features of DVB-S2 raise a 582 number of important and interesting issues worth consideration. 584 5.1. ACM and DVB-S2 Framing 586 Through the use of ACM, the dynamic variations of the RF channel will 587 have a direct impact over the physical waveform to be used for every 588 piece of data to be transmitted. Analysis of MODCOD allocation 589 policies due to channel variations might open field for IP carriage 590 efficiency improvement, and several competing resource allocation 591 algorithms should be tested. 593 On the other hand, the presence of BBFRAMEs measuring up to 7 kB 594 (around 37 times the size of a MPEG2 packet) suggests that in many 595 cases several full PDUs will be able to fit together in a single 596 DATAFIELD. Making reasonable assumptions about the fragmentation 597 complexity allowed by a future encapsulation, Segmentation and 598 Reassembly (SAR) should therefore occur less often than in DVB-S, 599 which raises other kind of questions and risks. In particular, a 600 partially filled and sent BBFRAME will make worse use of the RF 601 resource than a partially filled and sent MPEG2 packet. In contrast, 602 optimal BBFRAME filling should allow optimal resource use as it 603 minimizes redundant overhead. Indeed, available PDU encapsulations 604 such as MPE/MPEG2-TS, ULE/MPEG2-TS or AAL5/ATM were designed for a 605 relatively high probability of SAR use during SNDU processing. The 606 definition of a scheduling algorithm ensuring optimal BBFRAME filling 607 will certainly be a key point for improving IP carriage efficiency. 609 5.2. IP over Generic Streams 611 TS constant end-to-end delay and constant bit-rate are not a must for 612 IP services, and could be overridden if a GS solution were considered 613 for IP carriage. On top of that, the mandatory asynchronous mapping 614 of MPEG2 over the BBFRAMEs directly constitutes a triple drawback 615 from an IP point of view. First, it adds significant complexity and 616 processing to the overall process. Second, the eventual overhead 617 (here, padding) generated by this asynchronous mapping will add to 618 the overall overhead of the IP encapsulation over MPEG2-TS, 619 decreasing global efficiency. Finally, unexpected hardware/software 620 functioning that may affect proper reassembly of fragmented MPEG2 621 packets will directly impact PER at IP level. 623 The use of MPE and recently ULE to convey IP data over MPEG2-TS has 624 contributed over the past years to its wide acceptance as a IP 625 subnetwork technology. However, despite the unquestionable services 626 done by MPEG2-TS in the DVB-S context, the use of GS in a DVB-S2 627 system for conveying IP data seems to offer better perspectives. In 628 order to take full advantage of the handy features of GS and ACM, and 629 stick to the key goals specified in Section 1, new solutions have to 630 be considered. Those should rely on already available proved 631 concepts when possible, but should also innovate where existing 632 mechanisms do not offer a satisfactory solution. 634 6. General Framework Requirements 636 Detailed requirements for transmission of IP datagrams over MPEG2-TS 637 networks have been defined in RFC 4259 [7]. The present section will 638 therefore focus on the requirements for transmission of IP datagrams 639 over continuous Generic Streams in ACM mode. Note however, as stated 640 in Section 3.2, that seen from a BBFRAME, there is no difference 641 between a MPEG2-TS and a packetized Generic Stream with packets of 642 length 188B. From this perspective, MPE or ULE could be used for 643 encapsulation of upper layer datagrams over a packetized Generic 644 Stream, although this would be a very inefficient solution. Indeed, 645 in addition of artificially introducing the complexity and overhead 646 of the MPEG2 layer, advanced fragmentation and adaptive scheduling 647 could not be used, due to the flexibility limitations of the stream- 648 based MPEG2 approach. 650 This section is concerned with the efficient carriage of IP datagrams 651 over continuous Generic Streams relying on an adaptive link/physical 652 layer. Fundamental differences with a TS approach will therefore be 653 pointed out when possible. 655 6.1. Use of Existing Encapsulation Capabilities 657 In the general encapsulation case, PDUs are formatted one by one into 658 SNDUs, by receiving a particular header and an integrity check 659 trailer such as a CRC. When required, SNDUs are fragmented and their 660 fragments are sent over the link using one or more bearers (e.g. 661 MPEG2 packets or BBFRAMEs). The encapsulation header provides 662 delineation information to the Receiver, so that received SNDU 663 fragments can be located and properly assembled. The end-to-end 664 integrity check stands as a protection against re-assembly errors. 666 However, MPEG2 packets are encapsulated into BBFRAMEs without the 667 need of additional encapsulation headers, since BBHEADERs provide all 668 the functionalities necessary to delineate and reassemble fragmented 669 packetized streams. BBHEADERs have therefore some inherent 670 encapsulation capabilities, and a future framework intended to 671 standardize an IP over GS interface could take advantage of this 672 handy feature. 674 Of course, IP streams are not composed of fixed-length packets and 675 the above-mentioned encapsulation capabilities of BBHEADERs do not 676 directly apply. However, several concepts used in classical 677 encapsulation headers (e.g. Payload Pointer or Length Field for ULE) 678 could be transposed if IP packets were to be mapped over Generic 679 Streams, using available fields in BBHEADERs (e.g. SYNC and UPL/ 680 DFL). 682 Note finally that among the 10 bytes of BBHEADERs, at least 3 (SYNC 683 and SYNCD) are not relevant for continuous GS. Their re-definition 684 and use in an "IP over continuous GS" context might prove useful as 685 this would allow reducing the header length of a future 686 encapsulation. 688 6.2. Fragmentation Issues. Adaptive Packing and Scheduling Optimization 690 In order to ensure optimum use of the available resources, it is 691 required that BBFRAMEs addressed to a single NPA carry as much data 692 as possible, and therefore SNDU fragmentation is important. 693 Furthermore, since BBFRAMEs are considerably longer than classical 694 bearers, optimal packing of the SNDU fragments according to QoS or 695 size criteria is a key point for achieving efficient PDU carriage. 696 This is a major difference with DVB-S, in which SNDU fragments are 697 sent over the next MPEG2 bearer available, regardless of their sizes 698 or required QoS. 700 6.2.1. Fragmentation Schemes to be Supported 702 Several fragmentation schemes supported by the encapsulator with 703 increasing complexity can be imagined. For the authors, the 4 704 examples described below represent the maximum fragmentation levels 705 that should be implemented in an encapsulator in order to avoid 706 excessive Receiver complexity while ensuring optimum scheduling 707 management. Note that cases b. c. and d. do not occur in the MPEG2 708 stream-based approach, and therefore cannot be managed by simple ULE- 709 like SAR procedures. 711 The following BBFRAMEs belong to the same logical channel, and are 712 therefore seen by all the Receivers correctly tuned. For the 713 examples, we focus only on fragmentation of SNDU2 into 2 fragments 714 SNDU2a and SNDU2b, carried by 2 different BBFRAMES. Those 2 BBFRAMEs 715 do not necessarily use the same MODCODs, but we suppose that the 716 Receiver assembling SNDU2 can at least decode/demodulate them 717 correctly. Note that fragmentation of an SNDU over more than 2 718 fragments is of course possible. 720 a. Classical consecutive fragmentation 722 +---------+--------+ +------+--------------+ 723 | SNDU1 | SNDU2a | |SNDU2b| SNDU3 | 724 +---------+--------+ +------+--------------+ 726 This is the most natural and intuitive one, since it is classically 727 used over MPEG2 bearers. In this case, SNDU2 is sent over 2 728 consecutive BBFRAMEs, using the end of the first BBFRAME and the 729 start of the second one. 731 b. Consecutive fragmentation with arbitrary SNDU fragment placement 733 +---------+--------+ +----------+------+-------+ 734 | SNDU1 | SNDU2a | | SNDU3 |SNDU2b| SNDU4 | 735 +---------+--------+ +----------+------+-------+ 737 After sending the beginning of SNDU2, the scheduler decides to use 738 the beginning of the following BBFRAME to send SNDU3. This latter 739 SNDU could be addressed to another Receiver for example, or be 740 addressed to the recipient of SNDU2 but bear more priority. This is 741 not necessarily related to a change of MODCOD after the first 742 BBFRAME, although a narrowing of the bandwidth of the channel can 743 motivate this kind of decisions. SNDU2 is resumed using available 744 space in the following bearer, which implies basically that SNDU2b 745 does not start at the beginning of the second BBFRAME. 747 c. Non-consecutive fragmentation 749 +---------+--------+ +------- // --------+ +------+--------------+ 750 | SNDU1 | SNDU2a | | SNDU3 --> SNDU7 | |SNDU2b| SNDU8 | 751 +---------+--------+ +------- // --------+ +------+--------------+ 753 After placing fragment SNDU2a, the scheduler decides to delay 754 placement of SNDU2b in order to send 5 SNDUs, labelled 3 to 7. After 755 their transmission has finished a few BBFRAMEs later, SNDU2b is 756 placed and sent in the beginning of the next available bearer. In 757 this case, the Receiver needs to identify the BBFRAME carrying 758 SNDU2b. Note that SNDUs #3 to #7 might have been fragmented as well 759 over the intermediate BBFRAMEs, so that there might be more than 1 760 SNDU with suspended fragments within the same BBFRAME flow. 762 Such situation will happen e.g. because of a MODCOD change: 763 intermediary BBFRAMES might be using a very efficient MODCOD, so that 764 the Receiver assembling SNDU2 would not be able to decode/demodulate 765 them. In another scenario, they could have the same MODCOD as the 766 previous ones, but be addressed to another Receiver of the same 767 logical channel bearing more priority than the one assembling SNDU2. 769 d. Non-consecutive fragmentation with arbitrary SNDU fragment 770 placement 772 +---------+--------+ +-------- // --------+ +--------+------+-------+ 773 | SNDU1 | SNDU2a | | SNDU3 --> SNDU7a| | SNDU7b |SNDU2b| SNDU8 | 774 +---------+--------+ +-------- // --------+ +--------+------+-------+ 776 This case is a combination of cases b. and c. The Receiver needs to 777 identify the BBFRAME carrying SNDU2b as well as its position inside 778 the BBFRAME. This solution seems to offer the greatest flexibility 779 vs. reasonable complexity trade-off in the DVB-S2 context. 781 Note finally that in all previous schemes, SNDU2a is always at the 782 end of a given BBFRAME. A more generic fragmentation scheme could 783 allow for a free placement of SNDU2a in the BBFRAME flow (not 784 necessarily at the end of a BBFRAME), although this solution does not 785 seem much more performant than d. 787 6.2.2. Packing Optimization 789 MODCOD allocation by the ACM command is closely related to packing 790 optimization, since available DATAFIELD sizes will vary according to 791 the dynamics of the channel. A scheduling algorithm is required to 792 optimize filling and minimize BBFRAME Padding, that may be up to 793 7264B for an empty DATAFIELD. It should provide ways to fragment, 794 re-order SNDUs and delay them when necessary for the sake of optimal 795 filling, but always in the limits of an admissible complexity. In 796 particular, packet re-ordering between different IP flows to optimize 797 BBFRAME filling is encouraged, while fragment reordering within a 798 single flow of IP packets (that is between 2 fixed ports of 2 end 799 hosts) should be avoided, according to RFC 3819 [6]. 801 A scheduling algorithm should take in account the statistical 802 characteristics of the carried IP traffic, and its functioning should 803 not be independent from the ACM command. It should also provide 804 BBFRAME Padding when necessary (when no PDU is ready to be 805 encapsulated). 807 6.3. Next Level Protocol Type 809 A key feature of the required encapsulation is to identify the 810 payload type being transported. Such requirement is not specific to 811 DVB-S2: most protocols use a type field to identify a specific 812 process at the next higher layer that is the originator or the 813 recipient of the payload. 815 Given the length of BBFRAMEs, several PDUs will often be packed 816 within the same BBFRAME. Possible ways to differentiate protocol 817 types to which PDUs belong are: 819 -ISI channels. This requires no overhead and demands that only 820 PDUs from (or to) the same protocol can be sent together in a 821 single BBFRAME. The use of ISI for this purpose can interfere 822 with its use for address resolution or QoS mapping. 824 -A single Type field per BBFRAME (ex: appended to the BBHEADER or 825 inside it)in an homogeneous traffic environment (e.g. an IPv4-only 826 network). Only homogeneous PDUs (that is, originated or going to 827 a same protocol) will be packed together. This solution produces 828 very small overhead but offers low flexibility for future 829 evolution of the traffc mix. 831 -A Type field per PDU. In an heterogeneous traffic environment 832 (e.g. a mix of IPv4 and IPv6 packets), it is required that every 833 single PDU is labelled with a proper Type field. This solution 834 produces an overhead proportional to the number of transported 835 PDUs but offers no limits in its flexibility, since the detailed 836 composition of the traffic mix do not affect the encapsulation 837 procedures. 839 In a context of IPv4 to IPv6 migration and of increased use of the 840 Internet by new applications and users, the last solution seems to be 841 the most adapted. It is also the choice done in ULE. 843 6.4. Precise Payload Unit Delineation and Reassembly 845 Accurate delineation and identification of scattered SNDU fragments 846 must be done by every Receiver. As an example, ULE achieves 847 delineation with the joint use of MPEG2's PUSI, a Payload Pointer and 848 a Length field. 850 Precise PDU delineation is also required for a future encapsulation 851 over Generic Streams. The implemented solution may define a ULE-like 852 header for this, but it may also re-use (partially at least) BBHEADER 853 fields that already provide similar functionalities. It should also 854 be robust to synchronization losses, for which a "Payload Pointer 855 plus Length field" approach could prove desirable. 857 On the other hand, a future encapsulation must provide ways to ensure 858 reassembly of a scattered SNDUs even in the case that its fragments 859 are not "adjacent" within 2 consecutive BBFRAMEs, which could happen 860 if advanced SNDU scheduling/fragmentation procedures are used. In 861 the classical ULE/MPEG2-TS/DVB-S scenario, SNDU fragmentation is done 862 over MPEG2 packets of the same flow (same multiplex and PID) with 863 Continuity Counters differing only by 1 (modulo 16). This means that 864 a ULE Receiver knows in advance the size and position in the flow of 865 the next SNDU chunk needed for proper reassembly. However, in a 866 DVB-S2 context, the scheduling algorithm may chose to send SNDU 867 fragments over non-consecutive BBFRAMEs, or place SNDU fragments in 868 the middle of a given BBFRAME (cases b., c. and d. of Section 6.2.1). 869 Since ULE does not provide tools to locate scattered SNDU fragments 870 with a priori unknown positions and lengths in a BBFRAMEs multiplex, 871 it cannot be used directly in a GS context. More advanced reassembly 872 procedures will certainly have to be studied. 874 6.5. Integrity Check 876 For the IP service, the probability of undetected packet error should 877 be small or negligible, as stated in RFC 3819 [6]. There is 878 therefore a need for a strong error control, either provided by FEC 879 or by other means such as CRCs. FEC has been greatly improved in 880 DVB-S2, and it provides means to re-evaluate the way integrity check 881 can be done. The following considerations apply also for packetized 882 streams. 884 The CRC-32 used in ULE relies on the use of a 32-bit redundancy for 885 each SNDU, intended to stand as a protection against reassembly 886 errors following corruption or loss of SNDU bearers, due to 887 transmission errors or unexpected hardware/software operation. 889 Concerning resilient channel errors, DVB-S2 FEC has reduced the 890 probability of such event by several orders of magnitude compared to 891 DVB-S. Indeed, the implemented LDPC and BCH concatenated encoding 892 provide error protection close to the theoretical limits established 893 by Shannon in [13]. On top of that, and in addition to their 894 correction capabilities, outer BCH decoders can provide very accurate 895 error-detection information that could be used to detect and discard 896 corrupted BBFRAMEs. DVB-S2 FEC offers therefore the possibility to 897 manage globally the SNDU error-detection problem, done classically on 898 a SNDU-by-SNDU basis with CRCs. Details concerning these particular 899 issues are fully analyzed in [14]. 901 As for BBFRAME losses, only SNDUs with fragments in lost BBFRAMEs 902 will face reassembly problems. A non-fragmented SNDU within a lost 903 BBFRAME will be simply lost, even if it had a CRC. In this context 904 it seems adequate to apply CRC integrity checks to the PDUs that may 905 suffer SAR. 907 Accurate estimation of PER at IP level with or without CRCs should 908 drive the design decisions concerning this issue, and not legacy 909 considerations based on different or less efficient systems. 911 6.6. Link Layer Addressing Capabilities 913 Individual Receivers are not addressable at a BBFRAME level. 914 MPEG2-TS addressing considerations exposed in RFC 4259 [7] apply 915 therefore to BBFRAMEs too and should be used as guidelines for future 916 work on this key topic. 918 These considerations imply the use of an optional NPA field appended 919 to every PDU or group of PDUs sharing the same BBFRAME. There are 920 indeed cases where the use of a NPA is required (e.g. when link layer 921 filtering is desired) and if present, it should be carried in a way 922 to allow Receivers to pre-filter and discard unwanted PDUs. There 923 are other cases where an NPA is not required (e.g. when a Receiver is 924 the end host), and network layer filtering may be used. 926 An IP over GS interface should therefore support an optional NPA, as 927 current encapsulations for IP over MPEG2-TS do. The interactions and 928 synergies that can be achieved with the use of BBFRAMEs' logical 929 channels defined in Section 4.2 are to be analyzed. 931 6.7. Flexibility for Future Extension 933 The evolution of the Internet service may in the future require 934 additional functions. A flexible encapsulation protocol should 935 therefore provide a way to introduce new features when required, 936 without having to provide additional out-of-band configuration. This 937 is not a difference with TS, and a native way to signal header 938 extensions (like the Next-Header protocol type in ULE) should be 939 implemented. 941 6.8. Security Considerations 943 Security considerations are basically the same for GS and TS, and are 944 based on those concerning wireless links, see RFC 3819 [6]. Although 945 an analysis of specific security issues concerning GS is out of the 946 scope of this document, it will provide helpful input for addressing 947 this important topic in future work. 949 Current work on security issues for ULE carried out at the IPDVB 950 working group should certainly integrate considerations regarding 951 DVB-S2. 953 7. Summary 955 DVB-S2 offers new possibilities for deploying IP services over 956 satellite links, as a successor of DVB-S that offers many IP-friendly 957 capabilities. 959 The new standard's physical adaptability and new framing structure 960 motivate therefore a new encapsulation for IP, much more efficient in 961 terms of complexity and overhead than the classical MPEG2-TS 962 approach. 964 For this, some solutions developped for IP/MPEG2 can be simply 965 transposed to DVB-S2, like the use of Type fields or the definition 966 of logical channels. However, the full use of DVB-S2 specificities 967 will also need new procedures -like datagram scheduling optimization 968 and advanced fragmentation- to be defined from scratch. Finally, 969 other issues like integrity check management might be re-evaluated in 970 a DVB-S2 context, taking in account the enhanced error-control 971 achieved by the new FEC. 973 Finally, DVB-S2 BBFRAMEs are defined in such a way that BBHEADERs 974 present some inherent encapsulation capabilities. The definition of 975 a new IP over DVB-S2 adaptation layer could take advantage of this 976 handy feature, and open the way for other cross-layer synergies in 977 order to improve overall system efficiency. 979 8. Acknowledgements 981 This document is a result of discussions at IETF 63 and 64, as well 982 as on the ipdvb mailing list. Special thanks to the guidance of 983 ipdvb chairman G. Fairhurst, and to all those who, by their 984 curiosity, questions, critics and remarks have made the scientific 985 debate concerning DVB-S2 grow. 987 This draft is intended as a study item for proposed future work by 988 the IETF in this area. Comments relating to this document will be 989 gratefully received by the authors and the ipdvb mailing list at: 990 ipdvb@erg.abdn.ac.uk 992 9. Document History 993 -00 This draft is intended as a study item for proposed future 994 work by the IETF in this area. 995 -01 Draft re-written from scratch. Added a comprehensive glossary 996 and a complete introduction to DVB-S2. 997 -02 Focused the draft on the delivery of IP service over DVB-S2, 998 rather than on a requirements specification. Integrated a 999 converged view of possible fragmentations, and introduced 1000 important axes for future cross-layer optimization of the IP/ 1001 DVB-S2 protocol stack. References updated. 1002 -03 and 04: Minor modifications: withdrawn one author and updated 1003 one reference. 1005 10. References 1007 10.1. Normative References 1009 [1] "EN 302 307, Digital Video Broadcasting (DVB); Second generation 1010 framing structure, channel coding and modulation systems for 1011 Broadcasting, Interactive Services, News Gathering and other 1012 broadband satellite applications. European Telecommunications 1013 Standards Institute (ETSI)". 1015 [2] "EN 301 421, Digital Video Broadcasting (DVB); Modulation and 1016 Coding for DBS satellite systems at 11/12 GHz, European 1017 Telecommunications Standards Institute (ETSI)". 1019 [3] "ISO/IEC DIS 13818-1: Information Technology; Generic Coding of 1020 Moving Pictures and Associated Audio information: Systems, 1021 International Standards Organisation (ISO)". 1023 [4] Fairhurst, G. and B. Collini-Nocker, "Unidirectional Lightweight 1024 Encapsulation (ULE) for transmission of IP datagrams over an 1025 MPEG-2 Transport Stream", RFC 4326, December 2005. 1027 10.2. Informative References 1029 [5] "EN 301 192 Specifications for Data Broadcasting, European 1030 Telecommunications Standards Institute (ETSI)". 1032 [6] Karn, P., Borman, C., Fairhurst, G., Grossman, D., Ludwig, R., 1033 Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice 1034 for Internet Subnetwork Designers", RFC 3819. 1036 [7] Montpetit, M., Fairhurst, G., Clausen, H., and H. Linder, "A 1037 Framework for Transmission of IP Datagrams over MPEG-2 1038 Networks", RFC 4259, November 2005. 1040 [8] "EN 301 790, Digital Video Broadcasting (DVB); Interaction 1041 Channel for Satellite Distribution Systems. European 1042 Telecommunications Standards Institute (ETSI)". 1044 [9] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial 1045 Links", RFC 1144. 1047 [10] Degermark, M., Nordgren, B., and S. Pink, "IP Header 1048 Compression", RFC 2507. 1050 [11] Bormann et al., C., "RObust Header Compression (ROHC): 1051 Framework and four profiles: RTP, UDP ESP and uncompressed", 1052 RFC 3095. 1054 [12] Kent, S. and R. Atkinson, "Security Architecture for the 1055 Internet Protocol", RFC 2401. 1057 [13] Shannon, C., "A Mathematical Theory of Information", 1948. 1059 [14] Cantillo, J., Lacan, J., and I. Buret, "Cross-layer enhancement 1060 of error control techniques for adaptation layers of DVB 1061 satellites", International Journal of Satellite Communications 1062 and Networking, special issue on Cross-Layer Protocols for 1063 Satellite Communication Networks, Volume 24, Issue 6, Pages 1064 579-590, November/December 2006. 1066 Authors' Addresses 1068 Juan Cantillo 1069 ENSICA/TESA/Alcatel Alenia Space 1070 1, place Emile Blouin 1071 Toulouse 31056 1072 France 1074 Email: juan.cantillo@ensica.fr 1075 URI: http://dmi.ensica.fr/auteur.php3?id_auteur=61 1077 Jerome Lacan 1078 ENSICA/LAAS-CNRS 1079 1, place Emile Blouin 1080 Toulouse 31056 1081 France 1083 Email: jerome.lacan@ensica.fr 1084 URI: http://dmi.ensica.fr/auteur.php3?id_auteur=5 1086 Intellectual Property Statement 1088 The IETF takes no position regarding the validity or scope of any 1089 Intellectual Property Rights or other rights that might be claimed to 1090 pertain to the implementation or use of the technology described in 1091 this document or the extent to which any license under such rights 1092 might or might not be available; nor does it represent that it has 1093 made any independent effort to identify any such rights. Information 1094 on the procedures with respect to rights in RFC documents can be 1095 found in BCP 78 and BCP 79. 1097 Copies of IPR disclosures made to the IETF Secretariat and any 1098 assurances of licenses to be made available, or the result of an 1099 attempt made to obtain a general license or permission for the use of 1100 such proprietary rights by implementers or users of this 1101 specification can be obtained from the IETF on-line IPR repository at 1102 http://www.ietf.org/ipr. 1104 The IETF invites any interested party to bring to its attention any 1105 copyrights, patents or patent applications, or other proprietary 1106 rights that may cover technology that may be required to implement 1107 this standard. Please address the information to the IETF at 1108 ietf-ipr@ietf.org. 1110 Disclaimer of Validity 1112 This document and the information contained herein are provided on an 1113 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1114 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1115 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1116 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1117 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1118 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1120 Copyright Statement 1122 Copyright (C) The Internet Society (2006). This document is subject 1123 to the rights, licenses and restrictions contained in BCP 78, and 1124 except as set forth therein, the authors retain all their rights. 1126 Acknowledgment 1128 Funding for the RFC Editor function is currently provided by the 1129 Internet Society.