Internet Engineering Task Force Marie J. Montpetit ed.
Internet Draft MJMontpetit.com, USA
Document: draft-ietf-ipdvb-arch-00.txt Gorry Fairhurst
University of Aberdeen, U.K.
Horst D. Clausen
Bernhard Collini-Nocker
Hilmar Linder
University of Salzburg, Austria
Category: Informational July 2004
A Framework for transmission of IP datagrams over MPEG-2 networks
Status of this Memo
By submitting this Internet-Draft, we certify that any applicable
patent or other IPR claims of which we am aware have been disclosed,
or will be disclosed, and any of which we become aware will be
disclosed, in accordance with RFC 3668.
By submitting this Internet-Draft, we accept the provisions of
Section 3 of RFC 3667 (BCP 78).
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.
Copyright (C) The Internet Society (2004), All Rights Reserved
Abstract
This document describes a new architecture 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
of systems using MPEG-2 include the Digital Video Broadcast (DVB)
and Advanced Television Systems Committee (ATSC) Standards for
Digital Television.
The document 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 address resolution, to
associate IP packets with the properties of the Logical Channels
provided by an MPEG-2 TS.
Expires November 2004 [page 1]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
Table of Contents
1. Introduction
2. Conventions Used in this Document
3. Architecture
4. Encapsulation Protocol
5. Address Resolution Functions
6. Multicast Support
7. Summary
8. Security Considerations
9. Acknowledgments
10. References
11. Author's Addresses
12. IANA Considerations
Appendices
Expires November 2004 [page 2]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
Document History
-00 Current version
Expires November 2004 [page 3]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
1. Introduction
This document identifies requirements and an architecture for
transport
of IP Datagrams over ISO MPEG-2 Transport Streams [MPEG2]. The prime
focus is the efficient and flexible delivery of IP services over
those subnetworks that use the MPEG-2 transport stream.
Hence, the architecture is 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] and Cable Transmission [ETSI-
DVBC; ATSC-PSIP-TC]).
+---------+-+-+-+-+------+--------+---+--+--+
| |T|V|A|O| O | | O |S |O |
| |e|i|u|t| t | | t |I |t |
| |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 data types, MPEG-2
components may, and are, also used to build IP-only networks.
Often, those networks do not implement all parts of a DVB / ATSC
system, and may for instance support minimal, or no, signalling of
Service Information (SI) tables. Standard system components offer
advantages of improved interoperability and larger deployment.
1.1 Salient features of the Architecture
The architecture proposed in this document describes a set of
protocols
to support transmission of IP packets over the MPEG-2 TS. Key
characteristics of these networks are that they may provide link-
level broadcast capability, and that many supported applications
require access to a very large number of subnetwork nodes. Some or
Expires November 2004 [page 4]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
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 of the architecture are to reduce complexity when using the
system, while improving performance, increasing flexibility for IP
services, and providing opportunities for better integration with IP
services.
Since a majority of MPEG-2 transmission networks are bandwidth-
limited, encapsulation protocols must therefore add minimal overhead
to ensure good link efficiency while providing adequate network
services. They also needs to be simple to minimize processing,
robust to errors and security threats, and extensible to a wide
range of services.
In MPEG-2 systems, logical channels provide multiplexing,
addressing, and error reporting. The logical channel may also be
used to provide Quality of Service (QoS). Mapping functions are
required to relate Logical Channels to IP addresses, to map Logical
Channels to IP-level QoS, and to associate IP flows with specific
subnetwork capabilities. An important feature of the proposed
architecture will be to provide these functions in a dynamic way,
allowing transparent integration with other IP-layer protocols.
Collectively, these will form a MPEG-2 TS address resolution
protocol suite.
Expires November 2004 [page 5]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
2. Conventions Used In This Document
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 Media 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: Packetized Elementary Stream. A format of MPEG-2 TS packet
payload usually used for video or audio information in MPEG-2 [ISO-
MPEG].
Expires November 2004 [page 6]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
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 (decimal)
indicates a null packet that must be discarded by a Receiver.
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 November 2004 [page 7]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
3. Architecture
The following sections introduce the components of the MPEG-2
Transmission network and relate these to a networking framework.
3.1 MPEG-2 Transmission Networks
There are many possible topologies for the MPEG-2 Transmission
Networks. A number of example scenarios are briefly described below,
and the following text relates specific functions to this set of
scenarios.
A) Broadcast TV and Radio Delivery
The principal service in the Broadcast TV and Radio Delivery
scenario is Digital TV and/or Radio and their associated data [ID-
MMUSIC-IMG]. Such networks typically contain two components: the
contribution feed and the broadcast part. Contribution feeds
provide communication from a typically small number of individual
sites (usually at high quality) to the Hub of a broadcast network.
The traffic carried on contribution feeds is typically encrypted,
and is usually processed prior to being resent on the Broadcast part
of the network. The Broadcast part uses a star topology centred on
the Hub to reach a typically large numbers of down-stream Receivers.
Although such networks may provide IP transmission, they do not
necessarily provide access to the public Internet.
B) Broadcast Networks used as an ISP
Another scenario resembles that above, but includes the provision of
IP-services providing access to the public Internet. The IP traffic
in
this scenario is typically not related to the digital TV/Radio
content,
and the service may be operated by an independent operator such as
uni-
directional File Delivery or bi-directional ISP access. The IP
service
must adhere to the full system specification used for the broadcast
transmission, including allocation of PIDs, and generation of
appropriate MPEG-2 control information (e.g. DVB and ATSC SI tables).
C) Uni-directional Star IP Scenario
The Uni-directional Star IP Scenario utilises a Hub station to
provide a data network delivering a common bit stream to medium-
sized groups of Receivers. MPEG-2 transmission technology provides
the forward physical and link layers for this transmission, the
return link (if required) is provided by other means. IP services
typically form the main proportion of the transmission traffic. Such
networks may not necessarily implement the MPEG-2 control plane.
D) Data-cast overlay
The Data-cast overlay scenario employs MPEG-2 physical and link
layers to provide additional connectivity such as uni-directional
multicast to supplement an existing IP-based Internet service.
Examples of such a network includes IP Datacast to mobile wireless
receivers [ID-MMUSIC-IMG].
Expires November 2004 [page 8]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
E) Point-to-point links
Point-to-point connectivity may be provided using a pair of transmit
and receive interfaces supporting the MPEG-2 physical and link
layers. Typically the transmission from a sender is received by
only one or a small number of Receive terminals. Examples include
the use of transmit/receive DVB-S terminals to provide satellite
links between ISPs utilising BGP routing.
F) Two-Way IP Networks
Two-Way IP networks are typically satellite-based and star-based
utilising a Hub station to deliver a common bit stream to medium-
sized groups of receivers. A bi-directional service is provided over
a common air-interface. The transmission technology in the forward
physical and link layers for this transmission is MPEG-2, which may
also be used in the return direction. Such systems also usually
include a control plane element to manage the (shared) return link
capacity. A concrete example is the DVB-RCS system. IP services
typically form the main proportion of the transmission traffic.
Scenarios A-D employ uni-directional MPEG-2 Transmission networks.
For satellite-based networks, these typically have a star topology,
with a central Hub providing service to large numbers of down-stream
Receivers. Terrestrial networks may employ several transmission Hubs
each serving a particular coverage cell with a community of
Receivers.
From an IP viewpoint, the service is typically either uni-
directional multicast, or a bi-directional service in which some
complementary link technology (e.g. Modem, LMDS, GPRS, ...) is used
to provide the return path from Receivers to the Internet. Routing
in this case could be provided using Uni-Directional Link Routing
(UDLR) [RFC3077].
Note that only Scenarios A-B actually carry MPEG-2 video and audio
intended for reception by digital Set Top Boxes (STBs) as the
primary traffic. The other scenarios are IP-based data networks and
need not necessarily implement the MPEG-2 control plane.
Scenarios E-F provide two-way connectivity using MPEG-2
transmission. Such networks provide direct support for bi-
directional protocols above and below the IP layer.
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 include a TV operator
(Scenario A), or an ISP (Scenarios B-F). MPEG-2 transmission
networks are also used for private networks. These typically involve
a smaller number of Receivers and do not require the same level of
centralised control. Examples include companies wishing to connect
DVB-capable routers to form links within the Internet (Scenario B).
Expires November 2004 [page 9]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
3.2 TS Logical Channels
An MPEG-2 transport multiplex offers a number of parallel channels,
which are known here as 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 available channels is limited to 8192
(decimal), 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 packets [ISO-DSMCC; ETSI-DAT; ATSC-DAT],
or other data [ISO-DSMCC; ETSI-DAT; ATSC-DAT]. The value 8191
(decimal) 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
Multiplex (MUX). In most cases the data sent over the TS Logical
Channels will differ for different multiplexes. The above figure
shows a set of TS Logical Channels sent using two MPEG-2 TS
Multiplexes (A and B).
There are cases where the same data may be distributed over two or
more multiplexes (e.g., some SI tables; multicast content 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
Expires November 2004 [page 10]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
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).
As can been seen above, there are similarities between the way PIDs
are used and the operation of virtual channels in ATM. However,
unlike ATM, a PID defines a unidirectional broadcast channel and not
a point-to-point link. Contrary to ATM, there is, as yet, no
specified standard interface for MPEG-2 connection setup, or for
signalling mappings of IP flows to PIDs, or to set the Quality of
Service, QoS, assigned to an TS Logical Channel.
3.3 Multiplexing and Re-Multiplexing
In a simple example, one or more TS are processed by a MPEG-2
multiplexor resulting in a TS Multiplex. The TS Multiplex is
forwarded over a physical bearer towards one or more Receivers
(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
Expires November 2004 [page 11]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
In a more complex example, the same TS may be fed to multiple MPEG-2
multiplexors and these may, in turn, feed other MPEG-2 multiplexors
(remultiplexing). Remultiplexing may occur in several places (and is
common in Scenario A of section 3.1). One example is a satellite
that provides on-board processing of the TS packets, multiplexing
the TS Logical Channels received from one or more 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. It may also modify and/or
insert new SI data into the control plane to reflect the content
output using TS Multiplex.
In all cases, the final result is a "TS Multiplex" which is
transmitted over the physical bearer towards the Receiver.
3.4 IP Datagram Transmission
Packet data for transmission over the MPEG-2 transport multiplex is
passed to an Encapsulator, sometimes known as a Gateway. This
receives Protocol Data Units, PDUs, such as Ethernet frames or IP
packets, and formats each into a Sub-Network Data Unit, SNDU, by
adding an encapsulation header and trailer (see section 5). The
SNDUs are subsequently fragmented into a series of TS Packets.
To receive IP packets over a MPEG-2 transport multiplex, a Receiver
needs to identify the specific TS Multiplex (physical link) and also
the TS Logical Channel (the PID value of a logical link). It is
common for a number of MPEG-2 TS Logical Channels to carry SNDUs,
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, must filter other unwanted TS Logical Channels by
employing for example specific hardware support. Packets for one IP
flow (i.e. a specific combination of IP source and destination
addresses) must be sent using the same PID. It should not be assumed
that all IP packets are carried on a single PID, as in some cable
modem implementations, and multiple PIDs must be allowed in the
architecture. Many current hardware filters limit the maximum number
of
active PIDs (e.g. 32), although if needed, future systems may
reasonably be expected to support more.
In some cases, Receivers may need to select TS Logical Channels from
a number of simultaneously active TS Multiplexes. To do this, they
need multiple physical receive interfaces (e.g., RF front-ends and
demodulators). Some applications also envisage the concurrent
Expires November 2004 [page 12]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
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 (e.g. in Scenarios B-D of section
3.1). 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. The MPE specification includes a set of optional header
components and requires decoding of the control headers. This
processing is suboptimal for Internet traffic, since it incurs
significant receiver processing overhead and some extra link
overhead [CLC99].
+-----------------------------------------+
|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).
3.5 Motivation
The network layer protocols to be supported by this architecture
include:
(i) IPv4 Unicast packets, destined for a single end host
(ii) IPv4 Broadcast packets, sent to all end systems in an IP
network
(iii) IPv4 Multicast packets
(iv) IPv6 Unicast packets, destined for a single end host
(v) IPv6 Multicast packets
(vi) Packets with compressed IPv4 / IPv6 packet headers (e.g.
[RFC1114; RFC2507; RFC3095])
(vii) Bridged Ethernet frames
(viii) Other (MPLS, IPv6 anycast, potential new protocols__
Expires November 2004 [page 13]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
The architecture will provide:
(i) Guidance on which MPEG-2 features are pre-requisites for the IP
service, and identification of any optional fields that impact
performance/correct operation.
(ii) Standards to provide an efficient and flexible encapsulation
scheme that may be easily implemented in an Encapsulator or
Receiver. The payload encapsulation requires a type field for
the SNDU to indicate the type of packet and a mechanism to
signal which encapsulation is used on a certain PID.
(iii) Standards to associate a particular IP address with a Network
Point of Attachment (NPA) that could or could not be a MAC
Address. This process resembles the IPv4 Address Resolution
Protocol, ARP, or IPv6 Neighbour Discovery, ND, protocol [AR-
DRAFT]. In addition, the standard will be compatible with IPv6
autoconfiguration.
(iv) Standards 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.
(v) Standards to associate the capabilities of a MPEG-2 TS Logical
Channel with IP flows. This includes mapping of QoS functions,
such as IP QoS/DSCP and RSVP, to underlying MPEG-2 TS QoS,
multi-homing and mobility. This capability could be associated
by the AR standard proposed above.
(vi) Guidance on Security for IP transmission over MPEG-2. The
framework must permit use of IPSEC and clearly identify any
security issues concerning the specified protocols. The security
issues need to consider two cases: unidirectional transfer (in
which communication is only from the sending IP end host to the
receiving IP end host) and 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 of the IP transmission, including standardised SNMP
MIBs and error reporting procedures. The need for and scope of
this is to be determined.
The specified architecture and techniques should be suited to a range
of systems employing the MPEG-2 TS, and may also suit other (sub)
networks offering similar transfer capabilities.
Expires November 2004 [page 14]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
The following sections 4 and 5 describe encapsulation issues.
Sections 6 and 7 describe address resolution issues for unicast and
multicast. The appendix provides some use cases.
4. Encapsulation Protocol Requirements
This section identifies requirements 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.
The encapsulation protocol transports a SNDU over the MPEG-2 TS
service and provides 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
such as length of SNDU, Receiver address, multiplexing information,
payload type, sequence numbers etc. The SNDU payload is typically
followed by a trailer, which carries an Integrity Check (e.g.,
Cyclic Redundancy Check, CRC). Some protocols also add additional
control information and/or padding to or after the trailer.
+--------+-------------------------+-----------------+
| Header | SNDU | Integrity Check |
+--------+-------------------------+-----------------+
Figure 5: 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].
The existing proposals and standards for use with MPEG-2 carry
heritage from legacy implementations that reflect the limitations of
technology at their deployment. For example a majority are more
dominated by audio/video considerations than IP requirements. This
justifies the development of a new encapsulation that will be truly
IP-centric. Carrying IP packets over a TS Logical Channel involves
several convergence protocol functions. This section briefly
describes these functions and highlights the requirements for a new
encapsulation.
4.1 Payload_Unit Delimitation
MPEG-2 indicates the start of a Payload Unit 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
Expires November 2004 [page 15]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
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,
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.
4.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 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
Expires November 2004 [page 16]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
of the current Internet. This would seem a suitable maximum size
for an MPEG-2 transmission network.
4.3 Next Level Protocol Type
A key feature of the new encapsulation is to identify the type of
payload being transported (e.g., to differentiate IPv4, IPv6 etc.).
Most protocols use a type field to identify a specific process at
the next higher layer that is the originator or the recipient of the
payload (SNDU). This method is used by IPv4, IPv6, and also by the
original Ethernet protocol (DIX). OSI uses the concept of a
'Selector' for this, (e.g. in the IEEE 802/ISO 8802 standards for
CSMA/CD [LLC], although in this case a SNAP (subnetwork access
protocol) header is also required for IP packets.
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 architecture, 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 wireless 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. The selected type field should contain
sufficient code points to support this technique.
It is thus a requirement to include a Next Level Protocol Type field
in the encapsulation header. Such a field should specify values for
at least IPv4, IPv6, and must allow for other values (e.g., MAC-
level bridging).
4.4 L2 Subnet Addressing
In MPEG-2, 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
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.
Expires November 2004 [page 17]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
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 Receivers 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 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).
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. There are many cases
where a NPA is not required, and network layer filtering may be used.
A new encapsulation protocol should therefore support an optional
NPA.
4.5 Integrity Check
For the IP service, the probability of undetected packet error
should be small (or negligible) [ID-PILC-LINK]. 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).
Expires November 2004 [page 18]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
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.
4.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.
4.7 Extension Headers
The evolution of the Internet service may in future require
additional functions. A flexible protocol should therefore provide a
way to introduce new features when required, without having to
provide additional out-of-band configuration.
IPv6 introduced the concept of extension headers that carry extra
information necessary/desirable for certain subnetworks. The DOCSIS
cable specification also allows a MAC header to carry extension
headers to build operator-specific services. It is thus a
requirement for the new encapsulation to allow extension headers.
4.8 Summary of Requirements for Encapsulation
The main requirements for an IP-centric encapsulation include:
- support of IPv4 and IPv6 packets
- support for Ethernet encapsulated packets
- flexibility to support other IP formats and protocols (e.g.
ROHC, MPLS)
- easy processing by hardware devices
- low overhead/managed overhead
- a fully specified algorithm that allows a sender to pack
multiple packets per SNDU and to easily locate packet fragments
- extensibility
- compatibility with legacy deployments
- ability to allow link encryption, when required
- capability to support a full network architecture including
data, control and management planes
Expires November 2004 [page 19]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
5. Address Resolution Functions
Address Resolution (AR) provides a mechanism that associates L2
information 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 (e.g. 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 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 other information than the MAC address. This
includes identifying other parameters required for L2 transmission,
such as channel IDs (VCs in X.25, 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 many MPEG-2 transmission networks.
5.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 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 (see
section 3.2).
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 November 2004 [page 20]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
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.
A star topology MPEG-2 TS transmission network is illustrated below,
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 broadcast
MPEG-2TS \
----------------X /-----\
/ / \
| Receiver|
/----------+ A |
/ \ /
/-----\ / \-----/
/ \ /
| Hub |/
| +\ /-----\
\ / \ / \
\-----/ \ | Receiver|
\-----------+ B |
\ /
\-----/
Figure 6: MPEG-2 Transmission Network with 2 Receivers
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.
Expires November 2004 [page 21]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
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.
An end 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.
5.2 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
implementations of this are known)
(iii) An address resolution protocol transported over IP (as in ND)
There are three distinct cases 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 (see Scenario A of Section 3.1).
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.
5.2.1 Table-based AR over MPEG-2
In current deployments of MPEG-2 networks, 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
Expires November 2004 [page 22]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
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 delivering and co-ordinating the various
TS Logical Channels associated with a multimedia TV programme.
One possible requirement 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. The DVB INT and the A/92 Specification from ATSC
[ATSC-A92] are examples of the realization of such a requirement.
5.2.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
and therefore do not need to provide interoperability with TV
equipment (e.g. links used solely for connecting IP (sub)networks).
5.2.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.
5.3 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;
Expires November 2004 [page 23]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
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. 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 an IP
packet may lead to unexpected protocol behaviour. This also provides
a security vulnerability since arbitrary packets may be passed to
the IP layer.
5.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
that it receives. 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.
Expires November 2004 [page 24]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
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.
5.6 Requirements for Unicast AR over MPEG-2
The requirement for AR over MPEG-2 networks include:
(i) Use of a table based approach to promote AR scaling. This
requires 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) Support of IP subnetwork scoping.
(vi) Appropriate security associations to authenticate the sender.
6. 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.
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.
Expires November 2004 [page 25]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
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.
6.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 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.
Expires November 2004 [page 26]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
\
|
+---+----+ +--------+
| Tuner |---+TS Tabl | . . . .
+---+----+ +--------+ .
| .
+--------+ +--------+ .
| deMux |---+PID Tabl|........
+---+----+ +--------+ :
| :
+--------+ +--------+ +--------+
|MPE/ULE |---+AR Cache|---+ MFIB |
+---+----+ +--------+ +--------+
| | |
+---+----+ +---+----+ +---+----+
| IP | | AR | |IGMP/MLD|
+---+----+ +---+----+ +---+----+
| | |
*------------+------------+
Figure 7: Receiver Processing Architecture
6.2 Requirements for Multicast over MPEG-2
The requirements for supporting multicast 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 AR information to allow a Receiver to locate an IP
multicast flow within an MPEG-2 TS Multiplex.
(v) Error Reporting.
7. Summary
This document describes the architecture for a set of protocols to
perform efficient and flexible support for IP network services over
networks built upon the MPEG-2 Transport Stream (TS). It also
describes existing approaches. It focuses on IP networking, the
mechanisms that are used and their applicability to supporting IP
unicast and multicast services.
The requirements for a new encapsulation of IPv4 and IPv6 packets is
described, outlining the limitations of current methods and the need
for a streamlined IP-centric approach.
The architecture also describes MPEG-2 Address Resolution (AR)
procedures to allow dynamic configuration of the sender and Receiver
using an MPEG-2 transmission link/network. These support IPv4 and
IPv6 services in both the unicast and multicast modes. Resolution
protocols will support IP packet transmission using both the
Expires November 2004 [page 27]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
Multiprotocol Encapsulation (MPE), which is currently
widely deployed, and also any new optimised encapsulation.
8. Security Considerations
When the MPEG-2 network is not using a wireline network, the normal
security issues relating to the use of wireless links for transport
Internet traffic should be considered [ID-PILC-LINK].
End-to-end security (including confidentiality, authentication,
integrity and access control) is closely associated with the end-
user assets that are protected. This close association cannot be
ensured when providing security mechanisms only within a subnetwork
(e.g. an MPEG-2 transmission network). Several security mechanisms
that can be used end-to-end have already been deployed in the
general Internet and are enjoying increasing use. Important examples
include:
* The Secure Sockets Layer (SSL) and Transport Layer Security, TLS,
which is primarily used to protect web commerce;
* Pretty Good Privacy (PGP) and S/MIME, primarily used to protect
and authenticate email and software distributions;
* The Secure Shell (SSH), used to secure remote access and file
transfer;
* IPsec, a general purpose encryption and authentication mechanism
above IP that can be used by any IP application.
However, subnetwork security is also important [ID-PILC-LINK] and
should be encouraged, on the principle that it is better than the
default situation, which all too often is no security at all. Users
of especially vulnerable subnets (such as radio/broadcast networks
and /or shared media Internet access) often have control over at
most one endpoint - usually a client and therefore cannot enforce
the use of end-to-end mechanisms.
A related role for subnetwork security is to protect users against
traffic analysis, i.e., identifying the communicating parties (by IP
or MAC address) and determining their communication patterns, even
when their actual contents are protected by strong end-to-end
security mechanisms (this is important for networks such as
broadcast/radio, where eaves-dropping is easy).
Where it is possible for an attacker to inject traffic into the
subnetwork control plane, subnetwork security can additionally
protect the subnetwork assets. This threat must specifically be
considered for the protocols used for subnetwork control functions
(e.g. address resolution, management, configuration). Possible
threats include theft of service and denial of service; shared media
subnets tend to be especially vulnerable to such attacks [ID-PILC-
LINK]. Appropriate security functions must therefore be provided for
Expires November 2004 [page 28]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
ipdvb control protocols [ID-PILC-LINK], particularly when the
control functions are provided above the IP-layer using IP-based
protocols. Internet level security mechanisms (e.g. IPSEC) can
mitigate such threats.
In general, End-to-End security is recommended for users of any
communication path, especially when it includes a
wireless/radio/broadcast link, where a range of security techniques
already exist. Specification of security mechanisms at the
application layer, or within the MPEG-2 transmission network are the
concerns of organisations beyond the IETF. The complexity of any such
security mechanisms should be considered carefully so that it will
not unduly impact the IP operation.
8.1 Link Encryption
Link level encryption of IP traffic is commonly used in
broadcast/radio links to supplement End-to-End security (e.g.
provided by SSL, SSH, PGP, IPSec). The encryption and key exchange
methods vary significantly, depending on the intended application.
For example, DVB-S/DVB-RCS operated by Access Network Operators
(ANO) may wish to provide their customers (Internet Service
Providers, ISP) with security services. Common targeted security
services are: terminal authentication and data confidentiality (for
unicast and multicast) between a gateway and Receivers. A common
objective is to provide the same level of privacy as terrestrial
links. An ISP may also wish to provide end-to-end security services
to the end-users (based on the well known mechanisms such as IPSec).
Therefore it is important to understand that both security solutions
(ANO-to-ISP and ISP-to-end users) may co-exist.
MPE supports optional link encryption using a pair of bits within
the MPE protocol header to indicate the use of encryption. To
support optional link level encryption, it is recommended that a new
encapsulation also supports optional encryption of the SNDU payload.
Furthermore, it may be desirable to encrypt/authenticate some/all of
the SNDU headers. The method of encryption and the way in which
keys are exchanged is beyond the scope of the ULE Specification.
However, the specification must provide appropriate code points to
allow such encryption to be implemented at the link layer.
9. Acknowledgments
The authors wish to thank Isabel Amonou , Torsten Jaekel, Pierre
Loyer, Luoma Juha-Pekkaand and Rod Walsh for their detailed inputs.
We also wish to acknowledge the input provided by the members of the
IETF ipdvb WG.
Expires November 2004 [page 29]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
10. References
10.1 Normative References
[ISO-MPEG] ISO/IEC DIS 13818-1:2000 "Information technology --
Generic
coding of moving pictures and associated audio information:
Systems", International Standards Organisation (ISO).
[ETSI-DAT] EN 301 192 Specifications for Data Broadcasting, European
Telecommunications Standards Institute (ETSI).
[RFC1122] B. Braden, ed., "Requirements for Internet Hosts -
Communication Layers", RFC 1122.
10.2 Informative References
[ATSC] A/53C, "ATSC Digital Television Standard", Advanced Television
Systems Committee (ATSC), Doc. A/53C, 2004.
[ATSC-DAT] A/90, "ATSC Data Broadcast Standard", Advanced Television
Systems Committee (ATSC), Doc. A/090, 2000.
[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/54A, "Guide to the use of the ATSC Digital Television
Standard", Advanced Television Systems Committee (ATSC), Doc. A/54A,
2003.
[ATSC-PSIP-TC] A/65B, "Program and System Information Protocol for
Terrestrial Broadcast and Cable", Advanced Television Systems
Committee (ATSC), Doc. A/65B, 2003.
[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).
Expires November 2004 [page 30]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
[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-ipdvb-ule-xx.txt, Work
in Progress, IP-DVB WG.
[ID-PILC-LINK] P. Karn (ed) Advice for Internet Subnetwork
Designers, Internet Draft draft-ietf-pilc-link-design-00.txt , Work
in Progress, IETF PILC WG, BCP (with RFC-Ed).
[ID-IPDVB-AR] Fairhurst, G., M-J. Montpetit, "Address Resolution for
IP datagrams over MPEG-2 networks", Internet Draft, draft-fair-
ipdvb-ar-00.txt, Work in Progress, IP-DVB WG.
[ID-MMUSIC-IMG] Y. Nomura, R. Walsh, J-P. Luoma, J. Ott, H.
Schulzrinne, "Protocol Requirements for Internet Media Guides",
Internet Draft, draft-ietf-mmusic-img-req-XX.txt, Work in Progress,
MMUSIC 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-VID] ISO/IEC DIS 13818-2:1998 "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.
Expires November 2004 [page 31]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
[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.
http://www.atsc.org/standards/Code_Point_Registry.pdf
11. Authors' Addresses
Marie J. Montpetit
MJMontpetit.com
Email: marie@mjmontpetit.com
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
Debartment of Scientific Computing
University of Salzburg
Jakob Haringer Str. 2
5020 Salzburg
Austria
Email: [clausen|bnocker|hlinder]@cosy.sbg.ac.at
Web: http://www.network-research.org
Expires November 2004 [page 32]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
12. IPR Notices
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
13. Copyright Statement
Copyright (C) The Internet Society (2004). This document is
subject to the rights, licenses and restrictions contained in
BCP 78, and except as set forth therein, the authors retain all
their rights.
This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTORs, THE ORGANIZATIONS THEY
REPRESENT OR ARE SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY
THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS
OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
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 November 2004 [page 33]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
Appendix A: MPEG-2 Encapsulation Mechanisms
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 deployed scheme. Due to investments
in existing systems, usage is likely to continue in current
and future networks.
(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
Expires November 2004 [page 34]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
structure is transparent to the Receiver. It may conform to
any protocol, e.g., IP, Ethernet, NFS, FDDI, MPEG-2 PES, etc.
(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.
Two different types of PES headers can are selected via the
stream_id values [ISO-MPEG]. The private_stream_2 value
permits the use of the short PES header with limited
overhead, while the private_stream_1 value makes available
the scrambling control and the timing and clock reference
features of the PES layer.
Expires November 2004 [page 35]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
Appendix B: Address Resolution Use Cases
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.
(i) 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 November 2004 [page 36]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
(ii) 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 November 2004 [page 37]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
(iii) 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 November 2004 [page 38]
Internet Engineering Task Force Marie J. Montpetit ed.
Internet Draft MJMontpetit.com, USA
Document: draft-ipdvb-arch-00.txt Gorry Fairhurst
University of Aberdeen, U.K.
Horst D. Clausen
Bernhard Collini-Nocker
Hilmar Linder
University of Salzburg, Austria
Category: Informational July 2004
A Framework for transmission of IP datagrams over MPEG-2 networks
Status of this Memo
By submitting this Internet-Draft, we certify that any applicable
patent or other IPR claims of which we am aware have been disclosed,
or will be disclosed, and any of which we become aware will be
disclosed, in accordance with RFC 3668.
By submitting this Internet-Draft, we accept the provisions of
Section 3 of RFC 3667 (BCP 78).
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.
Copyright (C) The Internet Society (2004), All Rights Reserved
Abstract
This document describes a new architecture 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
of systems using MPEG-2 include the Digital Video Broadcast (DVB)
and Advanced Television Systems Committee (ATSC) Standards for
Digital Television.
The document 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 address resolution, to
associate IP packets with the properties of the Logical Channels
provided by an MPEG-2 TS.
Expires November 2004 [page 1]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
Table of Contents
1. Introduction
2. Conventions Used in this Document
3. Architecture
4. Encapsulation Protocol
5. Address Resolution Functions
6. Multicast Support
7. Summary
8. Security Considerations
9. Acknowledgments
10. References
11. Author's Addresses
12. IANA Considerations
Appendices
Expires November 2004 [page 2]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
Document History
-00 Current version
Expires November 2004 [page 3]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
1. Introduction
This document identifies requirements and an architecture for transport
of IP Datagrams over ISO MPEG-2 Transport Streams [MPEG2]. The prime
focus is the efficient and flexible delivery of IP services over
those subnetworks that use the MPEG-2 transport stream.
Hence, the architecture is 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] and Cable Transmission [ETSI-
DVBC; ATSC-PSIP-TC]).
+---------+-+-+-+-+------+--------+---+--+--+
| |T|V|A|O| O | | O |S |O |
| |e|i|u|t| t | | t |I |t |
| |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 data types, MPEG-2
components may, and are, also used to build IP-only networks.
Often, those networks do not implement all parts of a DVB / ATSC
system, and may for instance support minimal, or no, signalling of
Service Information (SI) tables. Standard system components offer
advantages of improved interoperability and larger deployment.
1.1 Salient features of the Architecture
The architecture proposed in this document describes a set of protocols
to support transmission of IP packets over the MPEG-2 TS. Key
characteristics of these networks are that they may provide link-
level broadcast capability, and that many supported applications
require access to a very large number of subnetwork nodes. Some or
Expires November 2004 [page 4]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
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 of the architecture are to reduce complexity when using the
system, while improving performance, increasing flexibility for IP
services, and providing opportunities for better integration with IP
services.
Since a majority of MPEG-2 transmission networks are bandwidth-
limited, encapsulation protocols must therefore add minimal overhead
to ensure good link efficiency while providing adequate network
services. They also needs to be simple to minimize processing,
robust to errors and security threats, and extensible to a wide
range of services.
In MPEG-2 systems, logical channels provide multiplexing,
addressing, and error reporting. The logical channel may also be
used to provide Quality of Service (QoS). Mapping functions are
required to relate Logical Channels to IP addresses, to map Logical
Channels to IP-level QoS, and to associate IP flows with specific
subnetwork capabilities. An important feature of the proposed
architecture will be to provide these functions in a dynamic way,
allowing transparent integration with other IP-layer protocols.
Collectively, these will form a MPEG-2 TS address resolution
protocol suite.
Expires November 2004 [page 5]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
2. Conventions Used In This Document
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 Media 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: Packetized Elementary Stream. A format of MPEG-2 TS packet
payload usually used for video or audio information in MPEG-2 [ISO-
MPEG].
Expires November 2004 [page 6]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
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 (decimal)
indicates a null packet that must be discarded by a Receiver.
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 November 2004 [page 7]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
3. Architecture
The following sections introduce the components of the MPEG-2
Transmission network and relate these to a networking framework.
3.1 MPEG-2 Transmission Networks
There are many possible topologies for the MPEG-2 Transmission
Networks. A number of example scenarios are briefly described below,
and the following text relates specific functions to this set of
scenarios.
A) Broadcast TV and Radio Delivery
The principal service in the Broadcast TV and Radio Delivery
scenario is Digital TV and/or Radio and their associated data [ID-
MMUSIC-IMG]. Such networks typically contain two components: the
contribution feed and the broadcast part. Contribution feeds
provide communication from a typically small number of individual
sites (usually at high quality) to the Hub of a broadcast network.
The traffic carried on contribution feeds is typically encrypted,
and is usually processed prior to being resent on the Broadcast part
of the network. The Broadcast part uses a star topology centred on
the Hub to reach a typically large numbers of down-stream Receivers.
Although such networks may provide IP transmission, they do not
necessarily provide access to the public Internet.
B) Broadcast Networks used as an ISP
Another scenario resembles that above, but includes the provision of
IP-services providing access to the public Internet. The IP traffic in
this scenario is typically not related to the digital TV/Radio content,
and the service may be operated by an independent operator such as uni-
directional File Delivery or bi-directional ISP access. The IP service
must adhere to the full system specification used for the broadcast
transmission, including allocation of PIDs, and generation of
appropriate MPEG-2 control information (e.g. DVB and ATSC SI tables).
C) Uni-directional Star IP Scenario
The Uni-directional Star IP Scenario utilises a Hub station to
provide a data network delivering a common bit stream to medium-
sized groups of Receivers. MPEG-2 transmission technology provides
the forward physical and link layers for this transmission, the
return link (if required) is provided by other means. IP services
typically form the main proportion of the transmission traffic. Such
networks may not necessarily implement the MPEG-2 control plane.
D) Data-cast overlay
The Data-cast overlay scenario employs MPEG-2 physical and link
layers to provide additional connectivity such as uni-directional
multicast to supplement an existing IP-based Internet service.
Examples of such a network includes IP Datacast to mobile wireless
receivers [ID-MMUSIC-IMG].
Expires November 2004 [page 8]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
E) Point-to-point links
Point-to-point connectivity may be provided using a pair of transmit
and receive interfaces supporting the MPEG-2 physical and link
layers. Typically the transmission from a sender is received by
only one or a small number of Receive terminals. Examples include
the use of transmit/receive DVB-S terminals to provide satellite
links between ISPs utilising BGP routing.
F) Two-Way IP Networks
Two-Way IP networks are typically satellite-based and star-based
utilising a Hub station to deliver a common bit stream to medium-
sized groups of receivers. A bi-directional service is provided over
a common air-interface. The transmission technology in the forward
physical and link layers for this transmission is MPEG-2, which may
also be used in the return direction. Such systems also usually
include a control plane element to manage the (shared) return link
capacity. A concrete example is the DVB-RCS system. IP services
typically form the main proportion of the transmission traffic.
Scenarios A-D employ uni-directional MPEG-2 Transmission networks.
For satellite-based networks, these typically have a star topology,
with a central Hub providing service to large numbers of down-stream
Receivers. Terrestrial networks may employ several transmission Hubs
each serving a particular coverage cell with a community of
Receivers.
From an IP viewpoint, the service is typically either uni-
directional multicast, or a bi-directional service in which some
complementary link technology (e.g. Modem, LMDS, GPRS, ...) is used
to provide the return path from Receivers to the Internet. Routing
in this case could be provided using Uni-Directional Link Routing
(UDLR) [RFC3077].
Note that only Scenarios A-B actually carry MPEG-2 video and audio
intended for reception by digital Set Top Boxes (STBs) as the
primary traffic. The other scenarios are IP-based data networks and
need not necessarily implement the MPEG-2 control plane.
Scenarios E-F provide two-way connectivity using MPEG-2
transmission. Such networks provide direct support for bi-
directional protocols above and below the IP layer.
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 include a TV operator
(Scenario A), or an ISP (Scenarios B-F). MPEG-2 transmission
networks are also used for private networks. These typically involve
a smaller number of Receivers and do not require the same level of
centralised control. Examples include companies wishing to connect
DVB-capable routers to form links within the Internet (Scenario B).
Expires November 2004 [page 9]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
3.2 TS Logical Channels
An MPEG-2 transport multiplex offers a number of parallel channels,
which are known here as 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 available channels is limited to 8192
(decimal), 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 packets [ISO-DSMCC; ETSI-DAT; ATSC-DAT],
or other data [ISO-DSMCC; ETSI-DAT; ATSC-DAT]. The value 8191
(decimal) 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
Multiplex (MUX). In most cases the data sent over the TS Logical
Channels will differ for different multiplexes. The above figure
shows a set of TS Logical Channels sent using two MPEG-2 TS
Multiplexes (A and B).
There are cases where the same data may be distributed over two or
more multiplexes (e.g., some SI tables; multicast content 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
Expires November 2004 [page 10]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
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).
As can been seen above, there are similarities between the way PIDs
are used and the operation of virtual channels in ATM. However,
unlike ATM, a PID defines a unidirectional broadcast channel and not
a point-to-point link. Contrary to ATM, there is, as yet, no
specified standard interface for MPEG-2 connection setup, or for
signalling mappings of IP flows to PIDs, or to set the Quality of
Service, QoS, assigned to an TS Logical Channel.
3.3 Multiplexing and Re-Multiplexing
In a simple example, one or more TS are processed by a MPEG-2
multiplexor resulting in a TS Multiplex. The TS Multiplex is
forwarded over a physical bearer towards one or more Receivers
(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
Expires November 2004 [page 11]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
In a more complex example, the same TS may be fed to multiple MPEG-2
multiplexors and these may, in turn, feed other MPEG-2 multiplexors
(remultiplexing). Remultiplexing may occur in several places (and is
common in Scenario A of section 3.1). One example is a satellite
that provides on-board processing of the TS packets, multiplexing
the TS Logical Channels received from one or more 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. It may also modify and/or
insert new SI data into the control plane to reflect the content
output using TS Multiplex.
In all cases, the final result is a "TS Multiplex" which is
transmitted over the physical bearer towards the Receiver.
3.4 IP Datagram Transmission
Packet data for transmission over the MPEG-2 transport multiplex is
passed to an Encapsulator, sometimes known as a Gateway. This
receives Protocol Data Units, PDUs, such as Ethernet frames or IP
packets, and formats each into a Sub-Network Data Unit, SNDU, by
adding an encapsulation header and trailer (see section 5). The
SNDUs are subsequently fragmented into a series of TS Packets.
To receive IP packets over a MPEG-2 transport multiplex, a Receiver
needs to identify the specific TS Multiplex (physical link) and also
the TS Logical Channel (the PID value of a logical link). It is
common for a number of MPEG-2 TS Logical Channels to carry SNDUs,
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, must filter other unwanted TS Logical Channels by
employing for example specific hardware support. Packets for one IP
flow (i.e. a specific combination of IP source and destination
addresses) must be sent using the same PID. It should not be assumed
that all IP packets are carried on a single PID, as in some cable
modem implementations, and multiple PIDs must be allowed in the
architecture. Many current hardware filters limit the maximum number of
active PIDs (e.g. 32), although if needed, future systems may
reasonably be expected to support more.
In some cases, Receivers may need to select TS Logical Channels from
a number of simultaneously active TS Multiplexes. To do this, they
need multiple physical receive interfaces (e.g., RF front-ends and
demodulators). Some applications also envisage the concurrent
Expires November 2004 [page 12]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
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 (e.g. in Scenarios B-D of section
3.1). 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. The MPE specification includes a set of optional header
components and requires decoding of the control headers. This
processing is suboptimal for Internet traffic, since it incurs
significant receiver processing overhead and some extra link
overhead [CLC99].
+-----------------------------------------+
|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).
3.5 Motivation
The network layer protocols to be supported by this architecture
include:
(i) IPv4 Unicast packets, destined for a single end host
(ii) IPv4 Broadcast packets, sent to all end systems in an IP
network
(iii) IPv4 Multicast packets
(iv) IPv6 Unicast packets, destined for a single end host
(v) IPv6 Multicast packets
(vi) Packets with compressed IPv4 / IPv6 packet headers (e.g.
[RFC1114; RFC2507; RFC3095])
(vii) Bridged Ethernet frames
(viii) Other (MPLS, IPv6 anycast, potential new protocols__
Expires November 2004 [page 13]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
The architecture will provide:
(i) Guidance on which MPEG-2 features are pre-requisites for the IP
service, and identification of any optional fields that impact
performance/correct operation.
(ii) Standards to provide an efficient and flexible encapsulation
scheme that may be easily implemented in an Encapsulator or
Receiver. The payload encapsulation requires a type field for
the SNDU to indicate the type of packet and a mechanism to
signal which encapsulation is used on a certain PID.
(iii) Standards to associate a particular IP address with a Network
Point of Attachment (NPA) that could or could not be a MAC
Address. This process resembles the IPv4 Address Resolution
Protocol, ARP, or IPv6 Neighbour Discovery, ND, protocol [AR-
DRAFT]. In addition, the standard will be compatible with IPv6
autoconfiguration.
(iv) Standards 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.
(v) Standards to associate the capabilities of a MPEG-2 TS Logical
Channel with IP flows. This includes mapping of QoS functions,
such as IP QoS/DSCP and RSVP, to underlying MPEG-2 TS QoS,
multi-homing and mobility. This capability could be associated
by the AR standard proposed above.
(vi) Guidance on Security for IP transmission over MPEG-2. The
framework must permit use of IPSEC and clearly identify any
security issues concerning the specified protocols. The security
issues need to consider two cases: unidirectional transfer (in
which communication is only from the sending IP end host to the
receiving IP end host) and 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 of the IP transmission, including standardised SNMP
MIBs and error reporting procedures. The need for and scope of
this is to be determined.
The specified architecture and techniques should be suited to a range
of systems employing the MPEG-2 TS, and may also suit other (sub)
networks offering similar transfer capabilities.
Expires November 2004 [page 14]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
The following sections 4 and 5 describe encapsulation issues.
Sections 6 and 7 describe address resolution issues for unicast and
multicast. The appendix provides some use cases.
4. Encapsulation Protocol Requirements
This section identifies requirements 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.
The encapsulation protocol transports a SNDU over the MPEG-2 TS
service and provides 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
such as length of SNDU, Receiver address, multiplexing information,
payload type, sequence numbers etc. The SNDU payload is typically
followed by a trailer, which carries an Integrity Check (e.g.,
Cyclic Redundancy Check, CRC). Some protocols also add additional
control information and/or padding to or after the trailer.
+--------+-------------------------+-----------------+
| Header | SNDU | Integrity Check |
+--------+-------------------------+-----------------+
Figure 5: 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].
The existing proposals and standards for use with MPEG-2 carry
heritage from legacy implementations that reflect the limitations of
technology at their deployment. For example a majority are more
dominated by audio/video considerations than IP requirements. This
justifies the development of a new encapsulation that will be truly
IP-centric. Carrying IP packets over a TS Logical Channel involves
several convergence protocol functions. This section briefly
describes these functions and highlights the requirements for a new
encapsulation.
4.1 Payload_Unit Delimitation
MPEG-2 indicates the start of a Payload Unit 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
Expires November 2004 [page 15]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
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,
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.
4.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 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
Expires November 2004 [page 16]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
of the current Internet. This would seem a suitable maximum size
for an MPEG-2 transmission network.
4.3 Next Level Protocol Type
A key feature of the new encapsulation is to identify the type of
payload being transported (e.g., to differentiate IPv4, IPv6 etc.).
Most protocols use a type field to identify a specific process at
the next higher layer that is the originator or the recipient of the
payload (SNDU). This method is used by IPv4, IPv6, and also by the
original Ethernet protocol (DIX). OSI uses the concept of a
'Selector' for this, (e.g. in the IEEE 802/ISO 8802 standards for
CSMA/CD [LLC], although in this case a SNAP (subnetwork access
protocol) header is also required for IP packets.
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 architecture, 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 wireless 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. The selected type field should contain
sufficient code points to support this technique.
It is thus a requirement to include a Next Level Protocol Type field
in the encapsulation header. Such a field should specify values for
at least IPv4, IPv6, and must allow for other values (e.g., MAC-
level bridging).
4.4 L2 Subnet Addressing
In MPEG-2, 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
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.
Expires November 2004 [page 17]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
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 Receivers 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 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).
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. There are many cases
where a NPA is not required, and network layer filtering may be used.
A new encapsulation protocol should therefore support an optional NPA.
4.5 Integrity Check
For the IP service, the probability of undetected packet error
should be small (or negligible) [ID-PILC-LINK]. 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).
Expires November 2004 [page 18]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
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.
4.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.
4.7 Extension Headers
The evolution of the Internet service may in future require
additional functions. A flexible protocol should therefore provide a
way to introduce new features when required, without having to
provide additional out-of-band configuration.
IPv6 introduced the concept of extension headers that carry extra
information necessary/desirable for certain subnetworks. The DOCSIS
cable specification also allows a MAC header to carry extension
headers to build operator-specific services. It is thus a
requirement for the new encapsulation to allow extension headers.
4.8 Summary of Requirements for Encapsulation
The main requirements for an IP-centric encapsulation include:
- support of IPv4 and IPv6 packets
- support for Ethernet encapsulated packets
- flexibility to support other IP formats and protocols (e.g.
ROHC, MPLS)
- easy processing by hardware devices
- low overhead/managed overhead
- a fully specified algorithm that allows a sender to pack
multiple packets per SNDU and to easily locate packet fragments
- extensibility
- compatibility with legacy deployments
- ability to allow link encryption, when required
- capability to support a full network architecture including
data, control and management planes
Expires November 2004 [page 19]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
5. Address Resolution Functions
Address Resolution (AR) provides a mechanism that associates L2
information 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 (e.g. 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 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 other information than the MAC address. This
includes identifying other parameters required for L2 transmission,
such as channel IDs (VCs in X.25, 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 many MPEG-2 transmission networks.
5.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 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 (see
section 3.2).
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 November 2004 [page 20]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
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.
A star topology MPEG-2 TS transmission network is illustrated below,
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 broadcast
MPEG-2TS \
----------------X /-----\
/ / \
| Receiver|
/----------+ A |
/ \ /
/-----\ / \-----/
/ \ /
| Hub |/
| +\ /-----\
\ / \ / \
\-----/ \ | Receiver|
\-----------+ B |
\ /
\-----/
Figure 6: MPEG-2 Transmission Network with 2 Receivers
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.
Expires November 2004 [page 21]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
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.
An end 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.
5.2 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
implementations of this are known)
(iii) An address resolution protocol transported over IP (as in ND)
There are three distinct cases 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 (see Scenario A of Section 3.1).
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.
5.2.1 Table-based AR over MPEG-2
In current deployments of MPEG-2 networks, 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
Expires November 2004 [page 22]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
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 delivering and co-ordinating the various
TS Logical Channels associated with a multimedia TV programme.
One possible requirement 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. The DVB INT and the A/92 Specification from ATSC
[ATSC-A92] are examples of the realization of such a requirement.
5.2.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
and therefore do not need to provide interoperability with TV
equipment (e.g. links used solely for connecting IP (sub)networks).
5.2.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.
5.3 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;
Expires November 2004 [page 23]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
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. 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 an IP
packet may lead to unexpected protocol behaviour. This also provides
a security vulnerability since arbitrary packets may be passed to
the IP layer.
5.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
that it receives. 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.
Expires November 2004 [page 24]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
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.
5.6 Requirements for Unicast AR over MPEG-2
The requirement for AR over MPEG-2 networks include:
(i) Use of a table based approach to promote AR scaling. This
requires 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) Support of IP subnetwork scoping.
(vi) Appropriate security associations to authenticate the sender.
6. 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.
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.
Expires November 2004 [page 25]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
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.
6.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 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.
Expires November 2004 [page 26]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
\
|
+---+----+ +--------+
| Tuner |---+TS Tabl | . . . .
+---+----+ +--------+ .
| .
+--------+ +--------+ .
| deMux |---+PID Tabl|........
+---+----+ +--------+ :
| :
+--------+ +--------+ +--------+
|MPE/ULE |---+AR Cache|---+ MFIB |
+---+----+ +--------+ +--------+
| | |
+---+----+ +---+----+ +---+----+
| IP | | AR | |IGMP/MLD|
+---+----+ +---+----+ +---+----+
| | |
*------------+------------+
Figure 7: Receiver Processing Architecture
6.2 Requirements for Multicast over MPEG-2
The requirements for supporting multicast 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 AR information to allow a Receiver to locate an IP
multicast flow within an MPEG-2 TS Multiplex.
(v) Error Reporting.
7. Summary
This document describes the architecture for a set of protocols to
perform efficient and flexible support for IP network services over
networks built upon the MPEG-2 Transport Stream (TS). It also
describes existing approaches. It focuses on IP networking, the
mechanisms that are used and their applicability to supporting IP
unicast and multicast services.
The requirements for a new encapsulation of IPv4 and IPv6 packets is
described, outlining the limitations of current methods and the need
for a streamlined IP-centric approach.
The architecture also describes MPEG-2 Address Resolution (AR)
procedures to allow dynamic configuration of the sender and Receiver
using an MPEG-2 transmission link/network. These support IPv4 and
IPv6 services in both the unicast and multicast modes. Resolution
protocols will support IP packet transmission using both the
Expires November 2004 [page 27]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
Multiprotocol Encapsulation (MPE), which is currently
widely deployed, and also any new optimised encapsulation.
8. Security Considerations
When the MPEG-2 network is not using a wireline network, the normal
security issues relating to the use of wireless links for transport
Internet traffic should be considered [ID-PILC-LINK].
End-to-end security (including confidentiality, authentication,
integrity and access control) is closely associated with the end-
user assets that are protected. This close association cannot be
ensured when providing security mechanisms only within a subnetwork
(e.g. an MPEG-2 transmission network). Several security mechanisms
that can be used end-to-end have already been deployed in the
general Internet and are enjoying increasing use. Important examples
include:
* The Secure Sockets Layer (SSL) and Transport Layer Security, TLS,
which is primarily used to protect web commerce;
* Pretty Good Privacy (PGP) and S/MIME, primarily used to protect
and authenticate email and software distributions;
* The Secure Shell (SSH), used to secure remote access and file
transfer;
* IPsec, a general purpose encryption and authentication mechanism
above IP that can be used by any IP application.
However, subnetwork security is also important [ID-PILC-LINK] and
should be encouraged, on the principle that it is better than the
default situation, which all too often is no security at all. Users
of especially vulnerable subnets (such as radio/broadcast networks
and /or shared media Internet access) often have control over at
most one endpoint - usually a client and therefore cannot enforce
the use of end-to-end mechanisms.
A related role for subnetwork security is to protect users against
traffic analysis, i.e., identifying the communicating parties (by IP
or MAC address) and determining their communication patterns, even
when their actual contents are protected by strong end-to-end
security mechanisms (this is important for networks such as
broadcast/radio, where eaves-dropping is easy).
Where it is possible for an attacker to inject traffic into the
subnetwork control plane, subnetwork security can additionally
protect the subnetwork assets. This threat must specifically be
considered for the protocols used for subnetwork control functions
(e.g. address resolution, management, configuration). Possible
threats include theft of service and denial of service; shared media
subnets tend to be especially vulnerable to such attacks [ID-PILC-
LINK]. Appropriate security functions must therefore be provided for
Expires November 2004 [page 28]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
ipdvb control protocols [ID-PILC-LINK], particularly when the
control functions are provided above the IP-layer using IP-based
protocols. Internet level security mechanisms (e.g. IPSEC) can
mitigate such threats.
In general, End-to-End security is recommended for users of any
communication path, especially when it includes a
wireless/radio/broadcast link, where a range of security techniques
already exist. Specification of security mechanisms at the
application layer, or within the MPEG-2 transmission network are the
concerns of organisations beyond the IETF. The complexity of any such
security mechanisms should be considered carefully so that it will
not unduly impact the IP operation.
8.1 Link Encryption
Link level encryption of IP traffic is commonly used in
broadcast/radio links to supplement End-to-End security (e.g.
provided by SSL, SSH, PGP, IPSec). The encryption and key exchange
methods vary significantly, depending on the intended application.
For example, DVB-S/DVB-RCS operated by Access Network Operators
(ANO) may wish to provide their customers (Internet Service
Providers, ISP) with security services. Common targeted security
services are: terminal authentication and data confidentiality (for
unicast and multicast) between a gateway and Receivers. A common
objective is to provide the same level of privacy as terrestrial
links. An ISP may also wish to provide end-to-end security services
to the end-users (based on the well known mechanisms such as IPSec).
Therefore it is important to understand that both security solutions
(ANO-to-ISP and ISP-to-end users) may co-exist.
MPE supports optional link encryption using a pair of bits within
the MPE protocol header to indicate the use of encryption. To
support optional link level encryption, it is recommended that a new
encapsulation also supports optional encryption of the SNDU payload.
Furthermore, it may be desirable to encrypt/authenticate some/all of
the SNDU headers. The method of encryption and the way in which
keys are exchanged is beyond the scope of the ULE Specification.
However, the specification must provide appropriate code points to
allow such encryption to be implemented at the link layer.
9. Acknowledgments
The authors wish to thank Isabel Amonou , Torsten Jaekel, Pierre
Loyer, Luoma Juha-Pekkaand and Rod Walsh for their detailed inputs.
We also wish to acknowledge the input provided by the members of the
IETF ipdvb WG.
Expires November 2004 [page 29]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
10. References
10.1 Normative References
[ISO-MPEG] ISO/IEC DIS 13818-1:2000 "Information technology -- Generic
coding of moving pictures and associated audio information:
Systems", International Standards Organisation (ISO).
[ETSI-DAT] EN 301 192 Specifications for Data Broadcasting, European
Telecommunications Standards Institute (ETSI).
[RFC1122] B. Braden, ed., "Requirements for Internet Hosts -
Communication Layers", RFC 1122.
10.2 Informative References
[ATSC] A/53C, "ATSC Digital Television Standard", Advanced Television
Systems Committee (ATSC), Doc. A/53C, 2004.
[ATSC-DAT] A/90, "ATSC Data Broadcast Standard", Advanced Television
Systems Committee (ATSC), Doc. A/090, 2000.
[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/54A, "Guide to the use of the ATSC Digital Television
Standard", Advanced Television Systems Committee (ATSC), Doc. A/54A,
2003.
[ATSC-PSIP-TC] A/65B, "Program and System Information Protocol for
Terrestrial Broadcast and Cable", Advanced Television Systems
Committee (ATSC), Doc. A/65B, 2003.
[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).
Expires November 2004 [page 30]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
[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-ipdvb-ule-xx.txt, Work
in Progress, IP-DVB WG.
[ID-PILC-LINK] P. Karn (ed) Advice for Internet Subnetwork
Designers, Internet Draft draft-ietf-pilc-link-design-00.txt , Work
in Progress, IETF PILC WG, BCP (with RFC-Ed).
[ID-IPDVB-AR] Fairhurst, G., M-J. Montpetit, "Address Resolution for
IP datagrams over MPEG-2 networks", Internet Draft, draft-fair-
ipdvb-ar-00.txt, Work in Progress, IP-DVB WG.
[ID-MMUSIC-IMG] Y. Nomura, R. Walsh, J-P. Luoma, J. Ott, H.
Schulzrinne, "Protocol Requirements for Internet Media Guides",
Internet Draft, draft-ietf-mmusic-img-req-XX.txt, Work in Progress,
MMUSIC 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-VID] ISO/IEC DIS 13818-2:1998 "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.
Expires November 2004 [page 31]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
[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.
http://www.atsc.org/standards/Code_Point_Registry.pdf
11. AuthorsÆ Addresses
Marie J. Montpetit
MJMontpetit.com
Email: marie@mjmontpetit.com
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
Debartment of Scientific Computing
University of Salzburg
Jakob Haringer Str. 2
5020 Salzburg
Austria
Email: [clausen|bnocker|hlinder]@cosy.sbg.ac.at
Web: http://www.network-research.org
Expires November 2004 [page 32]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
12. IPR Notices
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
13. Copyright Statement
Copyright (C) The Internet Society (2004). This document is
subject to the rights, licenses and restrictions contained in
BCP 78, and except as set forth therein, the authors retain all
their rights.
This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTORs, THE ORGANIZATIONS THEY
REPRESENT OR ARE SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY
THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS
OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
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 November 2004 [page 33]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
Appendix A: MPEG-2 Encapsulation Mechanisms
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 deployed scheme. Due to investments
in existing systems, usage is likely to continue in current
and future networks.
(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
Expires November 2004 [page 34]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
structure is transparent to the Receiver. It may conform to
any protocol, e.g., IP, Ethernet, NFS, FDDI, MPEG-2 PES, etc.
(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.
Two different types of PES headers can are selected via the
stream_id values [ISO-MPEG]. The private_stream_2 value
permits the use of the short PES header with limited
overhead, while the private_stream_1 value makes available
the scrambling control and the timing and clock reference
features of the PES layer.
Expires November 2004 [page 35]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
Appendix B: Address Resolution Use Cases
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.
(i) 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 November 2004 [page 36]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
(ii) 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 November 2004 [page 37]
INTERNET DRAFT Architecture for IP transport over DVB July 2004
(iii) 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 November 2004 [page 38]
