[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IESG WG Review: IP over DVB (ipdvb) - Synchronised delivery of IP packets
- To: ip-dvb@erg.abdn.ac.uk
- Subject: Re: IESG WG Review: IP over DVB (ipdvb) - Synchronised delivery of IP packets
- From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
- Date: Wed, 22 Oct 2003 14:00:23 +0100
- In-reply-to: <>
- Organization: Univesrity of Aberdeen
- References: <bn38h6$1vjq$1@intranet.6wind.com> <>
- Reply-to: ip-dvb@erg.abdn.ac.uk
- Sender: owner-ip-dvb@erg.abdn.ac.uk
- User-agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
I believe you're asing for more detai of the synchronised delivery
service...
See in-line comments, below.
alain.ritoux@6wind.com wrote:
IP over DVB (ipdvb)
... Snip
The current list of work items is:
1. Issue an Internet Draft specifying Requirements and Framework for
supporting IP services via MPEG-2 transmission networks. Such
requirements
So, its is more IP-over-MPEG2 rather tah IP-over-DVB. Am I correct ?
Yes, that always was the case.
... Snip
2. The working group will investigate and design an efficient
encapsulation
method for IPv4/IPv6, and advance this via the IESG to a
standards-track
RFC. The design needs to consider the need for MAC addresses, the
potential
need for synchronisation between streams, support for IPv6 and
multicast
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Is there not a risk of mixing different layers ? because this notion is
more a DVB one ?
To ensure we speak of the same thing the current requirements id (page
12) says:
"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. "
I agree this is an MPEG-TS attrribute for PES-format streams.
Both DVB and the ATSC Data Broadcast Standard describe how this may be
used (each with differing levels of detail).
At the moment the proposed charter says we should consider this need,
and assess the impact on the design of the encapsulation procdure.
I have a question to implementors and potnetial users is do they
envisage the need for this to be supported in the IETf-supplied
encapsulation. if so please send potential use cases to the list!!!
Are the systems over MPEG-2 such as DVB, ATSC, ISDB-T ... compatible in
terms of stream synchronisation ?
Anyway, what is the purpose of such sync between IP flows and other
streams ? or between IP flows ? shouldn't it be more a pb to be solved
at application and/or transport level (using RTP) rather than at a
newtork level ?
Not necessarily so, RTP can provide synchnosiation, but this isn't the same.
Well, I maybe I missed some importants points, but if this feature is
important/needed/whatever, why is it not in the requirement draft ?
Correct, we need text, are you offering text?
Does anyone else have text we can use to update the requirements draft
with use-cases for this type of service?
Regards.
Alain