RE: WG Review: IP over DVB (ipdvb)

[<Rod.Walsh@nokia.com>]

It would be helpful for the IPoverDVB charter to position itself with respect to existing standards. It would be extremely helpful to show how this IPoverDVB would complement the existing standards and where it would attempt to replace them (in what niches and in what time frame)

For instance, DVB has a data broadcasting standard which gives an IP in MPEG-2 encapsulation method (commonly called MPE), which is both working and deployed. This was based on commercial requirements and is reasonably efficient (down to 3% overhead for Ethernet MTU - http://www.erg.abdn.ac.uk/users/gorry/ip-dvb/refs/mpe-ohead.pdf). It is unclear, in the charter, whether the proposed WG aims to change the existing deployments, be used for all future deployments or be optimised for special purpose deployments as an alternative to MPE.

The risk of not positioning the IPoverDVB WG with respect to these existing technologies and standards is that the proposed WG may be seen as a competing solution which could fragment a fragile market place. From talking with Gorry, I've been convinced that the proposed WG does _not_ intend to fight it out with existing standards, rather fulfil the requirements of niche applications and open up the debate on a common "IP over MPEG-2" solution in the long term future. If I am wrong on this, I would be grateful if someone were to fill in the picture. In anycase, the ambiguity over the proposed WG's direction and objective is easy to see, and needs eliminating.

Unfortunately, most people involved with IP over DVB deployments don't have the privilege to have been exposed to this IETF/BOF, and talking to those involved, from the very beginning. So it would be extremely helpful to spell out explicitly how this proposed WG relates to existing standards (and thus markets), and which new and existing markets/commercial requirements it is focused on. This would ensure that any conflicts with existing markets are known (and hopefully minimised) so that existing commercial interests do not inhibit the charter's support.

In practice this is about adding a paragraph to the charter to make these things clear. If I got the idea of the proposed WG right (i.e. there are no errors in what I said above), I'd be happy to help craft this paragraph.

(I just wanted to point out this most fundamental need before getting into specifics of the charter).

Cheers, Rod.



> -----Original Message-----
> From: owner-ip-dvb@erg.abdn.ac.uk 
> [mailto:owner-ip-dvb@erg.abdn.ac.uk]On
> Behalf Of ext The IESG
> Sent: Wednesday, October 22, 2003 4:56 PM
> To: ip-dvb@erg.abdn.ac.uk
> Subject: WG Review: IP over DVB (ipdvb)
> 
> 
> 
> A new IETF working group has been proposed in the Internet Area.  
> The IESG has not made any determination as yet.  The 
> following description
> was submitted, and is provided for informational purposes 
> only.  Please send
> your comments to the IESG mailing list (iesg@ietf.org) by 
> October 27th.
> 
> IP over DVB (ipdvb)
> -------------------
> 
>  Current Status: Proposed Working Group
> 
>  Description of Working Group:
> 
>  The MPEG-2 Transport Stream provides a transmission network 
> that has become
> widely use to support digital TV broadcast, including: DVB, 
> ATSC, ISDB-T.
> These, and related standards, define a set of commercially available
> components that are increasingly being used to provide a 
> general-purpose
> packet transmission network. MPEG-2 Transport networks are 
> being used to
> build IP networks to supplement broadcast TV/audio services 
> and also provide
> one-way and two-way IP-only subnetworks.
> 
>  There is a need to define an efficient standardised 
> encapsulation for IPv4
> and IPv6 datagrams, and to recommend procedures for 
> supporting protocols.
> Examples include dynamic address resolution, multicast group 
> membership
> reporting and possibly management information tables and 
> MIBs. Documents
> will be defined that describe protocols required to build a complete
> IPv4/IPv6 unicast/multicast services, and the mappings 
> required to perform
> dynamic address resolution. The primary purpose of this 
> working group is to
> develop a set of Internet Drafts and where appropriate to 
> progress these as
> either Internet Informational RFCs or Standards track RFCs.
> 
>  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
> should consider the range of platforms currently (or 
> anticipated to be) in
> use. This draft will be submitted to the IESG for possible 
> publication as
> an Informational RFC.
> 
>  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
> services, and support for multiple gateways (feeds).
> 
>  3. The working group will consider the options for unicast 
> and multicast
> address resolution. A working group Internet Draft will 
> define a framework
> and recommend appropriate address resolution mechanisms for 
> IPv4 and IPv6
> using both the existing Multi-Protocol Encapsulation and any new
> encapsulation developed by the working group. Consideration 
> will be paid to
> existing standards, and the cases for IPv6 and IPv4 will be 
> described. This
> document will be submitted to the IESG for publication as an 
> Informational
> RFC.
> 
>  4. A working group Internet Draft will be written to 
> recommend a set of
> dynamic address resolution procedures for IPv6. It will describe the
> protocol and syntax of the information exchanged. This work 
> may be based on
> an extension to the Neighbor Discovery (ND) protocol to support MPEG-2
> transmission, and include specific optimisations for 
> broadcast networks.
> This document will be submitted to the IESG for publication as a
> standards-track RFC.
> 
>  5. If there is a need for further supporting protocols, it 
> will consider a
> possible recharter under the guidance of the IESG. Examples 
> in this area
> include, the negotiation/association of IP QoS with MPEG-2 transport
> streams, address resolution for IPv4, and the need for SNMP MIBs.
> 
> 
> 
> 
> 
> 
> 
> 
>