Internet Engineering Task Force Gorry Fairhurst
Internet Draft University of Aberdeen, U.K.
Document: draft-fair-ipdvb-req-04.txt Horst D. Clausen
Bernhard Collini-Nocker
Hilmar Linder
University of Salzburg, A
Category: Informational December 2003
Requirements for transmission of IP datagrams over MPEG-2 networks
Status of this Memo
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
This document describes a framework 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. Examples
include the Digital Video Broadcast (DVB) and Advanced Television
Systems Committee (ATSC) Standards for Digital Television.
It identifies the need for a set of Internet standards defining the
interface between the MPEG-2 Transport Stream and an IP subnetwork.
It suggests a new encapsulation method for IP datagrams, and
proposes protocols to perform IPv6/IPv4 resolution, to associate IP
packets with the properties of the Logical Channels provided by an
MPEG-2 TS.
Expires June 2004 [page 1]
INTERNET DRAFT Requirements for IP transport over DVB December 2003
Table of Contents
1. Introduction
2. Conventions used in this document
3. Motivation
4. IP Transport Service.
5. Encapsulation Protocol Requirements
6. Address Resolution Functions
7. Multicast Support
8. Examples of Usage
9. Summary
10. Security Considerations
11. Acknowledgments
12. References
>>> To be completed. <<<
Expires June 2003 [page 2]
INTERNET DRAFT Requirements for IP transport over DVB December 2003
Document History
-00 This draft is intended as a study item for proposed future work
by the IETF in this area.
-01 This draft has been expanded with additional rationale for the
simple encapsulation described in [ID-IPDVB-Enc].
-02a Comments received from Isabel Amonou, May 2002. Corrections to
spelling. Addition of section filter. Addition of first draft of
text on Śaddressed areaŽ in arp.
-02b GF Added some long-awaited figures
-02c GF Added text on section processing in MPE
-03a GF Updated text June 2003, comments from Bernhard C-N.
Abstract shortened
Description generalised to all MPEG-2 TS networks;-)
Improved discussion of PES / PUSI
Subtle title change
-03b GF updated to reflect ULE [ID-IPDVB-ULE].
IPv6 terminology improved.
-03c GF formatting for ID.
>>> 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
Further input is requested to refine these requirements and to
identify details of the other proposed protocols within this
framework. <<<
-04a NiTs following IETF-57 BOF
-04b Updated section on encapsulation.
New section numbering
New summary section
-04d Aligned with charter and reduced discussion on MPE/ULE/etc
-04e rewritten conclusion.
-04e feedback from various people on DVB address resolution process
-04f new address resolution section.
Expires June 2003 [page 3]
INTERNET DRAFT Requirements for IP transport over DVB December 2003
1. Introduction
This document identifies requirements for a framework for transport
of IP Datagrams over ISO MPEG-2 Transport Streams [MPEG2]. The
framework is also designed to be compatible with 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]).
+---------+-+-+-+-+------+--------+---+--+--+
| |T|V|A|O| O | | O |S |O |
| |e|i|u|t| t | | t |I |t |
|Other |l|d|d|h| h | IP | h | |h |
|protocols|e|e|i|e| e | | e |T |e |
|native |t|o|o|r| r | | r |a |r |
|over |e| | | | | | |b | |
|MPEG-2 TS|x| | | | | +----+-+ |l | |
| |t| | | | | | MPE | |e | |
| | | | | | +--+---+------+ | | |
| | | | | | | AAL5 |Priv. | | | |
| +-+-+-+-+---+------+ +-+--+--+
| | PES | ATM |Sect. |Section|
+---------+-------+----------+------+-------+
| MPEG-2 TS |
+---------+-------+-------+-----------------+
|Satellite| Cable | D-TV | Other PHY |
+---------+-------+-------+-----------------+
Figure 1: Overview of the MPEG-2 protocol stack
Although many MPEG-2 systems carry a mixture of types of data, MPEG-
2 components may, and are, also used to build IP-only networks. In
this case, standard system components offer advantages of mass
market and improved interoperability. Such networks often do not
implement all parts of a DVB / ATSC system, and may for instance
support minimal, or no, signalling of Service Information (SI)
tables.
1.1 TS Logical Channels
The service provided by an MPEG-2 transport multiplex offers a
number of parallel TS Logical Channels. Each MPEG-2 TS logical
channel is uniquely identified by the Packet ID, PID, value carried
in the header of each MPEG-2 TS Packet. 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-
Expires June 2003 [page 4]
INTERNET DRAFT Requirements for IP transport over DVB December 2003
VID], IP packets [ISO-DSMCC; ETSI-DAT; ATSC-DAT], or other data
[ISO-DSMCC; ETSI-DAT; ATSC-DAT]. The value 8191 indicates a null
packet, 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
Mux. In most cases the data sent over the TS Logical Channels will
differ for different multiplexes. The above figure shows 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 which
needs to be received by Receivers tuned to either MPEG-2 TS; unicast
data were the Receiver may be in either/both two potentially
overlapping MPEG-2 transmission cells). In figure 2, each multiplex
carries 3 MPEG-2 TS Logical Channels. These 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).
Similarities in the way PIDs are used may be observed with the
operation of virtual channels in ATM, however, unlike ATM, a PID
defines a unidirectional broadcast channel and not a point-to-point
link; there is, as yet, no specified interface for connection setup,
or for signalling mappings of IP flows to PIDs, or to set the
Quality of Service, QoS, assigned to an TS Logical Channel.
Expires June 2003 [page 5]
INTERNET DRAFT Requirements for IP transport over DVB December 2003
1.2 MPEG-2 Transmission Networks
Packet data for transmission over the MPEG-2 transport multiplex is
passed to an encapsulator. This receives Sub-Network Data Units,
SNDUs (e.g., Ethernet frames or IP packets) and formats each SNDU
into a series of TS Packets adding an encapsulation header and
trailer (see section 5).
There are many possible topologies for the MPEG-2 Transmission
Network. In a simple example, one or more TS are processed by a
MPEG-2 multiplexor resulting in a TS Multiplex. That is forwarded
over a physical bearer towards one or more Receivers. See figure 3.
+------------+ +------------+
| 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 uni-directional service
for IP transport over MPEG-2
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. One
example is a satellite that provides on-board processing of the TS
packets, multiplexing the TS Logical Channels received from one or
Expires June 2003 [page 6]
INTERNET DRAFT Requirements for IP transport over DVB December 2003
more up-link 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.
In all cases, the final result is a "TS Multiplex" which is
transmited over the physical bearer towards the Receiver.
To receive IP packets sent over a MPEG-2 transport multiplex, a
Receiver needs to identify the specific TS Multiplex (physical link)
and also the TS Logical Channel (i.e. PID value of a logical link).
It is common for a number of MPEG-2 TS Logical Channels to carry
SNDUs, and a Receiver must therefore 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, may utilise receiver hardware to filter other unwanted TS
Logical Channels. 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, multiple PIDs must be allowed. Most
Receivers currently have a limit on 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., 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).
Bi-directional (duplex) transmission can be provided using a MPEG-2
transmission network by using one of a number of alternate return
channel schemes [DVB-RC]. Duplex IP paths may also be supported
using non-MPEG-2 return links. One example of such an application is
that of Uni-Directional Link Routing, UDLR [RFC3077].
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]. This scheme is also
supported in ATSC [ATSC-DAT; ATSC-DATG]]. It allows transmission of
IP packets or Ethernet style frames in the control plane associated
with audio/video transport. Data is formatted as if it were a table
section. It includes a set of optional header components and
requires decoding of the control headers. This processing is
therefore not optimal for IP, since it incurs significant receiver
processing overhead and some extra link overhead [CLC99].
Expires June 2003 [page 7]
INTERNET DRAFT Requirements for IP transport over DVB December 2003
+-----------------------------------------+
|Encap Header| Subnetwork DU |
+-----------------------------------------+
/ / \ \
/ / \ \
/ / \ \
+------+----------+ +------+----------+ +------+----------+
|MPEG-2| MPEG-2 |..|MPEG-2| MPEG-2 |...|MPEG-2| MPEG-2 |
|Header| Payload | |Header| Payload | |Header| Payload |
+------+----------+ +------+----------+ +------+----------+
Figure 4: Encapsulation of an SNDU (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 complete MPEG-2 transmission network may be managed by a
transmission service operator. In such cases, the assignment of
addresses and TS Logical Channels at Receivers are usually under the
control of the service operator. Examples of this include a TV
distribution network, or ISP offering an Internet service to her
customers. MPEG-2 transmission networks are also used for private
networks. These typically involve a smaller number of terminals and
do not require the same level of centralised control as a managed
network. Examples of this include companies wishing to link DVB-
capable routers to form links within an Internet subnetwork.
1.3 Proposed Framework
The framework proposed in this document describes a set of protocols
to support transmission of IP packets over the MPEG-2 TS. A key
characteristic of these networks is that they may provide link-level
broadcast capability, and many applications require support for very
large numbers of subnetwork nodes. Some or all of these protocols
may also be applicable to other subnetworks, e.g,. other MPEG-2
transmission networks, regenerative satellite links [ETSI-BSM], and
some types of broadcast wireless links. The key goals are to reduce
complexity when using the system, while improving performance,
increasing flexibility, and providing opportunities for better
integration with IP Internet services.
Since most MPEG-2 transmission networks are bandwidth-limited, the
framework needs to be simple, robust, extensible (i.e. provide support
for a range of link services), and have good link efficiency (i.e.
small overhead). Supporting protocols need to provide resolution of IP
flows to the TS Logical Channels provided by the MPEG-2 TS. The Logical
Channels provide multiplexing, addressing, and error reporting. The
Logical Channel is also the basis of providing Quality of Service
(QoS). Mapping functions are required to relate this to IP-level QoS.
A key goal will be to provide functions in a dynamic way, permitting
integration with other IP protocols. Collectively, these form MPEG-2 TS
address resolution.
Expires June 2003 [page 8]
INTERNET DRAFT Requirements for IP transport over DVB December 2003
2. Conventions used in this document
ACK: A cumulative TCP acknowledgment. In this document, this term
refers to a TCP segment (packet) that carries a cumulative
acknowledgement (ACK), but no data.
Adaptation Field: Option control overhead or padding associated with
an MPEG-2 TS Packet. Examples of overhead are: TS Logical Channel
encryption details and clock (PCR) information to synchronise a set
of TS Logical Channels.
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.
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 that receives Ethernet frames or IP
packets, 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 (see also NPA).
MPE: Multiprotocol Encapsulation [ETSI-DAT]. A scheme that
encapsulates Ethernet frames or IP Packets, 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].
NPA: Network Point of Attachment. Addresses primarily used for
station (Receiver) identification within a local network (e.g. IEEE
MAC address).
PES: Programme Elementary Stream. A format of MPEG-2 TS packet
payload usually used for video or audio information in MPEG-2 [ISO-
MPEG].
Expires June 2003 [page 9]
INTERNET DRAFT Requirements for IP transport over DVB December 2003
PID: Packet Identifier. A 13-bit field carried in the header of all
MPEG-2 Transport Stream packets [ISO-MPEG]. This is used to identify
the TS Logical Channel to which it belongs. A PID of 8191 indicates
a null packet that must be discarded by a Receiver.
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.
STB: Set Top Box. A consumer equipment (Receiver) for reception of
digital TV services.
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 TS Logical Channels sent over a single
common physical bearer (i.e. a link transmitting 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 a
pointer to the next payload header (PUSI), and an adaptation field.
Each TS packet carries a PID value to associate it with a single TS
Logical Channel.
Expires June 2003 [page 10]
INTERNET DRAFT Requirements for IP transport over DVB December 2003
3. Motivation
The network layer protocols to be supported by this framework are:
(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.
[RFC1114; RFC2507; RFC3095])
(vii) Bridged Ethernet frames
The framework describes:
(i) The framework will offer guidance on which MPEG-2 features
are pre-requisites for this service, and any optional fields
that impact performance/correct operation.
(ii) Standards will be defined to provide an efficient and
flexible encapsulation scheme that may be easily implemented
in an Encapsulator or Receiver. The framework must support
IPv4 and IPv6 network protocols, and should support alternate
payloads ± such as bridged, compressed packets, and extension
options. The payload encapsulation requires a type field for
the SNDU to indicate the type of packet.
(iii) Standards will be defined to associate a particular IP
address with a Network Point of Attachment (NPA) (e.g. a MAC
Address). This process resembles the IPv4 Address Resolution
Protocol, ARP, or IPv6 Neighbour Discovery, ND, protocol [AR-
DRAFT]. The standard must be compatible with IPv6
autoconfiguration.
(iv) Standards will be defined to associate a 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. This could be implemented via descriptors sent in
the SI tables (e.g. using the existing MPEG-2 control plane),
via one or more new SI tables, or in-band by a protocol using
a data channel (e.g. utilising UDP) [AR-DRAFT].
(v) Existing standards do not address many areas, which are
desirable for Internet Service provision, (e.g., mapping of
QoS functions, such as IP QoS/DSCP and RSVP, to under-lying
MPEG-2 TS QoS, multi-homing and mobility). The need for and
scope of this is to be determined.
Expires June 2003 [page 11]
INTERNET DRAFT Requirements for IP transport over DVB December 2003
(vi) Security. 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 bi-
directional 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. There may be a need for standardised SNMP MIBs
and error reporting procedures. The need for and scope of
this is to be determined.
The specified framework and techniques to be developed should be suited
to a range of systems employing the MPEG-2 TS, and may also suit other
(sub)networks offering similar transfer capabilities.
Sections 4 and 5 describe encapsulation issues. Sections 6 and 7
desctribe address resolution issues for unicast and multicast. Section
8 provides some examples of use.
Expires June 2003 [page 12]
INTERNET DRAFT Requirements for IP transport over DVB December 2003
4. IP Transport Service.
The section identifies key needs and provides examples of mechanisms
that may be used to perform the encapsulation of IPv4 and IPv6
multicast and unicast packets over MPEG-2 transmission networks.
4.1 Options for Encapsulation
To transmit packet data over an MPEG-2 transmission network requires
that individual SNDUs (e.g. IPv4, IPv6 packets, or bridged Ethernet
Frames) are encapsulated using a convergence protocol. The following
encapsulations are currently standardised for MPEG-2 transmission
networks:
(i) Multi-Protocol Encapsulation (MPE).
The Multi-Protocol Encapsulation, MPE, specification of DVB
[ETSI-DAT] uses private Sections for the transport of IP
packets and uses encapsulation that is similar to the IEEE
LAN/MAN standards [LLC]. Data packets are encapsulated in
datagram sections that are compliant with the DSMCC section
format for private data. Some Receivers may exploit section-
processing hardware to perform a first-level filter of the
packets that arrive at the Receiver.
The section header also includes fields, which may be used by
a Receiver to filter datagrams assigned to the same TS
Logical Channel. This feature allows several logical
networks to be established without assigning PID values to
each of the services. Section filtering is especially well
suited for TV broadcast environments where remultiplexing
comes into play.
This encapsulation makes use of a MAC-level network point of
attachment address. The address format conforms to the
ISO/IEEE standards for LAN/MAN LLC]. The 48-bit MAC address
field contains the MAC address of the destination; it is
distributed over six 8-bit fields, labeled MAC_address_1 to
MAC_address_6. The MAC_address_1 field contains the most
significant byte of the MAC address, while MAC_address_6
contains the least significant byte. How many of these bytes
are significant is optional and defined by the value of the
broadcast descriptor table [SI-DAT] sent separately over
another MPEG-2 TS within the TS multiplex.
MPE is currently a widely used scheme. Due to investments in
existing equipment, usage is likely to continue in some
applications in current and future networks.
Expires June 2003 [page 13]
INTERNET DRAFT Requirements for IP transport over DVB December 2003
(ii) Data Piping.
The Data Piping profile [ETSI-DAT] is a minimum overhead,
simple and flexible profile that makes no assumptions
concerning the format of the data being sent. In this
profile, the Receiver is intended to provide PID filtering,
packet reassembly according to [DVB-SIDAT-368], error
detection and optional Conditional Access (link encryption).
The specification allows the user data stream to be
unstructured or organized into packets. The specific
structure is transparent to the Receiver. It may conform to
any protocol, e.g., IP, Ethernet, NFS, FDDI, MPEG-2 PES, etc.
The ULE specification [IPDVB-ULE] is an example of protocol
that uses this profile.
(iii) Data Streaming.
The data broadcast specification profile [ETSI-DAT] for PES
tunnels (Data Streaming) supports unicast and multicast data
services that require a stream-oriented delivery of data
packets. This encapsulation maps an IP packet into a single
PES Packet payload Data Streaming is intended to handle a
single stream of data at a high data rate using standard
demultiplexing ICs (e.g. developed for STBs) that have been
designed for video streams. Transporting data packets at the
PES level offers the benefits of PES layer functions
integrated into the chip sets, e.g. handling of program
specific information (tables), scrambling and synchronization
with other TS.
The standard PES Packet as defined in table 2-18 of [ISO-
MPEG] can also be used as a container for data packets. The
two values for the stream_id are "private_stream_1" and
"private_stream_2". The private_stream_2 permits the use of
the short PES header with limited overhead. This makes it
attractive for publicly accessible multicast distribution
services. The private_stream_1 makes available the scrambling
control and the timing and clock reference features of the
PES layer. The "PES_data_packet_header_length" will be used
in this context to insert stuffing bytes. This is an
important aspect since the payload can be aligned to 32-bit
word boundaries.
When the "data_identifier" field is used in conjunction with
the first 4 bits of the "sub_stream_id" field it forms a 12
bit field. This carries a descriptor of the next level
protocol. The list of protocol codes will be managed by
[EUTELSAT], and the values of the part stored into the
"data_identifier" field will be in the range 0x80-0xFF
(assigned by DVB as user defined). The remaining 4 bits of
the "sub_stream_id" field are used for storing the current
version of the encapsulation format.
Expires June 2003 [page 14]
INTERNET DRAFT Requirements for IP transport over DVB December 2003
5. Encapsulation Protocol Requirements
The aim of a encapsulation protocol is to transport a SNDU over the
MPEG-2 TS service and provide the appropriate mechanisms to deliver
this to the Receiver IP interface. A convergence protocol typically
adds header fields before a SNDU that carry protocol control
information (e.g., length of SNDU, Receiver address, multiplexing
information, payload type, sequence numbers). 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.
+--------+-------------------------+-----------------+
| Header | SNDU | Integrity Check |
+--------+-------------------------+-----------------+
Figure 3: Encapsulation of a subnetwork PDU (e.g. IPv4 or IPv6
packet) to form an MPEG-2 Payload Unit.
Examples of existing convergence protocols include ATM AAL5 [ITU-
AAL5], and MPEG-2 MPE [ETSI-DAT]. This section describes existing
standard encapsulations used with MPEG-2 transmission networks. The
section also reviews the requirements for performing an
encapsulation optimised for IP.
The existing proposals and standards for use with MPEG-2 (described
in the previous section) all introduce overhead that consumes link
capacity and receiver processing power. The then current state of
chip technology played an important role in defining these
encapsulations and it may be argued that there was little previous
implementation experience considered. Arguably, too much
consideration was paid to existing digital video/audio technology
and too little to Internet protocol aspects.
5.1 Convergence Functions
Carrying IP packets over a TS Logical Channel involves several
convergence protocol functions:
5.1.1 Payload_Unit Delimitation
MPEG-2 indicates the start of a Payload Unit in a new TS Packet with
a "start_of_payload_unit_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
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
this TS Packet. If the PUSI is set to '1', then one, and only one,
Expires June 2003 [page 15]
INTERNET DRAFT Requirements for IP transport over DVB December 2003
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 that indicates the position of the first byte of the
Payload Unit (Section) being carried; if the TS Packet does not
carry the first byte of a Section, the PUSI is set to '0',
indicating that there is no payload pointer.
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] however
does not specify how private data should use the PUSI bit.
5.1.2 Length Indicator
Most services using MPEG-2 include a length field in the payload
header to allow the Receiver to identify the end of a payload unit
(e.g. PES Packet, Section, or in the case of the IP service, 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 (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.
Expires June 2003 [page 16]
INTERNET DRAFT Requirements for IP transport over DVB December 2003
5.1.3 Next Level Protocol Type
There is a need to identify the type of payload being transported
(e.g., to differentiate IPv4, IPv6, arp messages, and compressed
packet headers). 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 'Selector' for this, (e.g. in the IEEE 802/ISO 8802
standards for CSMA/CD [LLC], although in this cased a SNAP
(subnetwork access protocol) header is also required for IP
packets).
The MPE encapsulation header does not directly include a type field
(e.g., to differentiate IPv4 and IPv6 packets). If such support is
required, an option must be specified in the MPE encapsulation
header to indicate the addition of an LLC header, and this must be
followed by a SNAP header. This introduces additional overhead.
A Next Level Protocol Type field is also required if compression
(e.g. Robust Header Compression, ROHC) is supported. No compression
method has currently been defined that is directly applicable to
this framework, however the ROHC framework defines a number of
header compression techniques that may yield considerable
improvement in throughput on links which have a limited capacity.
Since many MPEG-2 transmission networks are wire-less (e.g.,
satellite, terrestrial TV, line of sight microwave) the ROHC
framework will be directly applicable for many applications. Use of
ROHC implies the need to transfer smaller SNDUs and the need for
additional processing at the Receiver to expand the received
compressed packets. It is therefore recommended that the selected
type field contains sufficient code points for support of this
technique.
It is desirable therefore to include a Next Level Protocol Type
field in the encapsulation header. Such a field should specify
values for at least IPv4, IPv6, and ROHC (e.g. [RFC3095]). It is
also desirable to allow for other values (e.g., MAC-level bridging).
5.1.4 L2 Subnet Addressing
In the MPEG-2 system the PID carried in the TS Packet header is used
to identify individual services with the help of SI tables. This was
primarily intended as a unidirectional (simplex) broadcast system. A
TS Packet stream carries either tables or one PES Packet stream
(i.e., compressed video or audio). Individual Receivers are not
addressable at this level.
IPv4 and IPv6 allocate addresses to end hosts and intermediate
systems (routers). Each system (or interface) is identified by a
globally assigned address. ISO uses the concept of a hierarchically
Expires June 2003 [page 17]
INTERNET DRAFT Requirements for IP transport over DVB December 2003
structured Network Service Access Point (NSAP) address to identify
an end user process in an Internet environment.
Within a local network a completely different set of addresses for
the Network Point of Attachment (NPA) is used; frequently these NPA
addresses are referred to as Medium Access Control, MAC-level
addresses. In the Internet they are also called hardware addresses.
Whereas network layer addresses are used for routing, NPA addresses
are primarily used for Receiver identification.
Receivers may use the NPA of a received SNDU to reject unwanted
unicast packets within the (software) interface driver at the
Receiver, but must also perform forwarding checks based on the IP
address. IP multicast and broadcast may also filter based using the
NPA, but Recievers must also filter unwanted packets at the network
layer based on source and destination IP addresses. This does not
imply that each IP address must map to a unique NPA (more than one
IP address may map to the same NPA). If a separate NPA address is
not required, the IP address is sufficient for both functions.
If it is required to address an individual Receiver in an MPEG-2
transport system, this can be achieved either at the network level
(IP address) or via a hardware-level NPA address (MAC-address). If
both addresses are being used, they must, be mapped either in a
static or a dynamic way (e.g., by an address resolution process), a
similar requirement may also exist to identify the PID and TS
multiplex on which services are carried.
Using an NPA address in a MPEG-2 transport system may enhance
security, in that a particular payload may be targeted for a
particular Receiver by specifying the Receiver NPA address. This is
however only a weak form of security, since the NPA filtering is
often reconfigurable (frequently performed in software), and may be
modified by a user to allow reception of specified (or all packets),
similar to promiscuous mode operation in Ethernet. If security is
required, it should be applied at another place (e.g. link
encryption, authentication of address resolution, IPSEC, transport
level security and/or application level security).
MPE defines a NPA destination address in the convergence header. No
NPA source address is present. There are cases where an IP service
has no need for NPA addresses, in this case these add unnecessary
processing and transmission overhead, and should not be included in
the encapsulation header.
There are also cases where the use of a NPA is required (e.g. where
a system operates as a router) and if present this should be carried
in encapsulation header where it may be used by Receivers as a pre-
filter to discard unwanted SNDUs. The addresses allocated do not
need to conform to the IEEE MAC address format, and there may
therefore be a good case for allowing the use of a reduced (smaller
than an IEEE MAC address) NPA. There are many cases where a NPA is
Expires June 2003 [page 18]
INTERNET DRAFT Requirements for IP transport over DVB December 2003
not required, and network layer filtering may be used. A new
encapsulation protocol should therefore support an optional NPA and
may allow for future specification of the size of NPA.
5.1.5 Integrity Check
For the IP service, the probability of undetected packet error
should be small (or negligible) [LINK-ID]. There is therefore a
need for a CRC to verify correctness of a received IP packet. Such
checks should be sufficient to detect incorrect operation of the
encapsulator and Receiver (including reassembly errors following
loss/corruption of TS Packets), in addition to protecting from loss
and/or corruption by the transmission network (e.g., multiplexors
and links).
Mechanisms exist in MPEG-2 transmission networks that may assist in
detecting loss (e.g. the 4-bit continuity counter included as
standard in the MPEG-2 TS Packet header).
A convergence protocol should use an encapsulation that provides a
strong integrity check. For ease of hardware implementation, this
check should be carried in a trailer following the SNDU. A CRC-32 is
sufficient for operation with up to a 12 KB payload, and may still
provide adequate protection for larger payloads.
5.1.6 Identification of Scope.
The MPE section header contains information that may be used by the
Receiver to identify the scope of the (MAC) address carried as a
NPA, and prevent TS Packets intended for one scope to be received by
another.
Similar functionality may be achieved by ensuring that only IP
packets that do not have overlapping scope are sent on the same TS
Logical Channel. In some cases, this may imply the use of multiple
TS Logical Channels.
5.1.7 Extensibility
The evolution of the Internet service may in future require
additional functions (examples include the introduction of new
protocols at the network level, support of 802.1Q tags). A flexible
protocol should therefore provide a way to introduce new features
when required, without having to provide additional out-of-band
configuration.
5.2 Header Overhead
The fixed 184 byte payload size of a TS Packet also introduces a
bandwidth overhead due to the "padding" (or stuffing) commonly
employed when placing data in the TS Packets.
Expires June 2003 [page 19]
INTERNET DRAFT Requirements for IP transport over DVB December 2003
One common application is the use of a DVB-S multiplex to provide
the forward link for satellite delivery of IP data. In many current
applications the forward data traffic over the satellite link is
mostly data with a packet size 1500 bytes. This overhead is
approximately 2-11%. Short IP packets, (e.g., carrying control
information (e.g. ICMP, IGMP, and TCP ACK packets), can lead to a
much more overhead (up to approximately 500% for IPv4), if they are
carried individually in a TS Packet. IP header compression (e.g.
[RFC3095]), would offer no benefit in this case.
The "Payload_Unit_Start_Indicator" (PUSI) may be used to alleviate
this, by allowing the MPEG-2 payload pointer to indicate the
presence of a second payload unit within a single TS Packet. The
second payload unit may directly follow the end of the first, in a
procedure sometimes called "Packing".
Note, an under-run of data at the IP Encapsulator may cause a TS
Packet to be sent with less than 184 bytes of payload. Such a TS
Packet will need to be "padded".
5.3 TS Multiplexing
MPEG-2 multiplexers may forward TS Packets using a stream-based
design. They do not usually flush their buffers, but store TS
Packets until an input buffer fills to a threshold, (assuming that
the data arrives in a more or less continuous stream). This
assumption is not necessarily valid for IP packets, which tend to
arrive in intermittent traffic bursts. The forwarding behaviour of
the multiplex can lead to significant link transit delays for the
last TS Packet(s) in a traffic burst.
Various solutions to this problem are possible including:
(i) Flushing an IP packet stream with null TS Packets after each
traffic burst.
(ii) Redesign of the TS multiplexer buffer management to control
the maximum queuing latency for IP traffic flows.
(iii) Addition of a new push identifier that lets the TS
multiplexer identify the end of a traffic burst.
An Encapsulator could specify a maximum holding time (configured
based on well-known requirements, such as the TCP ACK_Delay
interval, but could also be based on QoS metric derived for the IP
traffic being carried). If required, the IP-DVB framework must
identify how this is to operate and specify appropriate values for
parameters.
5.4 Encapsulation Efficiency
In this section the following ranking is used to evaluate the
performance of different encapsulation methods:
Efficiency = Sum of transferred bytes / Payload size
Expires June 2003 [page 20]
INTERNET DRAFT Requirements for IP transport over DVB December 2003
The overhead of 4 bytes for each 188 byte TS Packet introduced by
the MPEG-2 TS results in a maximum of 0.98.
In MPE, this overhead is increased by the DSM-CC private section
mechanism that generates at least 17 bytes per IPv4 packet (16 bytes
for the datagram section and 1 byte for the Payload Pointer field).
This excludes the LLC/SNAP field that is optional and not required
in all cases. Implementations supporting Packing may approach the
maximum performance for large SNDUs.
The volume of data transmitted for additional tables and descriptors
should be omitted because PSI information and system tables are
immanent to the MPEG2/DVB transmission scheme and have nothing to do
with actual data transmission.
Expires June 2003 [page 21]
INTERNET DRAFT Requirements for IP transport over DVB December 2003
6. Address Resolution Functions
Address Resolution (AR) provides a mechanism that associates L2
information (including (NPA) address(es)) with the IP address of a
system. Many L2 technologies employ unicast AR at the sender: An IP
system wishing to send an IP packet encapsulates it and places it
into a L2 frame. It then identifies the appropriate L3 adjacency
(next hop router, end-host) and determines the appropriate L2
adjacency (e.g. MAC address in Ethernet) to which the frame should
be sent so that the packet gets across the L2 link.
The L2 addresses discovered using AR are normally recorded in a data
structure known as the arp/neighbor cache. The results of previous
AR requests are usually cached. Further AR protocol exchanges may be
required as communication proceeds to control (update or re-
initialise) the client cache state contents (i.e. purge/refresh the
contents [ND]). For stability, and to allow network topology changes
and client faults, the cache contents are normally "soft state",
that is, they are aged with respect to time and old entries removed.
In some cases (e.g. ATM, FR, X.25, MPEG-2 and many more), AR
involves finding more than the MAC address. This includes
identifying other parameters required for L2 transmission, such as
channel IDs (VCIs in ATM, or PIDs in MPEG-2 TS).
Address resolution has different purposes for unicast and multicast.
Multicast address resolution is not required for many L2 networks,
but is required for MPEG-2 transmission networks.
6.1 Address Resolution for MPEG-2
There are three elements to the L2 information required to perform
AR for a MPEG-2 TS. These are:
(i) A Receiver ID (e.g. a 6B MAC/NPA address).
(ii) A PID (Program IDentifier) or index to find a PID.
(iii) Tuner information (e.g. a Transport Stream ID) that maps to a
set of physical layer parameters.
Elements (ii) and (iii) need to be de-referenced via indexes to the
PMT when remultiplexors are used that may renumber the PID values,
(i.e. PIDs are not intended to be end-to-end identifiers). However,
although such use is common in broadcast TV networks, many private
networks do not need to employ multiplexors that renumber PIDs.
The third element (iii) allows an AR client to resolve to a
different MPEG TS Multiplex. This is used when there are several
channels that may be used for communication (i.e. multiple
outbound/inbound links). In a mesh system, this could be used to
determine connectivity.
Expires June 2003 [page 22]
INTERNET DRAFT Requirements for IP transport over DVB December 2003
This AR information is used in two ways at a Receiver:
(i) AR resolves an IP unicast or IPv4 broadcast address to the (MPEG
TS Multiplex, PID, MAC/NPA address). This allows the Receiver to set
L2 filters to let traffic pass to the IP layer. This is used for
unicast, and IPv4 subnet broadcast. Usually this is configured with
the equivalent of an "ifconfig" on the interface.
(ii) AR resolves an IP multicast address to the (MPEG TS Multiplex,
PID, MAC/NPA address), and allows the Receiver to set L2 filters
enabling traffic pass to the IP layer. This operation may need to be
performed many times based on IGMP, MLD, and Multicast Routing
protocol operation. A Receiver in a MPEG-2 TS network needs to
resolve the PID value and tuning parameters associated with a TS
Logical Channel and (at least for unicast) the destination Receiver
NPA address.
Expires June 2003 [page 23]
INTERNET DRAFT Requirements for IP transport over DVB December 2003
6.1.1 Example of AR in a Star Network
The example below shows a star topology MPEG-2 TS transmission
network, with two terminals receiving a forward broadcast channel
sent by a Hub. (A mesh system has some additional cases.) The
forward broadcast channel consists of a "TS Multiplex" (a single
physical bearer) allowing communication with the terminals. These
communicate using a set of return channels.
Forward brodcast
MPEG-2TS \
----------------X /-----\
/ / \
| Terminal|
/----------+ A |
/ \ /
/-----\ / \-----/
/ \ /
| Hub |/
| +\ /-----\
\ / \ / \
\-----/ \ | Terminal|
\-----------+ B |
\ /
\-----/
There are three possibilities for unicast AR:
(1) A system at a terminal, A, needs to resolve an address of a
system that is at the hub;
(2) A system at a terminal, A, needs to resolve an address that is
at another terminal, B;
(3) A host at the hub needs to resolve an address that is at a
terminal. The sender (encapsulation gateway), uses AR to provide the
(MPEG TS Multiplex, PID, MAC/NPA address) to be used to send
unicast, IPv4 subnet broadcast and multicast packets.
If the Hub is as an IP router, then case (1) and (2) are the same:
the host at the Receiver doesn't know the difference. In these
cases, the address to be determined is the L2 address of the device
at the hub to which the IP packet should be forwarded, and which
then relays the IP packet back to the forward (broadcast) MPEG-2
channel after AR (case 3).
If the hub is a L2 bridge, then case 2 still has to relay the IP
packet back to the outbound MPEG-2 channel. The AR protocol needs to
resolve the specific Receiver L2 MAC address of B, but needs to send
this on a L2 channel to the Hub. This requires terminals to be
informed of the L2 address of other terminals.
A host connected to the hub needs to use the AR protocol to resolve
the Receiver terminal MAC/NPA address. This requires the AR server
at the Hub to be informed of the L2 addresses of other terminals.
Expires June 2003 [page 24]
INTERNET DRAFT Requirements for IP transport over DVB December 2003
6.2 The AR Process
Several features are desirable for AR over broadcast-style networks:
(i) A table based approach to promote AR scaling. This requires a
definition of the frequency of update and volume of AR traffic
generated
(ii) Mechanisms to install AR information at the server (unsolicited
registration)
(iii) Mechanisms to verify AR information held at the server
(solicited responses). Appropriate timer values need to be defined.
(iv) An ability to purge client AR information (after IP network
renumbering, etc)
(v) Appropriate security associations to authenticate the parties.
6.3 Scenarios for MPEG AR
An AR protocol may transmit AR information in three distinct ways:
(i) An MPEG-2 signalling table transmitted at the MPEG-2 level
(ii) An MPEG-2 signalling table transmitted at the IP level (tbd, no
implantations of this are known)
(iii) An address resolution protocol transported over IP (as in ND)
There are three distinct scenarios in which AR may be used:
A. Multiple TS-Mux and the use of re-multiplexors; e.g. Digital
Terrestrial, Satellite TV broadcast multiplexes. Many such systems
employ remultiplexors that modify the PID values associated with TS
Logical Channels as they pass through the MPEG-2 transmission
network.
B. Tuner configuration(s) that are fixed or controlled by some other
process. In these systems, the PID value associated with a TS
Logical Channel may be known by the Sender.
C. A service run over one TS Mux (i.e., uses only one PID, for
example DOCSIS and some current DVB-RCS multicast systems). In these
systems, the PID value of a TS Logical Channel may be known by the
Sender.
6.3.1 Table-based AR over MPEG-2
Information about the set of MPEG-2 TS Logical Channels carried over
a TS Multiplex is usually distributed via tables (service
information, SI) sent using channels assigned a specific (well-
known) set of PIDs. This was originally designed for audio/video
distribution to set-top-boxes. The design requires access to and
processing of the SI table information (which is carried in MPEG-2
section format [ISO_DSMCC]). This scheme reflects the complexity of
Expires June 2003 [page 25]
INTERNET DRAFT Requirements for IP transport over DVB December 2003
delivering and co-ordinating the various TS Logical Channels
associated with a multimedia TV programme.
One possible approach to provide TS multiplex and PID information
for IP services is to integrate additional information into the
existing MPEG-2 tables, or to define additional tables specific to
the IP service.
This process could be:
(i) A 2-stage process, specifically decoupling PID using a Transport
Stream ID (TS-ID). This allows the transmission network to
remultiplex TS Logical Channels (resulting in a change of the PID
value associated with a TS Logical Channel). This is suited to
Scenario A.single stage where a target IP address resolves directly
providing full L2 information.
(ii) A 2-stage process, specifically the Receiver uses AR
information to establish the TS Logical Channel and a separate
process is used (when required) to resolve Receiver L2 addresses.
(iii) A one-stage process in which the tuning parameters and PID is
already known, or are resolved in the same process as used to
determine the NPA/MAC address.
The DVB INT and the A/92 Specification from ATSC [ATSC-A92] are
examples of (i). The DVB INT can associate an IP address with:
network_id, original_network_id, transport_stream_id, service_id and
component_tag.
- Network_id identifies the DVB network.
- Original_network_id and transport_stream_id together identify the
transport stream (globally, not only within the network. i.e. the
network_id is not actually needed, but it's there anyway).
- service_id identifies the PMT sub-table within the transport
stream.
- component_tag identifies the component within the PMT sub-table.
PMT announces PID for each component.
N.B. When a TS is re-mux'ed the remultiplexor doesn't update the
INT, but does modify the PMT for each of the PIDs it renumbers.
6.3.2 Table-based AR over IP
AR information could be carried over a TS data channel, (e.g. using
an IP protocol similar to the Service Announcement Protocol, SAP).
Implementing this independently of the SI tables, would ease
implementation, by allowing it to operate on systems where IP
processing is performed in a software driver. It may also allow the
technique to be more easily adapted to other similar delivery
networks. It also is advantageous for networks which use the MPEG-2
TS but links, but do not necessarily support audio/video services
Expires June 2003 [page 26]
INTERNET DRAFT Requirements for IP transport over DVB December 2003
and therefore do not need to provide interoperability with TV
equipment (e.g. links used solely for connecting IP (sub)networks).
The AR function could be centralised in one or more (replicated)
databases (as in MARS) so a Receiver can do the address mapping with
AR information from a known place. There are both drawbacks and
advantages in this approach. To find an address, a Receiver sends a
query to a server/servers, who respond (proxy) for other known
Receivers. In the simple case, the server is pre-configured with the
bindings of all clients (e.g. tables created from a DHCP server when
it allocates IP addresses).
A variant of the above is when each Receiver sends an unsolicited
neighbor advertisement registering its L2 binding to the server.
6.3.3. Query/Response AR over IP
A query/response protocol may be used at the IP level (similar to,
or based on IPv6 Neighbor Advertisements of the ND protocol). The AR
protocol may operate over an MPEG-2 TS Logical Channel using a
previously agreed PID (e.g. configured, or communicated using a SI
table). In this case, the AR could be performed by the target system
itself (as in arp and nd). This has good soft-state properties, and
is very tolerant to failures. To find an address, a system sends a
"query" to the network, and the "target" replies.
6.4 Scoping
In some case, an MPEG-2 Transmission Network may support multiple IP
networks. If this is the case, it is important to recognise the
context (scope) within which an address is resolved, to prevent
packets from one addressed scope leaking into other scopes.
Examples of overlapping IP address assignments, include:
(i) Private unicast addresses (e.g. in IPv4, 10/8 prefix;
172.16/12 prefix; 192.168/16 prefix) should be confined to
one addressed area.
(ii) Some multicast addresses, (e.g., the scoped multicast
addresses sometimes used in private networks). These are only
valid within an addressed area (examples for IPv4 include;
239/8; 224.0.0/24; 224.0.1/24). Similar cases exist for some
IPv6 multicast addresses.
(iii) Scoped multicast addresses. Forwarding of these addresses is
controlled by the scope associated with the address.
IP packets with these addresses must not be allowed to travel
outside their intended scope, and may cause unexpected behaviour if
allowed to do so.
Expires June 2003 [page 27]
INTERNET DRAFT Requirements for IP transport over DVB December 2003
In addition, overlapping address assignments can arise using level 2
NPA addresses:
(i) The NPA address must be unique within the TS Logical Channel.
IEEE MAC addresses used in Ethernet LANs are globally unique.
If the NPA addresses are not globally unique, the same NPA
address may be re-used by Receivers in different addressed
areas.
(ii) The NPA broadcast address (all 1s MAC address). Traffic with
this address should be confined to one addressed area.
(iii) Other non-IP protocols may also view sets of MAC multicast
addresses as link-local, and may produce unexpected results
if distributed across several private networks!
Reception of unicast packets destined for another addressed area may
lead to an increase in the rate of received packets by systems
connected via the network. IP end hosts normally filter received
unicast IP packets based on their assigned IP address. Reception of
The additional network traffic may contribute to processing load but
should not lead to unexpected protocol behaviour. It does however
introduce a potential Denial of Service (DoS) opportunity.
When the Receiver acts as an IP router, the receipt of such packet
may lead to unexpected protocol behaviour. This also provides a
security vulnerability since arbitrary packets may be passed to the
IP layer.
6.5 AR Authentication
In many AR designs authentication has been overlooked, because of
the wired nature of most existing IP networks, which makes it easy
to control hosts physically connected. With wireless connections,
this is changing: unauthorised hosts actually can claim L2
resources. The address resolution client (i.e. Receiver) may also
need to verify the integrity and authenticity of the AR information
it receives. There are similarities here with SEND [REF-to-SEND-
WG]. There are trust relationships both ways - clients need to know
they have a valid server and that the resolution is valid. Servers
have a basic authorisation issue before they allow a L2 address to
be used.
The MPEG-2 transmission system may also require access control to
prevent unauthorised use of the satellite bearer, however, this is
an orthogonal issue to address resolution.
Expires June 2003 [page 28]
INTERNET DRAFT Requirements for IP transport over DVB December 2003
7. Multicast Support
This section addresses specific issues concerning IPv4 and IPv6
multicast over MPEG-2 Transmission Networks. The primary goal of
multicast support will be efficient filtering of IP-multicast
packets by the Receiver, and the mapping of IPv4 and IPv6 multicast
addresses onto the associated PID value and TS Multiplex. The
design should permit a large number of active multicast groups, and
should minimise the processing load at the Receiver when filtering
and forwarding IP multicast packets. For example, schemes that may
be easily implemented in hardware would be beneficial, since these
may relieve drivers and operating systems from discarding unwanted
multicast traffic.
These issues include, but are not restricted to:
(i) Encapsulating multicast packets for transmission using a
MPEG-2 TS.
(ii) Mapping IP multicast groups to the underlying MPEG-2 TS
Logical Channel (PID) and the MPEG-2 TS Multiplex.
(iii) Provide signalling information to allow a Receiver to locate
an IP multicast flow within an MPEG-2 TS Multiplex.
(iv) Determining group membership (e.g. utilising IGMP/MLD).
(v) Error Reporting.
Multicast mechanisms are used at more than one protocol level. The
upstream MPEG-2 router may forward multicast traffic on the MPEG-2
TS link using a static or dynamic set of groups. When static
forwarding is used, the set of groups may also be configured or set
using SNMP, Telnet, etc. A Receiver normally uses either IGMP/MLD or
multicast routing to establish membership tables that it uses to
dynamically set local forwarding of received groups. In a dynamic
case, this group membership information is fed-back to the Sender to
enable it to start sending new groups and (if required) to update
the tables that it produces for multicast AR.
Appropriate procedures need to identify the correct action when the
same multicast group is available on more than one TS Logical
Channel. This could arise when different end hosts act as senders
to contribute IP packets with the same IP group destination address.
It may also arise when a sender duplicates the same IP group over
several TS Logical Channels (or even different TS Multiplexes), and
in this case a Receiver may potentially receive more than one copy
of the same packet. At the IP level, the host/router may be unaware
of this duplication.
Expires June 2003 [page 29]
INTERNET DRAFT Requirements for IP transport over DVB December 2003
7.1 Multicast AR Functions
The functions required for multicast AR may be summarised as:
(i) The Sender needs to know L2 mapping of multicast group.
(ii) The Receiver needs to know L2 mapping of multicast group.
In the Internet, multicast AR is normally a mapping function rather
than a one-to-one association using a protocol. In Ethernet, the
sender maps an IP address to a L2 MAC address, and the Receiver uses
the same mapping to determine the L2 address to set a L2
hardware/software filter entry.
A typical sequence of actions for the dynamic case is:
L3) Populate the IP L3 membership tables at the Receiver.
L3) Receivers send/forward IP L3 membership tables to the Hub
L3) Dynamic/static forwarding at hub/upstream router of IP L3 groups
L2) Populate the IP AR tables at the encapsulator gateway
(i.e. Map IP L3 mcast groups to L2 (PIDs))
L2) Distribute the AR information to Receivers
L2) Set Receiver L2 multicast filters for IP groups in the
membership table.
Multicast also introduces the concept of scoped addresses, requiring
appropriate scoping to be followed. To be flexible AR must associate
a Logical Channel (PID) not only with with a group, possibly a QoS
class, and other appropriate MPEG-2 TS attributes. Performing
multicast AR at the IP level can enable providers wishing to provide
independently scoped addresses would need to use multiple Multicast
AR servers, one per multicast domain. Explicit per group AR to
individual L2 addresses is to be avoided.
\
|
+---+----+ +--------+
| Tuner |---+TS Tabl | . . . .
+---+----+ +--------+ .
| .
+--------+ +--------+ .
| deMux |---+PID Tabl|........
+---+----+ +--------+ :
| :
+--------+ +--------+ +--------+
|MPE/ULE |---+AR Cache|---+ MFIB |
+---+----+ +--------+ +--------+
| | |
+---+----+ +---+----+ +---+----+
| IP | | AR | |IGMP/MLD|
+---+----+ +---+----+ +---+----+
| | |
*------------+------------+
|
Expires June 2003 [page 30]
INTERNET DRAFT Requirements for IP transport over DVB December 2003
8. Examples of Usage
Consider the case where a hub server collects a table of AR
information. The collected AR information then needs to be
redistributed to clients using the forward multicast link. The
number of Receivers may range from 1 to many thousands.
8.1 Example 1 Example protocol stack for Sender Side (2 interface)
Consider a router with two logical interface (A,B) each to an IP
network which could use either private or global IP addresses. If
AR is performed independently for each interface, the L2 addresses
used by subnetworks A,B may also overlap or be globally unique. A
separate association protocol could provide MPEG-2 other L2
information (MPEG-2 TS Logical Channels / PID mappings, etc) to the
IP systems in each of the connected IP networks. Both AR for L2
addresses and for association with TS logical channel attributes may
be performed by IP-level protocols using link-local IP multicast. A
good solution may also permit multiple servers. A simple association
protocol may only support networks that do not perform remux
renumbering of PIDs. When this needs to be supported, a L2 table
method may be used.
|
+--------+--------+
| Port C |
+-------------+--------+--------+-------------+
| Router |
+-----------------+---------+-----------------+
| Port A | | Port B |
+--------+--------+ +--------+--------+
| IP Interface 1 | | IP Interface 2 |
| (subnet) | | (subnet) |
+------+----------+ +------+----------+
| AR | +-------+ | AR | +-------+
|Server|.. | AR +--+ |Server|.. | AR +--+
+------+ | Cache | | +------+ | Cache | |
| +-+-----+ | | +-+-----+ |
| | Assoc | | | Assoc |
| +--------+ | +--------+
+-------( )--------------+----------( )-----------+
| Encapsulator X | Encapsulator Y |
+---------+--------------+-----------+------------+
| |
+----->------+ +----<----+
| |
+-------( )-( )--( )-----+
| PID PID PID |
| TS-Mux |
+---------+--------------+
| Forward Link
| (Feed)
Expires June 2003 [page 31]
INTERNET DRAFT Requirements for IP transport over DVB December 2003
8.2 Example 2
Suppose we have system B and a system A. The L2 address B is (Y:q)
(i.e. Combination of MAC address, PID, TS) and the corresponding one
for A is (X:p).
| Forward |
+-------+ +-------+ | Link | +-------+ +-------+
--+AR +--+Encaps +--------->--------+ A +--+AR +-
|server | | | | | | | |Client |
+-------+ +-------+ | | +-------+ +-------+
+------+ | | +------+
|A:X:p | | | |p:X:A |
+------+ | | +------+
| |
+-------+ +-------+ | | +-------+ +-------+
-+AR +--+ B +---------<--------+Encaps +--+AR +-
|Client | | Decaps| | | | | |server |
+-------+ +-------+ | Return | +-------+ +-------+
+------+ | Link | +------+
|q:Y:B | | | |B:Y:q |
+------+ | | +------+
IP addr B IP addr A
For B to send to A, the encapsulation gateway at B needs to resolve
the IP address of A to the l2 address of X and identify that this
must be carried over (PID,TS) of p.
A already knows its L2 address is X, this doesn't need to be
communicated. It also knows or can determine it's layer 3 IP
address. It can not determine the (pid,TS-ID) to use, so it must be
told p. Once it knows p it can tune and set the MPEG-2 demux filter.
The corresponding addresses for B are Y and q.
How do A and B find out X and Y?
1) X can be preassigned to A (e.g. A L2 address assigned by a
Receiver manufacturer), in which case, A has to tell the AR server
at B informing it that it will be using X (register). The AR server
at B could then inform other devices by sending an AR table that
includes an entry that says A uses X (mesh). The encapsulator needs
this information, and also other clients that need to send to A.
2) B can assign X to A. B informs A that it is using X. B could then
inform others by sending an AR table that includes an entry saying A
uses X (mesh) or that B uses Y as a proxy (star).
3) It is also possible that B does not know that A is using X. To
find this out, it may query the network/a third party AR server (Y)
looking for address A. A can then respond giving its resolved
address (X), which B then uses. The way in which Y is found is to be
determined (e.g. configured, or determined by a protocol mechanism).
Expires June 2003 [page 32]
INTERNET DRAFT Requirements for IP transport over DVB December 2003
8.3 Example 3
Assume a unicast (e.g. TCP) stream originates at a host, S, and is
intended for an end host, R.
The path between S and R includes an MPEG-2 link, with an
encapsulator B and a Receiver A. The Receiver, A, acts as a router.
The Encapsulator receives the IP packets from S and encapsulate them
with an SNDU destination address field of X, this is performed by
determining that A is not local to the subnetwork, but reached via
router with the IP Address A corresponding to the L2 value of X. The
packet is fragmented into TS-Packets and a PID assigned.
+-------+ +------+
+->----|AR | |A:X |
| +--+Server | +------+
| | +-------+ +----> |
| | | | |
| | | Forward +----> |
| | +-------+ | | | +-------+
| +->-+Encaps +------------>---+---->-------+Decaps +----+->--
| >---+ | | Data | | | |
| IP +-------+ | A sent over X | +-------+ ++------+
| data +------+ | | +------+ |AR |
| |A:X | | & AR Adverts (mcast)| |X:A | <-+Client |
| +------+ | A uses X | +------+ ++------+
| | B uses Y | |
| Encaps receives | | Cached values |
| AR Tables | | used for rx |
| | | AR of packets |
| Cached values | | own unicast addr|
| used for tx | | & mcast addrs |
| | | |
| | | |
| | Reverse | |
| +-------+ | | +-------+ |
-+--<----+Decaps +------------<----------------+Encaps +-<--+--<
Decaps | | | | | |
+-------+ | AR requests | +-------+
| who-is-C? |
| |
| & AR registration | IP addr A
| I-am A I-use X |
For A to forward packets to B, the encapsulation gateway at A.
For A to forward packets to B, the encapsulation gateway at A needs
to resolve the IP address.of B to the L2 address X. A should already
be listening on the L2 address X, because it is either the media-
resolved of its A's IP address. (For multicast, this could be L2
multicast IP address for a multicast group for which it has enabled
a filter).
Expires June 2003 [page 33]
INTERNET DRAFT Requirements for IP transport over DVB December 2003
9. Summary
This document proposes a framework for defining a set of protocols
to perform efficient and flexible support for IP network services
over networks built upon the MPEG-2 Transport Stream (TS).
An informational document is recommended to document the existing
approaches, focussing on IP networking, the mechanisms that are used
and their applicability to supporting IP unicast and multicast
services. This document is the first stage of this process. Import
areas include the interface between the IP network at the Sender and
Receiver and any protocols required. Scenarios and use-cases need
to be proposed and studied, specifically this should include
detailing how IP-only MPEG-2 networks can be used as a link
technology in the general Internet.
The encapsulation to transfer IPv4 and IPv6 packets is described,
outlining current encapsulation methods, together with guidelines on
the requirements for developing a new encapsulation. All other
protocols in the framework will support IP packet transmission using
both the Multiprotocol Encapsulation (MPE), which is currently
widely implemented, and also any new optimised encapsulation.
The framework also includes MPEG-2 Address Resolution (AR)
procedures to allow dynamic configuration of the sender and Receiver
using an MPEG-2 transmission link/network. These will support IPv4
and IPv6 services in both the unicast and multicast modes.
This proposed work is within scope of the ip-dvb WG and protocol
design could be done in this forum with the support and expertise of
other protocol design work. For this to be successful requires
inputs from the wider community and good liason with other
organisations. Comments are invited from implementers, operators,
and others interested people.
10. Security Considerations
The normal security issues relating to the use of wire-less links
for transport Internet traffic should be considered.
11. Acknowledgments
The authors wish to thank Isabel Amonou , Torsten Jaekel, Pierre
Loyer, Marie-Jose Montpetit, Luoma Juha-Pekkaand , and Rod Walsh,
for their detailed inputs. We also wish to acknowledge the input
provided by the members of the ip-dvb (ip-dvb@erg.abdn.ac.uk)
mailing list.
Expires June 2003 [page 34]
INTERNET DRAFT Requirements for IP transport over DVB December 2003
12. 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, 200
[ATSC-DATG] A/91, "Recommended Practice: Implementation Guidelines
for the ATSC Data Broadcast Standard", Advanced Television Systems
Committee (ATSC),Doc. A/91, 2001.
[ATSC-A92] A/92 "Delivery of IP Multicast Sessions over ATSC Data
Broadcast", Advanced Television Systems Committee (ATSC), Doc. A/92,
2002.
[ATSC-G] A/54, "Guide to the use of the ATSC Digital Television
Standard", Advanced Television Systems Committee (ATSC), Doc. A/54,
1995.
[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 , 2000.
[ATSC-S] A/80, "Modulation and Coding Requirements for Digital TV
(DTV) Applications over Satellite", Advanced Television Systems
Committee (ATSC), Doc. A/80, 1999.
[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).
[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).
[ID-IPDVB-ULE] Fairhurst, G., B. Collini-Nocker, "Simple Ultra
Lightweight Encapsulation for transmission of IP datagrams over
MPEG-2/DVB networks", Internet Draft, draft-fair-ipdvb-ule-xx.txt,
Work in Progress, IP-DVB WG.
Expires June 2003 [page 35]
INTERNET DRAFT Requirements for IP transport over DVB December 2003
[IP-DVB-AR] Fairhurst, G., M-J. Montpetit, "Address Resolution for
IP datagrams over MPEG-2 networks", Internet Draft, draft-fair-
ipdvb-ar-xx.txt, Work in Progress, IP-DVB WG.
[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).
[Ken87] Kent C.A., and J. C. Mogul, ŚFragmentation Considered
Harmful", Proc. ACM SIGCOMM, USA, CCR Vol.17, No.5, 1988, pp.390-
401.
[RFC793] Postel, J., "Transmission Control Protocol", RFC791.
[RFC1122] B. Braden, ed., "Requirements for Internet Hosts -
Communication Layers", RFC 1122.
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed
Serial Links", RFC1144.
[RFC1191] Mogul, J., Deering, S., "Path MTU Discovery", RFC 1191.
[RFC2507] Degermark, M., Nordgren, B., and Pink, S., "IP Header
Compression", RFC2507.
[RFC3077] Duros, E., W. Dabbous, H. Izumiyama, Y. Zhang, "A Link
Layer Tunneling Mechanism for Unidirectional Links", RFC3077.
[RFC3095] Bormann, C., et al, "RObust Header Compression (ROHC):
Framework and four profiles: RTP, UDP ESP and uncompressed",
RFC3095.
13.Authors' Addresses
Godred Fairhurst
Department of Engineering
University of Aberdeen
Aberdeen, AB24 3UE
Expires June 2003 [page 36]
INTERNET DRAFT Requirements for IP transport over DVB December 2003
UK
Email: gorry@erg.abdn.ac.uk
Web: http://www.erg.abdn.ac.uk/users/gorry
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/
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.
14. IANA Considerations
A set of protocols which meet these requirements, will require the IANA
to assign various numbers. This document by itself, however, does not
require any IANA involvement.
Expires June 2003 [page 37]
INTERNET DRAFT Requirements for IP transport over DVB December 2003
[AUTHORS NOTES:XXX THIS SECTION MUST BE REMOVED BY THE RFC Ed]
Evaluation of IP Service over MPEG-2 networks
A set of methodologies may be defined to assist in the evaluation of
the protocols defined by this framework. These could define
terminology, evaluation criteria (utilisation, throughput, loss
rate, undetected error rate, etc), and may specify tests to indicate
the impact of such parameters as IP Packet size, IP version,
multicast/unicast, and rate of transmission. A set of test cases
could also be defined to allow performance to be quantitatively
measured and compared.
Rationale for ULE Packing
Measurements of IPv4 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 Packet payload of 184 bytes;
- a long data packet using a number of TS Packets with
the last containing only a remainder.
Both of these lead to a fairly high overhead in the last TS Packet.
Since radio/satellite bandwidth is an expensive resource, as opposed
to bandwidth in wired LANs, a more efficient method is specified
here. One possibility is header compression, however this is outside
the scope of this document.
Additional Reading Matter
ETSI EN 301 192 [V1.3.1 (2003-05)
RFC 2461 - Neighbor Discovery
RFC 2462 - IPv6 Address Autoconfiguration
RFC 826 - An Ethernet Address Resolution Protocol, STD 37
MARS: RFC2121; RFC2149;RFC2269;RFC2443;RFC2602
IETF ND Working Group
IETF SEND Working Group
[XXX END of AUTHOR NOTE XXX]
Expires June 2003 [page 38]
INTERNET DRAFT Requirements for IP transport over DVB December 2003
Appendix A
The following principles are suggested for this work:
(i) Ubiquity. The framework operates below the IP network layer.
It must not require modifications to existing implementations
of IP (IPv4 or IPv6), UDP, TCP.
(ii) Minimal overhead. The framework should minimize protocol
overhead, in terms of the number of additional bytes to be
sent in addition to the IP packet and processing overhead in
terms of parsing effort of variable length headers or options
fields (see iv). The number of header bytes can
significantly impact performance for bandwidth-limited
systems (such as satellite, terrestrial radio/TV links).
(iii) Minimal set of required options. Reducing the number and
type of optional parameters reduces the receiver processing
overhead. Importantly, it also simplifies Receiver
implementation, allowing easier implementation and promoting
better interoperability between vendor implementations. The
header format currently adopted by MPE is known to be not
optimal for IP, incurring significant receiver processing
overhead and extra link overhead [CLC99].
(iv) Maximum Throughput. The framework should offer minimal
transmit/receive processing load. In some cases, the use of
header compression may represent a useful trade-off in
increased processing overhead, but reduced packet header
size. In some cases (e.g., to meet the QoS delay requirement
of a flow) efficiency at the MPEG-2 TS level may have to be
sacrificed for reduced transit delay.
(v) Flexibility. The framework should provide sufficient
flexibility to allow future inclusion of other mechanisms for
specific applications (e.g., synchronisation with other MPEG-
2 TS Logical Channels). There is also need for the framework
to operate over the range of MPEG-2 multiplexes in the
forward direction, and the diverse range of return channel
systems in the reverse direction.
(vi) Compatibility. If new protocols are defined by the framework,
it is desirable that they allow co-existence with existing
schemes, such as MPE, to allow continued use of the broad-
base of existing equipment.
(viii) Scalability. The framework must be efficient when used in
both large and small networks. The size of a network using
MPEG-2 transport may range from a pair of nodes, to one
including millions of Receivers.
Expires June 2003 [page 39]