idnits 2.17.1 draft-cantillo-ipdvb-s2encaps-01.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 820. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 797. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 804. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 810. ** 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 711 has weird spacing: '...ing and modul...' == Line 720 has weird spacing: '...rmation techn...' -- 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 (September 20, 2005) is 6790 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' Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 10 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: March 24, 2006 J. Lacan 5 ENSICA/LAAS-CNRS 6 S. Combes 7 Alcatel Alenia Space 8 September 20, 2005 10 draft-cantillo-ipdvb-s2encaps-01 11 Requirements for Transmission of IP Datagrams over DVB-S2 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on March 24, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 This document describes a framework for the transport of IP datagrams 45 over DVB-S2, the second generation standard for Digital Video 46 Broadcast over Satellite. The new standard features an improved and 47 adaptive physical layer, as well as a new framing structure at link 48 level, the Generic Streams. Combined use of adaptability and Generic 49 Streams is expected to offer throughputs never achieved for IP 50 services up to now, but no standard way to carry IP data using the 51 specific features of DVB-S2 has been defined yet. The present 52 document analyzes these issues, and it identifies the requirements 53 for the definition of a standard interface between the DVB-S2 link 54 layer and an IP subnetwork. 56 Document history 58 -v00 Original document presented at IETF-63 60 -v01 Re-written version following IETF-63 discussions. 2 Figures 61 and a glossary added. 63 This draft is intended as a study item for proposed future work by 64 the IETF in this area. Comments relating to this document will be 65 gratefully received by the authors and the ip-dvb mailing list at: 66 ip-dvb@erg.abdn.ac.uk 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Conventions Used in This Document . . . . . . . . . . . . . . 5 72 3. DVB-S2 Architecture . . . . . . . . . . . . . . . . . . . . . 7 73 3.1. General Architecture . . . . . . . . . . . . . . . . . . . 7 74 3.1.1. Functional Blocks and Framing Overview . . . . . . . . 7 75 3.1.2. BBHEADER Fields . . . . . . . . . . . . . . . . . . . 9 76 3.2. DVB-S2 Logical Channels . . . . . . . . . . . . . . . . . 10 77 3.3. Transmission Networks Supported in DVB-S2 . . . . . . . . 11 78 3.4. Protocols to be Supported over DVB-S2 . . . . . . . . . . 11 79 4. Motivations for a New Approach . . . . . . . . . . . . . . . . 11 80 4.1. ACM and DVB-S2 Framing . . . . . . . . . . . . . . . . . . 11 81 4.2. IP over Generic Streams . . . . . . . . . . . . . . . . . 12 82 5. General Framework Requirements . . . . . . . . . . . . . . . . 12 83 5.1. Use of Existing Encapsulation Capabilities . . . . . . . . 13 84 5.2. Adaptive Packing and Scheduling Optimization . . . . . . . 13 85 5.3. Next Level Protocol Type . . . . . . . . . . . . . . . . . 14 86 5.4. Precise Payload Unit Delineation and Reassembly . . . . . 14 87 5.5. Integrity Check . . . . . . . . . . . . . . . . . . . . . 15 88 5.6. Link Layer Addressing Capabilities . . . . . . . . . . . . 15 89 5.7. Flexibility for Future Extension . . . . . . . . . . . . . 16 90 5.8. Security Considerations . . . . . . . . . . . . . . . . . 16 91 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 92 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 93 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 94 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 95 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 97 Intellectual Property and Copyright Statements . . . . . . . . . . 20 99 1. Introduction 101 DVB-S2, the second generation architecture of Digital Video Broadcast 102 over Satellite links was recently specified by standards published by 103 the European Telecommunications Standards Institute (ETSI) [1]. This 104 architecture is designed for broadband satellite applications such as 105 digital television or radio, as well as interactive services such as 106 Internet access or content distribution. 108 Compared to its predecessor DVB-S [2], DVB-S2 features two main 109 enhancements. First, higher order modulations and stronger FEC are 110 teamed up with return channels to achieve real-time adaptability to 111 the link and propagation conditions. This novelty called Adaptive 112 Coding and Modulation (ACM) might allow for an enhanced throughput by 113 30% to 150%, which explains in part the genuine interest for this new 114 standard. DVB-S2 supports also Variable Coding and Modulation and of 115 course, Constant Coding and Modulation (CCM) modes. 117 Second, DVB-S2 offers a new link-layer framing structure called 118 Generic Streams (GS) in addition to the classical packetized 119 Transport Streams (TS). GS can be packetized or continuous, and are 120 intended to address the non-native way in which IP services are 121 carried today over MPEG2-TS using the Multi Protocol Encapsulation 122 (MPE) [4] or the Unidirectional Lightweight Encapsulation (ULE) [5]. 123 Indeed, MPEG2-TS constraints such as constant bit-rate and constant 124 end-to-end delay are not a must for IP services, which added to the 125 accumulation of multiple overheads undermine IP carriage efficiency. 126 Since the use of TS is no longer mandatory in DVB-S2 for carrying IP 127 data, IP over GS seems to offer new possibilities for satellite-based 128 IP networks. 130 Up to now, there is no standard procedure to carry IP datagrams over 131 Generic Streams. In order to take advantage of the new facilities 132 provided by DVB-S2, the previously mentioned solutions to encapsulate 133 IP over DVB-S should be adapted or new solutions should be proposed. 134 The key goals are to reduce complexity when using the system while 135 improving performance, increasing flexibility for IP services and 136 providing opportunities for better integration of IP-based networks. 138 This document presents the requirements for the transport of IP 139 datagrams over DVB-S2, using the specific features of DVB-S2. The 140 proposed framework should minimize overhead and be simple enough to 141 reduce processing while ensuring adequate network services, as well 142 as be robust to errors and security threats while providing enough 143 flexibility for future extension. The general guidelines for this 144 document are those exposed in RFC 3819 [6] and RFC XARCHX [7]. 146 2. Conventions Used in This Document 148 ACM: Adaptive Coding and Modulation. Dynamic adjustment of 149 transmission parameters (FEC coding rate and modulation scheme) on a 150 BBFRAME-by-BBFRAME and Receiver-per-Receiver basis, according to link 151 and propagation conditions. In order to implement ACM, feedback from 152 each Receiver has to be provided by a return channel such as DVB-RCS 153 [8]. 155 b: bit. For example, one byte consists of 8b. 157 B: Byte. Groups of bytes are represented in Internet byte order. 159 BBFRAME: Main framing unit of the DVB-S2 protocol stack, consisting 160 of a 10B BBHEADER, a variable size DATAFIELD and Padding (when 161 necessary). It may carry either Generic Streams (GS) or Transport 162 Streams (TS). 164 BBHEADER: 10B header of a BBFRAME. 166 CCM: Constant Coding and Modulation. In CCM transmission mode, the 167 system uses a single type of pre-defined waveform for every Receiver. 168 DVB-S is a CCM system. 170 DATAFIELD: Payload transported by each BBFRAME. Its maximum size 171 determines the length of the BBFRAME that contains it. For a given 172 Receiver, this maximum size is allowed dynamically on a BBFRAME-by- 173 BBFRAME basis among 21 possible sizes (ranging from 372B to 7264B) by 174 the VCM/ACM command. Each size is related to the FEC coding rate to 175 be used for encoding each particular BBFRAME. Lower BBFRAME sizes 176 are used when low coding rates (i.e. stronger protection against 177 channel errors) are needed, whereas longer sizes (i.e higher coding 178 rates) are used under good channel conditions. 180 DFL: One of the BBHEADER fields. Length in bits of the DATAFIELD. 182 DVB-S2: Second Generation of the Digital Video Broadcast for 183 Satellite applications standard [1]. A framework and set of 184 associated standards published by the European Telecommunications 185 standards Institute (ETSI) for the transmission of video, audio, and 186 data, intended to replace DVB-S [2]. 188 FEC: Forward Error Coding. The scheme used in DVB-S2 relies upon the 189 concatenation of Bose-Chaudhuri-Hocquenghem (BCH) and Low Density 190 Parity Check (LDPC) codes. For a given Receiver, its overall coding 191 rate is adjusted on a BBFRAME-by-BBFRAME basis according to the needs 192 specified for each BBFRAME by the VCM/ACM command. 194 FECFRAME: Encoded BBFRAME, as seen at the output of the FEC encoder. 195 FECFRAMEs have only two possible sizes, 2025B and 8100B, no matter 196 the size of the BBFRAME to code. 198 Generic Stream: One of the 2 possible input streams in DVB-S2, the 199 other one being Transport Streams. Generic Streams can be packetized 200 or continuous, and are intended to be used especially for carrying 201 data services such as IP distribution. An example of packetized 202 Generic Stream could be a flow of MPEG2 packets. 204 GS: See Generic Stream. 206 ISI: Input Stream Identifier, second byte of the BBHEADER field when 207 for multiple input streams. It provides a way to separate different 208 BBFRAMEs within a single multiplex, defining logical channels for 209 BBFRAMEs. 211 MPEG2: A set of standards specified by the Motion Picture Experts 212 Group (MPEG), and standardized by the International Standards 213 Organization (ISO) [3]. 215 MODCOD: Information provided by the VCM/ACM command to the BBFRAME 216 assembler, specifying the coding rate (therefore the size of the 217 maximum size of DATAFIELD to be allowed) and the modulation scheme to 218 be used to encode and modulate each BBFRAME. 220 NPA: Network Point of Attachment. Addresses primarily used for 221 station (Receiver) identification within a local network (e.g. IEEE 222 MAC address). An address may identify individual Receivers or groups 223 of Receivers. 225 PID: Packet Identifier [3]. A 13 bit field carried in the header of 226 TS Packets. This is used to identify the TS Logical Channel to which 227 a TS Packet belongs [3]. The TS Packets forming the parts of a Table 228 Section, PES, or other Payload Unit must all carry the same PID 229 value. The all 1s PID value indicates a Null TS Packet introduced to 230 maintain a constant bit rate of a TS Multiplex. There is no required 231 relationship between the PID values used for TS Logical Channels 232 transmitted using different TS Multiplexes. 234 PDU: Protocol Data Unit. Examples of a PDU include Ethernet frames, 235 IPv4 or IPv6 datagrams, and other network packets. 237 PLFRAME: Last framing unit of the Physical Layer of DVB-S2. 239 PLHEADER: Header of a PLFRAME. The PLHEADER contains synchronization 240 information coded over 2b, as well as the MODCOD used for the current 241 frame (5b). Since it has to be demodulated and decoded for every 242 Receiver without a priori knowledge of the carried MODCOD, it 243 features an unique modulation and coding, no matter the payload's 244 MODCOD. 246 Receiver: An equipment that processes the signal from the satellite 247 and performs filtering and forwarding of encapsulated PDUs to the 248 network-layer service (or bridging module when operating at the link 249 layer). 251 Return Channel: A way for end-users to interact with the transmitting 252 Gateway, in order to establish a bi-directional communication. Such 253 technologies can make use of two-way satellite links [8] and/or 254 terestrial links. 256 SAR: Segmentation And Reassembly, generally for encapsulated SNDUs. 258 SNDU: Sub Network Data Unit. A framing entity created on the basis 259 of a network-layer PDU by an adaptation layer protocol, allowing this 260 PDU to travel along a L2 subnetwork. 262 TS: Transport Stream [3], a method of transmission at the MPEG-2 263 level using MPEG2 Packets. 265 UPL: One of the BBHEADER fields. It carries packets lengths in bits, 266 in the case of packetized input streams. 268 VCM: Variable Coding and Modulation. Differentiated optimization of 269 transmission parameters according to the physical characteristics of 270 every Receiver, such as geographical position, size etc. 272 3. DVB-S2 Architecture 274 3.1. General Architecture 276 3.1.1. Functional Blocks and Framing Overview 278 DVB-S2 is organized as a sequence of functional blocks. 280 The Mode Adaptation block processes input data structured either as 281 TS or GS, single or multiple. Input streams are sliced into 282 DATAFIELDs to which a 10B BBHEADER is appended. The maximum length 283 of every DATAFIELD is chosen dynamically among 21 allowed sizes in 284 the range [374B;7264B] by the VCM/ACM command, according to the 285 protection required for everyone of them. Basically the shorter they 286 are, the more space there is for FEC redundancy protection. Actual 287 systems may only implement a subset of those 21 sizes. 289 The Stream Adaptation block may complete every DATAFIELD with Padding 290 in order to match the length of a valid BBFRAME. BBFRAMEs therefore 291 have one of 21 possible pre-defined sizes in the range [384B; 7274B]. 292 This is a major difference with DVB-S, since at this level there are 293 only 188 Byte MPEG2 containers. Note that DATAFIELDs sizes are not 294 multiples of 188B: Transport Streams, as well as Generic Streams, are 295 mapped asynchronously over BBFRAMEs. 297 Adaptive FEC encoding constitutes the third block. A set of coding 298 schemes based on a concatenation of LDPC and BCH codes ensures a very 299 efficient error protection, only 0.7 to 1 dB away from the Shannon 300 limit (DVB-S FEC is around 2.5 dB from that margin). In ACM mode, 301 the ACM command dictates dynamically the coding rate to be used for 302 every BBFRAME in order to provide a Quasi-Error Free (QEF) quality 303 target at the input of the Receiver's DEMUX (roughly equivalent to 304 PER < 1e-7 for a MPEG2 transmission). FEC parity bits are calculated 305 and appended systematically to each BBFRAME in order to provide 306 fixed-length FECFRAMEs of 2025B or 8100B. This implies that shorter 307 BBFRAMEs are completed with more redundancy than long BBFRAMEs, and 308 are therefore more protected. 310 Finally, FECFRAME bits are modulated and raised-cosine filtered, to 311 provide the body of a PLFRAME. 4 different modulations with spectral 312 efficiencies ranging from 2bits/s/Hz to 5 bits/s/Hz are available in 313 DVB-S2. Finally,information about the FEC coding rate and modulation 314 used for every frame (MODCOD) is stored in a PLHEADER and appended to 315 every PLFRAME. Of course, DVB-S2 provides mechanisms to ensure 316 proper reading of every PLHEADER for every Receiver without a priori 317 knowledge of the contained MODCOD, so all PLHEADERs use a pre- 318 determined coding and modulation. The final PLFRAME is finally sent 319 over the RF carrier using classical TDM and/or FDM techniques. 321 --------------------------------- 322 L2 :::| TS or GS |::: 323 --------------------------------- 324 +--------------+ . . 325 D | | . . 326 V | Mode | +-----+-------------------+ 327 B | Adaptation | |BBHDR| DATAFIELD | 328 - | | +-----+-------------------+ 329 S +--------------+ . 10B 0B 336 I +--------------+ . . 337 C | | . . 338 A | Adaptive FEC | +---------------------------------+-------+ 339 L | Encoding | | |Parity | 340 | | +---------------------------------+-------+ 341 L +--------------+ <------- FECFRAME: 2050B or 81000B -------> 342 A +--------------+ . . 343 Y | | . . 344 E | Adaptive | +-----+--+--+--+--+- -+--+--+--+--+ 345 R | Modulation | |PLHDR| | | | | ::::::::::::::: | | | | | 346 |& TDM Framing | +-----+--+--+--+--+- -+--+--+--+--+ 347 +--------------+ <----- PLFRAME: complex modulated symbols ------> 349 Figure 1: DVB-S2 architecture and framing structure overview 351 3.1.2. BBHEADER Fields 353 Several statements made in the following sections will refer to 354 fields present in the 10B BBHEADER, so a very short description of 355 this entity is presented here: 357 +-------------+-------------+-------+-------+-------------+-------+ 358 | MATYPE 2B | UPL 2B |DFL 1B |SYNC 1B| SYNCD 2B | CRC-8 | 359 +-------------+-------------+-------+-------+-------------+-------+ 361 Figure 2: A BBHEADER 363 The first byte of the MATYPE field specifies whether TS or GS are 364 used, and whether they are single or multiple. In the multiple case, 365 the second byte is an "Input Stream Identifier" (ISI). 367 UPL specifies packets lengths in bits, in the case of packetized 368 input streams. As an example, a value of 0x05E0 (188*8 in 369 hexadecimal notation) is characteristic of MPEG2 packets. A value of 370 0x0000 means a continuous GS. 372 DFL specifies the length of the DATAFIELD actually used in bits, in 373 the range [0b; 58112b] (58112 = 7264*8, 7264B being the maximum 374 DATAFIELD length allowed). 376 SYNC stores the synchronisation byte carried by all the packets of a 377 packetized stream, when there is one (e.g. if MPEG2 packets are 378 transported, SYNC=0x47). Since the synchronisation byte is now 379 carried by the BBHEADER, there is no need for every packet to carry 380 it anymore. A CRC-8 calculated for every packet replaces therefore 381 the synchronisation byte in every packet (it will prove useful 382 later). SYNC is not relevant for continuous Generic Streams. 384 SYNCD is the distance in bits, for a packetized stream, from the 385 beginning of the DATAFIELD to the first start of packet contained in 386 this DATAFIELD. Its use is therefore similar to a Payload Pointer, 387 as defined in ULE [5]. SYNCD is not relevant for continuous Generic 388 Streams. 390 Finally, a CRC-8 is calculated from the previous 9B of the BBHEADER. 392 Note that BBHEADER fields natively support Segmentation And 393 Reassembly (SAR) for MPEG2 packets and for any other packetized 394 Generic Streams asynchronously mapped over a BBFRAME flow. Indeed, 395 perfect delineation and reassembly can be achieved by the exclusive 396 use of UPL, DFL and SYNCD. Finally, the CRC-8 stored in the 1B slot 397 liberated by SYNC in every packet provides an end-to-end integrity 398 check, achieving thus an encapsulation that does not produce any 399 overhead at all (except when Padding is necessary). In DVB-S2, a 400 flow of MPEG2 packets can therefore be sent over a packetized Generic 401 Stream using UPL=0x05E0 and SYNC=0x47. 403 3.2. DVB-S2 Logical Channels 405 In the same way the PID field allowed to distinguish TS Logical 406 Channels for MPEG2, the ISI field of every BBHEADER can be used to 407 support logical channels for BBFRAMEs. 409 Up to now there is no standardized signalling associated to ISI (such 410 as tables or reserved values), and further work has to be done in 411 this direction in order to set a complete framework. This includes 412 mapping of upper layer QoS functions, or standards to associate the 413 capabilities of these potential logical channels to upper layer 414 flows. 416 3.3. Transmission Networks Supported in DVB-S2 418 As a successor to DVB-S, some compatibility at least, as well as 419 enhancement of network capabilities are expected for DVB-S2. 420 Transmission networks to be supported by DVB-S2 contain therefore 421 basically those specified in RFC XARCHX [7]. Those are: 423 Uni-directionnal scenarios such as: 424 -Digital radio and TV broadcast 425 -Broadcast networks used by an ISP 426 -Uni-directionnal star IP scenarios 427 -Datacast overlay 429 Bi-directionnal scenarios such as: 430 -Point-to-Point links 431 -Two-way IP networks 433 The growing demand for IP services and the increased availability of 434 return channels are bound to play an important role in the 435 development of the last 2 scenarios in the near future. 437 3.4. Protocols to be Supported over DVB-S2 439 The protocols to be supported over this architecture are basically 440 the same as those specified in RFC XARCHX [7] 441 -IPv4 Unicast datagrams 442 -IPv4 Broadcast datagrams 443 -IPv4 Multicast datagrams 444 -IPv6 Unicast datagrams 445 -IPv6 Multicast datagrams 446 -Datagrams with compressed IPv4/IPv6 headers (e.g. RFC 1114 [9], 447 RFC 2507 [10] and RFC 3095 [11]) 448 -Bridged Ethernet Frames 450 4. Motivations for a New Approach 452 Even though many existing solutions used in DVB-S can be extended or 453 adapted to the new standard, the new features of DVB-S2 raise a 454 number of important and interesting issues worth consideration. 456 4.1. ACM and DVB-S2 Framing 458 Through the use of ACM, the dynamic variations of the RF channel will 459 have a direct impact over the physical waveform to be used for every 460 piece of data to be transmitted. Analysis of MODCOD allocation 461 policies due to channel variations might open field for IP carriage 462 efficiency improvement, and several competing resource allocation 463 algorithms should be tested. 465 On the other hand, BBFRAMEs sizes ranging from 382B to 7274B suggest 466 several full IP packets will be able to fit in a single DATAFIELD. 467 SNDU Segmentation and Reassembly (SAR) will then statistically occur 468 less than in DVB-S, which raises other kind of questions and risks. 469 For example a partially filled and sent BBFRAME will make worse use 470 of the RF resource than a partially filled and sent MPEG2 packet. In 471 contrast, optimal BBFRAME filling should allow optimal resource use 472 as it minimizes redundant overhead. Indeed, available PDU 473 encapsulations such as MPE/MPEG2-TS, ULE/MPEG2-TS or AAL5/ATM were 474 designed for a relatively high probability of SAR use during SNDU 475 processing. The definition of a scheduling algorithm ensuring 476 optimal BBFRAME filling will certainly be a key point for improving 477 IP carriage efficiency. 479 4.2. IP over Generic Streams 481 TS constant end-to-end delay and constant bit-rate are not a must for 482 IP services, and could be overridden if a GS solution were considered 483 for IP carriage. On top of that, the mandatory asynchronous mapping 484 of MPEG2 over the BBFRAMEs directly constitutes a triple drawback 485 from an IP point of view. First, it adds significant complexity and 486 processing to the overall process. Second, the eventual overhead 487 (here, padding) generated by this asynchronous mapping will add to 488 the overall overhead of the IP encapsulation over MPEG2-TS, 489 decreasing global efficiency. Finally, unexpected hardware/software 490 functioning that may affect proper reassembly of fragmented MPEG2 491 packets will directly impact PER at IP level. 493 The use of MPE and recently ULE to convey IP data over MPEG2-TS has 494 contributed over the past years to its wide acceptance as a IP 495 subnetwork technology. However, despite the unquestionable services 496 done by MPEG2-TS in the DVB-S context, the use of GS in a DVB-S2 497 system for conveying IP data seems to offer better perspectives. In 498 order to take full advantage of the handy features of GS and ACM, and 499 stick to the key goals specified in Section 1, new solutions have to 500 be considered. Those should rely on already available proved 501 concepts when possible, but should also innovate where existing 502 mechanisms do not offer a satisfactory solution. 504 5. General Framework Requirements 506 Detailed requirements for transmission of IP datagrams over MPEG2-TS 507 networks have been defined in RFC XARCHX [7]. The present section 508 will therefore focus on the requirements for transmission of IP 509 datagrams over Generic Streams in ACM mode. Note however, as stated 510 in Section 3.1.2, that seen from a BBFRAME, there is no difference 511 between a MPEG2-TS and a packetized Generic Stream with packets of 512 length 188B. Fundamental differences with a TS approach will be 513 pointed out when possible. 515 5.1. Use of Existing Encapsulation Capabilities 517 In the general encapsulation case, PDUs are formatted one by one into 518 SNDUs, by receiving an encapsulation header and an integrity check 519 trailer such as a CRC. The encapsulation header provides delineation 520 information to the Receiver, and the end-to-end integrity check 521 stands as a protection against re-assembly errors. 523 However, MPEG2 packets are encapsulated into BBFRAMEs without the 524 need of additional encapsulation headers, since BBHEADERs provide all 525 the functionalities necessary to delineate and reassemble fragmented 526 packetized streams. BBHEADERs have therefore some inherent 527 encapsulation capabilities, and a future framework intended to 528 standardize an IP over GS interface should take advantage of this 529 handy feature. 531 Of course, IP streams are not composed of fixed-length packets and 532 the above-mentioned encapsulation capabilities of BBHEADERs do not 533 directly apply. However, several concepts used in classical 534 encapsulation headers (e.g. Payload Pointer or Length Field for ULE) 535 could be transposed if IP packets were to be mapped over Generic 536 Streams, using available fields in BBHEADERs (e.g. SYNC and UPL/ 537 DFL). 539 Note finally that among the 10 bytes of BBHEADERs, at least 3 (SYNC 540 and SYNCD) are not relevant for continuous GS. Their re-definition 541 and use in an "IP over continuous GS" context might prove useful as 542 this would allow reducing the header length of a future 543 encapsulation. 545 5.2. Adaptive Packing and Scheduling Optimization 547 In order to ensure optimum use of the available resources, it is 548 required that several SNDUs fit in a BBFRAME addressed to a single 549 NPA. Since BBFRAMEs are considerably longer than classical 550 containers, proper and optimal packing is a key point for achieving 551 an efficient carriage of IP packets over GS. This is a major 552 difference with DVB-S. 554 MODCOD allocation by the ACM command is closely related to this 555 issue, since available DATAFIELD sizes will vary according to the 556 dynamics of the channel. A scheduling algorithm is required to 557 optimize filling and minimize BBFRAME Padding, that may be up to 558 7264B for an empty DATAFIELD. It should provide ways to fragment 559 PDUs and delay them when necessary for the sake of optimal filling, 560 but in the limits of an admissible complexity. Such algorithm should 561 take in account the statistical characteristics of the carried IP 562 traffic, and its functioning should not be independent from the ACM 563 command. It should also provide BBFRAME Padding when necessary (when 564 no PDU is available). 566 5.3. Next Level Protocol Type 568 A key feature of the required encapsulation is to identify the 569 payload type being transported. Such requirement is not specific to 570 DVB-S2: most protocols use a type field to identify a specific 571 process at the next higher layer that is the originator or the 572 recipient of the payload. 574 Given the length of BBFRAMEs, several PDUs will often be packed 575 within the same BBFRAME. In the case where there are PDUs from 576 different protocols (e.g. a mix of IPv4 and IPv6 packets), it is 577 required that every single PDU is labelled with a proper Type field. 578 In another configuration, only homogeneous PDUs could be allowed to 579 be together in a single BBFRAME. In this latter case, a single Type 580 header would be enough for the whole BBFRAME. ISI channels could 581 also be used to differentiate protocol PDU flows in a dynamic or 582 static way. 584 5.4. Precise Payload Unit Delineation and Reassembly 586 Accurate delineation and identification of scattered fragments of 587 packed IP packets must be done by every Receiver. As an example, ULE 588 achieves delineation with the joint use of MPEG2's PUSI, a Payload 589 Pointer and a Length field. 591 Precise PDU delineation is also required for a future encapsulation 592 over Generic Streams. The implemented solution may define a ULE-like 593 header for this, but it may also re-use (partially at least) BBHEADER 594 fields that already provide similar functionalities. It should also 595 be robust to synchronisation losses, for which a Payload Pointer 596 approach could prove desirable. 598 On the other hand, a future encapsulation must provide ways to ensure 599 reassembly of a scattered PDU even in the case that its fragments are 600 not "adjacent" within 2 consecutive BBFRAMEs, which could happen if 601 advanced SNDU scheduling/fragmentation procedures are chosen. In a 602 ULE/MPEG2-TS scenario SNDU fragmentation is done over MPEG2 packets 603 with MPEG2 Continuity Counters differing only by 1 (modulo 16), 604 according to [3]. However, in a DVB-S2 context, the scheduling 605 algorithm may chose to send PDU fragments at different times over the 606 same BBFRAME, or even over non-consecutive BBFRAMEs. Since ULE 607 relies on the MPEG2 Continuity Counter, it cannot be used directly in 608 a GS context. More advanced fragmentation procedures will certainly 609 have to be studied. 611 5.5. Integrity Check 613 For the IP service, the probability of undetected packet error should 614 be small or negligible, as stated in RFC 3819 [6]. There is 615 therefore a need for a strong error control, either provided by FEC 616 or by other means such as CRCs. FEC has been greatly improved in 617 DVB-S2, and it provides means to re-evaluate the way integrity check 618 can be done. The following considerations apply also for packetized 619 streams. 621 The CRC-32 used in ULE relies on the use of a 32-bit redundancy for 622 each SNDU, intended to stand as a protection against reassembly 623 errors following corruption or loss of SNDU carriers, due to 624 transmission errors or unexpected hardware/software operation. 626 Concerning resilient channel errors, DVB-S2 FEC has reduced the 627 probability of such event by several orders of magnitude compared to 628 DVB-S. Indeed, the implemented LDPC and BCH concatenated encoding 629 provide error protection close to the theoretical limits established 630 by Shannon in [12]. On top of that, outer BCH encoding provides a 631 192-bit redundancy protection for each BBFRAME that can be used to 632 detect and discard corrupted BBFRAMEs. DVB-S2 FEC offers therefore 633 the possibility to manage globally the SNDU error-detection problem, 634 done classically on a SNDU-by-SNDU basis with CRCs. 636 As for BBFRAME losses, only PDUs with fragments in lost BBFRAMEs will 637 face reassembly problems. A non-fragmented PDU within a lost BBFRAME 638 will be simply lost, even if it had a CRC. In this context it seems 639 adequate to apply CRC integrity checks to the packets that may suffer 640 SAR. 642 Accurate estimation of PER at IP level with or without CRCs should 643 drive the design decisions concerning this issue, and not legacy 644 considerations based on different or less efficient systems. 646 5.6. Link Layer Addressing Capabilities 648 Individual Receivers are not addressable at a BBFRAME level. 649 MPEG2-TS addressing considerations exposed in RFC XARCHX [7] apply 650 therefore to BBFRAMEs too and should be used as guidelines for future 651 work on this key topic. 653 These considerations imply the use of an optional NPA field appended 654 to every PDU or group of PDUs sharing the same BBFRAME. There are 655 indeed cases where the use of a NPA is required (e.g. when link layer 656 filtering is desired) and if present, it should be carried in a way 657 to allow Receivers to pre-filter and discard unwanted PDUs. There 658 are other cases where an NPA is not required (e.g. when a Receiver is 659 the end host), and network layer filtering may be used. 661 An IP over GS interface should therefore support an optional NPA, as 662 current encapsulations for IP over TS do. The way to integrate it in 663 the BBFRAME is to be analyzed, as well as the interactions and 664 synergies that can be achieved with the use of BBFRAMEs channels 665 defined by ISI. 667 5.7. Flexibility for Future Extension 669 The evolution of the Internet Service may in the future require 670 additional functions. A flexible protocol should therefore provide a 671 way to introduce new features when required, without having to 672 provide additional out-of-band configuration. This is not a 673 difference with TS. 675 5.8. Security Considerations 677 Security considerations are basically the same for GS and TS, and are 678 based on those concerning wireless links, see RFC 3819 [6]. Although 679 an analysis of specific security issues concerning GS is out of the 680 scope of this document, it will provide helpful input for addressing 681 this important topic in future work. 683 6. Summary 685 DVB-S2 physical adaptability and new framing structure motivate a new 686 encapsulation for IP, much more efficient in terms of complexity and 687 overhead than the classical MPEG2-TS approach. 689 For this, some solutions developped for IP/MPEG2 can be simply 690 transposed to DVB-S2, like the use of Type fields or the definition 691 of logical channels. DVB-S2 specificities imply also that new 692 procedures will have to defined from scratch, such as datagram 693 scheduling optimization and advanced fragmentation. Finally, other 694 issues like integrity check management might be re-evaluated in a 695 DVB-S2 context, taking in account the enhanced error-control achieved 696 by the new FEC. 698 Finally, DVB-S2 BBFRAMEs are defined in such a way that BBHEADERs 699 present some inherent encapsulation capabilities. The definition of 700 a new IP over DVB-S2 adaptation layer could take advantage of this 701 handy feature, and open the way for other cross-layer synergies in 702 order to improve overall system efficiency. 704 7. Acknowledgements 706 8. References 708 8.1. Normative References 710 [1] "EN 302 307, Digital Video Broadcasting (DVB); Second generation 711 framing structure, channel coding and modulation systems for 712 Broadcasting, Interactive Services, News Gathering and other 713 broadband satellite applications. European Telecommunications 714 Standards Institute (ETSI)". 716 [2] "EN 301 421, Digital Video Broadcasting (DVB); Modulation and 717 Coding for DBS satellite systems at 11/12 GHz, European 718 Telecommunications Standards Institute (ETSI)". 720 [3] "ISO/IEC DIS 13818-1 Information technology -- Generic 721 coding of moving pictures and associated audio information: 722 Systems, International Standards Organisation (ISO)". 724 8.2. Informative References 726 [4] "EN 301 192 Specifications for Data Broadcasting, European 727 Telecommunications Standards Institute (ETSI)". 729 [5] Fairhurst, G. and B. Collini-Nocker, "Unidirectional 730 Lightweight Encapsulation (ULE) for transmission of IP 731 datagrams over an MPEG-2 Transport Stream, Work in progress", 732 Internet Draft draft-ietf-ipdvb-ule-06.txt, June 2005. 734 [6] Karn, P., Borman, C., Fairhurst, G., Grossman, D., Ludwig, R., 735 Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice 736 for Internet Subnetwork Designers", RFC 3819. 738 [7] Montpetit, M., Fairhurst, G., Clausen, H., and H. Linder, "A 739 Framework for Transmission of IP Datagrams over MPEG-2 740 Networks", RFC XARCHX, currently draft-ietf-ipdvb-arch-04, 741 RFCEd queue, 2005. 743 [8] "EN 301 790, Digital Video Broadcasting (DVB); Interaction 744 Channel for Satellite Distribution Systems. European 745 Telecommunications Standards Institute (ETSI)". 747 [9] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial 748 Links", RFC 1144. 750 [10] Degermark, M., Nordgren, B., and S. Pink, "IP Header 751 Compression", RFC 2507. 753 [11] Bormann et al., C., "RObust Header Compression (ROHC): 754 Framework and four profiles: RTP, UDP ESP and uncompressed", 755 RFC 3095. 757 [12] Shannon, C., "A Mathematical Theory of Information", 1948. 759 Authors' Addresses 761 Juan Cantillo 762 ENSICA/TESA/Alcatel Alenia Space 763 1, place Emile Blouin 764 Toulouse 31056 765 France 767 Email: juan.cantillo@ensica.fr 768 URI: http://dmi.ensica.fr/auteur.php3?id_auteur=61 770 Jerome Lacan 771 ENSICA/LAAS-CNRS 772 1, place Emile Blouin 773 Toulouse 31056 774 France 776 Email: jerome.lacan@ensica.fr 777 URI: http://dmi.ensica.fr/auteur.php3?id_auteur=5 779 Stephane Combes 780 Alcatel Alenia Space 781 26, avenue JF Champollion BP 1187 782 Toulouse Cedex 1 31037 783 France 785 Email: stephane.combes@alcatelaleniaspace.com 786 URI: http://www.alcatel.com/space/ 788 Intellectual Property Statement 790 The IETF takes no position regarding the validity or scope of any 791 Intellectual Property Rights or other rights that might be claimed to 792 pertain to the implementation or use of the technology described in 793 this document or the extent to which any license under such rights 794 might or might not be available; nor does it represent that it has 795 made any independent effort to identify any such rights. Information 796 on the procedures with respect to rights in RFC documents can be 797 found in BCP 78 and BCP 79. 799 Copies of IPR disclosures made to the IETF Secretariat and any 800 assurances of licenses to be made available, or the result of an 801 attempt made to obtain a general license or permission for the use of 802 such proprietary rights by implementers or users of this 803 specification can be obtained from the IETF on-line IPR repository at 804 http://www.ietf.org/ipr. 806 The IETF invites any interested party to bring to its attention any 807 copyrights, patents or patent applications, or other proprietary 808 rights that may cover technology that may be required to implement 809 this standard. Please address the information to the IETF at 810 ietf-ipr@ietf.org. 812 Disclaimer of Validity 814 This document and the information contained herein are provided on an 815 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 816 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 817 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 818 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 819 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 820 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 822 Copyright Statement 824 Copyright (C) The Internet Society (2005). This document is subject 825 to the rights, licenses and restrictions contained in BCP 78, and 826 except as set forth therein, the authors retain all their rights. 828 Acknowledgment 830 Funding for the RFC Editor function is currently provided by the 831 Internet Society.