[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Revised IP over mpeg-2/DVB charter
Hi,
ad 1.
The name "IP Over DVB" is somehow historically and is clarified in
draft-unisal-ipdvb-encaps-xxx (and also draft-fair-ipdvb-ule-xx):
------------------------ snip --------------------
This document describes an encapsulation for transport of IP datagrams or
other network layer packets over ISO MPEG-2 Transport Streams [ISO-MPEG].
This is suited to services based on MPEG-2, for example the Digital Video
Broadcast (DVB) architecture, the Advanced Television Systems Committee
(ATSC) system [ATSC; ATSC-G], and other similar MPEG-2 based transmission
systems. Such systems typically provide unidirectional (simplex) physical
and link layer standards, and have been defined for a wide range of physical
media (e.g. Terrestrial TV [ETSI-DVBT; ATSC-PSIP-TC], Satellite TV
[ETSI-DVBS; ATSC-S],Cable Transmission [ETSI-DVBC; ATSC-PSIP-TC]).
Bi-directional (duplex) links may also be established using these standards
(e.g., DVB defines a range of return channel technologies, including the use
of two-way satellite links [ETSI-RCS] and dial-up modem links [RFC3077]).
------------------------ snip --------------------
ad 2.
We have tried to motivate the reason for the need of a lighter encapsulation
in draft-fair-ipdvb-req-xxx in section 5:
------------------------ snip --------------------
5. Motivation for a Lightwight Protocol Encapsulation
To transmit packet data over an MPEG-2 transmission network requires that
individual SNDUs (e.g. IPv4, IPv6 packets, or bridged Ethernet Frames) are
encapsulated using a convergence protocol. The following encapsulations are
currently standardised for MPEG-2 transmission networks:
(i) Multi-Protocol Encapsulation (MPE).
The Multi-Protocol Encapsulation, MPE, specification of DVB [ETSI-DAT] uses
private Sections for the transport of IP packets and uses encapsulation that
is similar to the IEEE LAN/MAN standards [LLC]. Data packets are
encapsulated in datagram sections that are compliant with the DSMCC section
format for private data. One advantage of this is that 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 the most widely used scheme. Due to investments in existing
equipment, usage is likely to continue in some applications in current and
future networks.
(ii) Data Piping.
The DVB 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 MPEG-2 receiver is intended to provide PID
filtering, packet reassembly according to [DVB-SIDAT-368], error detection
and optionally CA support.
The specification allows the user data stream to be unstructured or
organized into packets. The specific structure is transparent to the
receiver. It may conform to any protocol, e.g., IP, Ethernet, NFS, FDDI,
MPEG-2 PES, etc.
(iii) Data Streaming.
The data broadcast specification profile [ETSI-DAT] for PES tunnels (Data
Streaming) supports unicast and multicast data services that require a
stream-oriented delivery of data packets. This encapsulation maps an IP
packet into a single PES Packet payload Data Streaming is intended to handle
a single stream of data at a high data rate using standard demultiplexing
ICs (e.g. developed for STBs) that have been designed for handling video
streams. Transporting data packets using the PES level offers the benefits
of PES layer functions integrated into the chip sets, e.g. handling of
program specific information (tables), scrambling and synchronization with
other TS.
The standard PES Packet as defined in table 2-18 of [ISO-MPEG] can also be
used as a container for data packets. The two values for the stream_id are
"private_stream_1" and "private_stream_2". The private_stream_2 permits the
use of the short PES header with limited overhead. This makes it attractive
for publicly accessible multicast distribution services. The
private_stream_1 makes available the scrambling control and the timing and
clock reference features of the PES layer. The PES_data_packet_header_length
will be used in this context to insert stuffing bytes. This is an important
aspect since the payload can be aligned to 32-bit word boundaries.
When the data_identifier field is used in conjunction with the first 4 bits
of the sub_stream_id field it forms a 12 bit field. This carries a
descriptor of the next level protocol. The list of protocol codes will be
managed by [EUTELSAT], and the values of the part stored into the
data_identifier field will be in the range 0x80-0xFF (assigned by DVB as
user defined). The remaining 4 bits of the sub_stream_id field are used for
storing the current version of the encapsulation format.
Some or all of these proposals have been implemented and are used in current
systems.
------------------------ snip --------------------
Best regards,
Bernhard
> -----Original Message-----
> From: owner-ip-dvb@erg.abdn.ac.uk [mailto:owner-ip-dvb@erg.abdn.ac.uk]On
> Behalf Of Michael A. Dolan
> Sent: Freitag, 20. Juni 2003 17:58
> To: ip-dvb@erg.abdn.ac.uk
> Subject: Re: Revised IP over mpeg-2/DVB charter
>
>
> Hi-
>
> I just joined this list, so am coming at this work entirely out of
> context. But I wanted to understand the scope and requirements
> as it moves
> to an IETF WG. Thanks in advance for your indulgence....
>
> 1. The proposed working group name is "IP over DVB", yet the charter says
> it is intended for any MPEG-2 transport stream. Is it the intent of this
> group to develop documents relating to non-DVB transports (ATSC, ARIB,
> video servers, and others)?
>
> 2. The second paragraph says, "There is therefore a need to define an
> efficient standardised encapsulation for IPv4 and IPv6
> datagrams...". This
> statement seems to presume that the ISO MPEG 13818-6 Amendment #1
> (and the
> related ETSI 301192 and ATSC A/90 and ATSC A/92) that everyone uses today
> are somehow unsuitable for some reason. I think it would be
> helpful to add
> something between these paragraphs that supports the need for the
> development of a new encapsulation. Alternatively, one could soften the
> "therefore there is a need" to something like "investigate and recommend".
>
> Regards,
>
> Mike
>
>
> At 10:00 AM 6/20/2003 +0100, gorry wrote:
>
> >A revised charter has been uploaded to the ip-dvb server at:
> >http://www.erg.abdn.ac.uk/ip-dvb/charter.html
> >
> >Please do send corrections to me and comments to the ip-dvb list.
> >
> >Best wishes,
> >
> >Gorry
> >
> >P.S. The index page has also been updated (long overdue!) at:
> >http://www.erg.abdn.ac.uk/ip-dvb/index.html
>
> -----------------------------------------------------
> Michael A. Dolan, President
> Television Broadcast Technology, Inc. (TBT)
> PO Box 1673 Alpine, CA 91903 USA
> 619-445-9070 FAX: 208-545-6564
> URL:http://www.tbt.com
>