Internet Engineering Task Force Horst D. Clausen
Internet Draft Bernhard Collini-Nocker
Document: draft-clausen-ipdvb-enc-01.txt Hilmar Linder
University of Salzburg, A
Gorry Fairhurst
University of Aberdeen, U.K.
Category: Draft May 2003
Simple Encapsulation for transmission of IP datagrams
over MPEG-2/DVB networks
Status of this Draft
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Document history
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
Abstract
This document contains the Simple Encapsulation, a simple and lean
encapsulation mechanism for the transport of IP Datagrams over ISO
MPEG-2 Transport Streams (TS). The MPEG-2 TS has been widely accepted
not only for providing digital TV services, but also as a subnetwork
technology for building IP networks. One example is the Digital Video
Broadcast (DVB), specified by standards published by the European
Telecommunications Standards Institute (ETSI).
Expires December 2003 [page 1]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB May 2003
Table of Contents
1. Introduction
2. Conventions used in this document
3. Description of method
4. SNDU Format
4.1 Bridged Payload
4.2 IPv4 Encapsulation
4.3 Ipv6
5. Processing at the Encapsulator and Receiver
5.1 Encapsulator processing
5.2 Flushing the bitstream
5.3 Receiver Processing
6. Summary
7. Acknowledgments
8. Security Considerations
9. References
10. Authors' Addresses
11. IANA Considerations
Expires December 2003 [page 2]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB May 2003
1. Introduction
This document describes an encapsulation for transport of IP
datagrams or other network layer packets over ISO MPEG-2 Transport
Streams [ISO-MPEG]. This is suited to services based on MPEG-2, for
example the Digital Video Broadcast (DVB) architecture, the Advanced
Television Systems Committee (ATSC) system [ATSC; ATSC-G], and other
similar MPEG-2 based transmission systems. Such systems typically
provide unidirectional (simplex) physical and link layer standards,
and have been defined for a wide range of physical media (e.g.
Terrestrial TV [ETSI-DVBT; ATSC-PSIP-TC], Satellite TV [ETSI-DVBS;
ATSC-S],Cable Transmission [ETSI-DVBC; ATSC-PSIP-TC]). Bi-
directional (duplex) links may also be established using these
standards (e.g., DVB defines a range of return channel technologies,
including the use of two-way satellite links [ETSI-RCS] and dial-up
modem links [RFC3077]).
The service provided by a MPEG-2 transport multiplex offers a number
of parallel channels, which correspond to logical links (forming the
MPEG Transport Stream (TS)). Each MPEG-2 TS channel is uniquely
identified by the Packet ID (PID) value carried in the header of
fixed length MPEG-2 TS Packets. The PID value is a 13 bit field and,
thus, the number of channels is limited to 8192, some of which are
reserved for transmission of SI tables. Non-reserved TS logical
channels may be use to carry audio [ISO-AUD], video [ISO-VID], IP
datagrams [ISO-DSMCC;ETSI-DAT;ATSC-DAT], or other private data [ISO-
DSMCC;ETSI-DAT; ATSC-DAT].
Data for transmission over the MPEG-2 transport multiplex is passed
to an encapsulator that typically receives PDUs (Ethernet
Frames, IP datagrams or other network layer packets). It formats
each PDU into a series of TS Packets (usually after adding an
encapsulation header), which is sent over a TS logical channel.
In a simple example, one or more TS logical channels are processed
by a MPEG-2 multiplexor resulting in a TS Multiplex. In more complex
examples, the same TS logical channel may be fed to multiple MPEG-2
multiplexors and these may, in turn, feed other MPEG-2 multiplexors
(remultiplexing). In all cases, the final result is a "TS Multiplex"
which is transmitted over the physical bearer towards the receiver.
Expires December 2003 [page 3]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB May 2003
2. Conventions used in this document
ADAPTATION FIELD: An optional variable-length extension field of the
fixed-length TS Packet header, intended to convey clock references
and timing and synchronization information as well as stuffing over
an MPEG-2 multiplex [ISO-MPEG].
AFC: Adaptation Field Control.
ATSC: Advanced Television Systems Committee [ATSC]. A set of
framework and associated standards for the transmission of video,
audio, and data, using the ISO MPEG-2 standard.
CA: DVB Conditional Access encryption and key management scheme.
DSM-CC: Digital Storage Management Command and Control [ISO-DSMCC].
A formatting defined by the ISO MPEG-2 standard, which is carried in
an MPEG-2 private section.
DVB: Digital Video Broadcast [ETSI-DVB]. A set of framework and
associated standards for the transmission of video, audio, and data,
using the ISO MPEG-2 standard.
ENCAPSULATOR: A network device which receives PDUs (Ethernet frames
or IP datagrams) and formats these for output as a transport stream
of TS Packets.
FORWARD DIRECTION: The dominant direction of data transfer over a
network path. Data transfer in the forward direction is called
"forward transfer". Packets travelling in the forward direction
follow the forward path through the IP network.
MAC: Medium Access and Control of the Ethernet IEEE 802 standard of
protocols.
MPE: Multiprotocol Encapsulation [ETSI-DAT]. A scheme that
encapsulates Ethernet frames or IP Datagrams, creating a
DSM-CC Section. The Section will be sent in a series of TS Packets
over a TS logical channel.
MPEG-2: A set of standards specified by the Motion Picture Experts
Group (MPEG), and standardized by the International Standards
Organisation (ISO) [ISO-MPEG].
PES: Programme Elementary Scheme of MPEG-2 [ISO-MPEG].
PID: Packet Identifier. A field carried in the header of all MPEG-2
Transport Stream packets. This is used to identify the TS logical
channel to which it belongs [ISO-MPEG].
PUSI: Payload_Unit_Start_Indicator of MPEG-2 [ISO-MPEG]. A PUSI
value of zero indicates that the TS Packet does not carry the start
Expires December 2003 [page 4]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB May 2003
of a new payload. In this document, a PUSI value of one indicates
that the TS Packet does carry the start of a new payload.
REVERSE DIRECTION: The direction in which feedback control messages
generally flow (e.g. acknowledgments of a forward TCP transfer
flow). Data transfer could also happen in this direction (and it is
termed "reverse transfer").
PRIVATE SECTION: a syntactic structure used for mapping all service
information (e.g. an SI table) into TS Packets. A table may be
divided into a number of sections. All sections of a table must be
carried over a single TS logical channel.
SI TABLE: Service Information Table. In this document, the term is
used to describe any table used to convey information about the
service carried in a TS Multiplex (e.g. [ISO-MPEG]). SI tables are
carried in MPEG-2 private sections.
SNDU: Subnetwork Data Unit, an IPv4 or IPv6 datagram (or other
subnetwork packet, e.g., an arp message or bridged Ethernet frame).
TS: Transport Stream [ISO-MPEG], a method of transmission at the
MPEG-2 level using TS Packets; it represents level 2 of the ISO/OSI
reference model. See also TS logical channel and TS Multiplex.
TS LOGICAL CHANNEL: a channel identified at the MPEG-2 level; it
represents level 2 of the ISO/OSI reference model. All packets sent
over a channel carry the same PID value
TS MULTIPLEX: A set of MPEG-2 transport stream channels sent over a
single common physical link (i.e. a transmission at a specified
symbol rate, FEC setting, and transmission frequency).
TS PACKET: A fixed-length 188B unit of data sent over an MPEG-2
multiplex [ISO-MPEG]; it corresponds to the cells, of e.g. ATM
networks, and is frequently also referred to as a TS_cell. Each TS
Packet carries a 4B header, plus optional overhead including an
adaptation field, encryption details and time stamp information to
synchronise a set of Transport Streams.
Expires December 2003 [page 5]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB May 2003
3. Description of method
Routed IP packets and bridged Ethernet frames shall be encapsulated
to form a Subnetwork Data Unit (SNDU). The method encapsulates IP
packets, Ethernet frames or packets from other network protocols
within a SNDU. The SNDU transmitted over an MPEG-2 transmission
system, by placing it in the payload of a single TS Packet, or, if
required, the SNDU may be fragmented into a series of TS Packets.
Where there is sufficient space, the method allows a single TS
Packet to carry more than one SNDU (or part there of).
All packets from a SNDU shall be assigned the same PID, and shall
therefore form a part of the same logical TS channel.
The method relies upon use of two fields present in the 4 byte
header of each TS Packet. The use of these values is intended to be
compatible with their use for video, audio, and other streams as
specified by MPEG-2 [ISO-MPEG].
The header of each TS Packet carries a one bit Payload Unit Start
Indicator (PUSI) field whose semantics is defined for PES and PSI
packets; for private data its use is not defined in the MPEG-2
standard [The meaning of this bit for Transport Stream packets
carrying only private data is not defined in this Specification].
In analogy with the use for PES and Section packets this bit is used
to identify the start of a payload unit within the MPEG-2 TS Packet
Payload. Hence, when used with this encapsulation, the following
PUSI values are defined:
0 - the TS Packet does not contain the start of a SNDU but the
continuation or end of a SNDU;
1 - the TS Packet contains the start of a SNDU.
The TS Packet Header also carries a two bit Adaptation Field Control
(AFC) value. The values of these two bits (adaptation field present
and data present) are defined by the standard 13818-1 as follows:
00 - Reserved for future use by ISO/IEC
01 - No adaptation_field, payload only
10 - Adaptation_field only, no payload
11 - Adaptation_field followed by payload
The usage of the adaptation field is being specified and supported
both by PES and Section encapsulation. It maintains a 4-byte
alignment of the MPEG-2 TS Packet Payload. SNDUs can be encapsulated
both in PES private streams, private Sections, and TS private
streams with the same semantics.
Expires December 2003 [page 6]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB May 2003
Standard decoders shall discard TS Packets with the
adaptation_field_control field set to a value of '00'; in the case
of a null packet the value of the adaptation_field_control shall be
set to '01'. The purpose of the adaptation field is primarily to
carry timing and synchronisation information and occasionally to
include stuffing bytes.
For the sender, the AFC MUST be assigned in the following way:
00 - Reserved for future use
01 - No adaptation field - only SNDU data is
contained in the payload field of the TS Packet
10 - Adaptation field only - currently not used for carrying
SNDU data
11 - Adaptation field followed by payload - the TS Packet
contains an adaptation field followed by SNDU data
00, and 10, MUST NOT be used for transport of an encapsulated SNDU.
The combinations 01 and 11 are obviously available for carrying SNDU
data, the 10 pattern indicates an extended adaptation field, but for
private data it is not specified how this field might be used. Hence
the pattern 10 might be used in the future for carrying differently
encapsulated datagrams. The 11 pattern is used to signal the start
of an SNDU that does not directly start after the Transport Stream
header.
In TS private streams, one could define the use of PUSI, AFC, and
adaptation field as appropriate. Such an encapsulation method
differs from that described here, since it is then limited to TS
private streams only.
Expires December 2003 [page 7]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB May 2003
4. SNDU Format
The encapsulation format to be used for IP packets and bridged
Ethernet frames is shown below:
+---------------------------------------------------+--------+
| length | type | SNDU field | CRC-32 |
+---------------------------------------------------+--------+
Figure 1: SNDU Encapsulation
Note that the SNDU field might include a Òlabel or some other form
of discriminator field, which in combination with the PID value,
could be interpreted as a ÒLink-Level address.
Length Field
A 16-bit value indicates the length in bytes of the SNDU
(encapsulated Ethernet frame, IP datagram or other packet) counted
from the byte following the type field up to and including the CRC.
The special value 0x0000 indicates that there are no further SNDUs
within the current TS packet (see section 5.1). The maximum value is
65531 bytes.
Type Field
The 16-bit type field indicates the type of payload being sent.
Three types are suggested in this document. These are:
0x0800 : IPv4 Payload (according to IANA EtherTypes)
0x86DD : IPv6 Payload (according to IANA EtherTypes)
0x8847 : MPLS frame (according to IANA EtherTypes)
0x????: ROHC Compressed IPv4 Packet
0x????: ROHC Compressed IPv6 Packet
0x6558: Bridged Ethernet Frame (i.e. MAC header follows)
All other assignments should be coordinated with the values defined
for IANA EtherTypes encapsulations.
[AuthorsÌ note: suitable values for bridged Ethernet Frames to be
determined; suitable values for ROHC types to be determined]
IPv4 SNDU
The payload shall be a complete IPv4 datagram.
IPv6 SNDU
The payload shall be a complete IPv6 datagram.
Bridged SNDU
The payload shall be a bridged MAC frame (see section 4.1).
CRC
Expires December 2003 [page 8]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB May 2003
The CRC field carries a CRC value calculated by the encapsulator and
checked by the receiver this protects the entire SNDU. A CRC-32 is
recommended for SNDUs up to 12 KB in size. The primary purpose of
this CRC is to protect an IP payload from undetected resassembly
errors and errors introduced by unexpected software / hardware
operation at the IP encapsulation gateway and/or the receiver. It
may also be used to detect the presence of uncorrected errors from
the physical link (these however may, in some case, also be detected
by other means).
4.1 Bridged Payload
The Bridged Payload shall carry an SNDU field with the following
format shown in figure 2.
+-------------------------------+
| Length and Type fields (4B) |
+-------------------------------+
| MAC destination address (6B) |
+-------------------------------+
| MAC source address (6B) |
+-------------------------------+
| Ethernet (DIX) Type (2B) |
+-------------------------------+
| |
| (remainder of MAC frame) |
| |
+-------------------------------+
| CRC_32 (4B) |
+-------------------------------+
Figure 2: SNDU Format for a Bridged Payload
The MAC addresses shall be assigned according to the rules specified
by the IEEE and may denote unknown, unicast, broadcast, and
multicast link addresses. The type of frame shall be defined
according to Ethernet [DIX]. Note that Òarp messages relate to the
binding of MAC addresses to IP addresses are carried in this format
and are identified by the appropriate DIX Ethernet frame type.
In normal operation, it is expected that any padding appended to the
Ethernet frame will be removed prior to forwarding. This requires the
sender to be aware of such padding.
32-bit CRC
The LAN FCS field, is in this case not forwarded by the
encapsulation, and is replaced by a CRC-32 calculated by the IP
encapsulator. Note: It is assumed the LAN FCS is checked prior to
removal.
4.2 IPv4 Encapsulation
Expires December 2003 [page 9]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB May 2003
IPv4 datagrams will be transported over the MPEG-2 Transport Stream
using the SNDU structure shown in figure 3.
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Length (2B) | Type = 0x0800 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
| IPv4 datagram |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| (CRC_32) |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 3: SNDU Format for an IPv4 Datagram
4.3 IPv6 Encapsulation
IPv6 datagrams will be transported over the MPEG-2 Transport Stream
using the SNDU structure shown in figure 4.
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Length (2B) | Type = 0x86DD |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
| IPv6 datagram |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| (CRC_32) |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 4: SNDU Format for an IPv6 Datagram
Expires December 2003 [page 10]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB May 2003
5. Processing at the Encapsulator and Receiver
5.1 Encapsulator processing
The encapsulator shall fragment the SNDU into a series of MPEG-2 TS
Packets belonging to the same logical TS channel (figure 5).
+-----------------------------------------+
|Encap Header| Subnetwork PU |
+-----------------------------------------+
/ / \ \
/ / \ \
/ / \ \
+------*----------* +------*----------* +------*----------+
|MPEG-2| MPEG-2 |..|MPEG-2| MPEG-2 |...|MPEG-2| MPEG-2 |
|Header| Payload | |Header| Payload | |Header| Payload |
+------+----------+ +------+----------+ +------+----------+
Figure 5: Encapsulation of a subnetwork Payload_Unit (SNDU) e.g. an
IP datagram into a series of TS Packets (each TS Packet carries a
header with a common Packet ID, PID, value).
The encapsulation layer will first wrap each payload unit (IP
datagram or Ethernet frame) to form a SNDU. (This is similar to an
AAL5 encapsulation in ATM networks). This SNDU will then be
segmented into payload units of TS Packets; the resulting set of TS
Packets will all use the same PID value and successive values for
the continuation counter. This set will then be sent as a sequence
over a TS multiplex or possibly as one burst over a satellite link.
Measurements of IP traffic have shown that the overwhelming majority
of the datagrams have lengths of 1500 or 576 bytes for data and 40
or 48 bytes for control traffic; for example, these values represent
almost 96% of the typical world-wide-web traffic.
The most frequent situations for the encapsulator are:
- a short control packet using only a fraction of the
TS payload of 184 bytes;
- a long data packet using a number of TS Packets with
the last one containing only a remainder.
Both of the most frequent values (576 and 1500) lead
to a fairly high overhead in the last TS Packet.
Since satellite bandwidth is an expensive resource, as opposed to
bandwidth in LANs, it is necessary to look for improvements. One
possibility is header compression but this is outside the scope of
this proposal. Another one is to pack SNDUs densely into TS Packets,
i.e. whenever the encapsulator has more than one SNDU available it
fills the TS Packets completely by appending the data of the
following SNDU directly to the preceding one before segmentation.
Expires December 2003 [page 11]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB May 2003
When the encapsulator has not previously sent a TS Packet for the
specified logical TS channel, or after an idle period, it will start
sending the SNDU in the first available TS Packet. This first TS
Packet MUST carry a value of one in the payload_unit_start_indicator
(PUSI) to indicate it contains the start of a SNDU.
The encapsulator will continue to fill subsequent TS Packets, until
the end of the SNDU.
The TS Packet that carries the last byte of the SNDU MUST carry an
adaptation field. This implies that the last packet contains an
MPEG-2 adaptation field. Note that a packet sufficiently small to
fit into one TS Packet will carry both a PUSI value of one and an
AFC value of 11 (see below).
If more packets are waiting at the encapsulator, it may start the
next SNDU in the next available byte of the TS Packet payload. (The
PUSI is set, if it is not already set). If this is the final packet
of a burst (i.e., there are no additional packets waiting), the
encapsulator becomes idle.
The adaptation field is either a single byte set to 0 (defined by
the 13818-1 standard) or it has the structure specified by the
standard recommendations (figure 6).
0 7 8 15 16 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ad.hdr.length=3| flags 1 | priv.length=1 | pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
^
transport_private_data_flag
Figure 6: Adaptation FIELD Format
For this encapsulation the adaptation header length is always 4
bytes, hence the value of the first byte must be 3. The second byte
is required by the standard and contains various flags; only bit 7
(Òtransport_private_data_flag) will be set to
1Ì indicating
private data. This requires in the next byte the length of the
private data, here the value of 1, and in the next byte the private
data which is to be a pointer to the start of the next SNDU or the
value of zero in case no further SNDU follows in this TS Packet.
Adding 4 bytes instead of the required one or two bytes adds
overhead but does not destroy the 16/32 bit alignment of the data
which may be important for performance.
The type field of the encapsulation format together with the
transport_private_data_flag in the adaptation field can be used to
construct an encapsulation that supports MPLS switching (e.g. type
field must be set to 0x8847 (see section 4),
transport_private_data_flag set to 1 and the private length byte in
Expires December 2003 [page 12]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB May 2003
the adaptation field specifies the length of a MPLS header (a value
of 5 which means that the adaptation field contains an MPLS header
followed by a one byte pointer field).
The operation of the Adaptation Field Control (AFC) bits and the
PUSI bits in the TS Packet Header may be summarised as follows:
PUSI AFC Meaning
1 01 first byte of a SNDU payload_unit is in the payload
of this TS Packet
0 01 payload of this TS Packet does not contain the start
of a new payload_unit, but is a continuation
0 11 this TS Packet contains the end of a payload_unit
1 11 this TS Packet contains the end of a payload_unit which
is followed by the first byte of a new payload_unit
The use of the AFC bits is mandatory for the operation of the
receiver to find the beginning of an SNDU in two cases when a SNDU
starts not right after the TS packet header although the PUSI flag
is set (indicating a new SNDU in this respective TS packet).
The first case occurs, when a SNDU is smaller than the TS packet
payload length and stuffing bytes are used.
+-------------------+
|Encap | Subnetwork |
|Header| PU |
+-------------------+
\ /
\ /
\ /
+------*--------*--------------+------------+
|MPEG-2| Adapt. | Stuffing | SNDU |
|Header| Header | bytes | |
+------+--------+--------------+------------+
Figure 7: Stuffing using the Adaptation Field
In this case the PUSI/AFC combination 1/11 indicates that the SNDU
header starts after the adaptation field.
The second case occurs when the remaining bytes of an SNDU are
carried together with (the start of) a new SNDU in one TS packet.
Expires December 2003 [page 13]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB May 2003
+------------------+ +------------------+
| Subnetwork | | Subnetwork |
| DU 1 | | DU 2 |
+------------------+ +------------------+
\ \ / /
\ \ / /
\ \ / /
+------*--------*--------+----------+
|MPEG-2| Adapt. | end of | start of |
|Header| Header | SNDU 1 | SNDU 2 |
+------+--------+--------+----------+
Figure 8: Packing using the Adaptation FIELD
The presence of the adaptation field (PUSI/AFC combination 1/11)
guarantees that the receiver does not interpret the end of SNDU 1 as
start of SNDU 2, hence failing reassembly. This case is likely to
occur during the tuning and synchronisation phase of a receiver,
when a number of consecutive 0x47 flags are searched and the
receiver locks to the data signal. If only the length field of SNDU
1 indicated the start of SNDU 2, the receiver would not know this
and would consider the PUSI set to 1 as a start of SNDU 2 directly
following the TS Packet header. The adaptation field length
therefore allows the start of SNDU 2 to be calculated.
In general the PUSI/AFC combinations of 1/01 and 0/01 indicate that
a TS Packet contains 184 bytes of the SNDU. The combinations 0/11
and 1/11 indicate an adaptation header of length 4, leaving 180
bytes for SNDU data.
The TS Packet that carries the last byte of a SNDU MUST always have
an adaptation field (1/11 PUSI/AFC) when one or more SNDUs are
following. Note that once the position and length of the first SNDU
starting in a particular Transport Stream packet is known,
subsequent SNDUs can follow without the need of another pointer.
In case the SNDU or its final portion exactly fits into one TS
Packet no adaptation field (0/00 PUSI/AFC) shall be used.
When there are no more SNDUs ready for encapsulation the TS Packet
(0/01 PUSI/AFC) shall be padded with stuffing bytes of value FF.
5.2 Flushing the bitstream
MPEG-2 multiplexers do not usually flush their buffers, but store TS
Packets until the buffer fills, assuming that the data comes in a
more or less continuous stream. In the case of data traffic, this
assumption no longer holds, leading to the problem that the last IP
datagram will be only partly transmitted unless a special Òpush
Expires December 2003 [page 14]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB May 2003
packet is appended. This introduces additional overhead and is not
an appealing solution.
A further SNDU within the same TS Packet is only started if it is
already available in the encapsulatorÌs buffer at the time the
previous one is encapsulated. The encapsulator does not wait for
another SNDU to fill a TS Packet, because this would introduce
additional latency.
5.3 Receiver Processing
A receiver reassembles SNDUs from the TS Packets received from a
logical TS channel. The receiver determines the start of the first
SNDU by waiting for a TS Packet with a PUSI value of 1.
The receiver identifies the end of the SNDU by interpreting the
PUSI/AFC bits and the information in the adaptation fields and by
keeping a record of the total number of bytes received since the
start of the current SNDU and comparing this value with the SNDU
length field.
The CRC MUST be calculated and verified. SNDUs that contain an
invalid CRC MUST be discarded.
Receipt of a non-zero PUSI value also indicates that the TS Packet
contains the start of a new SNDU. If the receiver has not completed
the current SNDU, and the Length Field indicates that it is awaiting
a greater number of bytes than one less the adaptation header
length, then the receiver has detected a delimiting error. The
partially received SNDU MUST be discarded.
The receiver MUST also check the MPEG-2 Continuity Counter carried
in the TS Packet Header. This counter should increment by one for
each TS Packet received on a logical TS channel. If the value is not
incremented by one in successive packets (modulo 16), any partially
received SNDU MUST be discarded. The receiver then waits for the
next TS Packet with a PUSI value of 1.
The receiver MUST also check the MPEG-2 Transport Error indicator
carried in the TS Packet Header. This flag indicates a transmission
error for the logical TS channel. If the flag is set to a one, any
partially received SNDU MUST be discarded. The receiver then waits
for the next TS Packet with a PUSI value of 1.
After receiving a valid SNDU, the receiver MUST check the Type
Field. The SNDU payload is then passed to the next protocol layer
specified. An SNDU with an unknown Type value MUST be discarded.
The receiver then starts reassembly of the next SNDU. This may
directly follow the previously reassembled SNDU within the TS Packet
Payload.
Expires December 2003 [page 15]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB May 2003
6. Summary
This document defines a Simple Encapsulation to perform efficient
and flexible support for IPv4 and IPv6 network services over
networks built upon the MPEG-2 Transport Stream (TS).
7. Acknowledgments
The authors wish to thank the members of the ip-dvb mailing list
(ip-dvb@erg.abdn.ac.uk) for the input provided. In particular, we
thank the many comments received from Patrick Cipiere,
8. Security Considerations
Security issues are not addressed in this document.
9. References
[ATSC] A/53, "ATSC Digital Television Standard", Advanced Television
Systems Committee (ATSC), Doc. A/53, 1995.
[ATSC-DAT] A/90, "ATSC Data Broadcast Standard", Advanced Television
Systems Committee (ATSC), Doc. A/090, 26 July 00
[ATSC-DATG] A/91, "Recommended Practice: Implementation Guidelines
for the ATSC Data Broadcast Standard", Advanced Television Systems
Committee (ATSC),Doc. A/91. 10 June 2001
[ATSC-G] A/54, "Guide to the use of the ATSC Digital Television
Standard", Advanced Television Systems Committee (ATSC), Doc. A/54,
4 Oct 95
[ATSC-PSIP-TC] A/65A, "Program and System Information Protocol for
Terrestrial Broadcast and Cable", Advanced Television Systems
Committee (ATSC), Doc. A/65A, 23 Dec 1997, Rev. A - 31 May 2000
[ATSC-S] A/80, "Modulation and Coding Requirements for Digital TV
(DTV) Applications over Satellite", Advanced Television Systems
Committee (ATSC), Doc. A/80, 17 July 99
[CLC99] Clausen, H., Linder, H., and Collini-Nocker, B., "Internet
over Broadcast Satellites", IEEE Commun. Mag. 1999, pp.146-151.
[ETSI-DAT] EN 301 192 Specifications for Data Broadcasting, European
Telecommunications Standards Institute (ETSI).
[ETSI-DVBC] EN 300 800 Digital Video Broadcasting (DVB); DVB
interaction channel for Cable TV distribution systems (CATV),
European Telecommunications Standards Institute (ETSI).
Expires December 2003 [page 16]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB May 2003
[ETSI-DVBS] EN 301 421 Digital Video Broadcasting (DVB); Modulation
and Coding for DBS satellite systems at 11/12 GHz, European
Telecommunications Standards Institute (ETSI).
[ETSI-DVBT] EN 300 744 Digital Video Broadcasting (DVB); Framing
structure, channel coding and modulation for digital terrestrial
television (DVB-T), European Telecommunications Standards Institute
(ETSI).
[ISO-DSMCC] ISO/IEC IS 13818-6 Information technology -- Generic
coding of moving pictures and associated audio information -- Part
6: Extensions for DSM-CC is a full software implementation,
International Standards Organisation (ISO).
[ISO-MPEG] ISO/IEC DIS 13818-1 Information technology -- Generic
coding of moving pictures and associated audio information: Systems,
International Standards Organisation (ISO).
[ISO-VID] ISO/IEC DIS 13818-2 Information technology -- Generic
coding of moving pictures and associated audio information: Video,
International Standards Organisation (ISO).
[ISO-AUD] ISO/IEC 13818-3:1995 Information technology -- Generic
coding of moving pictures and associated audio information -- Part
3: Audio, International Standards Organisation (ISO).
[LLC] IEEE Logical Link Control (ANSI/IEEE Std 802.2/ ISO 8802.2),
1985
[RFC3077] E. Duros, W. Dabbous, H. Izumiyama, Y. Zhang, "A Link
Layer Tunneling Mechanism for Unidirectional Links", RFC3077.
[RFC3095] C. Bormann, et al, "RObust Header Compression (ROHC):
Framework and four profiles: RTP, UDP ESP and uncompressed",
RFC3095.
[SI-DAT] SI-DAT group, "Second Draft DVB Specification for Data
Broadcasting", Geneva, 15 Jan. 1997
10.Authors' Addresses
Horst D. Clausen, Bernhard Collini-Nocker, Hilmar Linder
Institute of Computer Sciences
University of Salzburg
Jakob Haringer Str. 2
5020 Salzburg
Austria
Email: [clausen|bnocker|hlinder]@cosy.sbg.ac.at
Web: http://www.cosy.sbg.ac.at/cs/
Godred Fairhurst
Expires December 2003 [page 17]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB May 2003
Department of Engineering
University of Aberdeen
Aberdeen, AB24 3UE
UK
Email: gorry@erg.abdn.ac.uk
Web: http://www.erg.abdn.ac.uk/users/gorry
Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
11. IANA Considerations
This document will require IANA involvement.
The payload type field defined in this document must be aligned with
an existing IANA registry or the following values need to be
assigned by the IANA:
Payload Type Field
Expires December 2003 [page 18]