Re:IP over DVB and MPLS

[Gorry Fairhurst <gorry@erg.abdn.ac.uk>]

There seem to be two threads to your comments, one relating to MPLS
(which we can start discussing here), and one to native IP
(see following message).

Torsten.Jaekel@FTK.rohde-schwarz.com wrote:

<<snip>>

> - MPLS:
>    yes, not to consider protocols but a gateway function to connect DVB-IP
> networks directly on an
>   MPLS core/cloud, or to act as a MPLS edge router seems to be necessary in
> future. To extend pure and native
>   IP networks (which will be based on MPLS and optical networks) over DVB should
> be possible seamlessly.
>   By the way: The Generic MPLS (GMPLS) approach could fit perfectly and could be
> expanded to DVB networks.
>   where PIDs could be used as labels. (You see I like the MPLS approach ;-)

Seems an interesting area to debate, do others agree/disagree?

Since most current DVB decoders (tell me if I am wrong) support
only a small number <64 active PIDs, the use of large number of PIDs
requires at least some evolution of the way IP/DVB is used.

There are going to many issues here I guess, it would be VERY worthwhile
knowing the alternatives, their strengths and potential pitfalls.

I would however be disappointed if we could only work on MPLS transport, 
since I believe there will be long-standing need for native IP services.

> - TCP/IP header compression:
>    a)
>    yes but why not discarding IP headers ? Means: using a MPLS like approach -
> to map IP addressed to
>    broadcast channel numbers (PIDs, IP connections in dedicated PIDs) than we
> can
>    reconstruct IP headers at the receiving side (using a connection or service
> management). This allows also to
>    route IP connections within an DVB network which operate just on PIDs (MPLS
> labels !) instead of IP level.

Also note the work done in the IETF ROHC WG:

http://www.ietf.org/html.charters/rohc-charter.html

This WG hopes to offer a high compression of IP (and UDP, RTP, TCP in
some cases) so 
could also be of benefit to DVB links, and reduce the number of bytes
per packet.
 
>    b)
>    Why not to compress also the content, e.g. static web site (text and HMTL
> compression) or to adapt compression
>    standards like V.90 or others (similar the current development of compression
> on ISDN) ?

I'm not sure I see the need to discuss content compression here, compression
of the payload for IP packet flows is being discussed in other forums.  
I suggest we focus on DVB/MPEG specific issues, although as thinking evolves,
we may like to examine which other schemes offer advantage / problems when
used over a next generation IP over DVB service. 

<<Snip>>

> 
> Best regards
> 
> Torsten Jaekel
> Product Marketing Datacasting
> Rohde & Schwarz FTK GmbH
> Wendenschlossstr. 168, Haus 28
> 12557 Berlin
> Germany
> Phone: +49 30 65 89 1 - 103
> FAX:     +49 30 65 55 02 21
> email: Torsten.Jaekel@FTK.rohde-schwarz.com
> 
> -------------------------|
> 
> As a pre-requisite to any debate, I thought it may be useful to test
> whether we are in agreement on some background assumptions.
> 
> My suggestions for the basic assumptions are:
> 
> ---
> The encapsulation
> 
> Supports IPv4 unicast and multicast
> Supports IPv6 unicast and multicast
> Does NOT consider MPLS, Ethernet bridging, and other protocols
> Does include support for TCP/IP header compression schemes (e.g. ROHC)
> ---
> Encapsulation
> 
> Direct transmission in the MPEG-2 Transport stream
> This should NOT be based on DSM-CC, or a PES format
> This should support section-packing (multiple datagrams in the same
> MPEG-TS packet)
> ---
> 
> Are these all sensible starting assumptions?
> 
> Would this approach raise serious issues with conditional access?
> 
> How does this relate to data piping (specified in DVB EN 301 192)?
> 
> Gorry