Internet Engineering Task Force Gorry Fairhurst
Internet Draft University of Aberdeen, U.K.
Document: draft-fair-ipdvb-req-00.txt Horst D. Clausen
Bernhard Collini-Nocker
Hilmar Linder
University of Salzburg, A
Category: Informational January 2002
Requirements for transmission of IP datagrams over DVB 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 contains requirements for a framework for transport of
IP Datagrams over ISO MPEG-2 Transport Streams (TS). The MPEG-2 TS
has been widely accepted not only for providing digital TV services,
but also as a subnetwork technology for building IP networks. One
example is the Digital Video Broadcast (DVB), specified by standards
published by the European Telecommunications Standards Institute
(ETSI).
The document identifies the need for the definition of a set of
network protocols to standardise the interface between the MPEG-2
Transport Stream and an IP subnetwork. It also suggests an optimised
encapsulation method for IP datagrams. The requirements for these
functions are described, and a framework proposed for their
implementation.
Expires March 2002 [page 1]
INTERNET DRAFT Requirements for IP transport over DVB Sept 2001
Document history
-00 This draft is intended as a study item for proposed future work
by the IETF in this area. Comments relating to this document will
be gratefully received by the authors and the ip-dvb mailing list
at: ip-dvb@erg.abdn.ac.uk
Expires June 2002 [page 2]
INTERNET DRAFT Requirements for IP transport over DVB Sept 2001
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 | DSMCC | | |
| +-+-+-+-+---+------+--------+--+--+
| | PES | ATM |Priv. Section |
+---------+-------+----------+--------------+
| MPEG-2 TS |
+-------+-------+-------+-------------------+
| DVB-S | DVB-C | DVB-T | Other PHY |
+-------+-------+-------+-------------------+
Figure 1: Overview of protocol stack for DVB
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.
The service provided by a MPEG-2 transport multiplex offers a number
of parallel channels, which correspond to logical links (forming the
MPEG Transport Stream (TS)). Each MPEG-2 TS channel is uniquely
identified by the Packet ID, PID, value carried in the header of
MPEG-2 TS packets. The PID value is a 13 bit field and, thus, the
number of channels is limited to 8192, some of which are reserved
for transmission of SI tables. Non-reserved TS logical channels may
be use to carry audio [ISO-AUD], video [ISO-VID], IP datagrams [ISO-
DSMCC;ETSI-DAT;ATSC-DAT], or other data [ISO-DSMCC;ETSI-DAT; ATSC-
DAT].
Expires June 2002 [page 3]
INTERNET DRAFT Requirements for IP transport over DVB Sept 2001
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
to 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 MPEG-TS logical channel.
Data for transmission over the MPEG-2 transport multiplex is passed
to an encapsulator which typically receives PDUs (Ethernet
frames or IP datagrams). It formats each PDU into a series of TS
packets (usually adding an encapsulation header), forming a TS.
In a simple example, one or more TS are processed by a MPEG-2
multiplexor resulting in a TS Multiplex. In more complex examples,
the same TS may be fed to multiple MPEG-2 multiplexors and these
may, in turn, feed other MPEG-2 multiplexors (remultiplexing).
In all cases, the final result is a "TS Multiplex" which is
transmitted over the physical bearer towards the receiver.
To receive IP datagrams 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
subnetwork Protocol Data Units (PDUs), and the receiver must
therefore filter (accept) IP datagrams sent with a number of PID
values, and must independently reassemble each subnetwork PDU. A
system which simultaneously receives from several TS logical
channels, utilise receiver hardware to filter unwanted TS logical
channels. Most current hardware has a limit on the maximum number of
active PIDs (e.g. 32). 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 Datagrams over other
media not using MPEG-2 transmission.
Bi-directional (duplex) transmission can be provided in the DVB
framework by using one of a number of alternate return channel
schemes [DVB-RC]. Duplex IP paths may also be supported using non-
DVB 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 datagrams or Ethernet_style frames in the control plane
associated with audio/video transport. It includes a set of
optional header components and requires decoding of the control
headers.
Expires June 2002 [page 4]
INTERNET DRAFT Requirements for IP transport over DVB Sept 2001
+-----------------------------------------+
|Encap Header| Subnetwork PDU |
+-----------------------------------------+
/ / \ \
/ / \ \
/ / \ \
+------*----------* +------*----------* +------*----------+
|MPEG-2| MPEG-2 |..|MPEG-2| MPEG-2 |...|MPEG-2| MPEG-2 |
|Header| Payload | |Header| Payload | |Header| Payload |
+------+----------+ +------+----------+ +------+----------+
Figure 2: Encapsulation of subnetwork PDU (e.g. IP datagram) into a
series of MPEG-2 Transport Stream, TS, packets (each TS packet
carries a header with a common Packet ID, PID, value).
The framework proposed in this document describes a set of protocols
designed to allow IP datagrams to be sent over an MPEG-2 TS logical
channel. Since most MPEG-2 transmission links are bandwidth-limited,
this needs to be simple, robust, and have good link efficiency (i.e.
small overhead) when transporting variable sized IP datagrams. The
document also suggests the need for supporting protocols (e.g. to
support operation and configuration of the link, provide resolution
of the MPEG-2 TS logical channel, error reporting, etc).
The framework may also be applicable to other subnetworks utilizing
the MPEG-2 TS, and also similar links (e.g. other MPEG-2
transmission networks, regenerative satellite links [ETSI-BSM]).
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.
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 which receives Ethernet frames or IP
datagrams, and formats these for output as a transport stream of TS
packets.
Expires June 2002 [page 5]
INTERNET DRAFT Requirements for IP transport over DVB Sept 2001
FORWARD DIRECTION: The dominant direction of data transfer over a
network path. Data transfer in the forward direction is called
"forward transfer". Packets travelling in the forward direction
follow the forward path through the IP network.
MAC: Medium Access and Control of the Ethernet IEEE 802 standard of
protocols.
MPE: Multiprotocol Encapsulation [ETSI-DAT]. A scheme that
encapsulates Ethernet frames or IP Datagrams, creating a
DSM-CC Section. The Section will be sent in a series of TS Packets
over a TS logical channel.
MPEG-2: A set of standards specified by the Motion Picture Experts
Group (MPEG), and standardized by the International Standards
Organisation (ISO) [ISO-MPEG].
PID: Packet Identifier. A field carried in the header of all MPEG-2
Transport Stream packets. This is used to identify the TS logical
channel to which it belongs [ISO-MPEG].
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.
TS: Transport Stream [ISO-MPEG], a method of transmission at the
MPEG-2 level using TS packets; it represents level 2 of the ISO/OSI
reference model. See also TS logical channel and TS Multiplex.
TS LOGICAL CHANNEL: a channel identified at the MPEG-2 level; it
represents level 2 of the ISO/OSI reference model. All packets sent
over a channel carry the same PID value
TS MULTIPLEX: A set of MPEG-2 transport stream channels sent over a
single common physical link (i.e. a transmission at a specified
symbol rate, FEC setting, and transmission frequency).
TS PACKET: A fixed-length 188B unit of data sent over an MPEG-2
multiplex [ISO-MPEG]; it corresponds to the cells, of e.g. ATM
networks, and is frequently also referred to as a TS_cell. Each TS
packet carries a 4B header, plus optional overhead including
Expires June 2002 [page 6]
INTERNET DRAFT Requirements for IP transport over DVB Sept 2001
pointers to the next payload header, encryption details and time
stamp information to synchronise a set of Transport Streams.
3. Motivation
This section describes existing solutions and the need for a new
framework. This framework may be used over a link in the forward
and/or the reverse direction. The protocols to be supported over a
link are:
(i) IPv4 Unicast datagrams, destined for a single end host
(ii) IPv4 Broadcast datagrams, sent to all end systems in an IP
network
(iii) IPv4 Multicast datagrams
(iv) IPv6 Unicast datagrams, destined for a single end host
(v) IPv6 Multicast datagrams
(vi) Datagrams with compressed IPv4 / IPv6 packet headers (e.g.
[RFC1114;RFC2507;RFC3095])
Two issues are addressed by this framework: First that of providing
an efficient encapsulation scheme which may be easily implemented in
IP-based transmitters and receivers. Second, existing standards do
not define how an IP node should associate a particular IP address
with a subnetwork channel (PID, TS Multiplex). Bindings are required
for both unicast transmission, and multicast reception. In this
document, these are referred to as IP address resolution issues.
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 datagram and processing overhead in terms
of parsing effort of variable length headers or options fields
(see iv). This is important 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 known to be not optimal
for IP, incurring significant receiver processing overhead and
extra link overhead [CLC99].
Expires June 2002 [page 7]
INTERNET DRAFT Requirements for IP transport over DVB Sept 2001
(iv) Maximum Link Thruput. 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.
(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
IP 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.
(vi) 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.
The specified framework and techniques to be developed may also be
suited to non-DVB systems employing the MPEG-2 TS, or other
(sub)networks offering similar transfer capabilities.
4. Requirements for IP datagrams
This section describes the requirements for transporting IPv4 and
IPv6 over MPEG-2 links The section identifies key needs and provides
examples of mechanisms that may be used to implement these.
(i) MPEG-2 Transport Stream. The framework should provide
mechanisms to access the underlying network features (MPEG-2
timestamps, PIDs, etc). It should also offer guidance on
which MPEG-2 features are pre-requisites for this service,
and any optional fields which impact performance / correct
operation of the IP encapsulation.
(ii) Probability of undetected packet error. There should be a
small (or negligible) probability of an undetected packet
error [LINK-ID]. The scheme therefore needs to be robust to
software failures and link loss. The need for a subnetwork
PDU CRC will be determined.
(iii) TS logical channel Resolution. There is a need to signal the
PID and TS Multiplex that is associated with each IP flow to
the network layer at the sender and receiver (address
resolution). To make such schemes robust to loss and state
changes within the MPEG-2 subnetwork, a soft-state approach
Expires June 2002 [page 8]
INTERNET DRAFT Requirements for IP transport over DVB Sept 2001
may prove desirable. This could, for example, be implemented
via descriptors sent in the SI tables (using the MPEG-2
control plane), or in-band by a protocol using a data channel
(e.g. similar to the Ethernet address resolution protocol
(ARP)).
(iv) IPv4 and IPv6. The framework must support IPv4 and IPv6
network protocols. To do this, the payload encapsulation may
require a type field in the subnetwork PDU to indicate the
type of the PDU being carried (e.g. IPv4, IPv6).
(v) Compressed Headers. The framework must address the need in
certain applications for the support of header compression
schemes. This may require a type field in the subnetwork PDU
to indicate the type of the PDU being carried (e.g. IPv4,
IPv6, Compressed Header).
(vi) Multicast. The framework must support IP multicast
transmission of IPv4 and IPv6 datagrams. Support for
broadcast must also be considered for IPv4.
(vii) Frame size and fragmentation. Specification of minimum and
maximum frame sizes (MTU). The need (or not) for IP
fragmentation and transparent fragmentation to support the
minimum MTU [RFC1191;Ken87;LINK-ID]. There is no currently
anticipated need to support IPv6 Jumbograms.
(viii) Identification of subnetwork source/destination. A new
encapsulation scheme may need to support layer 2 addresses
(e.g. Ethernet MAC source and destination addresses) of nodes
in the MPEG-2 transport network. These are not required for
layer 3 functionality, and the need, and applicability, must
be addressed by the framework.
(ix) Filtering. Support for efficient filtering and extraction of
IP packets. This may require layer 2 addresses or labelling
of streams corresponding to IP flows.
(x) Diffserv and QoS. The mapping of QoS functions may also be
addressed (if specific issues arose). This may include how
such fields as IP address, IP QoS/DSCP should be mapped to
the under-lying MPEG-2 transport stream.
(xi) 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 (i.e. where there is also a reverse
direction path between the receiving IP end host and the
sending IP end host). Consideration should also be given to
Expires June 2002 [page 9]
INTERNET DRAFT Requirements for IP transport over DVB Sept 2001
security of the TS Multiplex, the need for closed user groups
and the use of MPEG-2 TS encryption.
(xii) Management. There may be a future need for standardised SNMP
MIBs and error reporting procedures. The need for and scope
of this is yet to be determined.
The first goal of this work is to define a lightweight encapsulation
protocol that meets the above requirement.
5. Supporting Protocols
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 system 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 DSM-CC section format [ISO_DSMCC]). This scheme is
complex, and reflects the complexity of delivering and co-ordinating
the various TS logical channels associated with a multimedia TV
programme. There is no direct support for IP mechanisms for
identification of the TS multiplex and PID in use for a particular
IP address.
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.
Another alternate approach is to carry this information over the a
TS data channel, (e.g. using a 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 and therefore do not need to provide full
interoperability with TV equipment (e.g. links used solely for
connecting IP (sub)networks).
A final possible approach is to design a query/response protocol
(like ARP) which operates over an MPEG-2 TS logical channel using a
previously agreed PID (e.g. configured, or communicated using a SI
table).
Work in this area includes:
(i) Request by a sender to associate a PID with an IP flow.
Expires June 2002 [page 10]
INTERNET DRAFT Requirements for IP transport over DVB Sept 2001
(ii) Request by a sender to establish a QoS association for a PID
carried over the MPEG-2 TS Multiplex.
(iii) Indication of the MPEG-2 TS Multiplex capabilities to
configure the upstream IP sender.
(iv) Indication to the IP receiver of the PID and TS Multiplex
that should be used for reception of IP datagrams from a
particular address.
(v) Definition of a MIB to provide standard management of the IP
subnetwork using SNMP.
The IP address resolution support may also be suited for use with
other IP over MPEG-2 encapsulations (e.g., MPE [ETSI-DAT]). As part
of address resolution, there is also a need to signal whether MPE or
an IETF encapsulation is used.
6. Multicast Support
This section addresses specific issues concerning IPv4 and IPv6
multicast over MPEG-2 links.
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.
Appropriate procedures need to be specified to identify the correct
action when the same multicast group is available on separate TS
logical channels. This could arise when different end hosts act as
senders to contribute IP datagrams with the same IP group
destination address. Another different case arises when a receiver
may potentially receive more than one copy of the same packet. In
some cases, these may be sent in different TS logical channels, or
even different TS Multiplexes.
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 the drivers and operating
systems from discarding unwanted multicast traffic.
7. Evaluation of transmission of IP datagrams over DVB networks
Expires June 2002 [page 11]
INTERNET DRAFT Requirements for IP transport over DVB Sept 2001
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 Datagram 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.
8. 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). This
framework transmits IP datagrams using the Multiprotocol
Encapsulation (MPE), which is widely implemented, and in addition,
proposes a new optimised encapsulation procedure. The framework
also includes one or more new MPEG-2 TS logical channel resolution
procedures to allow dynamic configuration of the sender and receiver
using an MPEG-2 link. The framework will support IPv4 and IPv6
services in both the unicast and multicast modes. Support for
compression is also a key element in this proposed framework.
9. Acknowledgments
The authors wish to thank Torsten Jaekel, Rod Walsh, and , Luoma
Juha-Pekkaand 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.
10. References
[ATSC] A/53, "ATSC Digital Television Standard", Advanced Television
Systems Committee (ATSC), Doc. A/53, 1995.
[ATSC-DAT] A/90, "ATSC Data Broadcast Standard", Advanced Television
Systems Committee (ATSC), Doc. A/090, 26 July 00
[ATSC-DATG] A/91, "Recommended Practice: Implementation Guidelines
for the ATSC Data Broadcast Standard", Advanced Television Systems
Committee (ATSC),Doc. A/91. 10 June 2001
[ATSC-G] A/54, "Guide to the use of the ATSC Digital Television
Standard", Advanced Television Systems Committee (ATSC), Doc. A/54,
4 Oct 95
[ATSC-PSIP-TC] A/65A, "Program and System Information Protocol for
Terrestrial Broadcast and Cable", Advanced Television Systems
Committee (ATSC), Doc. A/65A, 23 Dec 1997, Rev. A _ 31 May 2000
Expires June 2002 [page 12]
INTERNET DRAFT Requirements for IP transport over DVB Sept 2001
[ATSC-S] A/80, "Modulation and Coding Requirements for Digital TV
(DTV) Applications over Satellite", Advanced Television Systems
Committee (ATSC), Doc. A/80, 17 July 99
[CLC99] Clausen, H., Linder, H., and Collini-Nocker, B., "Internet
over Broadcast Satellites", IEEE Commun. Mag. 1999, pp.146-151.
[ETSI-DAT] EN 301 192 Specifications for Data Broadcasting, European
Telecommunications Standards Institute (ETSI).
[ETSI-DVBC] EN 300 800 Digital Video Broadcasting (DVB); DVB
interaction channel for Cable TV distribution systems (CATV),
European Telecommunications Standards Institute (ETSI).
[ETSI-DVBS] EN 301 421 Digital Video Broadcasting (DVB); Modulation
and Coding for DBS satellite systems at 11/12 GHz, European
Telecommunications Standards Institute (ETSI).
[ETSI-DVBT] EN 300 744 Digital Video Broadcasting (DVB); Framing
structure, channel coding and modulation for digital terrestrial
television (DVB-T), European Telecommunications Standards Institute
(ETSI).
[ISO-DSMCC] ISO/IEC IS 13818-6 Information technology -- Generic
coding of moving pictures and associated audio information -- Part
6: Extensions for DSM-CC is a full software implementation,
International Standards Organisation (ISO).
[ISO-MPEG] ISO/IEC DIS 13818-1 Information technology -- Generic
coding of moving pictures and associated audio information: Systems,
International Standards Organisation (ISO).
[ISO-VID] ISO/IEC DIS 13818-2 Information technology -- Generic
coding of moving pictures and associated audio information: Video,
International Standards Organisation (ISO).
[ISO-AUD] ISO/IEC 13818-3:1995 Information technology -- Generic
coding of moving pictures and associated audio information -- Part
3: Audio, International Standards Organisation (ISO).
[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.
Expires June 2002 [page 13]
INTERNET DRAFT Requirements for IP transport over DVB Sept 2001
[RFC1191] Mogul, J., Deering, S., "Path MTU Discovery", RFC 1191.
[RFC2507] Degermark, M., Nordgren, B., and Pink, S., "IP Header
Compression", RFC2507.
[RFC3077] E. Duros, W. Dabbous, H. Izumiyama, Y. Zhang, "A Link
Layer Tunneling Mechanism for Unidirectional Links", RFC3077.
[RFC3095] C. Bormann, et al, "RObust Header Compression (ROHC):
Framework and four profiles: RTP, UDP ESP and uncompressed",
RFC3095.
11.Authors' Addresses
Godred Fairhurst
Department of Engineering
University of Aberdeen
Aberdeen, AB24 3UE
UK
Email: gorry@erg.abdn.ac.uk
Web: http://www.erg.abdn.ac.uk/users/gorry
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.
Expires June 2002 [page 14]
INTERNET DRAFT Requirements for IP transport over DVB Sept 2001
12. 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 2002 [page 15]
INTERNET DRAFT Requirements for IP transport over DVB Sept 2001
Appendix 1 Examples of Available Mechanisms for Encapsulation
NOTE: The text in this appendix is working notes, and not intended
for publication in the final document.
List of possible issues include:
(i) Delineation of start and end of datagrams (and padding, if
required to end of a MPEG-2 TS packet).
- Should the MPEG-2 TS start-of-payload indicator be used?
- Many IP packets (e.g. a TCP ACK) are typically much smaller
than an MPEG-2 TS packet; Packing of multiple datagrams per
MPEG-2 packet may significantly improve link efficiency.
(ii) 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. Current DVB
implementations of DVB receivers frequently restrict the
number of PIDs that may be simultaneously received. A simpler
encapsulation method may reduce receiver complexity and/or
increase the number of PIDs that may be received.
(iii) Subnetwork PDUs could have an encapsulation header with
address field(s) (if required, e.g. MAC or layer 2 end-point)
This may not be required for direct router-to-router
communication.
(iv) Subnetwork PDUs could have a Protocol Type Field.
- Is this required?
- May be a pre-requisite for ROHC [RFC3095]?
- Also useful for supporting extension headers
- Also useful for IPv6 / IPv4 service access points.
(v) Subnetwork PDUs must have a Payload Length Field.
- Padding must also be supported.
(vi) Subnetwork options (to be discouraged, but could be provided
via an alternate protocol type field and an extension
header).
(vii) Payload Checksum / CRC (required? or optional?)
[LINK-ID] suggests a CRC-32 may be suitable. A PDU CRC may
also be used to validate
(viii) Error Reporting. If an equipment is an IP device, then it
should conform to standard requirements for hosts [RFC1122]
or routers [RFC1812] (depending on its behaviour).
(ix) The framework should allow IPSEC. Link level encryption may
be provided using an MPEG-2 TS option.
Expires June 2002 [page 16]
INTERNET DRAFT Requirements for IP transport over DVB Sept 2001
(x) There are benefits from designing a framework which may be
appropriate a packet/cell size different from 188B. This
would allow evolution of the techniques, to support future
versions of MPEG-2 and other cell based physical layers. A
common standard would also be very desirable for hybrid
systems which employ different physical links in the forward
and reverse directions.
Expires June 2002 [page 17]