Re: Antwort: Checking the backgorund to this...

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

Torsten.Jaekel@FTK.rohde-schwarz.com wrote:
> 
> Dear all,
> 
> thank you for installing the email reflector.
> 
> I aggree with Gorry's suggestions but few remarks from my side:
> - IPv6:
>   security is included as issue ? (see also conditional access)
> - IPv6:
>   if we are focused on IPv6 is it necessary to consider IPv4 (perhaps included
> or not needed anymore ?) ?

I think so - do others disagree? I expect IPv4 to be around for quite a while,
and wonder whether it will ever finally disappear, even if the bulk of
the net
becomes IPv6.

I think would be foolish not to consider IPv6 from the start?

> - MPLS:
<<snip>>  - see separate mail thread

> - direct transmission without DSM-CC:
>    seems to be needed in order to be more efficient but we should not drop the
>    DVB channel approach (the multiplex, the meaning of PIDs and the tables to
> signal the content and structure).

OK, so are you suggesting for DVB multiplexes we should use standard SI/PSI
to identify the mnutliplex and PIDs in use?

I guess the question I was wondering was should these tables also be
used for 
subnetwork functions such as IP address resolution to a PID and multicast
group control.  I know there have been proposals to do this using DVB tables,
but it may also be possible to do this directly over the MPEG2-TS, in the
same way that IP is to be carried, e.g. using a variant of "arp". 

I wonder what the pros and cons are?

>    The DVB has to provide a transport or baerer service and our new approach
> should not influence running TV programs. How to solve ?
> - multiple datagrams in the same MPEG-TS package:
>    is already possible right now (in terms of many simultaneous IP connections
> in MPEG-2 TS).
>    For me: How we could use free resources, like stuffing, Null Packets etc. and
> how we could multiplex different IP
>    connections without lost space (seemless IP frame packaging).

I'm not sure what you are saying here.  I was trying to talk about what
some people call section packing. In MPE, one can send an IP packet
which 
always starts at the first byte of a TS packet. Such a packet includes 
padding at the end of the last TS packet, if there are unused bytes. 
This 
resembles AAL5 in ATM.

An alternative (pcked) scheme sends the next available packet directly after
the end of the first. There may therefore be no padding, when there is 
data packets pending transmission at the MPE input. This achieves
greater efficiency, particularly for small (or compressed) packets.

> - Conditional Access (CA):
>    Do we support "native" DVB CA (the encryption of MPEG-2 TS) or is IP security
> an issue of higher layers (IP encryption using IP or higher tools) ?

A good question!!!!
- There may be lots of views on this????

> 
> Other questions:
> What about easy reception vs. efficient multiplexing ?

> Should we think in services and start with a top-down approach (which services
> have to be supported, which traffic profiles
> do we need and then how we could package IP frames) instead to change the
> physical layer first ?

Would you (or anyone else) like to suggest something?

> 
> 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
> 
> PS: Is there anybody visiting the IBC 2001 in Amsterdam ? I am going to be
> there, Rhode&Schwarz, Hall 8, booth 271.
> You are invited to visit us and to talk about this issue IP-over-DVB.
> 
> |--------+----------------------->
> |        |          Gorry        |
> |        |          Fairhurst    |
> |        |          <gorry@erg.ab|
> |        |          dn.ac.uk>    |
> |        |                       |
> |        |          04.09.01     |
> |        |          20:24        |
> |        |                       |
> |--------+----------------------->
>   >----------------------------------------------------------------------------|
>   |                                                                            |
>   |       An:     ip-dvb@erg.abdn.ac.uk                                        |
>   |       Kopie:  (Blindkopie: Torsten Jaekel/FTK)                             |
>   |       Thema:  Checking the backgorund to this...                           |
>   >----------------------------------------------------------------------------|
> 
> 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