[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: demo stream, filter questions
Some immediate questions/comments in-line to try to discover
whether the encapsulation has the correct features for users.
Gorry
---
> Karsten Siebert wrote:
>
> After reading the IP/DVB drafts we've implemented a sample
> encapsulation mode in our encapsulator (see below) and passed some
> data, to see, if the normal section packing method (without use of
> adaptation field) would be efficient enough for the receiver to
> de-capsulate the payload. And yes, PUSI and length are efficient to
> re-construct the payload (even when packed). We've just passed entire
> MAC frames over the link in this sample (also do not worry about the
> type, we've just picked 0x800 in the example).
>
The ID suggests you should be able to packet several IP datagrams
in the same MPEG-2 TS packet. It would be interesting to see an
IP packet size of 40B, and show how this is sent. Can you do this?
> What comes in mind here is that the MPE header is used as hardware
> filtering at "MAC/Section" level also. DVB streams are normally high
> speed streams (in the future > 100 mbps packet throughput (QAM,
> 8PSK)).
So... There are several questions here.
1) How significant a feature is "section filtering". I would
be interested to know how important this feature is. As I see it,
it gives the encapsulator the possibility of forming seperate
logical subnetworks within the same MPEG-2 TS Logical Channel.
Is this just feature-overload? Is there a good reason for not
using a separate PID for each subnetwork?
2) MAC address filtering - we NEED this to run routing protocols,
do we need it for directly connected end hosts? If hardware
filtering is indeed required, could it not use the IPv4 / IPv6 header?
Is this good / bad?
> I cannot imagine, that a standard receiver filters at IP or
> similar levels in software. MPE has the MAC address field, which tells
> the local hardware to set a section level filter. The "minimal header
> has no such capability. Will receivers get all packets on that PID ?
Yes, currently they would.
> How do you build groups of receiver devices ?
Use another PID?
>
>
> Karsten
>
>
> (In case one is interested we also have colored pdf version of the
> demo output for better visibility of individual bytes)
>
>
> The demo system transmits complete Ethernet frames, section_type
> (equal to Ethernet protocol identifier) is copied from Ethernet
> header. section_length = tot_len of section - 4 (in bytes).
>
> Syntax No. of bits Identifier
>
> MPM_section() {
>
> section_type 16 uimsbf
> section_length 16 uimsbf
>
> for(i=0; i<N; i++) {
> data_byte [i] 8 bslbf
> }
>
> section_crc32 32 rpchof
> }
>
>
> Two UDP packets (100 byte payload "a"),
> Section packing disabled, PID 0x64,
> PUSI set in both TS packets,
> Pointer byte set in both TS packets,
>
> Packet length 188
> 4740641700080000920002a0b0c0d00002a0b0c0d00800450000802097000040
> 11d872c0a80009c0a8000a04000312006c719b61616161616161616161616161
> 6161616161616161616161616161616161616161616161616161616161616161
> 6161616161616161616161616161616161616161616161616161616161616161
> 616161616161616161616161616161616161616161616134087b04ffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
>
> Packet length 188
> 4740641800080000920002a0b0c0d00002a0b0c0d00800450000802098000040
> 11d871c0a80009c0a8000a04000312006c719b61616161616161616161616161
> 6161616161616161616161616161616161616161616161616161616161616161
> 6161616161616161616161616161616161616161616161616161616161616161
> 616161616161616161616161616161616161616161616145e70541ffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
>
>
> Two UDP packets (100 byte payload "a"),
> Section packing enabled, PID 0x64,
> PUSI set in first TS packet,
> Pointer byte set in first TS packet,
>
> Packet length 188
> 4740641900080000920002a0b0c0d00002a0b0c0d00800450000802099000040
> 11d870c0a80009c0a8000a04000312006c719b61616161616161616161616161
> 6161616161616161616161616161616161616161616161616161616161616161
> 6161616161616161616161616161616161616161616161616161616161616161
> 61616161616161616161616161616161616161616161619710a3130800009200
> 02a0b0c0d00002a0b0c0d0080045000080209a00004011d86fc0a800
>
> Packet length 188
> 4700641a09c0a8000a04000312006c719b616161616161616161616161616161
> 6161616161616161616161616161616161616161616161616161616161616161
> 6161616161616161616161616161616161616161616161616161616161616161
> 616161616161616161616161616161616161616161c818168bffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
>
> Three UDP packets (100 byte payload "a"),
> Section packing enabled, PID 0x64,
> PUSI set in first two TS packets,
> Pointer byte set in first two TS packets,
>
> Packet length 188
> 4740641b00080000920002a0b0c0d00002a0b0c0d0080045000080209b000040
> 11d86ec0a80009c0a8000a04000312006c719b61616161616161616161616161
> 6161616161616161616161616161616161616161616161616161616161616161
> 6161616161616161616161616161616161616161616161616161616161616161
> 61616161616161616161616161616161616161616161611aefb0d90800009200
> 02a0b0c0d00002a0b0c0d0080045000080209c00004011d86dc0a800
>
> Packet length 188
> 4740641c7509c0a8000a04000312006c719b6161616161616161616161616161
> 6161616161616161616161616161616161616161616161616161616161616161
> 6161616161616161616161616161616161616161616161616161616161616161
> 61616161616161616161616161616161616161616161949b3409080000920002
> a0b0c0d00002a0b0c0d0080045000080209d00004011d86cc0a80009c0a8000a
> 04000312006c719b6161616161616161616161616161616161616161
>
> Packet length 188
> 4700641d61616161616161616161616161616161616161616161616161616161
> 6161616161616161616161616161616161616161616161616161616161616161
> 6161616161616161616161616161616161616161466c925bffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
>
>