Internet Engineering Task Force Gorry Fairhurst
Internet Draft University of Aberdeen, U.K.
Document: draft-fair-ipdvb-ule-01.txt Bernhard Collini-Nocker
University of Salzburg, A
Revision 1d
Category: Draft -Intended Standards Track October 2003
Ultra Lightweight Encapsulation (ULE) 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.
Abstract
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. This document describes an Ultra Lightweight
Encapsulation (ULE) mechanism for the transport of IPv4 and IPv6
Datagrams and other network protocol packets directly over ISO MPEG-
2 Transport Streams (TS) as TS Private Data.
Expires April 2004 [page 1]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB October 2003
[RFC EDITOR NOTE - This section must be deleted prior to publication]
DOCUMENT HISTORY
Draft -00
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 author(s) and the ip-dvb mailing list at:
ip-dvb@erg.abdn.ac.uk
DRAFT -01 Text corrected. Protocol amended following discussion on
the list.
1) Padding sequence modified to 0x0000, from 0xFFFF, this change
aligns with other usage by MPEG-2 streams. Treatment remains the
same as specified for ULE.
2) SDNU Format updated.
3) Procedure added for TS Packet carrying the final part of a SNDU
with either less than two bytes of unused payload updated.
4) A Receiver MUST silently discard the remainder of a TS Packet
Payload when two or less bytes remain unprocessed following the end
of a SNDU, irrespective of the PUSI value in the received TS Packet.
It MUST NOT record an error when the value of the remaining byte(s)
is identical to 0xFF or 0xFFFF.
5) Payload Pointer (PP) description updated.
6) CRC Calculation added.
7) Decapsulator processing revised.
8) Type field split into two parts.
9) References updated
10) Security considerations added (first draft)
11) Appendix added with examples.
KNOWN ISSUES (to be addressed by WG):
(i) No method is mandated to select the SNDU format without MAC
destination address.
[END of RFC EDITOR NOTE]
Expires April 2004 [page 2]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB October 2003
Table of Contents
1. Introduction
2. Conventions used in this document
3. Description of method
4. SNDU Format
4.1 Destination Address Present Field
4.2 Length Field
4.3 End Indicator
4.4 Type Field
4.4.1 Type 1: IANA Assigned Type Fields
4.4.2 Type 2: Ethertype Compatible Type Fields
4.5 SNDU Destination Address Field
4.6 SNDU Trailer CRC
4.7 Description of SNDU Formats
4.7.1 End Indicator
4.7.2 IPv4 SNDU Encapsulation
4.7.3 IPv6 SNDU Encapsulation
4.7.4 Test SNDU
5. Processing at the Encapsulator and Receiver
5.1 Encapsulator processing
5.1.1 Flushing the Bitstream
5.2 Receiver Processing
5.2.1 Idle State
5.2.2 Processing of Received SNDUs
5.2.3 Payload Pointer Checking
5.3 SNDU Packing
5.3.1 Encapsulator Packing
5.3.2 Processing of Packed SNDUs at the Receiver
6. Summary
7. Acknowledgments
8. Security Considerations
9. References
9.1 Normative References
9.2 Informative References
10. Authors' Addresses
11. IANA Considerations
Appendix A.
Expires April 2004 [page 3]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB October 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]. It 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.
Support has 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]).
Protocol Data Units, PDUs, (Ethernet Frames, IP datagrams or other
network layer packets) for transmission over an MPEG-2 Transport
Multiplex are passed to an Encapsulator. This formats each PDU into
a Subnetwork Data Unit (SNDU) by adding an encapsulation header and
an integrity check trailer. The SNDU is fragmented into a series of
TS Packets) that are sent over a single TS Logical Channel.
[Authorés NOTE: The draft describes a mechanism aimed at a subset of
the services supported by [DRAFT-ENC]. The format of this document
resembles [DRAFT-ENC]for ease of comparison and much of the
background text is common, although the encapsulation protocol is
different and more lightweight.]
Expires April 2004 [page 4]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB October 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, a pair of bits carried in the TS
Packet header that signal the presence of the Adaptation Field
and/or TS Packet payload.
ATSC: Advanced Television Systems Committee [ATSC]. A framework and
a set of associated standards for the transmission of video, audio,
and data using the ISO MPEG-2 standard.
DSM-CC: Digital Storage Management Command and Control [ISO-DSMCC].
A format for transmission of data and control information defined by
the ISO MPEG-2 standard that is carried in an MPEG-2 Private
Section.
DVB: Digital Video Broadcast [ETSI-DVB]. A framework and set of
associated standards published by the European Telecommunications
Standards Institute (ETSI) for the transmission of video, audio, and
data, using the ISO MPEG-2 Standard.
ENCAPSULATOR: A network device that receives PDUs and formats these
into Payload Units (known here as SNDUs) for output as a stream of
TS Packets.
MAC: Medium Access and Control. The link layer header of the
Ethernet IEEE 802 standard of protocols, consisting of a 6B
destination address, 6B source address, and 2B type field.
MPE: Multiprotocol Encapsulation [ETSI-DAT; ATSC-DAT ; ATSC-DATG]. A
scheme that encapsulates PDUs, forming a DSM-CC Table Section. Each
Section is sent in a series of TS Packets using a single 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]
NPA: Network Point of Attachment. In this document, refers to a 6 B
destination address within the MPEG-2 transmission network used to
identify individual Receivers or groups of Receivers.
PDU: Protocol Data Unit. Examples of PDU include Ethernet frames,
IPv4 or IPv6 datagrams, and other network packets
PES: Programme Elementary Scheme of MPEG-2 [ISO-MPEG].
Expires April 2004 [page 5]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB October 2003
PID: Packet Identifier. A field carried in the header of TS Packets.
This is used to identify the TS Logical Channel to which a TS Packet
belongs [ISO-MPEG]. 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.
PP: Payload Pointer. An optional one byte pointer that directly
follows the TS Packet header. It contains the number of bytes
between the end of the TS Packet header and the start of a Payload
Unit. The presence of the Payload Pointer is indicated by the value
of the PUSI bit in the TS Packet header. The Payload Pointer is
present in DSM-CC, and Table Sections, it is not present in TS
Logical Channels that use the PES-format.
PU: Payload Unit. A sequence of bytes sent using a TS. Examples of
Payload Units include: an MPEG-2 Table Section or a ULE SNDU.
PUSI: Payload_Unit_Start_Indicator of MPEG-2 [ISO-MPEG]. A single
bit flag carried in the TS Packet header. A PUSI value of zero
indicates that the TS Packet does not carry the start of a new
Payload Unit. A PUSI value of one indicates that the TS Packet does
carry the start of a new Payload Unit. In ULE, a PUSI bit set to 1
also indicates the presence of a one byte Payload Pointer (PP).
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 Table Sections, however all Table Sections
must be carried over a single TS Logical Channel.
PSI: Programme SI. An table used to convey information about the
service carried in a TS Multiplex. The set of PSI tables is defined
by [ISO-MPEG], see also SI Table.
SI TABLE: Service Information Table. In this document, this term
describes any table used to convey information about the service
carried in a TS Multiplex. SI tables are carried in MPEG-2 private
sections.
SNDU: Subnetwork Data Unit. An encapsulated PDU sent as an MPEG-2
Payload Unit.
TABLE SECTION: A Payload Unit carrying a part of a MPEG-2 SI Table.
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: Transport Stream Logical Channel, a channel
identified at the MPEG-2 level [ISO-MPEG]. It exists at level 2 of
the ISO/OSI reference model. All packets sent over a TS Logical
Channel carry the same PID value. According to MPEG-2, some TS
Expires April 2004 [page 6]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB October 2003
Logical Channels are reserved for specific signalling purposes.
Other standards (e.g., ATSC, DVB) also reserve specific TS Logical
Channels.
TS MULTIPLEX: A set of MPEG-2 TS Logical Channels sent over a single
common physical link (i.e. a transmission at a specified symbol
rate, FEC setting, and transmission frequency). The same TS Logical
Channel may be repeated over more than one TS Multiplex, for example
to redistribute the same multicast content to two terrestrial TV
transmission cells.
TS PACKET: A fixed-length 188B unit of data sent over a TS Multiplex
[ISO-MPEG]. Operation resembles that of cell in an ATM network, and
may also be 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
related Transport Streams.
Expires April 2004 [page 7]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB October 2003
3. Description of the Method
PDUs (IP packets, Ethernet frames or packets from other network
protocols) are encapsulated to form a Subnetwork Data Unit (SNDU).
The SNDU is transmitted over an MPEG-2 transmission network by
placing it either in the payload of a single TS Packet. If required,
a SNDU may be fragmented into a series of TS Packets. Where there is
sufficient space, the method permits a single TS Packet to carry
more than one SNDU (or part there of), sometimes known as Packing.
All TS Packets comprising a SNDU MUST be assigned the same PID, and
therefore form a part of the same TS Logical Channel.
The ULE encapsulation is limited to TS private streams only. The
header of each TS Packet carries a one bit Payload Unit Start
Indicator (PUSI) field. The PUSI identifies the start of a payload
unit (SNDU) within the MPEG-2 TS Packet payload. The semantics of
the PUSI bit are defined differently for PES and PSI packets [ISO-
MPEG]; for private data, its use is not defined in the MPEG-2
Standard. In ULE, the operation follows that of PSI packets. Hence,
the following PUSI values are defined:
0: The TS Packet does NOT contain the start of a SNDU, but
contains the continuation, or end of a SNDU;
1: The TS Packet contains the start of a SNDU, and a one byte
Payload Pointer follows the last byte of the TS Packet header.
If a Payload Unit (SNDU) finishes before the end of a TS Packet
payload, but it is not convenient to start another Payload Unit, a
stuffing procedure fills the remainder of the TS Packet payload with
bytes with a value 0xFF [ISO-MPEG2], known as Padding or Stuffing.
A Receiver processing MPEG-2 Table Sections is aware that when it
receives a table_id value of 0xFF, this indicates Padding/Stuffing
occurred and silently discards the remainder of the TS Packet
payload. The payload of the next TS Packet for the same TS Logical
Channel will begin with a Payload Pointer of value 0x00, indicating
that the next Payload Unit immediately follows the TS Packet header.
The ULE protocol resembles this, but differs in the exact procedure
(see the following sections).
The TS Packet Header also carries a two bit Adaptation Field Control
(AFC) value. The purpose of the adaptation field is primarily to
carry timing and synchronisation information and may be used to also
include stuffing bytes before a TS Packet payload. Standard
Receivers discard TS Packets with an adaptation_field_control field
value of '00'. Adaptation Field stuffing is NOT used in this
encapsulation method, and TS packets from a ULE Encapsulator MUST be
sent with an AFC value of '01'. Receivers MUST discard TS Packets
that carry other AFC values.
[XXX Author's NOTE: The enc encapsulation defines how to use the AF]
Expires April 2004 [page 8]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB October 2003
4. SNDU Format
PDUs are encapsulated using ULE to form a SNDU. Each SNDU is sent as
an MPEG-2 Payload Unit. The encapsulation format to be used for PDUs
(IP packets and bridged Ethernet frames) is illustrated below:
.-------------------------- SNDU ---------------------------.
+---+---------------------------------------------------+--------+
| R | Length | Type | PDU | CRC-32 |
+---+---------------------------------------------------+--------+
Figure 1: SNDU Encapsulation
The Length, Type, and Destination fields are transmitted most
significant byte first (Appendix A provides informative examples of
usage).
4.1 Reserved Field
The most significant bit of the Length Field is reserved. All
transmitted SNDUs MUST set this to the value 0. One exception is
transmission of an End Indicator (see 4.3), in which this bit MUST
be set to the value of 1.
At the receiver, the value of this bit MUST be checked ignored,
except for the special case defined in 4.3.
4.2 Length Field
A 15-bit value that 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.
Also note the special case described in 4.3.
4.3 End Indicator
When the first two bytes of a SNDU has the value 0xFFFF, this
denotes an End Indicator (i.e., all 1és length combined with a
Reserved Field set to a value of 1). It indicates that there are no
further SNDU are present within the current TS packet (see section
5.1). The value 0xFF has specific semantics in MPEG-2 framing, where
it is used to indicate the presence of stuffing. This use resembles
this.
4.4 Type Field
The 16-bit Type field indicates the type of payload carried in a
SNDU. The set of values that may be assigned to this field is
divided into two parts, similar to the allocations for Ethernet.
Expires April 2004 [page 9]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB October 2003
Ethertypes were originally by Xerox under the DIX framework. After
specification of IEEE 802.3, the set of Ethertypes less than 1500,
assumed the role of a length indicator. Receivers use this feature
to discriminate LLC format frames. Hence any Ethertype <= 1500
indicates an LLC frame, and the actual value indicates the length of
the LLC frame. This mode of identification is not required in ULE,
since the SNDU format always carries an explicit Length Field.
Specification of two independent length fields is undesirable, and
therefore the procedure in ULE is modified, as below:
The first set of ULE Type Field values apply to a Type Field value
<= 1500. These Type Field values are IANA assigned (see 4.4.1).
The second set of ULE Type Field values apply to a Type Field value
> 1500. In ULE, this indicates that the value is identical to the
corresponding type codes specified by the IEEE/DIX type assignments
for Ethernet
4.4.1 Type 1: IANA Assigned Type Fields
The first part of the Type space corresponds to the values 0x0000 to
1500 Decimal. These values are assigned to an IANA registry.
The following types are defined:
[XXX IANA ACTION REQUIRED XXX]
0x0000: Test SNDU, discarded by the Receiver.
0x0001: Bridged Ethernet Frame (i.e. MAC source address follows)
0x0002: LLC header follows in SNDU Payload
[XXX END OF IANA ACTION REQUIRED XXX]
[Author NOTE: Type allocation and appropriate IANA Procedure
to be determined.]
4.4.2 Type 2: Ethertype compatible Type Fields
The second part of the Type space corresponds to the values 1500
Decimal and 0xFFFF. This set of type assignments follow DIX/IEEE
assignments (not including use of LLC) [LLC]. The following types
are defined in this document for part 2:
0x0800 : IPv4 Payload (according to IANA EtherTypes)
0x86DD : IPv6 Payload (according to IANA EtherTypes)
All other assignments in part two of this space should be coordinated
with the values defined for IANA EtherType encapsulations.
Expires April 2004 [page 10]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB October 2003
[Author Note: Suitable values for ROHC types may in future
need to be added]
4.5 SNDU Destination Address Field
[Authorés note: Location of the D-bit, or the use of appropriate
Type Field allocations within the SNDU header is still to be
determined by the WG]
The SNDU Destination Address Field is optional.
This field MUST be carried for IP unicast packets destined to
routers. A sender MAY omit this field IP unicast packet and/or
multicast packets delivered to Receivers that are able to utilise a
discriminator field (e.g. the IPv4/IPv6 destination address), which
in combination with the PID value, could be interpreted as a Link-
Level address.
The default SNDU format MUST carry this field,
When the SNDU header indicates the presence of a SNDU destination
address field, a Network Point of Attachment, NPA, field directly
follows the SNDU Type Field. NPA destination addresses are 6 B
numbers, normally expressed in hexadecimal, used to identify the
Receiver(s) that should process a received SNDU within a MPEG-2
transmission network.
4.6 SNDU Trailer CRC
Each SNDU MUST carry a 32-bit CRC field in the last four bytes of
the SNDU. This position eases CRC computation by hardware. The CRC
polynomial to be used is the Reverse CRC-32. The reverse order of
calculation (i.e. where the CRC operates on successive bytes,
processing the lsb of each byte first) is compatible with both a
hardware or software implementation. The CRC-32 is calculated
according to the following generator polynomial:
x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x^1+x^0.
This description may be suited for hardware implementation, but this
document does not imply any specific implementation. Software-based
table-lookup or hardware-assisted software-based implementations are
also possible.
[Author NOTE: We need to specify initial register value!!!]
The Encapsulator calculates a transmit value for the CRC32 including
all bytes from the start of the SNDU header to the end of the
trailer, and places this in the CRC Field. The receiver performs an
integrity check by independently calculating the CRC value and
Expires April 2004 [page 11]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB October 2003
comparing this with the transmitted value in the SNDU trailer. SNDUs
that do not have a valid CRC-32, are discarded.
The primary purpose of this CRC is to protect the SNDU payload from
undetected resassembly errors and errors introduced by unexpected
software / hardware operation while the SNDU is in transit across
the MPEG-2 subnetwork and during processing at the encapsulation
gateway and/or the receiver. It may also detect the presence of
uncorrected errors from the physical link (these may however, in
some cases, also be detected by other means).
4.7 Description of SNDU Formats
[>>> Authorés Note: The mechanism for communicating the presence of
the Destination Address Field (D) is to be determined by the WG.
Early implementers should note the default value of D is 0,
indicating presence of the Destination Address Field <<<]
The Format of a SNDU is determined by the combination of the
Destination Address bit (D) and the SNDU Type field. The simplest
encapsulation places a PDU directly into a SNDU payload. Some Type
1 encapsulations may require additional header fields. These are
inserted in the SNDU directly preceding the PDU.
The following SNDU Formats are defined here:
End Indicator: The Receiver should enter the Idle State.
IPv4 SNDU: The payload is a complete IPv4 datagram.
IPv6 SNDU: The payload is a complete IPv6 datagram.
Test SNDU: The payload will be discarded by the Receiver.
Bridged SNDU: The payload carries a bridged MAC or LLC frame.
All other formats are currently reserved.
Expires April 2004 [page 12]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB October 2003
4.7.1 End Indicator
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|1 | 0x7FFF |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
= Arbitrary number of bytes >= 0 =
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 2: SNDU Formats for an End Indicator.
4.7.2 IPv4 SNDU
IPv4 datagrams are transported using one of the two standard SNDU
structures, in which the PDU is placed directly in the SNDU payload.
The two encapsulations are shown in figures 2 and 3.
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|R | Length (2B) | Type = 0x0800 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| MAC Destination Address (6B) |
+ +--+--+--+--+--+--+--+--+
| | |
+--+--+--+--+--+--+--+--+ +
| |
| IPv4 datagram |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| (CRC_32) |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 3: SNDU Formats for an IPv4 Datagram using L2 filtering.
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|R | Length (2B) | Type = 0x0800 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
| IPv4 datagram |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| (CRC_32) |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 4: SNDU Formats for an IPv4 Datagram using L3 filtering.
Expires April 2004 [page 13]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB October 2003
4.7.3 IPv6 SNDU Encapsulation
IPv6 datagrams are transported using one of the two standard SNDU
structures, in which the PDU is placed directly in the SNDU payload.
The two encapsulations are shown in figures 4 and 5.
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|R | Length (2B) | Type = 0x086DD |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| MAC Destination Address (6B) |
+ +--+--+--+--+--+--+--+--+
| | |
+--+--+--+--+--+--+--+--+ +
| |
| IPv6 datagram |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| (CRC_32) |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 5: SNDU Formats for an IPv6 Datagram using L2 filtering.
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|R | Length (2B) | Type = 0x86DD |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
| IPv6 datagram |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| (CRC_32) |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 6: SNDU Formats for an IPv6 Datagram using L3 filtering.
Expires April 2004 [page 14]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB October 2003
4.7.4 Test SNDU
A Test SNDU is of Type 1 (figure 6). The structure of the Data
portion of this SNDU is not defined by this document. All Receivers
MAY record reception in a log file, but MUST then discard any Test
SNDUs.
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|R | Length (2B) | Type = 0x0000 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
= Data (ignored by Receivers) =
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
+ ULE CRC-32 (4B) +
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 7: SNDU Format for a Test SNDUs
4.7.5 Bridge Frame SNDU Encapsulation
A bridged SNDU is of Type 1. The payload includes a MAC source and
Ether-Type field together with the contents of a bridged MAC frame.
The SNDU has the format shown in figure 8.
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|R | Length (2B) | Type = 0x0800 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| MAC Destination Address (6B) |
+ +--+--+--+--+--+--+--+--+
| | |
+--+--+--+--+--+--+--+--+ +
| MAC Source Address (6B) |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| EtherType (2B) | |
+--+--+--+--+--+--+--+--+ |
= =
| (Contents of bridged MAC frame) |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
+ ULE CRC-32 (4B) +
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 8: SNDU Format for a Bridged Payload
The MAC addresses are those specified in the frame being bridged and
are SHOULD be assigned according to the rules specified by the IEEE
Expires April 2004 [page 15]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB October 2003
and may denote unknown, unicast, broadcast, and multicast link
addresses. These MAC addresses denote the intended recipient in the
destination LAN, and therefore have a different function to the NPA
addresses carried in the SNDU header. The EtherType field of frame
is defined according to Ethernet/LLC [LLC].
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.
Most bridged frames will also carry a Local Area Network Frame Check
sequence, LAN FCS, field (e.g. CRC-32 for Ethernet). The LAN-FCS
value of all received frames MUST be checked by the Encapsulator
prior to processing. Frames received with an invalid LAN FCS MUST
be discarded. The LAN FCS is then removed (i.e., it is NOT forwarded
in the bridged SNDU). As in other ULE frames, the Encapsulator
appends a CRC-32 to the transmitted SNDU. At the Receiver, an
appropriate LAN-FCS field may be appended to the bridged frame prior
to onward transmission.
This design is readily implemented using existing network interface
cards, and does not introduce an efficiency cost by transmitting two
integrity check fields for bridged frames. However, it also
introduces the possibility that a frame corrupted within the
processing performed at an Encapsulator and/or Receiver may not be
detected by the final recipient(s) (i.e. such corruption would not
normally result in an invalid LAN FCS).
[Author Note: Is dest address signaled by the type or by the D-
bit. What is required in this case? - or should D=1 signify a MPEG-
2 transmission network MAC + and Ethernet dst MAC? - i.e. two
addresses - does this have nay practical sue - e.g. In Skyplex/RCS
scenarios?]
Expires April 2004 [page 16]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB October 2003
5. Processing at the Encapsulator and Receiver
The Encapsulator forms the PDUs awaiting transmission into SNDUs and
then segments these into a series of TS Packet payloads (figure 9).
These are transmitted using a single TS Logical Channel over a TS
Multiplex. The TS Multiplex may be processed by a number of MPEG-2
(re)multiplexors before it is finally delivered to a Receiver.
+----------------------------------------------+
|Encap Header| SubNetwork Data Unit | CRC-32 |
+----------------------------------------------+
/ / \ \
/ / \ \
/ / \ \
+------+----------+ +------+----------+ +------+----------+
|MPEG-2| MPEG-2 |... |MPEG-2| MPEG-2 |... |MPEG-2| MPEG-2 |
|Header| Payload | |Header| Payload | |Header| Payload |
+------+----------+ +------+----------+ +------+----------+
Figure 9: Encapsulation of a SNDU into a series of TS Packets
A Receiver tunes to a specific TS Multiplex and sets a receive
filter to accept all TS Packets with a specific PID. These TS
Packets are associated with a specific TS Logical Channel and are
reassembled to form a stream of SNDUs. A single receiver may be
able to receive multiple TS Logical Channels, possibly using a range
of TS Multiplexes. In each case, reassembly is performed
independently for each TS Logical Channel.
5.1 Encapsulator Processing
The Encapsulator adds a header and trailer to each PDU to form a
SNDU. This SNDU is then segmented into a series of MPEG-2 TS Packets
belonging to the same logical TS Logical Channel. This set is sent
as a sequence over a TS Multiplex.
5.1.1 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" TS
Packet is appended. This introduces additional overhead.
[Author Note: Do we need to specify functionality here ???]
Expires April 2004 [page 17]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB October 2003
5.2 Receiver Processing
Receipt of a TS Packet with a non-zero PUSI value indicates that the
TS Packet contains the start of a new SNDU. It also indicates the
presence of the Payload Pointer. The Payload Pointer value indicates
that there are Payload Pointer bytes of the SNDU currently being
reassembled at the start of the TS Packet payload. A Payload Pointer
value equal to greater than 183 is illegal in ULE, and the SNDU
reassembly MUST be aborted. This event SHOULD be recorded as an
error.
A Receiver reassembles SNDUs from the TS Packets received from a TS
Logical Channel. To perform this reassembly, the receiver may use a
buffer to hold the partially assembled SNDU, referred to here as the
Current SNDU buffer. Other implementations may choose to use other
data structures, but must provide equivalent operations.
[Author Note: Should we validate the CC field in TS Packet- or
ignore this. The strong CRC-32 suggests this is unnecessary, and it
does increase the required complexity of the (re)multiplexor - WG
thoughts please?]
5.2.1 Idle State
After initialisation or on receipt of an End Indicator, the Receiver
enters the Idle State. In this state, the Receiver discards the
contents of the Current SNDU buffer and waits for the start of the
next SNDU by waiting for a TS Packet with a PUSI value of 1. All
other TS Packets are discarded in this mode.
A PUSI value of 1, indicates the presence of a Payload Pointer. For
the first TS Packet received, the Payload Pointer will also have a
value of 0. Following a loss of synchronisation, values between 1
and 182 are permitted, in which case the receiver MUST discard the
number of bytes indicated by the Payload Pointer, before starting
reassembly of the next SNDU.
5.2.2 Processing of Received SNDUs
The Receiver reads the SNDU Length field from the current SNDU. If
this Length is less than or equal to 3, the Receiver discards the
Current SNDU and the remaining TS Packet payload and returns to the
search mode waiting for the next TS Packet with a PUSI value of 1.
If the Length of the Current SNDU is greater than 4, it then accepts
bytes from the TS Packet payload to the Current SNDU buffer until
either Length bytes in total are received, or the end of the TS
Packet is reached. When Length bytes are received, the receiver MUST
calculate and verify the CRC value. SNDUs that contain an invalid
CRC value MUST be discarded. After receiving a valid SNDU, the
receiver MUST check the Type Field. The SNDU payload is then passed
Expires April 2004 [page 18]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB October 2003
to the next protocol layer specified. An SNDU with an unknown Type
value MUST be discarded. This error event SHOULD be recorded in a
log file.
The receiver then starts reassembly of the next SNDU. This MAY
directly follow the previously reassembled SNDU within the TS Packet
Payload.
If there is either 0 or 1 byte of payload data remaining in the TS
Packet after completion of the Current SNDU, the receiver MUST
discard this remaining TS payload, and wait for the next TS Packet
with the PUSI value set to 1 (the Idle State).
If there is more than one byte of payload data remaining in the TS
Packet after completion of the Current SNDU, the Receiver MUST
accept the next bytes as the start of the next SNDU (or an End
Indicator), and continue with processing the next SNDU.
5.2.3 Payload Pointer Checking
An idle Receiver (i.e. one that is not currently reassembling a PDU)
MUST check the PUSI value in the header of all received TS Packets.
If it receives a TS Packet with a PUSI value of 1, and MUST discard
a number of bytes equal to the Payload Pointer value from the start
of the TS Packet payload, before it commence reassembly of a new
SNDU at this point. Normally, the Payload Pointer will have a value
of 0.
A Receiver that has partially received a SNDU (in the Current SNDU
buffer) MUST check the PUSI value in the header of all received TS
Packets. If it receives a TS Packet with a PUSI value of 1, it MUST
then verify the Payload Pointer. If the Payload Pointer does NOT
equal the number of bytes remaining to complete the Current SNDU,
i.e., the difference between the SNDU Length field and the number of
reassembled bytes, the Receiver has detected a delimiting error.
Following a delimiting error, the Receiver MUST discard the
partially assembled SNDU (in the Current SNDU buffer), and SHOULD
record a reassembly error. It MUST also discard a number of bytes
equal to the Payload Pointer value from the start of the TS Packet
payload, and commence reassembly of a new SNDU at this point.
5.2.4 Other Error Conditions
[Author Note: Should we check the MPEG-2 CC??]
The Receiver SHOULD also check the MPEG-2 Continuity Counter carried
in the TS Packet header. This value MUST be incremented by one for
each TS Packet sent using a TS Logical Channel. If the received
value does not increment by one in successive TS Packets (modulo
Expires April 2004 [page 19]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB October 2003
16), the Receiver has detected a continuity error. Any partially
received SNDU MUST be discarded. The receiver then enters a mode to
wait for the next TS Packet with a PUSI value of 1.
The Receiver SHOULD check the MPEG-2 Transport Error indicator
carried in the TS Packet header. This flag indicates a transmission
error for a TS Logical Channel. If the flag is set to a value of
one, an error event SHOULD be recorded. Any partially received SNDU
MUST be discarded. The Receiver then enters the Idle State.
5.3 SNDU Packing
When an Encapsulator has not previously sent a TS Packet for a
specific TS Logical Channel, or after an idle period, it starts to
send a SNDU in the first available TS Packet. This first TS Packet
generated MUST carry a PUSI value of 1. It MUST also carry a Payload
Pointer value of zero indicating the SNDU starts in the first
available byte of the TS Packet payload.
If the TS Packet carrying the final part of a SNDU has one byte of
unused payload, the Encapsulator MUST place the value 0xFF in this
final byte.
If there are at least two bytes remaining in the TS Packet payload
after processing the Current SNDU and further PDUs are queued at an
Encapsulator, it MAY append the bytes of the next SNDU directly to
the preceding one before segmentation (figure 9). This procedure is
known as Packing. If there are no further SNDUs available, an
Encapsulator MAY wait for additional PDUs to fill the incomplete TS
Packet.
[Author Note: Should this waiting period be bounded?]
+------------------+ +------------------+
| Subnetwork | | Subnetwork |
| DU 1 | | DU 2 |
+------------------+ +------------------+
\ \ / /\
\ \ / / \
\ \ / / \
+------+--------+--------+----------+
|MPEG-2| Payload| end of | start of |
|Header| Pointer| SNDU 1 | SNDU 2 |
+------+--------+--------+----------+
| ^
PUSI=1 | |
+--------------+
Figure 10: A TS Packet with the end of SNDU 1, followed by SNDU 2
Expires April 2004 [page 20]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB October 2003
If an Encapsulator decides NOT to wait for another SNDU, it MUST
instead transmit an End Indicator directly after the end of the last
SNDU. This informs the Receiver that there are no more SNDUs in this
TS Packet payload. The End Indicator is followed by stuffing bytes
until the end of the TS Packet payload (figure 10). The latter
procedure trades decreased efficiency against improved latency.
+-------------+
| Subnetwork |
| DU 3 |
+-------------+
\ \
\ \
\ \
+------+--------+--------+----------+
|MPEG-2| End of | 0xFFFF | Unused |
|Header| SNDU 3 | | Bytes |
+------+--------+--------+----------+
PUSI=0 End
Indicator
Figure 10: A TS Packet carrying the end of SNDU 3, followed by an
End Indicator
[Author Note: Should we mandate ALL stuffing bytes are 0xFF???
Why?]
5.3.1 Encapsulator Packing
If more packets are waiting at the Encapsulator, and a TS Packet has
more than two bytes of unused payload, it MAY start the next SNDU in
the next available byte of the TS Packet payload. The PUSI MUST be
set, if not already set. When an Encapsulator packs a further SNDU
into an already formed TS Packet, this may require the PUSI value in
the TS Packet header to be updated, also requiring a Payload Pointer
to be inserted in the TS Packet.
If the PUSI is set by this operation, the 8-bit Payload Pointer MUST
be inserted in the first byte directly following the TS Packet
header. The value MUST be set to the position of the byte following
the end of the first SNDU in the TS Packet payload. The value 0x00
indicates that a SNDU starts immediately after the Payload Pointer.
If the TS Packet carrying the final part of a SNDU has less than two
bytes of unused payload, the Encapsulator MUST start transmission of
the next SNDU in a new TS Packet. (The standard rules require the
header of this new TS Packet to carry a PUSI value of 1.) This rule
provides a simple mechanism to resolve the complex behaviour that
may arise when the TS Packet has no PUSI set. In ULE, this would
Expires April 2004 [page 21]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB October 2003
otherwise require the addition of a Payload Pointer that would
consume the last remaining byte of TS Packet payload. The behaviour
follows similar practice for other MPEG-2 payload types.
When a SNDU is less than the size of a TS Packet payload, a TS
Packet may be formed which carries a PUSI value of one and also an
End Indicator.
5.3.2 Processing of Packed SNDUs at the Receiver
All Receivers MUST support the use of the Packing method for any
received SNDU. Use of the Packing method by an Encapsulation Gateway
is optional, and may be determined on a per session, per-packet, or
per-SNDU basis.
A Receiver MUST silently discard the remainder of a TS Packet
Payload when two or less bytes remain unprocessed following the end
of a SNDU, irrespective of the PUSI value in the received TS Packet.
It MUST NOT record an error when the value of the remaining byte(s)
is identical to 0xFF or 0xFFFF. The receiver MUST then enter the
Idle State.
6. Summary
This document defines an Ultra Lightweight Encapsulation (ULE) to
perform efficient and flexible support for IPv4 and IPv6 network
services over networks built upon the MPEG-2 Transport Stream (TS).
The encapsulation is also suited to transport of other protocol
packets and bridged Ethernet frames.
7. Acknowledgments
This draft is based on a previous draft authored by: Horst D.
Clausen, Bernhard Collini-Nocker, Hilmar Linder, and Gorry
Fairhurst. The authors wish to thank the members of the ip-dvb
mailing list for their input provided. In particular, the many
comments received from Patrick Cipiere, and Alain Ritoux.
8. Security Considerations
There is a known security issue with un-initialised stuffing bytes.
There are also a potential security issue when an encapsulation
permits two length fields - as in the use of bridged LLC packets.
The Encapsulator and Receiver MUST validate the actual length and
the Length field and ensure that inconsistent values are not
propagated by the network.
Expires April 2004 [page 22]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB October 2003
There are known integrity issues with the removal of the LAN FCS in
a bridged networking environment. The removal exposes the traffic to
potentially undetected corruption while being processed by the
Encapsulator and/or Receiver.
9. References
9.1 Normative References
[ISO-MPEG] ISO/IEC DIS 13818-1 "Information technology -- Generic
coding of moving pictures and associated audio information:
Systems", International Standards Organisation (ISO).
[RFC2026] Bradner, S., "The Internet Standards Process - Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2 Informative 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.
[DRAFT-ENC] IETF Work in Progress, draft-clausen-ipdvb-enc-XX.txt
[ETSI-DAT] EN 301 192 "Specifications for Data Broadcasting",
European Telecommunications Standards Institute (ETSI).
Expires April 2004 [page 23]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB October 2003
[ETSI-DVBC] EN 300 800 "Digital Video Broadcasting (DVB); DVB
interaction channel for Cable TV distribution systems (CATV)",
European Telecommunications Standards Institute (ETSI).
[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).
[ETSI-RCS] XXX Reference Required XXX
[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).
[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
Godred Fairhurst
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
Bernhard Collini-Nocker
Institute of Computer Sciences
University of Salzburg
Expires April 2004 [page 24]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB October 2003
Jakob Haringer Str. 2
5020 Salzburg
Austria
Email: [bnocker]@cosy.sbg.ac.at
Web: http://www.cosy.sbg.ac.at/cs/
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 April 2004 [page 25]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB October 2003
ANNEXE A: Informative Appendix
This appendix provides some examples of use. The appendix is
informative. It does not provide a description of the protocol. The
examples provide the complete TS Packet sequence for some sample
encapsulated IP packets.
The specification of the TS Packet header operation and field values
is provided in [ISO-MPEG]. The specification of ULE is provided in
the body of this document.
The key below is provided for the following examples.
HDR 4B TS Packet Header
PUSI Payload Unit Start Indicator
PP Payload Pointer
*** TS Packet Payload Pointer (PP)
[XXX Editor note: Can someone please provide us with a hex-dump
including the TS Packet headers for these examples??? XXX]
Example A.1: Two 186B PDUs.
SNDU A is 200 bytes (including destination MAC address)
SNDU B is 200 bytes (including destination MAC address)
The sequence comprises 3 TS Packets:
SNDU
PP=0 Length
+-----+------+------+------+- -+------+
| HDR | 0x00 | 0x00 | 0xC8 | ... | A182 |
+-----+----*-+-*----+------+- -+------+
PUSI=1 * *
*****
SNDU
PP=16 Length
+-----+------+------+- -+--- --+------+------+- -+------+
| HDR | 0x10 | A183 | ... | A199 | 0x00 | 0xC0 | ... | B165 |
+-----+----*-+------+- -+------+-*----+------+- -+------+
PUSI=1 * *
*************************
End Stuffing
Indicator Bytes
+-----+------+- -+------+----+----+- -+
| HDR | B166 | ... | B199 |0xFF|0xFF| ... |
+-----+------+- -+------+----+----+- -+
PUSI=0
Expires April 2004 [page 26]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB October 2003
Example A.2: Usage of last byte in a TS-Packet
SNDU A is 183 bytes
SNDU B is 182 bytes
SNDU C is 181 bytes
SNDU D is 185 bytes
The sequence comprises 4 TS Packets:
PP=0
+-----+------+------+- -+------+
| HDR | 0x00 | A000 | ... | A182 |
+-----+----*-+-*----+- -+------+
PUSI=1 * *
*****
Unused
PP=0 byte
+-----+------+------+- -+------+------+
| HDR | 0x00 | B000 | ... | B181 | 0xFF |
+-----+---*--+-*----+- -+------+------+
PUSI=1 * *
******
PP=0
+-----+------+------+- -+------+------+------+
| HDR | 0x00 | C000 | ... | C180 | D000 | D001 |
+-----+---*--+-*----+- -+------+------+------+
PUSI=1 * *
****** Unused
byte
+-----+------+- -+------+------+
| HDR | D002 | ... | D184 | 0xFF |
+-----+------+- -+------+------+
PUSI=0
Expires April 2004 [page 27]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB October 2003
Example A.3: Large SNDUs
SNDU A is 732 bytes
SNDU B is 284 bytes
The sequence comprises 6 TS Packets:
PP=0
+-----+------+------+- -+------+
| HDR | 0x00 | A000 | ... | A182 |
+-----+---*--+-*----+- -+------+
PUSI=1 * *
******
+-----+------+- -+------+
| HDR | A183 | ... | A366 |
+-----+------+- -+------+
PUSI=0
+-----+------+- -+------+
| HDR | A367 | ... | A550 |
+-----+------+- -+------+
PUSI=0
PP=181
+-----+------+------+- -+------+------+------+
| HDR | 0xB5 | A551 | ... | A731 | B000 | B001 |
+-----+---*--+------+- -+------+*-----+------+
PUSI=1 * *
*************************
+-----+------+- -+------+
| HDR | B002 | ... | B186 |
+-----+------+- -+------+
PUSI=0
End Stuffing
Indicator Bytes
+-----+------+- -+------+------+------+- -+
| HDR | B187 | ... | B283 | OxFF | 0xFF | ... |
+-----+------+- -+------+------+------+- -+
PUSI=0
Expires April 2004 [page 28]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB October 2003
Example A.4: Packing of SNDUs
SNDU A is 200 bytes
SNDU B is 60 bytes
SNDU C is 60 bytes
The sequence comprises two TS Packets:
PP=0 SNDU A Length
+-----+------+------+------+- -+------+
| HDR | 0x00 | A000 | A001 | ... | A182 |
+-----+----*-+-*----+------+- -+------+
PUSI=1 * * + +
***** ++++++++
+
+++++++++++++++++
+
PP=17 +SNDU B Length
+-----+------+------+- -+------+-+----+------+-
| HDR | 0x11 | A183 | ... | A199 | B000 | B001 | ...
+-----+----*-+------+- -+------+*-----+------+-
PUSI=1 * * + +
************************ +++++++++
+
+++++++++++++++++++++++++++++++++++ End Stuffing
+ SNDU C Length Indicator bytes
+ -+------+------+------+ -+------+------+------+- -+
+ ... | B059 | C000 | C001 | ... | C059 | 0xFF | 0xFF | ... |
+ -+------+-+----+------+ -+------+-+----+------+- -+
+ + + + +
+ + ++++++++ +
+ + + +
++++++++++++++++++ ++++++++++++++++++++++++
*** TS Packet Payload Pointer (PP)
+++ ULE Length Indicator
Expires April 2004 [page 29]