[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Text for: Adding ULE into a network already using MPE...
I think the time has come to write this down as a text block for the AR
draft
This seems a fine start on some text to me. I would like to propose using
this as a basis and working through the mail thread to make sure that we
also capture all the points earlier in the thread. Let's capture all this as
a set of paragraphs - we could possibly place this at the front of section
4.
Gorry
On 4/8/05 8:52 pm, "Goldberg, Adam" <agoldberg@sharplabs.com> wrote:
> 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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>