Dear Tor Brekke,
Sorry if I have confused, may be I should
make it more detailed J
In DSM-CC (MPE) we have section-length to
specify the size of the payload it carries, this can be maximum of 4096 bytes. Hence
any IP packet as a potential payload for DSM-CC can be maximum of 4096 bytes,
this length normally discovered using L2 MTU size and IP packets gets
fragmented if the packet is greater than 4096 bytes. But theoretically, DSM-CC
supports multiple segments/fragments by itself (section number and last section
number) which gives room for bigger ip packet even greater than 4096 bytes.
Does any of the vendor uses this functionally for ip data transmission is a
question !!!. I myself never come across such support for ip data transmission.
Next, if a single DSM-CC (MPE) can carry more than one IP packet??, I don’t
understand if it is possible, since we don’t have payload start indicator
and pointer to perform IP datagram section packing in single DSM-CC (MPE)
payload, which can be decapsulated at the other end.
Next, MPEG2-TS, for any MPEG2-TS packet it
MUST be of length 188 bytes. Any MPE (DSM-CC) packet less than 183 bytes (considering
after MPEG2-TS header and payload pointer) needs to be stuffed/padding, instead
of doing so we can do section packing, by sending next MPE packet into the same MPEG2-Transport Stream.
Hope now it is clear
Update me if I’m wrong J
-William.
From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On Behalf Of Tor Brekke
Sent: Monday, May 02, 2005 11:25
AM
To: ipdvb@erg.abdn.ac.uk
Subject: RE: MPE Question
Hi William,
I
think you are somewhat confused in the use of terminology here. Section packing
is the process of having more than one (partial) IP packet in each MPG frame.
This has nothing to do with maximum section size. All IP encapsulators probably
support MPE Section packing.
MPE
Does additionally support fragmentation of an IP packet into multiple DSM-CC
sections (I guess this is what you are really talking about). This is only
useful for IP packets which do not fit into the maximum section size of 4096
octets. This function, while defined by the MPE standard, is not (normally?)
supported by the IP encapsulators. I have to admit that I have not checked
details on ever vendor here, but have not seen this in any of the ones I have
used myself.
Regards
Tor
Brekke
|
"William StanisLaus"
<william@erg.abdn.ac.uk>
Sent
by: owner-ipdvb@erg.abdn.ac.uk
29.04.2005 17:56
|
Please
respond to
ipdvb@erg.abdn.ac.uk
|
|
|
To
|
<ipdvb@erg.abdn.ac.uk>
|
|
cc
|
|
|
Subject
|
RE: MPE Question
|
|
Hi
Siva and Bernhard,
DSM-CC which is a potential MPE of our present day
DOES NOT support section
packing for normal IP data transmissions. In
DSM-CC we have section length
of 12 bits, which can hold maximum of 4096 Bytes
of payload data (IP in our
discussion). In Normal
scenario we don't even use this big, since section
packing is not supported practically
(theoretically YES), we use DVB router
one interface as Ethernet and other as DVB, on
Ethernet wire we get only
1500 bytes the max, though there is a room for
section
packing(theoretically) real time packet routing
don't wait for another IP
packet, just push each and every ip packet
received with MPE (DSM-CC) and to
MPEG2-TS (supports section packing, based on the
timer - reason MPEG2-TS
MUST be 188 bytes, instead of wasting bytes with
stuffing we have section
packing).
When we are talking about stuffing bytes, that was
perfect by Bernhard, we
use for packet alignment, to be more specific,
real time operating system
like PSOS, requires it be WORD aligned ( Multiples
of Four) before
encryption algorithm to be applied for scrambling.
-William.
> -----Original Message-----
> From: owner-ipdvb@erg.abdn.ac.uk
[mailto:owner-ipdvb@erg.abdn.ac.uk]
On
> Behalf Of Bernhard Collini-Nocker
> Sent: Friday, April 29, 2005 6:55 AM
> To: ipdvb@erg.abdn.ac.uk
> Subject: Re: MPE Question
>
> Dear Siva,
>
> you are right in that I had understood your
question different.
>
> Generally Sections do allow for numbering
that is, one can put a payload
> (for example a DSM-CC object) into a number
of Sections and with
> section_number and last_section_number the
reassebler knows what to do.
> MPE uses this Section mechanism, so multiple
Section operations should
> be possible. Actually I have never tested
whether MPE decapsulators do
> support this in real, in principle they
should (again the DVB
> databroadacst standard does not say too much,
if anything, about it) but
> in DSM-CC Obejct carousels is a very usual
mode of operation.
>
> Siva Veerepalli wrote:
> > Thanks for the response Bernhard, but I
am a bit
> > confused about the answer. Please see my
question
> > below:
> >
> > --- Bernhard Collini-Nocker
<bnocker@cosy.sbg.ac.at>
> > wrote:
> >
> >>Siva Veerepalli wrote:
> [...]
> > I understand that two MPE sections could
probably
> > start in the same
TS packet (I guess that is what you
> > mean by section packing).
>
> Yes.
>
> > My original questions was, what is the
usual practice
> > with regards to fragmenting an IP
datagram over
> > multiple MPE sections (irrespective of
how these
> > sections are transported in TS packets)?
The DVB-H
> > (data broadcast standard) allows for
this, however,
> > the IPDC interim specification requires
that one
> > datagram be encapsulated entirely in one
mpe section
> > i.e., no datagram fragmentation over
multiple MPE
> > sections.
>
> Now the confusion starts when one introduces
the wording of "over
> multiple MPE sections", because there is
no such thing as a MPE section
> fragmentation.
> I will have to read the DVB-H standard again
in order to find out what
> it really says. I guess the only real issues
the DVB-H wrt to IP is
> addressing is the necessity of a IP datagram
encapsulated in MPE is to
> support time slicing (ie a burst transmission
of the resulting TS
> packets to allow for power saving) and
MPE-FEC (adding redundant code to
> allow for reconstruction). In that case I
woould assume that it is very
> reasonable (especially with legacy equipment)
to avoid all potential
> interpretations of MPE wrt multiple section
operation and section packing.
>
> > thanks,
> > Siva
> [...]
>
> Yor are very welcome,
> and I hope I got THE expected answer closer,
> Bernhard
|