RE: Adding ULE into a network already using MPE...

["Goldberg, Adam" <agoldberg@sharplabs.com>]

I see it rather simply: consider an environment with a mix of non-IETF-aware
devices (widely available MPEG-transport-processing devices, like
multiplexers, remultiplexers, rate shapers, ad insertion equipment, etc etc)
- call this set "A" - and IETF-aware devices (couldn't name one, but you
probably have something in mind) - call this set "B".

If you signal the existence of IETF steams in a MPEG Transport Stream
compliant manner (that is, via PMT entries), then every device in "A" will
autorecognize that those steams exist, and even if they don't know what they
are or what to do with them, will pass them through the system.  Also, of
course, devices in "B" will work, too.

If you signal the existence of IETF streams in some other manner, either by
well-known PID values, or "out of band" signaling or some prearrangement or
whatever, then every device in "B" will work ... and a large proportion of
devices in "A" will IMMEDIATELY DROP ALL OF THOSE PACKETS AND NOT PASS THEM
THROUGH.

Seems a clear choice to me.  But feel free to design a private system that
requires all entirely new infrastructure hardware.  It'll be much less
useful.


Adam Goldberg
Director, Television Standards & Policy Development
Sharp Laboratories of America
8605 Westwood Center Drive, Suite 206
Vienna, VA  22182
703-556-4406
703-556-4410 fax
571-276-0305 cell
 


> -----Original Message-----
> From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On
> Behalf Of Marie-Jose Montpetit
> Sent: Thursday, August 04, 2005 1:48 PM
> To: ipdvb@erg.abdn.ac.uk
> Cc: ipdvb@erg.abdn.ac.uk
> Subject: RE: Adding ULE into a network already using MPE...
> 
> I agree with Gorry. I think there are many ways of looking at it and
> there is a trend to design signaling mechanisms that become to certain
> extent independant of the actual implementation (that can depend on for
> example if you MPEG steam is DVB, DCII etc) and allow ti include other
> features (such as QoS) in the auto-detection.
> 
> But then, I did write a draft on this ;-)
> 
> /mjm
> 
> > -------- Original Message --------
> > Subject: Re: Adding ULE into a network already using MPE...
> > From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
> > Date: Thu, August 04, 2005 12:55 pm
> > To: <ipdvb@erg.abdn.ac.uk>
> >
> > I don't see it this way.
> >
> > On 4/8/05 5:45 pm, "Goldberg, Adam" <agoldberg@sharplabs.com> wrote:
> >
> > > Sure, you can decide to not use the mechanisms already existent in an
> MPEG
> > > Transport Stream (B, C), but in doing so you merely cause redesign or
> > > purchase of special-purpose "MPEG" processing devices.
> >
> > Why do you feel auto-detection of the encapsulation ( C ) implies a
> redesign
> > of the MPEG equipment? This is a driver issue only, and orthogonal to
> > supplying SI/PSI signalling. It does not stop a stream sending
> signalling as
> > well, or imply it. It provides a way to know that you have got the right
> > encaps.
> >
> > > Make it a Transport Stream.  This has very little real overhead,
> requiring
> > > only a PAT and PMT.  The PMT is very lightweight but yet can easily
> signal
> > > which elementary streams (er, "PIDs") are encoded with what protocols.
> > >
> > > This has many advantages:  You don't need to reinvent anything (inband
> > > signaling) -- merely an identifying descriptor; you don't have to
> require
> > > multiplexers and other non-IETF MPEG processing devices do anything
> special
> > > (that is to say, you don't require existing MPEG processing devices to
> also
> > > process nonstandard IETF things); IETF streams would coexist
> peacefully with
> > > non-IETF streams in a Transport Stream; it's very extensible to other
> > > encapsulation formats yet-to-be-defined.
> >
> > I think someone should gather this thread and write one or two
> paragraphs to
> > summarise this to include in section 4 of the address resolution
> document
> > (draft-ietf-ipdvb-ar-00.txt), especially the implications of the PSI/SI
> on
> > the remultiplexing environment.
> >
> > Gorry
> >
> > >
> > > Adam Goldberg
> > > Director, Television Standards & Policy Development
> > > Sharp Laboratories of America
> > > 8605 Westwood Center Drive, Suite 206
> > > Vienna, VA  22182
> > > 703-556-4406
> > > 703-556-4410 fax
> > > 571-276-0305 cell
> > >
> > >
> > >
> > >> -----Original Message-----
> > >> From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk]
> On
> > >> Behalf Of Gorry Fairhurst
> > >> Sent: Thursday, August 04, 2005 3:56 AM
> > >> To: ipdvb@erg.abdn.ac.uk
> > >> Subject: Re: Adding ULE into a network already using MPE...
> > >>
> > >> There ways to do this I can think of three, and I think John you are
> > >> asking
> > >> about C?
> > >>
> > >>
> > >> A) You could parse the SI/PSI signalling (if any) and extract the
> > >> information from there.
> > >>
> > >> B) You could configure it (out of band) or using IP
> > >> configuration/resolution, etc.
> > >>
> > >> C) I once worked through an "auto-detect mode", where you knew the
> PID but
> > >> didn't know the type of encapsulation.
> > >>
> > >> ----
> > >>
> > >> The basic rule is only one type of encapsulation is allowed for a
> single
> > >> PID. So how can you find out which is used?
> > >>
> > >> I note there is a reasonably strong CRC there in the ULE framing, and
> you
> > >> can easily extract framing alignment to the TS from the PUSI setting
> in
> > >> the
> > >> TS header:
> > >>
> > >> (i) Supposing your receiver starts as unconfigured.
> > >>
> > >> (ii) The receiver looks for a PUSI setting and extracts the PP value.
> > >>
> > >> (iii) It then tries reassembly of the first section as a ULE packet.
> If it
> > >> succeeds with a valid CRC-32 and Length, it is probably safe to
> assume
> > >> this
> > >> is ULE.
> > >>
> > >> (iv) If the CRC fails, it tries a DSM-CC section reassembly (being
> aware
> > >> the
> > >> integrity check is interpreted in more than one way in MPE). The MPE
> start
> > >> code is also another "hint" that this may not be ULE, but this value
> > >> *could*
> > >> appear as the start of a ULE field - (Note one needs to be aware that
> MPE
> > >> and ATSC use different start values).
> > >>
> > >> (v) You could (probably should!!!) verify the next few SNDUs to
> increase
> > >> your confidence, as in any alignment algorithm.  It would also be
> wise to
> > >> re-initialise the detection if you suffer an alignment failure. This
> could
> > >> be a result of a change of mutliplexing policy.
> > >>
> > >> Note: This is orthogonal to the generation of SI/PSI tables used to
> > >> control
> > >> the TS multiplexing layer itself. If you use a transport stream
> > >> multiplexor
> > >> as a part of your L2 MPEG transmission network, this may need the
> SI/PSI
> > >> to
> > >> allow the PID to reach the Receiver.
> > >>
> > >> Thoughts?
> > >>
> > >> Gorry
> > >>
> > >> On 3/8/05 8:39 pm, "John Border" <border@hns.com> wrote:
> > >>>
> > >>>     I was thinking along those lines.  The sender associates the
> > >>> encapsulation method with a particular PID and "knows" (via AR)
> which
> > >>> PID to use to send to a particular receiver.  Receivers which only
> > >>> understand MPE only use MPE PIDs.  Receivers which understand ULE
> and
> > >>> MPE determine which method is being used by which PID is being
> > >>> received.  (I think the ULE capable receivers will still need to
> support
> > >>> MPE for multicast traffic that is shared with "older" terminals.)
> > >>>
> > >>>     I was wondering if there is a way for the receiver to look at
> the
> > >>> header and determine if it is ULE or MPE on the fly.  I haven't
> taken a
> > >>> close look at it yet.  But, I suspect that it is not reliably
> > > possible...
> > >>>
> > >>> John
> > >>>
> > >>>
> > >>> Marie-Jose Montpetit wrote:
> > >>>
> > >>>> I think this is one thing that could be solved by some of the
> > >>>> configuration work that was started where you could associate a PID
> to
> > >>>> an encapsulation. You may not want to ignore the new encapsulation.
> > >>>>
> > >>>> Marie-Jose
> > >>>>
> > >>>>
> > >>>>
> > >>>>> -------- Original Message --------
> > >>>>> Subject: RE: Adding ULE into a network already using MPE...
> > >>>>> From: "Allison, Art" <AAllison@nab.org>
> > >>>>> Date: Wed, August 03, 2005 2:05 pm
> > >>>>> To: <ipdvb@erg.abdn.ac.uk>
> > >>>>>
> > >>>>> Use of the MRD will enable a device on a MPEG-2 network that does
> not
> > >>>>> understand that MRD's signaling/meaning to ignore the new
> > >> encapsulation.
> > >>>>>
> > >>>>>
> > >>>>> Of course if the existing network just used private data with out
> > >>>>> signaling what it was, a problem may exist.
> > >>>>> __________________
> > >>>>> Art Allison
> > >>>>> Director, Advanced Engineering
> > >>>>> NAB Science & Technology
> > >>>>> 1771 N St NW, Washington DC 20036
> > >>>>> 202 429 5418
> > >>>>> -----Original Message-----
> > >>>>> From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-
> ipdvb@erg.abdn.ac.uk]
> > >>>>> Sent: Wednesday, August 03, 2005 11:32 AM
> > >>>>> To: ipdvb@erg.abdn.ac.uk
> > >>>>> Subject: Adding ULE into a network already using MPE...
> > >>>>>
> > >>>>>
> > >>>>>    Has anyone looked at the operational problems associated with
> > >> adding
> > >>>>> ULE use to a network which has some deployed terminals which only
> > >>>>> understand MPE?
> > >>>>>
> > >>>>>
> > >>>>> John
> > >>>>>
> > >>>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >
> > >