Request for Comments: 4326 University of Aberdeen
Category: Standards Track B. Collini-Nocker
University of Salzburg
December 2005
Unidirectional Lightweight Encapsulation (ULE) for
Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS)
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The MPEG-2 Transport Stream (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 a Unidirectional Lightweight Encapsulation
(ULE) mechanism for the transport of IPv4 and IPv6 Datagrams and
other network protocol packets directly over the ISO MPEG-2 Transport
Stream as TS Private Data. ULE specifies a base encapsulation format
and supports an extension format that allows it to carry additional
header information to assist in network/Receiver processing.
Table of Contents
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................4
3. Description of the Method .......................................8
4. SNDU Format .....................................................9
4.1. Destination Address Absent (D) Field ......................10
4.2. Length Field ..............................................10
4.3. End Indicator .............................................10
4.4. Type Field ................................................10
4.4.1. Type 1: Next-Header Type Fields ....................11
4.4.2. Type 2: EtherType Compatible Type Fields ...........11
4.5. SNDU Destination Address Field ............................12
4.6. SNDU Trailer CRC ..........................................12
4.7. Description of SNDU Formats ...............................13
4.7.1. End Indicator ......................................14
4.7.2. IPv4 SNDU Encapsulation ............................14
4.7.3. IPv6 SNDU Encapsulation ............................15
5. Extension Headers ..............................................16
5.1. Test SNDU .................................................18
5.2. Bridged Frame SNDU Encapsulation ..........................18
5.3. Extension-Padding Optional Extension Header ...............21
6. Processing at the Encapsulator .................................22
6.1. SNDU Encapsulation ........................................22
6.2. Procedure for Padding and Packing .........................24
7. Receiver Processing ............................................25
7.1. Idle State ................................................26
7.1.1. Idle State Payload Pointer Checking ................26
7.2. Processing of a Received SNDU .............................26
7.2.1. Reassembly Payload Pointer Checking ................28
7.3. Other Error Conditions ....................................28
8. Summary ........................................................29
9. Acknowledgements ...............................................29
10. Security Considerations .......................................29
11. IANA Considerations ...........................................30
11.1. IANA Guidelines ..........................................30
12. References ....................................................31
12.1. Normative References .....................................31
12.2. Informative References ...................................32
Appendix A. SNDU Packing Examples .................................35
Appendix B. SNDU Encapsulation ....................................40
1. Introduction
This document describes an encapsulation for the transport of IP
datagrams, or other network-layer packets, over ISO MPEG-2 Transport
Streams [ISO-MPEG2, RFC4259]. The encapsulation satisfies the
requirement for a lightweight encapsulation defined in section 4 of
[RFC4259]. The basic header provides the required set of protocol
fields. Extension headers may also be defined. This header
structure is significantly simpler to parse and process [SOOR05] than
current alternative methods (e.g., MPE [ETSI-DAT], which builds upon
the DSM-CC Table Section syntax [ISO-DSMCC]).
The encapsulation 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 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], and 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), such as Ethernet Frames, IP datagrams, or
other network-layer packets, used 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 one or more MPEG-2 Transport Stream (TS) Packets that are
sent over a single TS Logical Channel.
The MPEG-2 specification [ISO-MPEG2] requires that conformant TS
Multiplexes provide Program Specific Information (PSI) for each
stream in the TS Multiplex. Other MPEG-2-based transmission
standards may also define Service Information (SI).
A format_identifier value has been registered for ULE [ULE1]. This
32 bit number has a hexadecimal value of 0x554C4531. Transport
Streams that utilise the Programme Map Table (PMT) defined in ISO
13818-1 [ISO-MPEG2] and that use the ULE format defined in this
document, SHOULD insert a descriptor with this value in the PMT
ES_info descriptor loop. ULE Streams may also be identified by the
stream_type value of 0x91 [ATSC-REG] in a SI/PSI Table [ISO_MPEG2].
This information may allow Receivers and Re-multiplexors [RFC4259] to
locate a specific ULE Stream (i.e., the PID value of the TS Logical
Channel that carries a ULE Stream). The conditions under which this
information is required and the format in which it is to be provided
are beyond the scope of this document. Addressing and mapping issues
for ULE over MPEG-2 are also described in [IPDVB-AR].
2. Conventions Used in This Document
The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
Other terms used in this document are defined below:
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-MPEG2].
AFC: Adaptation Field Control [ISO-MPEG2]. 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.
b: bit. For example, one byte consists of 8b.
B: Byte. Groups of bytes are represented in Internet byte order.
DSM-CC: Digital Storage Media Command and Control [ISO-DSMCC]. A
format for transmission of data and control information in an MPEG-2
Private Section, defined by the ISO MPEG-2 standard.
DVB: Digital Video Broadcast. A framework and set of associated
standards published by the European Telecommunications Standards
Institute (ETSI) (e.g., [ETSI-DVBC, ETSI-DVBS, ETSI-DVBT]) for the
transmission of video, audio, and data using the ISO MPEG-2 Standard
[ISO-MPEG2].
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.
End Indicator: A value that indicates to the Receiver that there are
no further SNDUs present within the current TS Packet.
LLC: Logical Link Control [ISO-8802-2, IEEE-802.2]. A link-layer
protocol defined by the IEEE 802 standard, which follows the Ethernet
MAC Header.
MAC: Medium Access Control [IEEE-802.3]. A link-layer protocol
defined by the IEEE 802.3 standard (or by Ethernet v2 [DIX]).
MAC Header: The link-layer header of the IEEE 802.3 standard
[IEEE-802.3] or Ethernet v2 [DIX]. It consists of a 6B destination
address, 6B source address, and 2B Type field (see also NPA, LLC).
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/IEC 13818-1) [ISO-MPEG2], and ITU-T (in H.222
[ITU-H222]).
Next-Header: A Type value indicating an Extension Header.
NPA: Network Point of Attachment. In this document, refers to a
6-byte destination address (resembling an IEEE MAC address) within
the MPEG-2 transmission network that is used to identify individual
Receivers or groups of Receivers.
Packing Threshold: A period of time an Encapsulator is willing to
defer transmission of a partially filled TS-Packet to accumulate more
SNDUs, rather than use Padding. After the Packet Threshold period,
the Encapsulator uses Padding to send the partially filled TS-Packet.
Padding: A method that fills the remaining unused bytes in a TS
Packet payload using the specific pattern of 0xFF.
Payload Unit, PU. A sequence of bytes sent using a TS. Examples of
Payload Units include: an MPEG-2 Table Section or a ULE SNDU.
PDU: Protocol Data Unit. Examples of a PDU include Ethernet frames,
IPv4 or IPv6 datagrams, and other network packets.
PES: Packetized Elementary Steam [ISO-MPEG2]. A format of MPEG-2 TS
packet payload usually used for video or audio information.
PID: Packet Identifier [ISO-MPEG2]. 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 [ISO-MPEG2]. The TS Packets
forming the parts of a Table Section, PES, or other Payload Unit must
all carry the same PID value. The all-zeros PID 0x0000 as well as
other PID values are reserved for specific PSI/SI Tables [ISO-MPEG2].
The all-ones PID value 0x1FFF 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.
PP: Payload Pointer [ISO-MPEG2]. An optional one-byte pointer that
directly follows the 4-byte TS Packet header. It contains the number
of bytes that follow the Payload Pointer, up to the start of the
first Payload Unit (counted from the first byte of the TS Packet
payload field, and excluding the PP field itself). 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, Table
Sections, and ULE. It is not present in TS Logical Channels that use
the PES-format.
Private Section: A syntactic structure constructed in accordance with
Table 2-30 of [ISO-MPEG2]. The structure may be used to identify
private information (i.e., not defined by [ISO-MPEG2]) relating to
one or more elementary streams, or a specific MPEG-2 program, or the
entire Transport Stream. Other Standards bodies, e.g., ETSI, ATSC,
have defined sets of table structures using the private_section
structure. A Private Section is transmitted as a sequence of TS
Packets using a TS Logical Channel. A TS Logical Channel may carry
sections from more than one set of tables.
PSI: Program Specific Information [ISO-MPEG2]. Tables used to convey
information about the service carried in a TS Multiplex. The
information is carried in one of four specifically identified Table
Sections defined by MPEG-2 [ISO-MPEG2]. See also SI Table.
PU: Payload Unit.
PUSI: Payload_Unit_Start_Indicator [ISO-MPEG2]. 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).
Receiver: Equipment that processes the signal from a TS Multiplex and
performs filtering and forwarding of encapsulated PDUs to the
network-layer service (or bridging module when operating at the link
layer).
SI Table: Service Information Table [ISO-MPEG2]. In this document,
this term describes a table that is defined by another standards body
to convey information about the services carried in a TS Multiplex.
A Table may consist of one or more Table Sections; however, all
sections of a particular SI Table must be carried over a single TS
Logical Channel [ISO-MPEG2].
SNDU: SubNetwork Data Unit. An encapsulated PDU sent as an MPEG-2
Payload Unit.
Table Section: A Payload Unit carrying all or part of an SI or PSI
Table [ISO-MPEG2].
TS: Transport Stream [ISO-MPEG2], a method of transmission at the
MPEG-2 level using TS Packets; it represents layer 2 of the ISO/OSI
reference model. See also TS Logical Channel and TS Multiplex.
TS Header: The 4-byte header of a TS Packet [ISO-MPEG2]. Each 188B
TS Packet incorporates a 4B header with the following fields (those
referenced within this document are marked with *):
Field Length Name/Purpose
(in bits)
8b Synchronisation pattern equal to 0x47
*1b Transport Error Indicator
*1b Payload Unit Start Indicator (PUSI)
1b Transport Priority
*13b Packet IDentifier (PID)
2b Transport Scrambling Control
*2b Adaptation Field Control (AFC)
*4b Continuity Counter (CC)
If the PUSI bit is set to a value of 1, there is one
additional field following the TS packet header:
*8b Payload Pointer (PP)
TS Logical Channel: Transport Stream Logical Channel. In this
document, this term identifies a channel at the MPEG-2 level
[ISO-MPEG2]. It exists at level 2 of the ISO/OSI reference model.
All packets sent over a TS Logical Channel carry the same PID value
(this value is unique within a specific TS Multiplex). The term
"Stream" is defined in MPEG-2 [ISO-MPEG2] to describe the content
carried by a specific TS Logical Channel (see ULE Stream). Some PID
values are reserved (by MPEG-2) for specific signalling. Other
standards (e.g., ATSC, DVB) also reserve specific PID values.
TS Multiplex: In this document, this term defines a set of MPEG-2 TS
Logical Channels sent over a single lower-layer connection. This may
be a common physical link (i.e., a transmission at a specified symbol
rate, FEC setting, and transmission frequency) or an encapsulation
provided by another protocol layer (e.g., Ethernet, or RTP over IP).
The same TS Logical Channel may be repeated over more than one TS
Multiplex (possibly associated with a different PID value) [RFC4259];
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-MPEG2]. 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 TS Logical
Channels.
ULE Stream: An MPEG-2 TS Logical Channel that carries only ULE
encapsulated PDUs. ULE Streams may be identified by definition of a
stream_type in SI/PSI [ISO-MPEG2].
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 either by
being placed in the payload of a single TS Packet, or, if required,
by being 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 thereof), a practice sometimes known as
Packing. All TS Packets comprising an 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. A PUSI field with a value of 1 indicates the
start of at least one Payload Unit (SNDU) within the TS Packet
payload. The semantics of the PUSI bit are defined for PES and PSI
packets [ISO-MPEG2]; for private data, its use is not defined in the
MPEG-2 Standard. Although ULE uses private data, the operation
follows that of PSI packets. Hence, the following PUSI values are
defined:
0: The TS Packet does NOT contain the start of an SNDU, but
contains the continuation, or end, of an SNDU;
1: The TS Packet contains the start of an 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 intended to start another Payload Unit, a
stuffing procedure (known as Padding) fills the remainder of the TS
Packet payload with bytes with a value 0xFF [ISO-MPEG2].
A Receiver processing MPEG-2 Table Sections that receives a value of
0xFF in the first byte of a Table Section (table_Id) interprets this
as Padding/Stuffing 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. This adaptation field may extend the TS Packet Header
to carry timing and synchronisation information and may also be used
to include stuffing bytes before a TS Packet payload. 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’. For TS Logical Channels supporting ULE, Receivers MUST discard
TS Packets that carry other AFC values.
4. SNDU Format
PDUs are encapsulated using ULE to form an SNDU. (Each SNDU is an
MPEG-2 Payload Unit.) The encapsulation format to be used for PDUs is
illustrated below:
< ----------------------------- SNDU ----------------------------- >
+-+-------------------------------------------------------+--------+
|D| Length | Type | Dest Address* | PDU | CRC-32 |
+-+-------------------------------------------------------+--------+
Figure 1: SNDU Encapsulation (* optional Destination Address)
All multi-byte values in ULE (including the Length/End Indicator
(4.2,4.3), Type (4.4), Destination Address (4.5), and Extension
Headers (5)) are transmitted in network byte order (most significant
byte first). The most significant bit of each byte is placed in the
left-most position of the 8-bit field. Appendix A provides
informative examples of usage.
4.1. Destination Address Absent (D) Field
The most significant bit of the Length field carries the value of the
Destination Address Absent Field, the D-bit. A value of 0 indicates
the presence of the Destination Address Field (see section 4.5). A
value of 1 indicates that a Destination Address Field is not present.
An End Indicator (4.3) MUST be sent with a D-bit value of 1. Other
SNDUs MAY be sent with a D-bit value of 0 or 1. The default method
SHOULD use a D-bit value of 0 (see section 4.5).
4.2. Length Field
A 15-bit value that indicates the length, in bytes, of the SNDU
counted from the byte following the Type field of the SNDU base
header (figure 9) up to and including the CRC. This Length includes
the size of any extension headers that may be present (section 5).
Note the special case described in section 4.3.
4.3. End Indicator
When the first two bytes following an SNDU have the value 0xFFFF,
this denotes an End Indicator (i.e., all ones length combined with a
D-bit value of 1). This indicates to the Receiver that there are no
further SNDUs present within the current TS Packet (see section 6),
and that no Destination Address Field is present. The value 0xFF has
specific semantics in MPEG-2 framing, where it is used to indicate
the presence of Padding. This use resembles [ISO-DSMCC].
4.4. Type Field
The 16-bit Type field indicates the type of payload carried in an
SNDU, or the presence of a Next-Header. The set of values that may
be assigned to this field is divided into two parts, similar to the
allocations for Ethernet.
EtherTypes were originally specified by Xerox under the Ethernet v2
Specification [DIX]. After specification of IEEE 802.3 [IEEE-802.3,
ISO-8802-2], the set of EtherTypes less than 1536 (0x0600) assumed
the role of a length indicator. Ethernet receivers use this feature
to discriminate LLC format frames. Hence, any IEEE EtherType < 1536
indicates an LLC frame, and the actual value indicates the length of
the LLC frame.
There is a potential ambiguous case when a Receiver receives a PDU
with two Length fields: The Receiver would need to validate the
actual length and the Length field and ensure that inconsistent
values are not propagated by the network. Specification of two
independent Length fields is therefore undesirable. In the ULE
header, this is avoided in the SNDU header by including only one
length value, but bridging of LLC frames re-introduces this
consideration (section 5.2).
The Ethernet LLC mode of identification is not required in ULE, since
the SNDU format always carries an explicit Length field, and
therefore the procedure in ULE is modified, as below:
The first set of ULE Type field values comprise the set of values
less than 1536 in decimal. These Type field values are IANA assigned
(see section 4.4.1) and indicate the Next-Header.
The second set of ULE Type field values comprise the set of values
greater than or equal to 1536 in decimal. In ULE, this value is
identical to the corresponding type codes specified by the IEEE/DIX
type assignments for Ethernet and recorded in the IANA EtherType
registry.
4.4.1. Type 1: Next-Header Type Fields
The first part of the Type space corresponds to the values 0 to 1535
decimal. These values may be used to identify link-specific
protocols and/or to indicate the presence of Extension Headers that
carry additional optional protocol fields (e.g., a bridging
encapsulation). Use of these values is co-ordinated by an IANA
registry. The following types are defined in this document:
0x0000: Test SNDU (see section 5.1)