decimal or 0x1FFF in hexadecimal, some of which are reserved for
transmission of SI tables. Non-reserved TS Logical Channels may be
used to carry audio [ISO-AUD], video [ISO-VID], IP packets
[ISO-DSMCC, ETSI-DAT, ATSC-DAT], or other data [ISO-DSMCC, ETSI-DAT,
ATSC-DAT]. The value 8191 decimal (0x1FFF) indicates a null packet
that is used to maintain the physical bearer bit rate when there are
no other MPEG-2 TS packets to be sent.
TS-LC-A-1 /---\--------------------/---\
\ / \ / \
\ | | | |
TS-LC-A-2 ----------- | | -------------
-------------------- | | -------------
| | | |
/-------- / | -------------
/ \----/-------------------\----/
TS-LC-A-3/ MPEG-2 TS MUX A
/
TS-LC /
------------X
\ TS-LC-B-3 /---\------------------------/---\
\ / \ / \
\ | | | |
TS-LC-B-2 \----------- | | ---------
-------------------- | | ---------
| | | |
/-------- / | ---------
/ \----/-----------------------\----/
/ MPEG-2 TS MUX B
TS-LC-B-1
Figure 2: Example showing MPEG-2 TS Logical Channels carried
Over 2 MPEG-2 TS Multiplexes.
TS Logical Channels are independently numbered on each MPEG-2 TS
Multiplex (MUX). In most cases, the data sent over the TS Logical
Channels will differ for different multiplexes. Figure 2 shows a set
of TS Logical Channels sent using two MPEG-2 TS Multiplexes (A and
B).
There are cases where the same data may be distributed over two or
more multiplexes (e.g., some SI tables; multicast content that needs
to be received by Receivers tuned to either MPEG-2 TS; unicast data
where the Receiver may be in either/both of two potentially
overlapping MPEG-2 transmission cells). In figure 2, each multiplex
carries 3 MPEG-2 TS Logical Channels. These TS Logical Channels may
differ (TS-LC-A-1, TS-LC-A-2, TS-LC-B-2, TS-LC-B-1), or may be common
to both MPEG-2 TS Multiplexes (i.e., TS-LC-A-3 and TS-LC-B-3 carry
identical content).
As can been seen, there are similarities between the way PIDs are
used and the operation of virtual channels in ATM. However, unlike
ATM, a PID defines a unidirectional broadcast channel and not a
point-to-point link. Contrary to ATM, there is, as yet, no specified
standard interface for MPEG-2 connection setup, or for signaling
mappings of IP flows to PIDs, or to set the Quality of Service, QoS,
assigned to a TS Logical Channel.
3.3. Multiplexing and Re-Multiplexing
In a simple example, one or more TS Logical Channels are processed by
an MPEG-2 multiplexor, resulting in a TS Multiplex. The TS Multiplex
is forwarded over a physical bearer towards one or more Receivers
(Figure 3).
In a more complex example, the same TS may be fed to multiple MPEG-2
multiplexors and these may, in turn, feed other MPEG-2 multiplexors
(remultiplexing). Remultiplexing may occur in several places (and is
common in Scenarios A and B of Section 3.1). One example is a
satellite that provides on-board processing of the TS packets,
multiplexing the TS Logical Channels received from one or more uplink
physical bearers (TS Multiplex) to one (or more in the case of
broadcast/multicast) down-link physical bearer (TS Multiplex). As
part of the remultiplexing process, a remultiplexor may renumber the
PID values associated with one or more TS Logical Channels to prevent
clashes between input TS Logical Channels with the same PID carried
on different input multiplexes. It may also modify and/or insert new
SI data into the control plane.
In all cases, the final result is a "TS Multiplex" that is
transmitted over the physical bearer towards the Receiver.
+------------+ +------------+
| IP | | IP |
| End Host | | End Host |
+-----+------+ +------------+
| ^
+------------>+---------------+ |
+ IP | |
+-------------+ Encapsulator | |
SI-Data | +------+--------+ |
+-------+-------+ |MPEG-2 TS Logical Channel |
| MPEG-2 | | |
| SI Tables | | |
+-------+-------+ ->+------+--------+ |
| -->| MPEG-2 | . . .
+------------>+ Multiplexor | |
MPEG-2 TS +------+--------+ |
Logical Channel |MPEG-2 TS Mux |
| |
Other ->+------+--------+ |
MPEG-2 -->+ MPEG-2 | |
TS --->+ Multiplexor | |
---->+------+--------+ |
|MPEG-2 TS Mux |
| |
+------+--------+ +------+-----+
|Physical Layer | | MPEG-2 |
|Modulator +---------->+ Receiver |
+---------------+ MPEG-2 +------------+
TS Mux
Figure 3: An example configuration for a unidirectional
Service for IP transport over MPEG-2
3.4. IP Datagram Transmission
Packet data for transmission over an MPEG-2 Transport Multiplex is
passed to an Encapsulator, sometimes known as a Gateway. This
receives Protocol Data Units, PDUs, such as Ethernet frames or IP
packets, and formats each into a Sub-Network Data Unit, SNDU, by
adding an encapsulation header and trailer (see Section 4). The
SNDUs are subsequently fragmented into a series of TS Packets.
To receive IP packets over an MPEG-2 TS Multiplex, a Receiver needs
to identify the specific TS Multiplex (physical link) and also the TS
Logical Channel (the PID value of a logical link). It is common for
a number of MPEG-2 TS Logical Channels to carry SNDUs; therefore, a
Receiver must filter (accept) IP packets sent with a number of PID
values, and must independently reassemble each SNDU.
A Receiver that simultaneously receives from several TS Logical
Channels must filter other unwanted TS Logical Channels by employing,
for example, specific hardware support. Packets for one IP flow
(i.e., a specific combination of IP source and destination addresses)
must be sent using the same PID. It should not be assumed that all
IP packets are carried on a single PID, as in some cable modem
implementations, and multiple PIDs must be allowed in the
architecture. Many current hardware filters limit the maximum number
of active PIDs (e.g., 32), although if needed, future systems may
reasonably be expected to support more.
In some cases, Receivers may need to select TS Logical Channels from
a number of simultaneously active TS Multiplexes. To do this, they
need multiple physical receive interfaces (e.g., radio frequency (RF)
front-ends and demodulators). Some applications also envisage the
concurrent reception of IP Packets over other media that may not
necessarily use MPEG-2 transmission.
Bidirectional (duplex) transmission can be provided using an MPEG-2
Transmission Network by using one of a number of alternate return
channel schemes [ETSI-RC]. Duplex IP paths may also be supported
using non-MPEG-2 return links (e.g., in Scenarios B-D of section
3.1). One example of such an application is that of UniDirectional
Link Routing, UDLR [RFC3077].
3.5. Motivation
The network layer protocols to be supported by this architecture
include:
(i) IPv4 Unicast packets, destined for a single end host
(ii) IPv4 Broadcast packets, sent to all end systems in an IP
network
(iii) IPv4 Multicast packets
(iv) IPv6 Unicast packets, destined for a single end host
(v) IPv6 Multicast packets
(vi) Packets with compressed IPv4 / IPv6 packet headers (e.g.,
[RFC2507, RFC3095])
(vii) Bridged Ethernet frames
(viii) Other network protocol packets (MPLS, potential new protocols)
The architecture will provide:
(i) Guidance on which MPEG-2 features are pre-requisites for the
IP service, and identification of any optional fields that
impact performance/correct operation.
(ii) Standards to provide an efficient and flexible encapsulation
scheme that may be easily implemented in an Encapsulator or
Receiver. The payload encapsulation requires a type field for
the SNDU to indicate the type of packet and a mechanism to
signal which encapsulation is used on a certain PID.
(iii) Standards to associate a particular IP address with a Network
Point of Attachment (NPA) that could or may not be a MAC
Address. This process resembles the IPv4 Address Resolution
Protocol, ARP, or IPv6 Neighbor Discovery, ND, protocol
[IPDVB-AR]. In addition, the standard will be compatible with
IPv6 autoconfiguration.
(iv) Standards to associate an MPEG-2 TS interface with one or more
specific TS Logical Channels (PID, TS Multiplex). Bindings
are required for both unicast transmission, and multicast
reception. In the case of IPv4, this must also support
network broadcast. To make the schemes robust to loss and
state changes within the MPEG-2 transmission network, a soft-
state approach may prove desirable.
(v) Standards to associate the capabilities of an MPEG-2 TS
Logical Channel with IP flows. This includes mapping of QoS
functions, such as IP QoS/DSCP and RSVP, to underlying MPEG-2
TS QoS, multi-homing and mobility. This capability could be
associated by the AR standard proposed above.
(vi) Guidance on Security for IP transmission over MPEG-2. The
framework must permit use of IPsec and clearly identify any
security issues concerning the specified protocols. The
security issues need to consider two cases: unidirectional
transfer (in which communication is only from the sending IP
end host to the receiving IP end host) and bidirectional
transfer. Consideration should also be given to security of
the TS Multiplex: the need for closed user groups and the use
of MPEG-2 TS encryption.
(vii) Management of the IP transmission, including standardized SNMP
MIBs and error reporting procedures. The need for and scope
of this is to be determined.
The specified architecture and techniques should be suited to a range
of systems employing the MPEG-2 TS, and may also suit other
(sub)networks offering similar transfer capabilities.
The following section, 4, describes encapsulation issues. Sections 5
and 6 describe address resolution issues for unicast and multicast,
respectively.
4. Encapsulation Protocol Requirements
This section identifies requirements and provides examples of
mechanisms that may be used to perform the encapsulation of IPv4/v6
unicast and multicast packets over MPEG-2 Transmission Networks.
A network device, known as an Encapsulator receives PDUs (e.g., IP
Packets or Ethernet frames) and formats these into Subnetwork Data
Units, SNDUs. An encapsulation (or convergence) protocol transports
each SNDU over the MPEG-2 TS service and provides the appropriate
mechanisms to deliver the encapsulated PDU to the Receiver IP
interface.
In forming an SNDU, the encapsulation protocol typically adds header
fields that carry protocol control information, such as the length of
SNDU, Receiver address, multiplexing information, payload type,
sequence numbers, etc. The SNDU payload is typically followed by a
trailer, which carries an Integrity Check (e.g., Cyclic Redundancy
Check, CRC). Some protocols also add additional control information
and/or padding to or after the trailer (figure 4).
+--------+-------------------------+-----------------+
| Header | PDU | Integrity Check |
+--------+-------------------------+-----------------+
<--------------------- SNDU ------------------------->
Figure 4: Encapsulation of a subnetwork PDU (e.g., IPv4 or IPv6
packet) to form an MPEG-2 Payload Unit.
Examples of existing encapsulation/convergence protocols include ATM
AAL5 [ITU-AAL5] and MPEG-2 MPE [ETSI-DAT].
When required, an SNDU may be fragmented across a number of TS
Packets (figure 5).
+-----------------------------------------+
|Encap Header|SubNetwork Data Unit (SNDU) |
+-----------------------------------------+
/ / \ \
/ / \ \
/ / \ \
+------+----------+ +------+----------+ +------+----------+
|MPEG-2| MPEG-2 |..|MPEG-2| MPEG-2 |...|MPEG-2| MPEG-2 |
|Header| Payload | |Header| Payload | |Header| Payload |
+------+----------+ +------+----------+ +------+----------+
Figure 5: Encapsulation of a PDU (e.g., IP packet) into a
Series of MPEG-2 TS Packets. Each TS Packet carries
a header with a common Packet ID (PID) value denoting
the MPEG-2 TS Logical Channel.
The DVB family of standards currently defines a mechanism for
transporting an IP packet, or Ethernet frame using the Multi-Protocol
Encapsulation (MPE) [ETSI-DAT]. An equivalent scheme is also
supported in ATSC [ATSC-DAT, ATSC-DATG]. It allows transmission of
IP packets or (by using LLC) Ethernet frames by encapsulation within
a Table Section (with the format used by the control plane associated
with the MPEG-2 transmission). The MPE specification includes a set
of optional header components and requires decoding of the control
headers. This processing is suboptimal for Internet traffic, since
it incurs significant receiver processing overhead and some extra
link overhead [CLC99].
The existing standards carry heritage from legacy implementations.
These have reflected the limitations of technology at the time of
their deployment (e.g., design decisions driven by audio/video
considerations rather than IP networking requirements). IPv6, MPLS,
and other network-layer protocols are not natively supported.
Together, these justify the development of a new encapsulation that
will be truly IP-centric. Carrying IP packets over a TS Logical
Channel involves several convergence protocol functions. This
section briefly describes these functions and highlights the
requirements for a new encapsulation.
4.1. Payload Unit Delimitation
MPEG-2 indicates the start of a Payload Unit (PU) in a new TS Packet
with a "payload_unit_start_indicator" (PUSI) [ISO-MPEG] carried in
the 4B TS Packet header. The PUSI is a 1 bit flag that has normative
meaning [ISO-MPEG] for TS Packets that carry PES Packets or PSI/SI
data.
When the payload of a TS Packet contains PES data, a PUSI value of
’1’ indicates the TS Packet payload starts with the first byte of a
PES Packet. A value of ’0’ indicates that no PES Packet starts in
the TS Packet. If the PUSI is set to ’1’, then one, and only one,
PES Packet starts in the TS Packet.
When the payload of the TS Packet contains PSI data, a PUSI value of
’1’ indicates the first byte of the TS Packet payload carries a
Payload Pointer (PP) that indicates the position of the first byte of
the Payload Unit (Table Section) being carried; if the TS Packet does
not carry the first byte of a Table Section, the PUSI is set to ’0’,
indicating that no Payload Pointer is present.
Using this PUSI bit, the start of the first Payload Unit in a TS
Packet is exactly known by the Receiver, unless that TS Packet has
been corrupted or lost in the transmission. In which case, the
payload is discarded until the next TS Packet is received with a PUSI
value of ’1’.
The encapsulation should allow packing of more than one SNDU into the
same TS Packet and should not limit the number of SNDUs that can be
sent in a TS Packet. In addition, it should allow an IP Encapsulator
to insert padding when there is an incomplete TS Packet payload. A
mechanism needs to be identified to differentiate this padding from
the case where another encapsulated SNDU follows.
A combination of the PUSI and a Length Indicator (see below) allows
an efficient MPEG-2 convergence protocol to receive accurate
delineation of packed SNDUs. The MPEG-2 standard [ISO-MPEG] does not
specify how private data should use the PUSI bit.
4.2. Length Indicator
Most services using MPEG-2 include a length field in the Payload Unit
header to allow the Receiver to identify the end of a Payload Unit
(e.g., PES Packet, Section, or an SNDU).
When parts of more than two Payload Units are carried in the same TS
Packet, only the start of the first is indicated by the Payload
Pointer. Placement of a Length Indicator in the encapsulation header
allows a Receiver to determine the number of bytes until the start of
the next encapsulated SNDU. This placement also provides the
opportunity for the Receiver to pre-allocate an appropriate-sized
memory buffer to receive the reassembled SNDU.
A Length Indicator is required, and should be carried in the
encapsulation header. This should support SNDUs of at least the MTU
size offered by Ethernet (currently 1500 bytes). Although the IPv4
and IPv6 packet format permits an IP packet of size up to 64 KB, such
packets are seldom seen on the current Internet. Since high speed
links are often limited by the packet forwarding rate of routers,
there has been a tendency for Internet core routers to support MTU
values larger than 1500 bytes. A value of 16 KB is not uncommon in
the core of the current Internet. This would seem a suitable maximum
size for an MPEG-2 transmission network.
4.3. Next Level Protocol Type
Any IETF-defined encapsulation protocol should identify the payload
type being transported (e.g., to differentiate IPv4, IPv6, etc).
Most protocols use a type field to identify a specific process at the
next higher layer that is the originator or the recipient of the
payload (SNDU). This method is used by IPv4, IPv6, and also by the
original Ethernet protocol (DIX). OSI uses the concept of a