IPDVB Working Group J. Cantillo
Internet-Draft ENSICA/TESA/Alcatel Alenia Space
Expires: March 24, 2006 J. Lacan
ENSICA/LAAS-CNRS
S. Combes
Alcatel Alenia Space
September 20, 2005
draft-cantillo-ipdvb-s2encaps-01
Requirements for Transmission of IP Datagrams over DVB-S2
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 24, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes a framework for the transport of IP datagrams
over DVB-S2, the second generation standard for Digital Video
Broadcast over Satellite. The new standard features an improved and
adaptive physical layer, as well as a new framing structure at link
level, the Generic Streams. Combined use of adaptability and Generic
Cantillo, et al. Expires March 24, 2006 [Page 1]
Internet-Draft draft-cantillo-ipdvb-s2encaps-01 September 2005
Streams is expected to offer throughputs never achieved for IP
services up to now, but no standard way to carry IP data using the
specific features of DVB-S2 has been defined yet. The present
document analyzes these issues, and it identifies the requirements
for the definition of a standard interface between the DVB-S2 link
layer and an IP subnetwork.
Document history
-v00 Original document presented at IETF-63
-v01 Re-written version following IETF-63 discussions. 2 Figures
and a glossary added.
This draft is intended as a study item for proposed future work by
the IETF in this area. Comments relating to this document will be
gratefully received by the authors and the ip-dvb mailing list at:
ip-dvb@erg.abdn.ac.uk
Cantillo, et al. Expires March 24, 2006 [Page 2]
Internet-Draft draft-cantillo-ipdvb-s2encaps-01 September 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 5
3. DVB-S2 Architecture . . . . . . . . . . . . . . . . . . . . . 7
3.1. General Architecture . . . . . . . . . . . . . . . . . . . 7
3.1.1. Functional Blocks and Framing Overview . . . . . . . . 7
3.1.2. BBHEADER Fields . . . . . . . . . . . . . . . . . . . 9
3.2. DVB-S2 Logical Channels . . . . . . . . . . . . . . . . . 10
3.3. Transmission Networks Supported in DVB-S2 . . . . . . . . 11
3.4. Protocols to be Supported over DVB-S2 . . . . . . . . . . 11
4. Motivations for a New Approach . . . . . . . . . . . . . . . . 11
4.1. ACM and DVB-S2 Framing . . . . . . . . . . . . . . . . . . 11
4.2. IP over Generic Streams . . . . . . . . . . . . . . . . . 12
5. General Framework Requirements . . . . . . . . . . . . . . . . 12
5.1. Use of Existing Encapsulation Capabilities . . . . . . . . 13
5.2. Adaptive Packing and Scheduling Optimization . . . . . . . 13
5.3. Next Level Protocol Type . . . . . . . . . . . . . . . . . 14
5.4. Precise Payload Unit Delineation and Reassembly . . . . . 14
5.5. Integrity Check . . . . . . . . . . . . . . . . . . . . . 15
5.6. Link Layer Addressing Capabilities . . . . . . . . . . . . 15
5.7. Flexibility for Future Extension . . . . . . . . . . . . . 16
5.8. Security Considerations . . . . . . . . . . . . . . . . . 16
6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 20
Cantillo, et al. Expires March 24, 2006 [Page 3]
Internet-Draft draft-cantillo-ipdvb-s2encaps-01 September 2005
1. Introduction
DVB-S2, the second generation architecture of Digital Video Broadcast
over Satellite links was recently specified by standards published by
the European Telecommunications Standards Institute (ETSI) [1]. This
architecture is designed for broadband satellite applications such as
digital television or radio, as well as interactive services such as
Internet access or content distribution.
Compared to its predecessor DVB-S [2], DVB-S2 features two main
enhancements. First, higher order modulations and stronger FEC are
teamed up with return channels to achieve real-time adaptability to
the link and propagation conditions. This novelty called Adaptive
Coding and Modulation (ACM) might allow for an enhanced throughput by
30% to 150%, which explains in part the genuine interest for this new
standard. DVB-S2 supports also Variable Coding and Modulation and of
course, Constant Coding and Modulation (CCM) modes.
Second, DVB-S2 offers a new link-layer framing structure called
Generic Streams (GS) in addition to the classical packetized
Transport Streams (TS). GS can be packetized or continuous, and are
intended to address the non-native way in which IP services are
carried today over MPEG2-TS using the Multi Protocol Encapsulation
(MPE) [4] or the Unidirectional Lightweight Encapsulation (ULE) [5].
Indeed, MPEG2-TS constraints such as constant bit-rate and constant
end-to-end delay are not a must for IP services, which added to the
accumulation of multiple overheads undermine IP carriage efficiency.
Since the use of TS is no longer mandatory in DVB-S2 for carrying IP
data, IP over GS seems to offer new possibilities for satellite-based
IP networks.
Up to now, there is no standard procedure to carry IP datagrams over
Generic Streams. In order to take advantage of the new facilities
provided by DVB-S2, the previously mentioned solutions to encapsulate
IP over DVB-S should be adapted or new solutions should be proposed.
The key goals are to reduce complexity when using the system while
improving performance, increasing flexibility for IP services and
providing opportunities for better integration of IP-based networks.
This document presents the requirements for the transport of IP
datagrams over DVB-S2, using the specific features of DVB-S2. The
proposed framework should minimize overhead and be simple enough to
reduce processing while ensuring adequate network services, as well
as be robust to errors and security threats while providing enough
flexibility for future extension. The general guidelines for this
document are those exposed in RFC 3819 [6] and RFC XARCHX [7].
Cantillo, et al. Expires March 24, 2006 [Page 4]
Internet-Draft draft-cantillo-ipdvb-s2encaps-01 September 2005
2. Conventions Used in This Document
ACM: Adaptive Coding and Modulation. Dynamic adjustment of
transmission parameters (FEC coding rate and modulation scheme) on a
BBFRAME-by-BBFRAME and Receiver-per-Receiver basis, according to link
and propagation conditions. In order to implement ACM, feedback from
each Receiver has to be provided by a return channel such as DVB-RCS
[8].
b: bit. For example, one byte consists of 8b.
B: Byte. Groups of bytes are represented in Internet byte order.
BBFRAME: Main framing unit of the DVB-S2 protocol stack, consisting
of a 10B BBHEADER, a variable size DATAFIELD and Padding (when
necessary). It may carry either Generic Streams (GS) or Transport
Streams (TS).
BBHEADER: 10B header of a BBFRAME.
CCM: Constant Coding and Modulation. In CCM transmission mode, the
system uses a single type of pre-defined waveform for every Receiver.
DVB-S is a CCM system.
DATAFIELD: Payload transported by each BBFRAME. Its maximum size
determines the length of the BBFRAME that contains it. For a given
Receiver, this maximum size is allowed dynamically on a BBFRAME-by-
BBFRAME basis among 21 possible sizes (ranging from 372B to 7264B) by
the VCM/ACM command. Each size is related to the FEC coding rate to
be used for encoding each particular BBFRAME. Lower BBFRAME sizes
are used when low coding rates (i.e. stronger protection against
channel errors) are needed, whereas longer sizes (i.e higher coding
rates) are used under good channel conditions.
DFL: One of the BBHEADER fields. Length in bits of the DATAFIELD.
DVB-S2: Second Generation of the Digital Video Broadcast for
Satellite applications standard [1]. A framework and set of
associated standards published by the European Telecommunications
standards Institute (ETSI) for the transmission of video, audio, and
data, intended to replace DVB-S [2].
FEC: Forward Error Coding. The scheme used in DVB-S2 relies upon the
concatenation of Bose-Chaudhuri-Hocquenghem (BCH) and Low Density
Parity Check (LDPC) codes. For a given Receiver, its overall coding
rate is adjusted on a BBFRAME-by-BBFRAME basis according to the needs
specified for each BBFRAME by the VCM/ACM command.
Cantillo, et al. Expires March 24, 2006 [Page 5]
Internet-Draft draft-cantillo-ipdvb-s2encaps-01 September 2005
FECFRAME: Encoded BBFRAME, as seen at the output of the FEC encoder.
FECFRAMEs have only two possible sizes, 2025B and 8100B, no matter
the size of the BBFRAME to code.
Generic Stream: One of the 2 possible input streams in DVB-S2, the
other one being Transport Streams. Generic Streams can be packetized
or continuous, and are intended to be used especially for carrying
data services such as IP distribution. An example of packetized
Generic Stream could be a flow of MPEG2 packets.
GS: See Generic Stream.
ISI: Input Stream Identifier, second byte of the BBHEADER field when
for multiple input streams. It provides a way to separate different
BBFRAMEs within a single multiplex, defining logical channels for
BBFRAMEs.
MPEG2: A set of standards specified by the Motion Picture Experts
Group (MPEG), and standardized by the International Standards
Organization (ISO) [3].
MODCOD: Information provided by the VCM/ACM command to the BBFRAME
assembler, specifying the coding rate (therefore the size of the
maximum size of DATAFIELD to be allowed) and the modulation scheme to
be used to encode and modulate each BBFRAME.
NPA: Network Point of Attachment. Addresses primarily used for
station (Receiver) identification within a local network (e.g. IEEE
MAC address). An address may identify individual Receivers or groups
of Receivers.
PID: Packet Identifier [3]. A 13 bit field carried in the header of
TS Packets. This is used to identify the TS Logical Channel to which
a TS Packet belongs [3]. The TS Packets forming the parts of a Table
Section, PES, or other Payload Unit must all carry the same PID
value. The all 1s PID value indicates a Null TS Packet introduced to
maintain a constant bit rate of a TS Multiplex. There is no required
relationship between the PID values used for TS Logical Channels
transmitted using different TS Multiplexes.
PDU: Protocol Data Unit. Examples of a PDU include Ethernet frames,
IPv4 or IPv6 datagrams, and other network packets.
PLFRAME: Last framing unit of the Physical Layer of DVB-S2.
PLHEADER: Header of a PLFRAME. The PLHEADER contains synchronization
information coded over 2b, as well as the MODCOD used for the current
frame (5b). Since it has to be demodulated and decoded for every
Cantillo, et al. Expires March 24, 2006 [Page 6]
Internet-Draft draft-cantillo-ipdvb-s2encaps-01 September 2005
Receiver without a priori knowledge of the carried MODCOD, it
features an unique modulation and coding, no matter the payload's
MODCOD.
Receiver: An equipment that processes the signal from the satellite
and performs filtering and forwarding of encapsulated PDUs to the
network-layer service (or bridging module when operating at the link
layer).
Return Channel: A way for end-users to interact with the transmitting
Gateway, in order to establish a bi-directional communication. Such
technologies can make use of two-way satellite links [8] and/or
terestrial links.
SAR: Segmentation And Reassembly, generally for encapsulated SNDUs.
SNDU: Sub Network Data Unit. A framing entity created on the basis
of a network-layer PDU by an adaptation layer protocol, allowing this
PDU to travel along a L2 subnetwork.
TS: Transport Stream [3], a method of transmission at the MPEG-2
level using MPEG2 Packets.
UPL: One of the BBHEADER fields. It carries packets lengths in bits,
in the case of packetized input streams.
VCM: Variable Coding and Modulation. Differentiated optimization of
transmission parameters according to the physical characteristics of
every Receiver, such as geographical position, size etc.
3. DVB-S2 Architecture
3.1. General Architecture
3.1.1. Functional Blocks and Framing Overview
DVB-S2 is organized as a sequence of functional blocks.
The Mode Adaptation block processes input data structured either as
TS or GS, single or multiple. Input streams are sliced into
DATAFIELDs to which a 10B BBHEADER is appended. The maximum length
of every DATAFIELD is chosen dynamically among 21 allowed sizes in
the range [374B;7264B] by the VCM/ACM command, according to the
protection required for everyone of them. Basically the shorter they
are, the more space there is for FEC redundancy protection. Actual
systems may only implement a subset of those 21 sizes.
Cantillo, et al. Expires March 24, 2006 [Page 7]
Internet-Draft draft-cantillo-ipdvb-s2encaps-01 September 2005
The Stream Adaptation block may complete every DATAFIELD with Padding
in order to match the length of a valid BBFRAME. BBFRAMEs therefore
have one of 21 possible pre-defined sizes in the range [384B; 7274B].
This is a major difference with DVB-S, since at this level there are
only 188 Byte MPEG2 containers. Note that DATAFIELDs sizes are not
multiples of 188B: Transport Streams, as well as Generic Streams, are
mapped asynchronously over BBFRAMEs.
Adaptive FEC encoding constitutes the third block. A set of coding
schemes based on a concatenation of LDPC and BCH codes ensures a very
efficient error protection, only 0.7 to 1 dB away from the Shannon
limit (DVB-S FEC is around 2.5 dB from that margin). In ACM mode,
the ACM command dictates dynamically the coding rate to be used for
every BBFRAME in order to provide a Quasi-Error Free (QEF) quality
target at the input of the Receiver's DEMUX (roughly equivalent to
PER < 1e-7 for a MPEG2 transmission). FEC parity bits are calculated
and appended systematically to each BBFRAME in order to provide
fixed-length FECFRAMEs of 2025B or 8100B. This implies that shorter
BBFRAMEs are completed with more redundancy than long BBFRAMEs, and
are therefore more protected.
Finally, FECFRAME bits are modulated and raised-cosine filtered, to
provide the body of a PLFRAME. 4 different modulations with spectral
efficiencies ranging from 2bits/s/Hz to 5 bits/s/Hz are available in
DVB-S2. Finally,information about the FEC coding rate and modulation
used for every frame (MODCOD) is stored in a PLHEADER and appended to
every PLFRAME. Of course, DVB-S2 provides mechanisms to ensure
proper reading of every PLHEADER for every Receiver without a priori
knowledge of the contained MODCOD, so all PLHEADERs use a pre-
determined coding and modulation. The final PLFRAME is finally sent
over the RF carrier using classical TDM and/or FDM techniques.
Cantillo, et al. Expires March 24, 2006 [Page 8]
Internet-Draft draft-cantillo-ipdvb-s2encaps-01 September 2005
---------------------------------
L2 :::| TS or GS |:::
---------------------------------
+--------------+ . .
D | | . .
V | Mode | +-----+-------------------+
B | Adaptation | |BBHDR| DATAFIELD |
- | | +-----+-------------------+
S +--------------+ . 10B 0B<DFL<7264B .
2 +--------------+ . .
| | . .
P | Stream | +-------------------------+-------+
H | Adaptation | | |Padding|
Y | | +-------------------------+-------+
S +--------------+ <---- BBFRAME: [382B;7274B] ------>
I +--------------+ . .
C | | . .
A | Adaptive FEC | +---------------------------------+-------+
L | Encoding | | |Parity |
| | +---------------------------------+-------+
L +--------------+ <------- FECFRAME: 2050B or 81000B ------->
A +--------------+ . .
Y | | . .
E | Adaptive | +-----+--+--+--+--+- -+--+--+--+--+
R | Modulation | |PLHDR| | | | | ::::::::::::::: | | | | |
|& TDM Framing | +-----+--+--+--+--+- -+--+--+--+--+
+--------------+ <----- PLFRAME: complex modulated symbols ------>
Figure 1: DVB-S2 architecture and framing structure overview
3.1.2. BBHEADER Fields
Several statements made in the following sections will refer to
fields present in the 10B BBHEADER, so a very short description of
this entity is presented here:
+-------------+-------------+-------+-------+-------------+-------+
| MATYPE 2B | UPL 2B |DFL 1B |SYNC 1B| SYNCD 2B | CRC-8 |
+-------------+-------------+-------+-------+-------------+-------+
Figure 2: A BBHEADER
The first byte of the MATYPE field specifies whether TS or GS are
used, and whether they are single or multiple. In the multiple case,
the second byte is an "Input Stream Identifier" (ISI).
Cantillo, et al. Expires March 24, 2006 [Page 9]
Internet-Draft draft-cantillo-ipdvb-s2encaps-01 September 2005
UPL specifies packets lengths in bits, in the case of packetized
input streams. As an example, a value of 0x05E0 (188*8 in
hexadecimal notation) is characteristic of MPEG2 packets. A value of
0x0000 means a continuous GS.
DFL specifies the length of the DATAFIELD actually used in bits, in
the range [0b; 58112b] (58112 = 7264*8, 7264B being the maximum
DATAFIELD length allowed).
SYNC stores the synchronisation byte carried by all the packets of a
packetized stream, when there is one (e.g. if MPEG2 packets are
transported, SYNC=0x47). Since the synchronisation byte is now
carried by the BBHEADER, there is no need for every packet to carry
it anymore. A CRC-8 calculated for every packet replaces therefore
the synchronisation byte in every packet (it will prove useful
later). SYNC is not relevant for continuous Generic Streams.
SYNCD is the distance in bits, for a packetized stream, from the
beginning of the DATAFIELD to the first start of packet contained in
this DATAFIELD. Its use is therefore similar to a Payload Pointer,
as defined in ULE [5]. SYNCD is not relevant for continuous Generic
Streams.
Finally, a CRC-8 is calculated from the previous 9B of the BBHEADER.
Note that BBHEADER fields natively support Segmentation And
Reassembly (SAR) for MPEG2 packets and for any other packetized
Generic Streams asynchronously mapped over a BBFRAME flow. Indeed,
perfect delineation and reassembly can be achieved by the exclusive
use of UPL, DFL and SYNCD. Finally, the CRC-8 stored in the 1B slot
liberated by SYNC in every packet provides an end-to-end integrity
check, achieving thus an encapsulation that does not produce any
overhead at all (except when Padding is necessary). In DVB-S2, a
flow of MPEG2 packets can therefore be sent over a packetized Generic
Stream using UPL=0x05E0 and SYNC=0x47.
3.2. DVB-S2 Logical Channels
In the same way the PID field allowed to distinguish TS Logical
Channels for MPEG2, the ISI field of every BBHEADER can be used to
support logical channels for BBFRAMEs.
Up to now there is no standardized signalling associated to ISI (such
as tables or reserved values), and further work has to be done in
this direction in order to set a complete framework. This includes
mapping of upper layer QoS functions, or standards to associate the
capabilities of these potential logical channels to upper layer
flows.
Cantillo, et al. Expires March 24, 2006 [Page 10]
Internet-Draft draft-cantillo-ipdvb-s2encaps-01 September 2005
3.3. Transmission Networks Supported in DVB-S2
As a successor to DVB-S, some compatibility at least, as well as
enhancement of network capabilities are expected for DVB-S2.
Transmission networks to be supported by DVB-S2 contain therefore
basically those specified in RFC XARCHX [7]. Those are:
Uni-directionnal scenarios such as:
-Digital radio and TV broadcast
-Broadcast networks used by an ISP
-Uni-directionnal star IP scenarios
-Datacast overlay
Bi-directionnal scenarios such as:
-Point-to-Point links
-Two-way IP networks
The growing demand for IP services and the increased availability of
return channels are bound to play an important role in the
development of the last 2 scenarios in the near future.
3.4. Protocols to be Supported over DVB-S2
The protocols to be supported over this architecture are basically
the same as those specified in RFC XARCHX [7]
-IPv4 Unicast datagrams
-IPv4 Broadcast datagrams
-IPv4 Multicast datagrams
-IPv6 Unicast datagrams
-IPv6 Multicast datagrams
-Datagrams with compressed IPv4/IPv6 headers (e.g. RFC 1114 [9],
RFC 2507 [10] and RFC 3095 [11])
-Bridged Ethernet Frames
4. Motivations for a New Approach
Even though many existing solutions used in DVB-S can be extended or
adapted to the new standard, the new features of DVB-S2 raise a
number of important and interesting issues worth consideration.
4.1. ACM and DVB-S2 Framing
Through the use of ACM, the dynamic variations of the RF channel will
have a direct impact over the physical waveform to be used for every
piece of data to be transmitted. Analysis of MODCOD allocation
policies due to channel variations might open field for IP carriage
efficiency improvement, and several competing resource allocation
Cantillo, et al. Expires March 24, 2006 [Page 11]
Internet-Draft draft-cantillo-ipdvb-s2encaps-01 September 2005
algorithms should be tested.
On the other hand, BBFRAMEs sizes ranging from 382B to 7274B suggest
several full IP packets will be able to fit in a single DATAFIELD.
SNDU Segmentation and Reassembly (SAR) will then statistically occur
less than in DVB-S, which raises other kind of questions and risks.
For example a partially filled and sent BBFRAME will make worse use
of the RF resource than a partially filled and sent MPEG2 packet. In
contrast, optimal BBFRAME filling should allow optimal resource use
as it minimizes redundant overhead. Indeed, available PDU
encapsulations such as MPE/MPEG2-TS, ULE/MPEG2-TS or AAL5/ATM were
designed for a relatively high probability of SAR use during SNDU
processing. The definition of a scheduling algorithm ensuring
optimal BBFRAME filling will certainly be a key point for improving
IP carriage efficiency.
4.2. IP over Generic Streams
TS constant end-to-end delay and constant bit-rate are not a must for
IP services, and could be overridden if a GS solution were considered
for IP carriage. On top of that, the mandatory asynchronous mapping
of MPEG2 over the BBFRAMEs directly constitutes a triple drawback
from an IP point of view. First, it adds significant complexity and
processing to the overall process. Second, the eventual overhead
(here, padding) generated by this asynchronous mapping will add to
the overall overhead of the IP encapsulation over MPEG2-TS,
decreasing global efficiency. Finally, unexpected hardware/software
functioning that may affect proper reassembly of fragmented MPEG2
packets will directly impact PER at IP level.
The use of MPE and recently ULE to convey IP data over MPEG2-TS has
contributed over the past years to its wide acceptance as a IP
subnetwork technology. However, despite the unquestionable services
done by MPEG2-TS in the DVB-S context, the use of GS in a DVB-S2
system for conveying IP data seems to offer better perspectives. In
order to take full advantage of the handy features of GS and ACM, and
stick to the key goals specified in Section 1, new solutions have to
be considered. Those should rely on already available proved
concepts when possible, but should also innovate where existing
mechanisms do not offer a satisfactory solution.
5. General Framework Requirements
Detailed requirements for transmission of IP datagrams over MPEG2-TS
networks have been defined in RFC XARCHX [7]. The present section
will therefore focus on the requirements for transmission of IP
datagrams over Generic Streams in ACM mode. Note however, as stated
Cantillo, et al. Expires March 24, 2006 [Page 12]
Internet-Draft draft-cantillo-ipdvb-s2encaps-01 September 2005
in Section 3.1.2, that seen from a BBFRAME, there is no difference
between a MPEG2-TS and a packetized Generic Stream with packets of
length 188B. Fundamental differences with a TS approach will be
pointed out when possible.
5.1. Use of Existing Encapsulation Capabilities
In the general encapsulation case, PDUs are formatted one by one into
SNDUs, by receiving an encapsulation header and an integrity check
trailer such as a CRC. The encapsulation header provides delineation
information to the Receiver, and the end-to-end integrity check
stands as a protection against re-assembly errors.
However, MPEG2 packets are encapsulated into BBFRAMEs without the
need of additional encapsulation headers, since BBHEADERs provide all
the functionalities necessary to delineate and reassemble fragmented
packetized streams. BBHEADERs have therefore some inherent
encapsulation capabilities, and a future framework intended to
standardize an IP over GS interface should take advantage of this
handy feature.
Of course, IP streams are not composed of fixed-length packets and
the above-mentioned encapsulation capabilities of BBHEADERs do not
directly apply. However, several concepts used in classical
encapsulation headers (e.g. Payload Pointer or Length Field for ULE)
could be transposed if IP packets were to be mapped over Generic
Streams, using available fields in BBHEADERs (e.g. SYNC and UPL/
DFL).
Note finally that among the 10 bytes of BBHEADERs, at least 3 (SYNC
and SYNCD) are not relevant for continuous GS. Their re-definition
and use in an "IP over continuous GS" context might prove useful as
this would allow reducing the header length of a future
encapsulation.
5.2. Adaptive Packing and Scheduling Optimization
In order to ensure optimum use of the available resources, it is
required that several SNDUs fit in a BBFRAME addressed to a single
NPA. Since BBFRAMEs are considerably longer than classical
containers, proper and optimal packing is a key point for achieving
an efficient carriage of IP packets over GS. This is a major
difference with DVB-S.
MODCOD allocation by the ACM command is closely related to this
issue, since available DATAFIELD sizes will vary according to the
dynamics of the channel. A scheduling algorithm is required to
optimize filling and minimize BBFRAME Padding, that may be up to
Cantillo, et al. Expires March 24, 2006 [Page 13]
Internet-Draft draft-cantillo-ipdvb-s2encaps-01 September 2005
7264B for an empty DATAFIELD. It should provide ways to fragment
PDUs and delay them when necessary for the sake of optimal filling,
but in the limits of an admissible complexity. Such algorithm should
take in account the statistical characteristics of the carried IP
traffic, and its functioning should not be independent from the ACM
command. It should also provide BBFRAME Padding when necessary (when
no PDU is available).
5.3. Next Level Protocol Type
A key feature of the required encapsulation is to identify the
payload type being transported. Such requirement is not specific to
DVB-S2: most protocols use a type field to identify a specific
process at the next higher layer that is the originator or the
recipient of the payload.
Given the length of BBFRAMEs, several PDUs will often be packed
within the same BBFRAME. In the case where there are PDUs from
different protocols (e.g. a mix of IPv4 and IPv6 packets), it is
required that every single PDU is labelled with a proper Type field.
In another configuration, only homogeneous PDUs could be allowed to
be together in a single BBFRAME. In this latter case, a single Type
header would be enough for the whole BBFRAME. ISI channels could
also be used to differentiate protocol PDU flows in a dynamic or
static way.
5.4. Precise Payload Unit Delineation and Reassembly
Accurate delineation and identification of scattered fragments of
packed IP packets must be done by every Receiver. As an example, ULE
achieves delineation with the joint use of MPEG2's PUSI, a Payload
Pointer and a Length field.
Precise PDU delineation is also required for a future encapsulation
over Generic Streams. The implemented solution may define a ULE-like
header for this, but it may also re-use (partially at least) BBHEADER
fields that already provide similar functionalities. It should also
be robust to synchronisation losses, for which a Payload Pointer
approach could prove desirable.
On the other hand, a future encapsulation must provide ways to ensure
reassembly of a scattered PDU even in the case that its fragments are
not "adjacent" within 2 consecutive BBFRAMEs, which could happen if
advanced SNDU scheduling/fragmentation procedures are chosen. In a
ULE/MPEG2-TS scenario SNDU fragmentation is done over MPEG2 packets
with MPEG2 Continuity Counters differing only by 1 (modulo 16),
according to [3]. However, in a DVB-S2 context, the scheduling
algorithm may chose to send PDU fragments at different times over the
Cantillo, et al. Expires March 24, 2006 [Page 14]
Internet-Draft draft-cantillo-ipdvb-s2encaps-01 September 2005
same BBFRAME, or even over non-consecutive BBFRAMEs. Since ULE
relies on the MPEG2 Continuity Counter, it cannot be used directly in
a GS context. More advanced fragmentation procedures will certainly
have to be studied.
5.5. Integrity Check
For the IP service, the probability of undetected packet error should
be small or negligible, as stated in RFC 3819 [6]. There is
therefore a need for a strong error control, either provided by FEC
or by other means such as CRCs. FEC has been greatly improved in
DVB-S2, and it provides means to re-evaluate the way integrity check
can be done. The following considerations apply also for packetized
streams.
The CRC-32 used in ULE relies on the use of a 32-bit redundancy for
each SNDU, intended to stand as a protection against reassembly
errors following corruption or loss of SNDU carriers, due to
transmission errors or unexpected hardware/software operation.
Concerning resilient channel errors, DVB-S2 FEC has reduced the
probability of such event by several orders of magnitude compared to
DVB-S. Indeed, the implemented LDPC and BCH concatenated encoding
provide error protection close to the theoretical limits established
by Shannon in [12]. On top of that, outer BCH encoding provides a
192-bit redundancy protection for each BBFRAME that can be used to
detect and discard corrupted BBFRAMEs. DVB-S2 FEC offers therefore
the possibility to manage globally the SNDU error-detection problem,
done classically on a SNDU-by-SNDU basis with CRCs.
As for BBFRAME losses, only PDUs with fragments in lost BBFRAMEs will
face reassembly problems. A non-fragmented PDU within a lost BBFRAME
will be simply lost, even if it had a CRC. In this context it seems
adequate to apply CRC integrity checks to the packets that may suffer
SAR.
Accurate estimation of PER at IP level with or without CRCs should
drive the design decisions concerning this issue, and not legacy
considerations based on different or less efficient systems.
5.6. Link Layer Addressing Capabilities
Individual Receivers are not addressable at a BBFRAME level.
MPEG2-TS addressing considerations exposed in RFC XARCHX [7] apply
therefore to BBFRAMEs too and should be used as guidelines for future
work on this key topic.
These considerations imply the use of an optional NPA field appended
Cantillo, et al. Expires March 24, 2006 [Page 15]
Internet-Draft draft-cantillo-ipdvb-s2encaps-01 September 2005
to every PDU or group of PDUs sharing the same BBFRAME. There are
indeed cases where the use of a NPA is required (e.g. when link layer
filtering is desired) and if present, it should be carried in a way
to allow Receivers to pre-filter and discard unwanted PDUs. There
are other cases where an NPA is not required (e.g. when a Receiver is
the end host), and network layer filtering may be used.
An IP over GS interface should therefore support an optional NPA, as
current encapsulations for IP over TS do. The way to integrate it in
the BBFRAME is to be analyzed, as well as the interactions and
synergies that can be achieved with the use of BBFRAMEs channels
defined by ISI.
5.7. Flexibility for Future Extension
The evolution of the Internet Service may in the future require
additional functions. A flexible protocol should therefore provide a
way to introduce new features when required, without having to
provide additional out-of-band configuration. This is not a
difference with TS.
5.8. Security Considerations
Security considerations are basically the same for GS and TS, and are
based on those concerning wireless links, see RFC 3819 [6]. Although
an analysis of specific security issues concerning GS is out of the
scope of this document, it will provide helpful input for addressing
this important topic in future work.
6. Summary
DVB-S2 physical adaptability and new framing structure motivate a new
encapsulation for IP, much more efficient in terms of complexity and
overhead than the classical MPEG2-TS approach.
For this, some solutions developped for IP/MPEG2 can be simply
transposed to DVB-S2, like the use of Type fields or the definition
of logical channels. DVB-S2 specificities imply also that new
procedures will have to defined from scratch, such as datagram
scheduling optimization and advanced fragmentation. Finally, other
issues like integrity check management might be re-evaluated in a
DVB-S2 context, taking in account the enhanced error-control achieved
by the new FEC.
Finally, DVB-S2 BBFRAMEs are defined in such a way that BBHEADERs
present some inherent encapsulation capabilities. The definition of
a new IP over DVB-S2 adaptation layer could take advantage of this
Cantillo, et al. Expires March 24, 2006 [Page 16]
Internet-Draft draft-cantillo-ipdvb-s2encaps-01 September 2005
handy feature, and open the way for other cross-layer synergies in
order to improve overall system efficiency.
7. Acknowledgements
8. References
8.1. Normative References
[1] "EN 302 307, Digital Video Broadcasting (DVB); Second generation
framing structure, channel coding and modulation systems for
Broadcasting, Interactive Services, News Gathering and other
broadband satellite applications. European Telecommunications
Standards Institute (ETSI)".
[2] "EN 301 421, Digital Video Broadcasting (DVB); Modulation and
Coding for DBS satellite systems at 11/12 GHz, European
Telecommunications Standards Institute (ETSI)".
[3] "ISO/IEC DIS 13818-1 Information technology -- Generic
coding of moving pictures and associated audio information:
Systems, International Standards Organisation (ISO)".
8.2. Informative References
[4] "EN 301 192 Specifications for Data Broadcasting, European
Telecommunications Standards Institute (ETSI)".
[5] Fairhurst, G. and B. Collini-Nocker, "Unidirectional
Lightweight Encapsulation (ULE) for transmission of IP
datagrams over an MPEG-2 Transport Stream, Work in progress",
Internet Draft draft-ietf-ipdvb-ule-06.txt, June 2005.
[6] Karn, P., Borman, C., Fairhurst, G., Grossman, D., Ludwig, R.,
Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice
for Internet Subnetwork Designers", RFC 3819.
[7] Montpetit, M., Fairhurst, G., Clausen, H., and H. Linder, "A
Framework for Transmission of IP Datagrams over MPEG-2
Networks", RFC XARCHX, currently draft-ietf-ipdvb-arch-04,
RFCEd queue, 2005.
[8] "EN 301 790, Digital Video Broadcasting (DVB); Interaction
Channel for Satellite Distribution Systems. European
Telecommunications Standards Institute (ETSI)".
Cantillo, et al. Expires March 24, 2006 [Page 17]
Internet-Draft draft-cantillo-ipdvb-s2encaps-01 September 2005
[9] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial
Links", RFC 1144.
[10] Degermark, M., Nordgren, B., and S. Pink, "IP Header
Compression", RFC 2507.
[11] Bormann et al., C., "RObust Header Compression (ROHC):
Framework and four profiles: RTP, UDP ESP and uncompressed",
RFC 3095.
[12] Shannon, C., "A Mathematical Theory of Information", 1948.
Cantillo, et al. Expires March 24, 2006 [Page 18]
Internet-Draft draft-cantillo-ipdvb-s2encaps-01 September 2005
Authors' Addresses
Juan Cantillo
ENSICA/TESA/Alcatel Alenia Space
1, place Emile Blouin
Toulouse 31056
France
Email: juan.cantillo@ensica.fr
URI: http://dmi.ensica.fr/auteur.php3?id_auteur=61
Jerome Lacan
ENSICA/LAAS-CNRS
1, place Emile Blouin
Toulouse 31056
France
Email: jerome.lacan@ensica.fr
URI: http://dmi.ensica.fr/auteur.php3?id_auteur=5
Stephane Combes
Alcatel Alenia Space
26, avenue JF Champollion BP 1187
Toulouse Cedex 1 31037
France
Email: stephane.combes@alcatelaleniaspace.com
URI: http://www.alcatel.com/space/
Cantillo, et al. Expires March 24, 2006 [Page 19]
Internet-Draft draft-cantillo-ipdvb-s2encaps-01 September 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Cantillo, et al. Expires March 24, 2006 [Page 20]