From gorry at erg.abdn.ac.uk Wed Feb 2 19:47:30 2005 From: gorry at erg.abdn.ac.uk (Gorry Fairhurst) Date: Wed, 02 Feb 2005 19:47:30 +0000 Subject: LLC support in DVB , ATSC, MPEG-2? - DO WE NEED A NEW EXTENSION? In-Reply-To: <41FE494D.2000607@erg.abdn.ac.uk> References: <41F945E4.1040403@erg.abdn.ac.uk> <41FE2FC4.6000805@erg.abdn.ac.uk> <904a5ff0bd74cd8d26b2e76016f88483@tzi.org> <41FE494D.2000607@erg.abdn.ac.uk> Message-ID: <42012E52.8030603@erg.abdn.ac.uk> So let me try to see if I can summarise the discussion: One motive for the query about the LLC usage was linked to anticipated future support for ROHC. The important goal at this time for the ipdvb WG is to KNOW that we can extend ULE in the furture satisfy new needs - I see ROHC as one which is very desirable. The text below seems to indicate we could do this. However, I am hessitant to introduce a new extension header for a possible use, which isn't quite decided yet, and where there may be other issues that come to light as the ROHC work progresses (some people would like to see multiple small packets per SNDU - but again this needs more thought, and there ARE issues, there may be others). ULE has already completed one WGLC, and this was raised in the second one. I recommend that we publish ULE without this new specific optimisation, with the understanding that once the requirements are understood and optimisations considered, a separate short ID could be written defining how to do ROHC (or optimised LLC... etc) over ULE. **BUT**, I want to know what others think: Is this a good plan for the WG, or should we look further at this now? Gorry Fairhurst (ipdvb WG Chair) Gorry Fairhurst wrote: > > Right, I (personally) do think it would be good to explore ROHC > requirements for ipdvb. Perhaps we should point this list to the ROHC > draft? > > > 1) MPE+LLC/SNAP+ROHC > > To support ROHC over MPE would need LLC/SNAP - which has > overhead/processing drawbacks. This mitigates the benefit from > performing ROHC in this case. > > > 2) ULE+Bridging+LLC+ROHC > > I can see why an LLC-based method could serve ROHC well when ROHC may > have to cross a L2 Ethernet subnetwork - especially when some of the L2 > devices act as bridges (such as Wireless APs). To support ROHC over ULE > using LLC would currently also require the Bridging Extension. If the > ULE gateway is operating in a Bridging mode, this seems rather like the > case for an 802.11 AP. So I'd have expected it to work with LLC bridging > - but there is an overhead. > > > 3) Other Options? > > If the ULE-capable device is a router, you could have saved bytes by > suppressing some fields. If you intend to use a L2 code point > (LLC-Type), but at the same time do not need the L2 end point identifier > (MAC Addresses), I think I need to understand more. > > Clearly it would be posisble to define a header of this sort - but then > it creates more Receiver de-multiplexing options... > > One thought: If the WG envisages only one or a small number of uses for > an LLC without MAC mode, would it make sense to think of a separate IANA > assignment(s) for a Mndatory Type value from the ULE Registry? And what > would the protocol dependices be on ROHC --- would the same ROHC methods > still work? > > Gorry > > Carsten Bormann wrote: > >>> (i) Do we need LLC? >>> Yes (discussed at both ipdvb BoF as well as at other times), we >>> should supportLLC, because of it use/potential use for OSPF; >>> Bridging; L2 Management/devcice discovery >> >> >> >> LLC is also the basis for SNAP. >> >>> (ii) Non-issues for ULE. >>> LLC is also used: >>> - To raise the ETnerenet frame size above that of traditional Ethernet >>> - To provide a Type field (not present in basic MPE header). >>> Both of these are supported natively within ULE without the need for >>> LLC/SNAP >> >> >> >> SNAP can be used for protocols other than those that have an ethertype. >> Again, I don't know all protocols... >> >>>> Is the assumption that all LLC protocols need full MAC addresses? >>> >>> >>> >>> So, yes that was it. >>> >>> - My understanding was that because this was an IEEE protocol, and >>> much of the use of LLC reflected use in a bridged network, then it >>> was best to include both a source and destination MAC address. >> >> >> >> I'd say leave this for the encapsulator to decide. >> Assuming that ROHC over 802 goes the LLC route, it is not a given to >> me that we always need MAC addresses. >> >>>> It would be easy to introduce a mandatory extension header 2, which >>>> is like 1 (i.e., does not allow chaining) but leaves out the 14 >>>> bytes of (DA, SA, Type -- the latter is redundant with the LLC >>>> length), leading to: >>>> 0 1 2 3 >>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> |1| Length (15b) | Type = 0x0002 | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | | >>>> = LLC payload = >>>> | | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | (CRC-32) | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> (and the obvious equivalent for D=0). >>> >>> >>> >>> I'm keen to understand first the intended usage.... >> >> >> >> This would be used for compressed voice in a ROHC/RTP scenario. >> The LLC payload would contain the necessary glue, a ROHC header (which >> has a context ID useful for demultiplexing), and the voice payload >> (say, 10 bytes). >> Adding MAC addresses and another (redundant) type/length field makes >> this SNDU significantly larger. >> An NPA may or may not be necessary, depending on the specific use. >> >> Gruesse, Carsten >> >> > > From marie at mjmontpetit.com Wed Feb 2 20:36:25 2005 From: marie at mjmontpetit.com (Marie-Jose Montpetit) Date: Wed, 2 Feb 2005 13:36:25 -0700 Subject: LLC support in DVB , ATSC, MPEG-2? - DO WE NEED A NEW EXTENSION? Message-ID: <20050202203625.2294.qmail@webmail01.mesa1.secureserver.net> I guess ROHC over ULE/Enet would be a great topic for Minneapolis? Gorry could that lead to another draft maybe? Marie-Jose > -------- Original Message -------- > Subject: Re: LLC support in DVB , ATSC, MPEG-2? - DO WE NEED A NEW > EXTENSION? > From: "Gorry Fairhurst" > Date: Wed, February 02, 2005 2:47 pm > To: ipdvb at erg.abdn.ac.uk > Cc: "Carsten Bormann" > > So let me try to see if I can summarise the discussion: > > One motive for the query about the LLC usage was linked to anticipated future > support for ROHC. The important goal at this time for the ipdvb WG is to KNOW > that we can extend ULE in the furture satisfy new needs - I see ROHC as one > which is very desirable. The text below seems to indicate we could do this. > > However, I am hessitant to introduce a new extension header for a possible > use, which isn't quite decided yet, and where there may be other issues that > come to light as the ROHC work progresses (some people would like to see > multiple small packets per SNDU - but again this needs more thought, and there > ARE issues, there may be others). > > ULE has already completed one WGLC, and this was raised in the second one. I > recommend that we publish ULE without this new specific optimisation, with the > understanding that once the requirements are understood and optimisations > considered, a separate short ID could be written defining how to do ROHC (or > optimised LLC... etc) over ULE. > > **BUT**, I want to know what others think: Is this a good plan for the WG, or > should we look further at this now? > > Gorry Fairhurst > (ipdvb WG Chair) > > Gorry Fairhurst wrote: > > > > Right, I (personally) do think it would be good to explore ROHC > > requirements for ipdvb. Perhaps we should point this list to the ROHC > > draft? > > > > > > 1) MPE+LLC/SNAP+ROHC > > > > To support ROHC over MPE would need LLC/SNAP - which has > > overhead/processing drawbacks. This mitigates the benefit from > > performing ROHC in this case. > > > > > > 2) ULE+Bridging+LLC+ROHC > > > > I can see why an LLC-based method could serve ROHC well when ROHC may > > have to cross a L2 Ethernet subnetwork - especially when some of the L2 > > devices act as bridges (such as Wireless APs). To support ROHC over ULE > > using LLC would currently also require the Bridging Extension. If the > > ULE gateway is operating in a Bridging mode, this seems rather like the > > case for an 802.11 AP. So I'd have expected it to work with LLC bridging > > - but there is an overhead. > > > > > > 3) Other Options? > > > > If the ULE-capable device is a router, you could have saved bytes by > > suppressing some fields. If you intend to use a L2 code point > > (LLC-Type), but at the same time do not need the L2 end point identifier > > (MAC Addresses), I think I need to understand more. > > > > Clearly it would be posisble to define a header of this sort - but then > > it creates more Receiver de-multiplexing options... > > > > One thought: If the WG envisages only one or a small number of uses for > > an LLC without MAC mode, would it make sense to think of a separate IANA > > assignment(s) for a Mndatory Type value from the ULE Registry? And what > > would the protocol dependices be on ROHC --- would the same ROHC methods > > still work? > > > > Gorry > > > > Carsten Bormann wrote: > > > >>> (i) Do we need LLC? > >>> Yes (discussed at both ipdvb BoF as well as at other times), we > >>> should supportLLC, because of it use/potential use for OSPF; > >>> Bridging; L2 Management/devcice discovery > >> > >> > >> > >> LLC is also the basis for SNAP. > >> > >>> (ii) Non-issues for ULE. > >>> LLC is also used: > >>> - To raise the ETnerenet frame size above that of traditional Ethernet > >>> - To provide a Type field (not present in basic MPE header). > >>> Both of these are supported natively within ULE without the need for > >>> LLC/SNAP > >> > >> > >> > >> SNAP can be used for protocols other than those that have an ethertype. > >> Again, I don't know all protocols... > >> > >>>> Is the assumption that all LLC protocols need full MAC addresses? > >>> > >>> > >>> > >>> So, yes that was it. > >>> > >>> - My understanding was that because this was an IEEE protocol, and > >>> much of the use of LLC reflected use in a bridged network, then it > >>> was best to include both a source and destination MAC address. > >> > >> > >> > >> I'd say leave this for the encapsulator to decide. > >> Assuming that ROHC over 802 goes the LLC route, it is not a given to > >> me that we always need MAC addresses. > >> > >>>> It would be easy to introduce a mandatory extension header 2, which > >>>> is like 1 (i.e., does not allow chaining) but leaves out the 14 > >>>> bytes of (DA, SA, Type -- the latter is redundant with the LLC > >>>> length), leading to: > >>>> 0 1 2 3 > >>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>> |1| Length (15b) | Type = 0x0002 | > >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>> | | > >>>> = LLC payload = > >>>> | | > >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>> | (CRC-32) | > >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>> (and the obvious equivalent for D=0). > >>> > >>> > >>> > >>> I'm keen to understand first the intended usage.... > >> > >> > >> > >> This would be used for compressed voice in a ROHC/RTP scenario. > >> The LLC payload would contain the necessary glue, a ROHC header (which > >> has a context ID useful for demultiplexing), and the voice payload > >> (say, 10 bytes). > >> Adding MAC addresses and another (redundant) type/length field makes > >> this SNDU significantly larger. > >> An NPA may or may not be necessary, depending on the specific use. > >> > >> Gruesse, Carsten > >> > >> > > > > From cabo at tzi.org Wed Feb 2 22:04:19 2005 From: cabo at tzi.org (Carsten Bormann) Date: Wed, 2 Feb 2005 23:04:19 +0100 Subject: LLC support in DVB , ATSC, MPEG-2? - DO WE NEED A NEW EXTENSION? In-Reply-To: <42012E52.8030603@erg.abdn.ac.uk> References: <41F945E4.1040403@erg.abdn.ac.uk> <41FE2FC4.6000805@erg.abdn.ac.uk> <904a5ff0bd74cd8d26b2e76016f88483@tzi.org> <41FE494D.2000607@erg.abdn.ac.uk> <42012E52.8030603@erg.abdn.ac.uk> Message-ID: On Feb 02 2005, at 20:47 Uhr, Gorry Fairhurst wrote: > I recommend that we publish ULE without this new specific > optimisation, with the understanding that once the requirements are > understood and optimisations considered, a separate short ID could be > written defining how to do ROHC (or optimised LLC... etc) over ULE. That's certainly fine with me: the new extension header can be added at any time. We just should consider whether it is good to have implementations out there that do ULE but don't do the compact LLC. The protocol designer in me has the general feeling that the asymmetry (can choose to use/not use MAC addresses with ethertype, must use MAC with length) is wrong. I can't point out the specific example that would validate that feeling now -- apart from ROHC, whose details haven't been decided. Gruesse, Carsten From chteh at nrg.cs.usm.my Thu Feb 3 02:23:53 2005 From: chteh at nrg.cs.usm.my (Simon Teh) Date: Thu, 3 Feb 2005 10:23:53 +0800 Subject: LLC support in DVB , ATSC, MPEG-2? - DO WE NEED A NEW EXTENSION? In-Reply-To: <20050202203625.2294.qmail@webmail01.mesa1.secureserver.net> Message-ID: <20050203022405.D481B2200EA@nrg.cs.usm.my> Currently I'm doing a research on ROHC over ULE also. I can foreseeing that it got some issues might need to be discuss for ROHC in ULE such as does it support broadcast, extension header...etc So if Mr.Gorry can lead to another draft on ROHC, I would be happy to join the discussion and sharing the idea. Best Regards, Simon Teh Universiti Sains Malaysia -----Original Message----- From: owner-ipdvb at erg.abdn.ac.uk [mailto:owner-ipdvb at erg.abdn.ac.uk] On Behalf Of Marie-Jose Montpetit Sent: 03 February 2005 04:36 To: ipdvb at erg.abdn.ac.uk Cc: Carsten Bormann; ipdvb at erg.abdn.ac.uk Subject: RE: LLC support in DVB , ATSC, MPEG-2? - DO WE NEED A NEW EXTENSION? I guess ROHC over ULE/Enet would be a great topic for Minneapolis? Gorry could that lead to another draft maybe? Marie-Jose > -------- Original Message -------- > Subject: Re: LLC support in DVB , ATSC, MPEG-2? - DO WE NEED A NEW > EXTENSION? > From: "Gorry Fairhurst" > Date: Wed, February 02, 2005 2:47 pm > To: ipdvb at erg.abdn.ac.uk > Cc: "Carsten Bormann" > > So let me try to see if I can summarise the discussion: > > One motive for the query about the LLC usage was linked to anticipated future > support for ROHC. The important goal at this time for the ipdvb WG is to KNOW > that we can extend ULE in the furture satisfy new needs - I see ROHC as one > which is very desirable. The text below seems to indicate we could do this. > > However, I am hessitant to introduce a new extension header for a possible > use, which isn't quite decided yet, and where there may be other issues that > come to light as the ROHC work progresses (some people would like to see > multiple small packets per SNDU - but again this needs more thought, and there > ARE issues, there may be others). > > ULE has already completed one WGLC, and this was raised in the second one. I > recommend that we publish ULE without this new specific optimisation, with the > understanding that once the requirements are understood and optimisations > considered, a separate short ID could be written defining how to do ROHC (or > optimised LLC... etc) over ULE. > > **BUT**, I want to know what others think: Is this a good plan for the WG, or > should we look further at this now? > > Gorry Fairhurst > (ipdvb WG Chair) > > Gorry Fairhurst wrote: > > > > Right, I (personally) do think it would be good to explore ROHC > > requirements for ipdvb. Perhaps we should point this list to the ROHC > > draft? > > > > > > 1) MPE+LLC/SNAP+ROHC > > > > To support ROHC over MPE would need LLC/SNAP - which has > > overhead/processing drawbacks. This mitigates the benefit from > > performing ROHC in this case. > > > > > > 2) ULE+Bridging+LLC+ROHC > > > > I can see why an LLC-based method could serve ROHC well when ROHC may > > have to cross a L2 Ethernet subnetwork - especially when some of the L2 > > devices act as bridges (such as Wireless APs). To support ROHC over ULE > > using LLC would currently also require the Bridging Extension. If the > > ULE gateway is operating in a Bridging mode, this seems rather like the > > case for an 802.11 AP. So I'd have expected it to work with LLC bridging > > - but there is an overhead. > > > > > > 3) Other Options? > > > > If the ULE-capable device is a router, you could have saved bytes by > > suppressing some fields. If you intend to use a L2 code point > > (LLC-Type), but at the same time do not need the L2 end point identifier > > (MAC Addresses), I think I need to understand more. > > > > Clearly it would be posisble to define a header of this sort - but then > > it creates more Receiver de-multiplexing options... > > > > One thought: If the WG envisages only one or a small number of uses for > > an LLC without MAC mode, would it make sense to think of a separate IANA > > assignment(s) for a Mndatory Type value from the ULE Registry? And what > > would the protocol dependices be on ROHC --- would the same ROHC methods > > still work? > > > > Gorry > > > > Carsten Bormann wrote: > > > >>> (i) Do we need LLC? > >>> Yes (discussed at both ipdvb BoF as well as at other times), we > >>> should supportLLC, because of it use/potential use for OSPF; > >>> Bridging; L2 Management/devcice discovery > >> > >> > >> > >> LLC is also the basis for SNAP. > >> > >>> (ii) Non-issues for ULE. > >>> LLC is also used: > >>> - To raise the ETnerenet frame size above that of traditional Ethernet > >>> - To provide a Type field (not present in basic MPE header). > >>> Both of these are supported natively within ULE without the need for > >>> LLC/SNAP > >> > >> > >> > >> SNAP can be used for protocols other than those that have an ethertype. > >> Again, I don't know all protocols... > >> > >>>> Is the assumption that all LLC protocols need full MAC addresses? > >>> > >>> > >>> > >>> So, yes that was it. > >>> > >>> - My understanding was that because this was an IEEE protocol, and > >>> much of the use of LLC reflected use in a bridged network, then it > >>> was best to include both a source and destination MAC address. > >> > >> > >> > >> I'd say leave this for the encapsulator to decide. > >> Assuming that ROHC over 802 goes the LLC route, it is not a given to > >> me that we always need MAC addresses. > >> > >>>> It would be easy to introduce a mandatory extension header 2, which > >>>> is like 1 (i.e., does not allow chaining) but leaves out the 14 > >>>> bytes of (DA, SA, Type -- the latter is redundant with the LLC > >>>> length), leading to: > >>>> 0 1 2 3 > >>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>> |1| Length (15b) | Type = 0x0002 | > >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>> | | > >>>> = LLC payload = > >>>> | | > >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>> | (CRC-32) | > >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>> (and the obvious equivalent for D=0). > >>> > >>> > >>> > >>> I'm keen to understand first the intended usage.... > >> > >> > >> > >> This would be used for compressed voice in a ROHC/RTP scenario. > >> The LLC payload would contain the necessary glue, a ROHC header (which > >> has a context ID useful for demultiplexing), and the voice payload > >> (say, 10 bytes). > >> Adding MAC addresses and another (redundant) type/length field makes > >> this SNDU significantly larger. > >> An NPA may or may not be necessary, depending on the specific use. > >> > >> Gruesse, Carsten > >> > >> > > > > From gorry at erg.abdn.ac.uk Fri Feb 4 11:55:49 2005 From: gorry at erg.abdn.ac.uk (Gorry Fairhurst) Date: Fri, 04 Feb 2005 11:55:49 +0000 Subject: Forward from Art Alison: WGLC ULE - Data Broadcast Descriptors In-Reply-To: <41FE68DA.1020507@erg.abdn.ac.uk> References: <41FE68DA.1020507@erg.abdn.ac.uk> Message-ID: <420362C5.20308@erg.abdn.ac.uk> 1) Done - point 1 was an edit mistake. 2) I think some text on data broadcast descriptors, stream-type, or/and PSI entries would be a valuable addition. On thinking about this, I wonder if the text about this should go at the end of the Introduction (1.0) to the whole document, where people can see it clearly and then undesrtand that there may be something else needed for those networks that rely on PSI for remultiplexing! - Bernhard & others who understand PSI, can you work with Art to agree the exact wording please? Gorry Fairhurst (ipdvb WG Chair) Gorry Fairhurst wrote: > WG please read and respond to this message. > > The following message was received on January 22nd before WGLC, but was > dropped because the email source address was not verified by the list > server. > > The exact text of the message follows. > > best wishes, > > Gorry > (ipdvb WG Chair) > > ----- > 1) > Thanks for considering my previous input... > I note that the new draft has an editorial oversight in that it contains > two > definitions of PSI. I suggest the second should be deleted. > 2) > I previously made a comment about the ancillary requirements when adding a > TS logical channel to a TS multiplex and asserted there appeared to be > under > specification. Perhaps it was viewed as out of scope, or perhaps I simply > don't recognize the change that resulted. I can not find what stream_type > is required to be used for the ULE stream when a "TS Logical Channel" is > added to a multiplex. > > I suggest at least an informative note be added in Section 6 (after the > third line which says: "These are transmitted using a single TS Logical > Channel over a TS Multiplex.") The note should say "PSI entries to be > consistent with [ISO-MPEG] when constructing a conformant TS Multiplex and > means for Receivers to locate each such TS Logical Channel are outside the > scope of this recommendation." > > Reason: > Just inserting a "TS Logical Channel" without including a > TS_Program_map_section that lists the PID and a stream_type does not appear > to me to result in a strictly MPEG-2 conformant bit stream; and practically > could result in the PIDs being dropped by a remultiplexer. If the means > for binding the inserted element into a multiplex and subsequent discovery > is to be covered in another document, a pointer to that document would be > more helpful than this warning. It seems at least a warning is needed and > preferably a pointer to where this next level of TS construction is > defined. > > Art Allison > Director, Advanced Engineering > NAB Science & Technology > 1771 N St NW, Washington Dc 20036 > 202 429 5418 > > > From Joel.Grotz at ses-astra.com Fri Feb 4 12:37:15 2005 From: Joel.Grotz at ses-astra.com (Joel.Grotz at ses-astra.com) Date: Fri, 4 Feb 2005 13:37:15 +0100 Subject: Joel Grotz is out of office. Message-ID: I will be out of the office starting 02/04/2005 and will not return until 02/14/2005. If required, I will respond to your message when I return to office. Best Regards, Joel Grotz. -- DISCLAIMER: This e-mail contains proprietary information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail. If you are not the intended recipient you must not use, disclose, distribute, copy, print, or rely on this e-mail. From AAllison at nab.org Thu Feb 3 14:35:44 2005 From: AAllison at nab.org (Allison, Art) Date: Thu, 3 Feb 2005 09:35:44 -0500 Subject: LLC support in DVB , ATSC, MPEG-2? Message-ID: Although I do not speak for ATSC as an organization; in response to this query, I asked among those knowledgeable about ATSC implementations of IP traffic in broadcast if they are using LLCSNAP. I have not found anyone who is using LLCSNAP today and no plans to do so were exposed. The ATSC Standard A/90 supports the DSMCC LLCSNAP flag, and specifies which protocol encapsulation is used based on that flag setting. All IP implementations of which I am aware use encapsulation 0x04, which indicated Asynchronous IP datagrams in Addressable Sections. So, my judgment is that use of LLC is likely to be small in those Regions of the World that use ATSC Transport Standards. As there is a defined standard method for those that wish to employ LLC in MPEG-2 TS (DSMCC), I suggest that developing another one is not a good investment of resources to handle this corner case. Art Allison Director, Advanced Engineering NAB Science & Technology 1771 N St NW, Washington Dc 20036 202 429 5418 -----Original Message----- From: owner-ipdvb at erg.abdn.ac.uk [mailto:owner-ipdvb at erg.abdn.ac.uk] On Behalf Of Gorry Fairhurst Sent: Monday, January 31, 2005 8:17 AM To: ipdvb at erg.abdn.ac.uk Cc: Carsten Bormann Subject: LLC support in DVB , ATSC, MPEG-2? So, I'd like to ask the group as a whole, what they see as the usage of LLC within DVB, ATSC, or any MPEG-2 based transmission network? Carsten Bormann wrote: > > One question though: Why is it that ethertype frames can be sent > without MAC but length (LLC) frames can't? So the WG did discuss this, but it seems worthwhile checking again that we have got this correct. The history as I recall is: (i) Do we need LLC? Yes (discussed at both ipdvb BoF as well as at other times), we should supportLLC, because of it use/potential use for OSPF; Bridging; L2 Management/devcice discovery (ii) Non-issues for ULE. LLC is also used: - To raise the ETnerenet frame size above that of traditional Ethernet - To provide a Type field (not present in basic MPE header). Both of these are supported natively within ULE without the need for LLC/SNAP > Is the assumption that all LLC protocols need full MAC addresses? So, yes that was it. - My understanding was that because this was an IEEE protocol, and much of the use of LLC reflected use in a bridged network, then it was best to include both a source and destination MAC address. > I don't know all existing LLC protocols, Nor me --- can anyone else on this list help? > but I know at least one > proposal for one that probably doesn't. Aha - Do tell more... > It would be easy to introduce a mandatory extension header 2, which is > like 1 (i.e., does not allow chaining) but leaves out the 14 bytes of > (DA, SA, Type -- the latter is redundant with the LLC length), leading to: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1| Length (15b) | Type = 0x0002 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > = LLC payload = > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | (CRC-32) | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > (and the obvious equivalent for D=0). > I'm keen to understand first the intended usage.... > Gruesse, Carsten > > Best wishes, Gorry Fairhurst From agoldberg at sharplabs.com Fri Feb 4 22:09:11 2005 From: agoldberg at sharplabs.com (Goldberg, Adam) Date: Fri, 4 Feb 2005 14:09:11 -0800 Subject: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto rs Message-ID: <08259490B3BC3140B549DD0907A5644811D638@admsrvnt10.enet.sharplabs.com> I apologize for being "late to the party", but: I do not see a particular need to define new term "TS Logical Channel", and indeed doing so creates risks of ill-specification (such as those Art points out), as well as confusion heaped upon someone familiar with MPEG-2 Transport (as typically used in entertainment delivery). Furthermore, the definition is quite wrong with respect to ATSC and DVB use of "specific TS Logical Channels". To my knowledge, this internet-draft is the only document anywhere which uses such terms. It is certainly true that MPEG, DVB and ATSC define //elementary streams// identified by stream_type values. I suspect this is what is meant by "TS Logical Channel", but it is difficult for me to tell. (from the draft) TS Logical Channel: Transport Stream Logical Channel. In this document, this term identifies a channel at the MPEG-2 level [ISO- MPEG]. It exists at level 2 of the ISO/OSI reference model. All packets sent over a TS Logical Channel carry the same PID value (this value is unique within a specific TS Multiplex). According to MPEG-2, some TS Logical Channels are reserved for specific signalling purposes. Other standards (e.g., ATSC, DVB) also reserve specific TS Logical Channels. While I'm commenting on this definition, it also seems to me that "channel at the MPEG-2 level" is either wrong or also ill-specified. What's a channel? If you're talking about MPEG-2, it's certainly conceivable that the reader may associate "channel" with "[television] channel" - which are the subject of a large amount of ATSC and DVB systems. Additionally, it is also wrong or ill-specified to say "According to MPEG-2 ... TS Logical Channels ...". There is no such concept defined or used within MPEG (unless what you really mean is elementary stream, in which case what do you need this extraneous term for anyhow?). In any case, Art is certainly correct that merely identifying a "TS Logical Channel" as a sequence of packets identified with a common PID value without identifying the PSI details is an invitation to multiplexers and remultiplexers to drop those packets on the floor. If there remains an opportunity to repair what I believe to be errors in the draft, I'm eager and willing to participate from a MPEG-2 entertainment (which is to say, legacy use of MPEG-2 Transport) point of view. [Apologies for being strident at all, to say nothing of at such an apparently late stage - if the above is perceived as such] Regards, Adam Goldberg Director, Television Standards & Policy Development Sharp Laboratories of America 8605 Westwood Center Drive, Suite 206 Vienna, VA 22182 +1-703-556-4406 +1-703-556-4410 fax +1-571-276-0305 cell -----Original Message----- From: owner-ipdvb at erg.abdn.ac.uk [mailto:owner-ipdvb at erg.abdn.ac.uk] On Behalf Of Gorry Fairhurst Sent: Friday, February 04, 2005 6:56 AM To: ipdvb at erg.abdn.ac.uk; Bernhard Collini-Nocker Cc: AAllison at nab.org Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast Descriptors 1) Done - point 1 was an edit mistake. 2) I think some text on data broadcast descriptors, stream-type, or/and PSI entries would be a valuable addition. On thinking about this, I wonder if the text about this should go at the end of the Introduction (1.0) to the whole document, where people can see it clearly and then undesrtand that there may be something else needed for those networks that rely on PSI for remultiplexing! - Bernhard & others who understand PSI, can you work with Art to agree the exact wording please? Gorry Fairhurst (ipdvb WG Chair) Gorry Fairhurst wrote: > WG please read and respond to this message. > > The following message was received on January 22nd before WGLC, but was > dropped because the email source address was not verified by the list > server. > > The exact text of the message follows. > > best wishes, > > Gorry > (ipdvb WG Chair) > > ----- > 1) > Thanks for considering my previous input... > I note that the new draft has an editorial oversight in that it contains > two > definitions of PSI. I suggest the second should be deleted. > 2) > I previously made a comment about the ancillary requirements when adding a > TS logical channel to a TS multiplex and asserted there appeared to be > under > specification. Perhaps it was viewed as out of scope, or perhaps I simply > don't recognize the change that resulted. I can not find what stream_type > is required to be used for the ULE stream when a "TS Logical Channel" is > added to a multiplex. > > I suggest at least an informative note be added in Section 6 (after the > third line which says: "These are transmitted using a single TS Logical > Channel over a TS Multiplex.") The note should say "PSI entries to be > consistent with [ISO-MPEG] when constructing a conformant TS Multiplex and > means for Receivers to locate each such TS Logical Channel are outside the > scope of this recommendation." > > Reason: > Just inserting a "TS Logical Channel" without including a > TS_Program_map_section that lists the PID and a stream_type does not appear > to me to result in a strictly MPEG-2 conformant bit stream; and practically > could result in the PIDs being dropped by a remultiplexer. If the means > for binding the inserted element into a multiplex and subsequent discovery > is to be covered in another document, a pointer to that document would be > more helpful than this warning. It seems at least a warning is needed and > preferably a pointer to where this next level of TS construction is > defined. > > Art Allison > Director, Advanced Engineering > NAB Science & Technology > 1771 N St NW, Washington Dc 20036 > 202 429 5418 > > > From bnocker at cosy.sbg.ac.at Sun Feb 6 14:03:53 2005 From: bnocker at cosy.sbg.ac.at (Bernhard Collini-Nocker) Date: Sun, 06 Feb 2005 15:03:53 +0100 Subject: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto rs In-Reply-To: <08259490B3BC3140B549DD0907A5644811D638@admsrvnt10.enet.sharplabs.com> References: <08259490B3BC3140B549DD0907A5644811D638@admsrvnt10.enet.sharplabs.com> Message-ID: <420623C9.50005@cosy.sbg.ac.at> Thanks for the comments and critical words. I am trying to give you my views and results of some endless discussions with collegues in the networking and television world. Goldberg, Adam wrote: > I apologize for being "late to the party", but: > > I do not see a particular need to define new term "TS Logical Channel", and > indeed doing so creates risks of ill-specification (such as those Art points > out), as well as confusion heaped upon someone familiar with MPEG-2 > Transport (as typically used in entertainment delivery). Unfortunately the MPEG-2 standards do not provide a reasonable term for the purpose of networking. The question is whether other terms, for example "PID network" or "PID stream" would be better received and understood? The term "TS logical channel" tries to verbally visualize that the encapsulation uses a continouos stream of transport stream packets using one specific packet identifier to transport subnetwork data units. Maybe the term "TS (virtual) circuit" better names this? > Furthermore, the definition is quite wrong with respect to ATSC and DVB use > of "specific TS Logical Channels". To my knowledge, this internet-draft is > the only document anywhere which uses such terms. It is certainly true that > MPEG, DVB and ATSC define //elementary streams// identified by stream_type > values. I suspect this is what is meant by "TS Logical Channel", but it is > difficult for me to tell. I am not so sure, whether this analysis is correct. Elementary streams are those that are transported as Packetized ES, whereas "auxillary" data and signalling is transported as sections. Although a stream_type in the program map section is used to reference both PESs and sections the term elementary stream is used very vague and we tried to avoid using it in the same vague manner. According to, for example EN301192 v1.3.1, defines Data Piping as: " The data broadcast service shall insert the data to be broadcast directly in the payload of MPEG-2 TS packets." That raises the question, how to call a continouos stream of MPEG-2 TS packets with a certain PID? Further the standard details that: "The data broadcast service may use the payload_unit_start_indicator field and the transport_priority field of the MPEG-2 Transport Stream packets in a service private way. The use of the adaptation_field shall be MPEG-2 compliant." ULE uses PUSI and does not utilize the AF. "The delivery of the bits in time through a data pipe is service private and is not specified in the present document." It seems obvious that the use of the term "TS Data Pipe" would lead to the wrong conclusion that ULE equals Data Piping. But Data Piping is not detailed at all, whereas ULE tries to be. > (from the draft) > TS Logical Channel: Transport Stream Logical Channel. In this > document, this term identifies a channel at the MPEG-2 level [ISO- > MPEG]. It exists at level 2 of the ISO/OSI reference model. All > packets sent over a TS Logical Channel carry the same PID value > (this value is unique within a specific TS Multiplex). According to > MPEG-2, some TS Logical Channels are reserved for specific > signalling purposes. Other standards (e.g., ATSC, DVB) also reserve > specific TS Logical Channels. > > While I'm commenting on this definition, it also seems to me that "channel > at the MPEG-2 level" is either wrong or also ill-specified. What's a > channel? If you're talking about MPEG-2, it's certainly conceivable that > the reader may associate "channel" with "[television] channel" - which are > the subject of a large amount of ATSC and DVB systems. The term channel is indeed problematic in the context of television, however, network engineers might have a different understanding about what a channel is. According to ATIS a channel is "1. A connection between initiating and terminating nodes of a circuit. 2. A single path provided by a transmission medium via either (a) physical separation, such as by multipair cable or (b) electrical separation, such as by frequency- or time-division multiplexing. ..." > Additionally, it is also wrong or ill-specified to say "According to MPEG-2 > ... TS Logical Channels ...". There is no such concept defined or used > within MPEG (unless what you really mean is elementary stream, in which case > what do you need this extraneous term for anyhow?). Again, elementary stream is not exactly what is being meant: For example EN 300468 v1.5.1 defines: "component (ELEMENTARY Stream): one or more entities which together make up an event, e.g. video, audio, teletext" and says further: "The component descriptor identifies the type of component stream and may be used to provide a text description of the elementary stream" where: "component_type: This 8-bit field specifies the type of the video, audio or EBU-data component. The coding of this field is specified in table 26." Table 26 then lists all kinds of video, audio, and teletext formats, but unfortunately no networking formats. At other places this standard is as innovative/creative in naming: "event: grouping of elementary broadcast data streams with a defined start and end time belonging to a common service, e.g. first half of a football match, News Flash, first part of an entertainment show" What is a "elementary broadcast data streams"? Not by guessing but by definition? > In any case, Art is certainly correct that merely identifying a "TS Logical > Channel" as a sequence of packets identified with a common PID value without > identifying the PSI details is an invitation to multiplexers and > remultiplexers to drop those packets on the floor. Oh yes, this is the real problem of defining something outside television standardiszation bodies: one risks that ULE packets are being dropped. We have discussed basically two approaches: 1. define the PSI and get an ID, or tag, or "stream_type" for ULE, or 2. define ULE and let somebody else do the PSI work. We have had some reasons for choice 2. > If there remains an opportunity to repair what I believe to be errors in the > draft, I'm eager and willing to participate from a MPEG-2 entertainment > (which is to say, legacy use of MPEG-2 Transport) point of view. Of course the terms in the document should not conflict with meaning in another context. However, ambiguous terms in other documents should be avoided as well. > [Apologies for being strident at all, to say nothing of at such an > apparently late stage - if the above is perceived as such] > > Regards, > Adam Goldberg > Director, Television Standards & Policy Development > Sharp Laboratories of America > 8605 Westwood Center Drive, Suite 206 > Vienna, VA 22182 > +1-703-556-4406 > +1-703-556-4410 fax > +1-571-276-0305 cell > > > -----Original Message----- > From: owner-ipdvb at erg.abdn.ac.uk [mailto:owner-ipdvb at erg.abdn.ac.uk] On > Behalf Of Gorry Fairhurst > Sent: Friday, February 04, 2005 6:56 AM > To: ipdvb at erg.abdn.ac.uk; Bernhard Collini-Nocker > Cc: AAllison at nab.org > Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast Descriptors > > > 1) Done - point 1 was an edit mistake. > > 2) I think some text on data broadcast descriptors, stream-type, or/and PSI > entries would be a valuable addition. > > On thinking about this, I wonder if the text about this should go at the end > > of the Introduction (1.0) to the whole document, where people can see it > clearly and then undesrtand that there may be something else needed for > those > networks that rely on PSI for remultiplexing! > > - Bernhard & others who understand PSI, can you work with Art to agree the > exact wording please? > > Gorry Fairhurst > (ipdvb WG Chair) > > Gorry Fairhurst wrote: > > >>WG please read and respond to this message. >> >>The following message was received on January 22nd before WGLC, but was >>dropped because the email source address was not verified by the list >>server. >> >>The exact text of the message follows. >> >>best wishes, >> >>Gorry >>(ipdvb WG Chair) >> >>----- >> > > 1) > >>Thanks for considering my previous input... >>I note that the new draft has an editorial oversight in that it contains >>two definitions of PSI. I suggest the second should be deleted. >> > > 2) > >>I previously made a comment about the ancillary requirements when adding a >>TS logical channel to a TS multiplex and asserted there appeared to be >>under >>specification. Perhaps it was viewed as out of scope, or perhaps I simply >>don't recognize the change that resulted. I can not find what stream_type >>is required to be used for the ULE stream when a "TS Logical Channel" is >>added to a multiplex. The problem here is the same as above. Without "applying" for a "stream_type" for ULE there is no stream_type for ULE. In contrary why should one register a stream_type value for ULE earlier than ULE is standardized? >>I suggest at least an informative note be added in Section 6 (after the >>third line which says: "These are transmitted using a single TS Logical >>Channel over a TS Multiplex.") The note should say "PSI entries to be >>consistent with [ISO-MPEG] when constructing a conformant TS Multiplex and >>means for Receivers to locate each such TS Logical Channel are outside the >>scope of this recommendation." Thanks, this is a very helpful suggestion for potential readers. In addition the ipdvb-wg works on providing signalling other than PSI/SI. >>Reason: >>Just inserting a "TS Logical Channel" without including a >>TS_Program_map_section that lists the PID and a stream_type does not >> appear to me to result in a strictly MPEG-2 conformant bit stream; and >> practically >>could result in the PIDs being dropped by a remultiplexer. If the means >>for binding the inserted element into a multiplex and subsequent discovery >>is to be covered in another document, a pointer to that document would be >>more helpful than this warning. It seems at least a warning is needed and >>preferably a pointer to where this next level of TS construction is >>defined. From an architectural point of view it is a reasonable assupmption that whatever is being sent in a TS multiplex should be referenced. However, the reality is that "ghost" PIDs do occur in many services either accidentially or for well-defined reasons. What is the penalty for not being strictly MPEG-2 conformant/compliant? >>Art Allison >>Director, Advanced Engineering >>NAB Science & Technology >>1771 N St NW, Washington Dc 20036 >>202 429 5418 Regards, Bernhard Collini-Nocker From agoldberg at sharplabs.com Mon Feb 7 05:45:46 2005 From: agoldberg at sharplabs.com (Goldberg, Adam) Date: Sun, 6 Feb 2005 21:45:46 -0800 Subject: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto rs Message-ID: <08259490B3BC3140B549DD0907A5644811D664@admsrvnt10.enet.sharplabs.com> ARGH. I fat-fingered 'send' before completing the email. See below. Adam Goldberg Director, Television Standards & Policy Development Sharp Laboratories of America 8605 Westwood Center Drive, Suite 206 Vienna, VA 22182 +1-703-556-4406 +1-703-556-4410 fax +1-571-276-0305 cell > -----Original Message----- > From: Goldberg, Adam > Sent: Monday, February 07, 2005 12:42 AM > To: 'Bernhard Collini-Nocker'; Goldberg, Adam > Cc: ipdvb at erg.abdn.ac.uk; Allison, Art; Matthew Goldman > Subject: RE: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto > rs > > See below... > > Adam Goldberg > Director, Television Standards & Policy Development > Sharp Laboratories of America > 8605 Westwood Center Drive, Suite 206 > Vienna, VA 22182 > +1-703-556-4406 > +1-703-556-4410 fax > +1-571-276-0305 cell > > > Bernhard Collini-Nocker wrote: > > > > Goldberg, Adam wrote: > > > I apologize for being "late to the party", but: > > > > > > I do not see a particular need to define new term "TS Logical Channel", > > and > > > indeed doing so creates risks of ill-specification (such as those Art > > points > > > out), as well as confusion heaped upon someone familiar with MPEG-2 > > > Transport (as typically used in entertainment delivery). > > > > Unfortunately the MPEG-2 standards do not provide a reasonable term for > > the purpose of networking. The question is whether other terms, for > > example "PID network" or "PID stream" would be better received and > > understood? > > The term "TS logical channel" tries to verbally visualize that the > > encapsulation uses a continouos stream of transport stream packets using > > one specific packet identifier to transport subnetwork data units. Maybe > > the term "TS (virtual) circuit" better names this? > > It is perhaps not well defined in 13818-1, but the term of art is > "streams". Many people use "PID stream" which is a poor combination of > words. I'd have no objection to defining a "SNDU Stream" as something > like "a sequence of MPEG-2 Transport Stream packets identified by a common > PID value" (or some such). > > Perhaps discussing 'virtual circuits' relative to a Transport Stream is > begging for confusion. Use of any such words ("TS (virtual) circuit") > needs careful definition, likely requiring the above SNDU Stream > definition plus an explanation of what it means for multiple SNDU Streams > to exist in a single Transport Stream. > > > > Furthermore, the definition is quite wrong with respect to ATSC and > DVB > > use > > > of "specific TS Logical Channels". To my knowledge, this internet- > draft > > is > > > the only document anywhere which uses such terms. It is certainly > true > > that > > > MPEG, DVB and ATSC define //elementary streams// identified by > > stream_type > > > values. I suspect this is what is meant by "TS Logical Channel", but > it > > is > > > difficult for me to tell. > > > > I am not so sure, whether this analysis is correct. Elementary streams > > are those that are transported as Packetized ES, whereas "auxillary" > > data and signalling is transported as sections. Although a stream_type > > in the program map section is used to reference both PESs and sections > > the term elementary stream is used very vague and we tried to avoid > > using it in the same vague manner. > > Perhaps I overstepped with "elementary stream". > > Consider the 13818-1 definition of "Packetized Elementary Stream": "A > continuous sequence of PES packets of one elementary stream with one > stream ID may be used to construct a PES Stream." (ISO/IEC 13818-1:2000 p. > xiii) > > Stuff carried as payload of Transport Stream packets are merely 'payload'. > What the draft starts to define is a new type of payload stream (that is, > a new way to carry data in a transport stream). The definition is not > compete. > > > According to, for example EN301192 v1.3.1, defines Data Piping as: > > " The data broadcast service shall insert the data to be broadcast > > directly in the payload of MPEG-2 TS packets." > > That raises the question, how to call a continouos stream of MPEG-2 TS > > packets with a certain PID? > > > > Further the standard details that: > > "The data broadcast service may use the payload_unit_start_indicator > > field and the transport_priority field of the MPEG-2 Transport Stream > > packets in a service private way. The use of the adaptation_field shall > > be MPEG-2 compliant." > > ULE uses PUSI and does not utilize the AF. > > > > "The delivery of the bits in time through a data pipe is service private > > and is not specified in the present document." > > It seems obvious that the use of the term "TS Data Pipe" would lead to > > the wrong conclusion that ULE equals Data Piping. But Data Piping is not > > detailed at all, whereas ULE tries to be. > > I'm not going to argue that DVB's specification is complete. I will argue > that ULE isn't complete. > > > > (from the draft) > > > TS Logical Channel: Transport Stream Logical Channel. In this > > > document, this term identifies a channel at the MPEG-2 level [ISO- > > > MPEG]. It exists at level 2 of the ISO/OSI reference model. All > > > packets sent over a TS Logical Channel carry the same PID value > > > (this value is unique within a specific TS Multiplex). According to > > > MPEG-2, some TS Logical Channels are reserved for specific > > > signalling purposes. Other standards (e.g., ATSC, DVB) also reserve > > > specific TS Logical Channels. > > > > > > While I'm commenting on this definition, it also seems to me that > > "channel > > > at the MPEG-2 level" is either wrong or also ill-specified. What's a > > > channel? If you're talking about MPEG-2, it's certainly conceivable > > that > > > the reader may associate "channel" with "[television] channel" - which > > are > > > the subject of a large amount of ATSC and DVB systems. > > > > The term channel is indeed problematic in the context of television, > > however, network engineers might have a different understanding about > > what a channel is. > > According to ATIS a channel is "1. A connection between initiating and > > terminating nodes of a circuit. 2. A single path provided by a > > transmission medium via either (a) physical separation, such as by > > multipair cable or (b) electrical separation, such as by frequency- or > > time-division multiplexing. ..." > > I understand that 'channel' vis-?-vis networking has a different meaning > than 'channel' vis-?-vis television. This was my point actually, that > those familiar with MPEG transport should not be assumed to be networking- > types (even when speaking with respect to ULE). > > > > Additionally, it is also wrong or ill-specified to say "According to > > MPEG-2 > > > ... TS Logical Channels ...". There is no such concept defined or > used > > > within MPEG (unless what you really mean is elementary stream, in > which > > case > > > what do you need this extraneous term for anyhow?). > > > > Again, elementary stream is not exactly what is being meant: > > For example EN 300468 v1.5.1 defines: > > "component (ELEMENTARY Stream): one or more entities which together make > > up an event, e.g. video, audio, teletext" > > > > and says further: > > "The component descriptor identifies the type of component stream and > > may be used to provide a text description of the elementary stream" > > > > where: > > "component_type: This 8-bit field specifies the type of the video, audio > > or EBU-data component. The coding of this field is specified in table > 26." > > Table 26 then lists all kinds of video, audio, and teletext formats, but > > unfortunately no networking formats. > > > > At other places this standard is as innovative/creative in naming: > > "event: grouping of elementary broadcast data streams with a defined > > start and end time belonging to a common service, e.g. first half of a > > football match, News Flash, first part of an entertainment show" > > What is a "elementary broadcast data streams"? Not by guessing but by > > definition? > > > > > In any case, Art is certainly correct that merely identifying a "TS > > Logical > > > Channel" as a sequence of packets identified with a common PID value > > without > > > identifying the PSI details is an invitation to multiplexers and > > > remultiplexers to drop those packets on the floor. > > > > Oh yes, this is the real problem of defining something outside > > television standardiszation bodies: one risks that ULE packets are being > > dropped. > > We have discussed basically two approaches: > > 1. define the PSI and get an ID, or tag, or "stream_type" for ULE, or 2. > > define ULE and let somebody else do the PSI work. > > We have had some reasons for choice 2. > > This is a very easy thing to fix and something which should be done. > Without defining a stream_type for ULE data, it is neither possible to > construct a transport stream compliant with MPEG-2 nor one that > interoperates with other ULE equipment. > > ATSC maintains a 'codepoint registry', and would be happy to allocate a > stream_type value for ULE data upon request from IETF. Furthermore, the > text to specify usage of the stream_type would be reasonably easy (and > perhaps ties in to my suggested "SNDU Stream" definition (that is, define > it as SNDU Stream: a sequence of MPEG-2 Transport Stream packets identified by a common PID value of stream_type <0xnn>. All that then remains, I think, would be to signal when a Program carries SNDU Stream(s), and what it means when there are more than one SNDU Stream per program, or more than one Program that carries one or more SNDU Streams. > > > If there remains an opportunity to repair what I believe to be errors > in > > the > > > draft, I'm eager and willing to participate from a MPEG-2 > entertainment > > > (which is to say, legacy use of MPEG-2 Transport) point of view. > > > > Of course the terms in the document should not conflict with meaning in > > another context. However, ambiguous terms in other documents should be > > avoided as well. > > > > > [Apologies for being strident at all, to say nothing of at such an > > > apparently late stage - if the above is perceived as such] > > > > > > Regards, > > > Adam Goldberg > > > Director, Television Standards & Policy Development > > > Sharp Laboratories of America > > > 8605 Westwood Center Drive, Suite 206 > > > Vienna, VA 22182 > > > +1-703-556-4406 > > > +1-703-556-4410 fax > > > +1-571-276-0305 cell > > > > > > > > > -----Original Message----- > > > From: owner-ipdvb at erg.abdn.ac.uk [mailto:owner-ipdvb at erg.abdn.ac.uk] > On > > > Behalf Of Gorry Fairhurst > > > Sent: Friday, February 04, 2005 6:56 AM > > > To: ipdvb at erg.abdn.ac.uk; Bernhard Collini-Nocker > > > Cc: AAllison at nab.org > > > Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast > > Descriptors > > > > > > > > > 1) Done - point 1 was an edit mistake. > > > > > > 2) I think some text on data broadcast descriptors, stream-type, > or/and > > PSI > > > entries would be a valuable addition. > > > > > > On thinking about this, I wonder if the text about this should go at > the > > end > > > > > > of the Introduction (1.0) to the whole document, where people can see > it > > > clearly and then undesrtand that there may be something else needed > for > > > those > > > networks that rely on PSI for remultiplexing! > > > > > > - Bernhard & others who understand PSI, can you work with Art to agree > > the > > > exact wording please? > > > > > > Gorry Fairhurst > > > (ipdvb WG Chair) > > > > > > Gorry Fairhurst wrote: > > > > > > > > >>WG please read and respond to this message. > > >> > > >>The following message was received on January 22nd before WGLC, but > was > > >>dropped because the email source address was not verified by the list > > >>server. > > >> > > >>The exact text of the message follows. > > >> > > >>best wishes, > > >> > > >>Gorry > > >>(ipdvb WG Chair) > > >> > > >>----- > > >> > > > > > > 1) > > > > > >>Thanks for considering my previous input... > > >>I note that the new draft has an editorial oversight in that it > contains > > >>two definitions of PSI. I suggest the second should be deleted. > > >> > > > > > > 2) > > > > > >>I previously made a comment about the ancillary requirements when > adding > > a > > >>TS logical channel to a TS multiplex and asserted there appeared to be > > >>under > > >>specification. Perhaps it was viewed as out of scope, or perhaps I > > simply > > >>don't recognize the change that resulted. I can not find what > > stream_type > > >>is required to be used for the ULE stream when a "TS Logical Channel" > is > > >>added to a multiplex. > > > > The problem here is the same as above. Without "applying" for a > > "stream_type" for ULE there is no stream_type for ULE. In contrary why > > should one register a stream_type value for ULE earlier than ULE is > > standardized? > > > > >>I suggest at least an informative note be added in Section 6 (after > the > > >>third line which says: "These are transmitted using a single TS > Logical > > >>Channel over a TS Multiplex.") The note should say "PSI entries to be > > >>consistent with [ISO-MPEG] when constructing a conformant TS Multiplex > > and > > >>means for Receivers to locate each such TS Logical Channel are outside > > the > > >>scope of this recommendation." > > > > Thanks, this is a very helpful suggestion for potential readers. In > > addition the ipdvb-wg works on providing signalling other than PSI/SI. > > > > >>Reason: > > >>Just inserting a "TS Logical Channel" without including a > > >>TS_Program_map_section that lists the PID and a stream_type does not > > >> appear to me to result in a strictly MPEG-2 conformant bit stream; > and > > >> practically > > >>could result in the PIDs being dropped by a remultiplexer. If the > > means > > >>for binding the inserted element into a multiplex and subsequent > > discovery > > >>is to be covered in another document, a pointer to that document would > > be > > >>more helpful than this warning. It seems at least a warning is needed > > and > > >>preferably a pointer to where this next level of TS construction is > > >>defined. > > > > From an architectural point of view it is a reasonable assupmption that > > whatever is being sent in a TS multiplex should be referenced. However, > > the reality is that "ghost" PIDs do occur in many services either > > accidentially or for well-defined reasons. > > > > What is the penalty for not being strictly MPEG-2 conformant/compliant? > > > > >>Art Allison > > >>Director, Advanced Engineering > > >>NAB Science & Technology > > >>1771 N St NW, Washington Dc 20036 > > >>202 429 5418 > > > > > > Regards, > > Bernhard Collini-Nocker > > > > From agoldberg at sharplabs.com Mon Feb 7 05:41:35 2005 From: agoldberg at sharplabs.com (Goldberg, Adam) Date: Sun, 6 Feb 2005 21:41:35 -0800 Subject: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto rs Message-ID: <08259490B3BC3140B549DD0907A5644811D663@admsrvnt10.enet.sharplabs.com> See below... Adam Goldberg Director, Television Standards & Policy Development Sharp Laboratories of America 8605 Westwood Center Drive, Suite 206 Vienna, VA 22182 +1-703-556-4406 +1-703-556-4410 fax +1-571-276-0305 cell Bernhard Collini-Nocker wrote: > > Goldberg, Adam wrote: > > I apologize for being "late to the party", but: > > > > I do not see a particular need to define new term "TS Logical Channel", > and > > indeed doing so creates risks of ill-specification (such as those Art > points > > out), as well as confusion heaped upon someone familiar with MPEG-2 > > Transport (as typically used in entertainment delivery). > > Unfortunately the MPEG-2 standards do not provide a reasonable term for > the purpose of networking. The question is whether other terms, for > example "PID network" or "PID stream" would be better received and > understood? > The term "TS logical channel" tries to verbally visualize that the > encapsulation uses a continouos stream of transport stream packets using > one specific packet identifier to transport subnetwork data units. Maybe > the term "TS (virtual) circuit" better names this? It is perhaps not well defined in 13818-1, but the term of art is "streams". Many people use "PID stream" which is a poor combination of words. I'd have no objection to defining a "SNDU Stream" as something like "a sequence of MPEG-2 Transport Stream packets identified by a common PID value" (or some such). Perhaps discussing 'virtual circuits' relative to a Transport Stream is begging for confusion. Use of any such words ("TS (virtual) circuit") needs careful definition, likely requiring the above SNDU Stream definition plus an explanation of what it means for multiple SNDU Streams to exist in a single Transport Stream. > > Furthermore, the definition is quite wrong with respect to ATSC and DVB > use > > of "specific TS Logical Channels". To my knowledge, this internet-draft > is > > the only document anywhere which uses such terms. It is certainly true > that > > MPEG, DVB and ATSC define //elementary streams// identified by > stream_type > > values. I suspect this is what is meant by "TS Logical Channel", but it > is > > difficult for me to tell. > > I am not so sure, whether this analysis is correct. Elementary streams > are those that are transported as Packetized ES, whereas "auxillary" > data and signalling is transported as sections. Although a stream_type > in the program map section is used to reference both PESs and sections > the term elementary stream is used very vague and we tried to avoid > using it in the same vague manner. Perhaps I overstepped with "elementary stream". Consider the 13818-1 definition of "Packetized Elementary Stream": "A continuous sequence of PES packets of one elementary stream with one stream ID may be used to construct a PES Stream." (ISO/IEC 13818-1:2000 p. xiii) Stuff carried as payload of Transport Stream packets are merely 'payload'. What the draft starts to define is a new type of payload stream (that is, a new way to carry data in a transport stream). The definition is not compete. > According to, for example EN301192 v1.3.1, defines Data Piping as: > " The data broadcast service shall insert the data to be broadcast > directly in the payload of MPEG-2 TS packets." > That raises the question, how to call a continouos stream of MPEG-2 TS > packets with a certain PID? > > Further the standard details that: > "The data broadcast service may use the payload_unit_start_indicator > field and the transport_priority field of the MPEG-2 Transport Stream > packets in a service private way. The use of the adaptation_field shall > be MPEG-2 compliant." > ULE uses PUSI and does not utilize the AF. > > "The delivery of the bits in time through a data pipe is service private > and is not specified in the present document." > It seems obvious that the use of the term "TS Data Pipe" would lead to > the wrong conclusion that ULE equals Data Piping. But Data Piping is not > detailed at all, whereas ULE tries to be. I'm not going to argue that DVB's specification is complete. I will argue that ULE isn't complete. > > (from the draft) > > TS Logical Channel: Transport Stream Logical Channel. In this > > document, this term identifies a channel at the MPEG-2 level [ISO- > > MPEG]. It exists at level 2 of the ISO/OSI reference model. All > > packets sent over a TS Logical Channel carry the same PID value > > (this value is unique within a specific TS Multiplex). According to > > MPEG-2, some TS Logical Channels are reserved for specific > > signalling purposes. Other standards (e.g., ATSC, DVB) also reserve > > specific TS Logical Channels. > > > > While I'm commenting on this definition, it also seems to me that > "channel > > at the MPEG-2 level" is either wrong or also ill-specified. What's a > > channel? If you're talking about MPEG-2, it's certainly conceivable > that > > the reader may associate "channel" with "[television] channel" - which > are > > the subject of a large amount of ATSC and DVB systems. > > The term channel is indeed problematic in the context of television, > however, network engineers might have a different understanding about > what a channel is. > According to ATIS a channel is "1. A connection between initiating and > terminating nodes of a circuit. 2. A single path provided by a > transmission medium via either (a) physical separation, such as by > multipair cable or (b) electrical separation, such as by frequency- or > time-division multiplexing. ..." I understand that 'channel' vis-?-vis networking has a different meaning than 'channel' vis-?-vis television. This was my point actually, that those familiar with MPEG transport should not be assumed to be networking-types (even when speaking with respect to ULE). > > Additionally, it is also wrong or ill-specified to say "According to > MPEG-2 > > ... TS Logical Channels ...". There is no such concept defined or used > > within MPEG (unless what you really mean is elementary stream, in which > case > > what do you need this extraneous term for anyhow?). > > Again, elementary stream is not exactly what is being meant: > For example EN 300468 v1.5.1 defines: > "component (ELEMENTARY Stream): one or more entities which together make > up an event, e.g. video, audio, teletext" > > and says further: > "The component descriptor identifies the type of component stream and > may be used to provide a text description of the elementary stream" > > where: > "component_type: This 8-bit field specifies the type of the video, audio > or EBU-data component. The coding of this field is specified in table 26." > Table 26 then lists all kinds of video, audio, and teletext formats, but > unfortunately no networking formats. > > At other places this standard is as innovative/creative in naming: > "event: grouping of elementary broadcast data streams with a defined > start and end time belonging to a common service, e.g. first half of a > football match, News Flash, first part of an entertainment show" > What is a "elementary broadcast data streams"? Not by guessing but by > definition? > > > In any case, Art is certainly correct that merely identifying a "TS > Logical > > Channel" as a sequence of packets identified with a common PID value > without > > identifying the PSI details is an invitation to multiplexers and > > remultiplexers to drop those packets on the floor. > > Oh yes, this is the real problem of defining something outside > television standardiszation bodies: one risks that ULE packets are being > dropped. > We have discussed basically two approaches: > 1. define the PSI and get an ID, or tag, or "stream_type" for ULE, or 2. > define ULE and let somebody else do the PSI work. > We have had some reasons for choice 2. This is a very easy thing to fix and something which should be done. Without defining a stream_type for ULE data, it is neither possible to construct a transport stream compliant with MPEG-2 nor one that interoperates with other ULE equipment. ATSC maintains a 'codepoint registry', and would be happy to allocate a stream_type value for ULE data upon request from IETF. Furthermore, the text to specify usage of the stream_type would be reasonably easy (and perhaps ties in to my suggested "SNDU Stream" definition (that is, define it as > > If there remains an opportunity to repair what I believe to be errors in > the > > draft, I'm eager and willing to participate from a MPEG-2 entertainment > > (which is to say, legacy use of MPEG-2 Transport) point of view. > > Of course the terms in the document should not conflict with meaning in > another context. However, ambiguous terms in other documents should be > avoided as well. > > > [Apologies for being strident at all, to say nothing of at such an > > apparently late stage - if the above is perceived as such] > > > > Regards, > > Adam Goldberg > > Director, Television Standards & Policy Development > > Sharp Laboratories of America > > 8605 Westwood Center Drive, Suite 206 > > Vienna, VA 22182 > > +1-703-556-4406 > > +1-703-556-4410 fax > > +1-571-276-0305 cell > > > > > > -----Original Message----- > > From: owner-ipdvb at erg.abdn.ac.uk [mailto:owner-ipdvb at erg.abdn.ac.uk] On > > Behalf Of Gorry Fairhurst > > Sent: Friday, February 04, 2005 6:56 AM > > To: ipdvb at erg.abdn.ac.uk; Bernhard Collini-Nocker > > Cc: AAllison at nab.org > > Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast > Descriptors > > > > > > 1) Done - point 1 was an edit mistake. > > > > 2) I think some text on data broadcast descriptors, stream-type, or/and > PSI > > entries would be a valuable addition. > > > > On thinking about this, I wonder if the text about this should go at the > end > > > > of the Introduction (1.0) to the whole document, where people can see it > > clearly and then undesrtand that there may be something else needed for > > those > > networks that rely on PSI for remultiplexing! > > > > - Bernhard & others who understand PSI, can you work with Art to agree > the > > exact wording please? > > > > Gorry Fairhurst > > (ipdvb WG Chair) > > > > Gorry Fairhurst wrote: > > > > > >>WG please read and respond to this message. > >> > >>The following message was received on January 22nd before WGLC, but was > >>dropped because the email source address was not verified by the list > >>server. > >> > >>The exact text of the message follows. > >> > >>best wishes, > >> > >>Gorry > >>(ipdvb WG Chair) > >> > >>----- > >> > > > > 1) > > > >>Thanks for considering my previous input... > >>I note that the new draft has an editorial oversight in that it contains > >>two definitions of PSI. I suggest the second should be deleted. > >> > > > > 2) > > > >>I previously made a comment about the ancillary requirements when adding > a > >>TS logical channel to a TS multiplex and asserted there appeared to be > >>under > >>specification. Perhaps it was viewed as out of scope, or perhaps I > simply > >>don't recognize the change that resulted. I can not find what > stream_type > >>is required to be used for the ULE stream when a "TS Logical Channel" is > >>added to a multiplex. > > The problem here is the same as above. Without "applying" for a > "stream_type" for ULE there is no stream_type for ULE. In contrary why > should one register a stream_type value for ULE earlier than ULE is > standardized? > > >>I suggest at least an informative note be added in Section 6 (after the > >>third line which says: "These are transmitted using a single TS Logical > >>Channel over a TS Multiplex.") The note should say "PSI entries to be > >>consistent with [ISO-MPEG] when constructing a conformant TS Multiplex > and > >>means for Receivers to locate each such TS Logical Channel are outside > the > >>scope of this recommendation." > > Thanks, this is a very helpful suggestion for potential readers. In > addition the ipdvb-wg works on providing signalling other than PSI/SI. > > >>Reason: > >>Just inserting a "TS Logical Channel" without including a > >>TS_Program_map_section that lists the PID and a stream_type does not > >> appear to me to result in a strictly MPEG-2 conformant bit stream; and > >> practically > >>could result in the PIDs being dropped by a remultiplexer. If the > means > >>for binding the inserted element into a multiplex and subsequent > discovery > >>is to be covered in another document, a pointer to that document would > be > >>more helpful than this warning. It seems at least a warning is needed > and > >>preferably a pointer to where this next level of TS construction is > >>defined. > > From an architectural point of view it is a reasonable assupmption that > whatever is being sent in a TS multiplex should be referenced. However, > the reality is that "ghost" PIDs do occur in many services either > accidentially or for well-defined reasons. > > What is the penalty for not being strictly MPEG-2 conformant/compliant? > > >>Art Allison > >>Director, Advanced Engineering > >>NAB Science & Technology > >>1771 N St NW, Washington Dc 20036 > >>202 429 5418 > > > Regards, > Bernhard Collini-Nocker > > From bnocker at cosy.sbg.ac.at Mon Feb 7 12:48:43 2005 From: bnocker at cosy.sbg.ac.at (Bernhard Collini-Nocker) Date: Mon, 07 Feb 2005 13:48:43 +0100 Subject: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto rs In-Reply-To: <08259490B3BC3140B549DD0907A5644811D664@admsrvnt10.enet.sharplabs.com> References: <08259490B3BC3140B549DD0907A5644811D664@admsrvnt10.enet.sharplabs.com> Message-ID: <420763AB.50107@cosy.sbg.ac.at> Hello, let me try to summarize the two major points being raised and what the discussion is about: 1. the name/definition of "TS Logical Channel" is not well received and the name/definition of a "SNDU stream" is proposed instead 2. it is proposed to consider MPEG-2 conformance in specifying that ULE requires a specific stream_type value for the PMT Personally I have no objection against 1., because it is easy to change and improves wording and naming (unless somebody has an even better name for it). For 2. my concern is that mentioning stream_type may require some additional wording about PSI/SI in general, which is likely out of scope of the ULE draft. Even worse, in introducing a "world" besides the encapsulation/decapsulation of ULE, this may result in further confusion about what the MPEG-2/Section layer does in addition to and/or in comparison to ULE/IP. Actually some difficult question may arise from this direction, for example whether it is a wishful requirement for ULE to support PAT/PMT/NIT/INT/... table parsing? Any opinions, recommendations or suggestions about this? Regards, Bernhard Goldberg, Adam wrote: > ARGH. I fat-fingered 'send' before completing the email. See below. > > Adam Goldberg > Director, Television Standards & Policy Development > Sharp Laboratories of America > 8605 Westwood Center Drive, Suite 206 > Vienna, VA 22182 > +1-703-556-4406 > +1-703-556-4410 fax > +1-571-276-0305 cell > > > >>-----Original Message----- >>From: Goldberg, Adam >>Sent: Monday, February 07, 2005 12:42 AM >>To: 'Bernhard Collini-Nocker'; Goldberg, Adam >>Cc: ipdvb at erg.abdn.ac.uk; Allison, Art; Matthew Goldman >>Subject: RE: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto >>rs >> >>See below... >> >>Adam Goldberg >>Director, Television Standards & Policy Development >>Sharp Laboratories of America >>8605 Westwood Center Drive, Suite 206 >>Vienna, VA 22182 >>+1-703-556-4406 >>+1-703-556-4410 fax >>+1-571-276-0305 cell >> >> >>Bernhard Collini-Nocker wrote: >> >>>Goldberg, Adam wrote: >>> >>>>I apologize for being "late to the party", but: >>>> >>>>I do not see a particular need to define new term "TS Logical > > Channel", > >>>and >>> >>>>indeed doing so creates risks of ill-specification (such as those Art >>> >>>points >>> >>>>out), as well as confusion heaped upon someone familiar with MPEG-2 >>>>Transport (as typically used in entertainment delivery). >>> >>>Unfortunately the MPEG-2 standards do not provide a reasonable term for >>>the purpose of networking. The question is whether other terms, for >>>example "PID network" or "PID stream" would be better received and >>>understood? >>>The term "TS logical channel" tries to verbally visualize that the >>>encapsulation uses a continouos stream of transport stream packets using >>>one specific packet identifier to transport subnetwork data units. Maybe >>>the term "TS (virtual) circuit" better names this? >> >>It is perhaps not well defined in 13818-1, but the term of art is >>"streams". Many people use "PID stream" which is a poor combination of >>words. I'd have no objection to defining a "SNDU Stream" as something >>like "a sequence of MPEG-2 Transport Stream packets identified by a common >>PID value" (or some such). >> >>Perhaps discussing 'virtual circuits' relative to a Transport Stream is >>begging for confusion. Use of any such words ("TS (virtual) circuit") >>needs careful definition, likely requiring the above SNDU Stream >>definition plus an explanation of what it means for multiple SNDU Streams >>to exist in a single Transport Stream. >> >> >>>>Furthermore, the definition is quite wrong with respect to ATSC and >> >>DVB >> >>>use >>> >>>>of "specific TS Logical Channels". To my knowledge, this internet- >> >>draft >> >>>is >>> >>>>the only document anywhere which uses such terms. It is certainly >> >>true >> >>>that >>> >>>>MPEG, DVB and ATSC define //elementary streams// identified by >>> >>>stream_type >>> >>>>values. I suspect this is what is meant by "TS Logical Channel", but >> >>it >> >>>is >>> >>>>difficult for me to tell. >>> >>>I am not so sure, whether this analysis is correct. Elementary streams >>>are those that are transported as Packetized ES, whereas "auxillary" >>>data and signalling is transported as sections. Although a stream_type >>>in the program map section is used to reference both PESs and sections >>>the term elementary stream is used very vague and we tried to avoid >>>using it in the same vague manner. >> >>Perhaps I overstepped with "elementary stream". >> >>Consider the 13818-1 definition of "Packetized Elementary Stream": "A >>continuous sequence of PES packets of one elementary stream with one >>stream ID may be used to construct a PES Stream." (ISO/IEC 13818-1:2000 p. >>xiii) >> >>Stuff carried as payload of Transport Stream packets are merely 'payload'. >>What the draft starts to define is a new type of payload stream (that is, >>a new way to carry data in a transport stream). The definition is not >>compete. >> >> >>>According to, for example EN301192 v1.3.1, defines Data Piping as: >>>" The data broadcast service shall insert the data to be broadcast >>>directly in the payload of MPEG-2 TS packets." >>>That raises the question, how to call a continouos stream of MPEG-2 TS >>>packets with a certain PID? >>> >>>Further the standard details that: >>>"The data broadcast service may use the payload_unit_start_indicator >>>field and the transport_priority field of the MPEG-2 Transport Stream >>>packets in a service private way. The use of the adaptation_field shall >>>be MPEG-2 compliant." >>>ULE uses PUSI and does not utilize the AF. >>> >>>"The delivery of the bits in time through a data pipe is service private >>>and is not specified in the present document." >>>It seems obvious that the use of the term "TS Data Pipe" would lead to >>>the wrong conclusion that ULE equals Data Piping. But Data Piping is not >>>detailed at all, whereas ULE tries to be. >> >>I'm not going to argue that DVB's specification is complete. I will argue >>that ULE isn't complete. >> >> >>>>(from the draft) >>>> TS Logical Channel: Transport Stream Logical Channel. In this >>>> document, this term identifies a channel at the MPEG-2 level [ISO- >>>> MPEG]. It exists at level 2 of the ISO/OSI reference model. All >>>> packets sent over a TS Logical Channel carry the same PID value >>>> (this value is unique within a specific TS Multiplex). According to >>>> MPEG-2, some TS Logical Channels are reserved for specific >>>> signalling purposes. Other standards (e.g., ATSC, DVB) also reserve >>>> specific TS Logical Channels. >>>> >>>>While I'm commenting on this definition, it also seems to me that >>> >>>"channel >>> >>>>at the MPEG-2 level" is either wrong or also ill-specified. What's a >>>>channel? If you're talking about MPEG-2, it's certainly conceivable >>> >>>that >>> >>>>the reader may associate "channel" with "[television] channel" - which >>> >>>are >>> >>>>the subject of a large amount of ATSC and DVB systems. >>> >>>The term channel is indeed problematic in the context of television, >>>however, network engineers might have a different understanding about >>>what a channel is. >>>According to ATIS a channel is "1. A connection between initiating and >>>terminating nodes of a circuit. 2. A single path provided by a >>>transmission medium via either (a) physical separation, such as by >>>multipair cable or (b) electrical separation, such as by frequency- or >>>time-division multiplexing. ..." >> >>I understand that 'channel' vis-?-vis networking has a different meaning >>than 'channel' vis-?-vis television. This was my point actually, that >>those familiar with MPEG transport should not be assumed to be networking- >>types (even when speaking with respect to ULE). >> >> >>>>Additionally, it is also wrong or ill-specified to say "According to >>> >>>MPEG-2 >>> >>>>... TS Logical Channels ...". There is no such concept defined or >> >>used >> >>>>within MPEG (unless what you really mean is elementary stream, in >> >>which >> >>>case >>> >>>>what do you need this extraneous term for anyhow?). >>> >>>Again, elementary stream is not exactly what is being meant: >>>For example EN 300468 v1.5.1 defines: >>>"component (ELEMENTARY Stream): one or more entities which together make >>>up an event, e.g. video, audio, teletext" >>> >>>and says further: >>>"The component descriptor identifies the type of component stream and >>>may be used to provide a text description of the elementary stream" >>> >>>where: >>>"component_type: This 8-bit field specifies the type of the video, audio >>>or EBU-data component. The coding of this field is specified in table >> >>26." >> >>>Table 26 then lists all kinds of video, audio, and teletext formats, but >>>unfortunately no networking formats. >>> >>>At other places this standard is as innovative/creative in naming: >>>"event: grouping of elementary broadcast data streams with a defined >>>start and end time belonging to a common service, e.g. first half of a >>>football match, News Flash, first part of an entertainment show" >>>What is a "elementary broadcast data streams"? Not by guessing but by >>>definition? >>> >>> >>>>In any case, Art is certainly correct that merely identifying a "TS >>> >>>Logical >>> >>>>Channel" as a sequence of packets identified with a common PID value >>> >>>without >>> >>>>identifying the PSI details is an invitation to multiplexers and >>>>remultiplexers to drop those packets on the floor. >>> >>>Oh yes, this is the real problem of defining something outside >>>television standardiszation bodies: one risks that ULE packets are being >>>dropped. >>>We have discussed basically two approaches: >>>1. define the PSI and get an ID, or tag, or "stream_type" for ULE, or 2. >>>define ULE and let somebody else do the PSI work. >>>We have had some reasons for choice 2. >> >>This is a very easy thing to fix and something which should be done. >>Without defining a stream_type for ULE data, it is neither possible to >>construct a transport stream compliant with MPEG-2 nor one that >>interoperates with other ULE equipment. >> >>ATSC maintains a 'codepoint registry', and would be happy to allocate a >>stream_type value for ULE data upon request from IETF. Furthermore, the >>text to specify usage of the stream_type would be reasonably easy (and >>perhaps ties in to my suggested "SNDU Stream" definition (that is, define >>it as > > > SNDU Stream: a sequence of MPEG-2 Transport Stream packets identified by a > common PID value of stream_type <0xnn>. > > All that then remains, I think, would be to signal when a Program carries > SNDU Stream(s), and what it means when there are more than one SNDU Stream > per program, or more than one Program that carries one or more SNDU Streams. > > >>>>If there remains an opportunity to repair what I believe to be errors >> >>in >> >>>the >>> >>>>draft, I'm eager and willing to participate from a MPEG-2 >> >>entertainment >> >>>>(which is to say, legacy use of MPEG-2 Transport) point of view. >>> >>>Of course the terms in the document should not conflict with meaning in >>>another context. However, ambiguous terms in other documents should be >>>avoided as well. >>> >>> >>>>[Apologies for being strident at all, to say nothing of at such an >>>>apparently late stage - if the above is perceived as such] >>>> >>>>Regards, >>>>Adam Goldberg >>>>Director, Television Standards & Policy Development >>>>Sharp Laboratories of America >>>>8605 Westwood Center Drive, Suite 206 >>>>Vienna, VA 22182 >>>>+1-703-556-4406 >>>>+1-703-556-4410 fax >>>>+1-571-276-0305 cell >>>> >>>> >>>>-----Original Message----- >>>>From: owner-ipdvb at erg.abdn.ac.uk [mailto:owner-ipdvb at erg.abdn.ac.uk] >> >>On >> >>>>Behalf Of Gorry Fairhurst >>>>Sent: Friday, February 04, 2005 6:56 AM >>>>To: ipdvb at erg.abdn.ac.uk; Bernhard Collini-Nocker >>>>Cc: AAllison at nab.org >>>>Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast >>> >>>Descriptors >>> >>>> >>>>1) Done - point 1 was an edit mistake. >>>> >>>>2) I think some text on data broadcast descriptors, stream-type, >> >>or/and >> >>>PSI >>> >>>>entries would be a valuable addition. >>>> >>>>On thinking about this, I wonder if the text about this should go at >> >>the >> >>>end >>> >>>>of the Introduction (1.0) to the whole document, where people can see >> >>it >> >>>>clearly and then undesrtand that there may be something else needed >> >>for >> >>>>those >>>>networks that rely on PSI for remultiplexing! >>>> >>>>- Bernhard & others who understand PSI, can you work with Art to agree >>> >>>the >>> >>>>exact wording please? >>>> >>>>Gorry Fairhurst >>>>(ipdvb WG Chair) >>>> >>>>Gorry Fairhurst wrote: >>>> >>>> >>>> >>>>>WG please read and respond to this message. >>>>> >>>>>The following message was received on January 22nd before WGLC, but >> >>was >> >>>>>dropped because the email source address was not verified by the list >>>>>server. >>>>> >>>>>The exact text of the message follows. >>>>> >>>>>best wishes, >>>>> >>>>>Gorry >>>>>(ipdvb WG Chair) >>>>> >>>>>----- >>>>> >>>> >>>>1) >>>> >>>> >>>>>Thanks for considering my previous input... >>>>>I note that the new draft has an editorial oversight in that it >> >>contains >> >>>>>two definitions of PSI. I suggest the second should be deleted. >>>>> >>>> >>>>2) >>>> >>>> >>>>>I previously made a comment about the ancillary requirements when >> >>adding >> >>>a >>> >>>>>TS logical channel to a TS multiplex and asserted there appeared to be >>>>>under >>>>>specification. Perhaps it was viewed as out of scope, or perhaps I >>> >>>simply >>> >>>>>don't recognize the change that resulted. I can not find what >>> >>>stream_type >>> >>>>>is required to be used for the ULE stream when a "TS Logical Channel" >> >>is >> >>>>>added to a multiplex. >>> >>>The problem here is the same as above. Without "applying" for a >>>"stream_type" for ULE there is no stream_type for ULE. In contrary why >>>should one register a stream_type value for ULE earlier than ULE is >>>standardized? >>> >>> >>>>>I suggest at least an informative note be added in Section 6 (after >> >>the >> >>>>>third line which says: "These are transmitted using a single TS >> >>Logical >> >>>>>Channel over a TS Multiplex.") The note should say "PSI entries to be >>>>>consistent with [ISO-MPEG] when constructing a conformant TS Multiplex >>> >>>and >>> >>>>>means for Receivers to locate each such TS Logical Channel are outside >>> >>>the >>> >>>>>scope of this recommendation." >>> >>>Thanks, this is a very helpful suggestion for potential readers. In >>>addition the ipdvb-wg works on providing signalling other than PSI/SI. >>> >>> >>>>>Reason: >>>>>Just inserting a "TS Logical Channel" without including a >>>>>TS_Program_map_section that lists the PID and a stream_type does not >>>>>appear to me to result in a strictly MPEG-2 conformant bit stream; >> >>and >> >>>>>practically >>>>>could result in the PIDs being dropped by a remultiplexer. If the >>> >>>means >>> >>>>>for binding the inserted element into a multiplex and subsequent >>> >>>discovery >>> >>>>>is to be covered in another document, a pointer to that document would >>> >>>be >>> >>>>>more helpful than this warning. It seems at least a warning is needed >>> >>>and >>> >>>>>preferably a pointer to where this next level of TS construction is >>>>>defined. >>> >>> From an architectural point of view it is a reasonable assupmption that >>>whatever is being sent in a TS multiplex should be referenced. However, >>>the reality is that "ghost" PIDs do occur in many services either >>>accidentially or for well-defined reasons. >>> >>>What is the penalty for not being strictly MPEG-2 conformant/compliant? >>> >>> >>>>>Art Allison >>>>>Director, Advanced Engineering >>>>>NAB Science & Technology >>>>>1771 N St NW, Washington Dc 20036 >>>>>202 429 5418 >>> >>> >>>Regards, >>>Bernhard Collini-Nocker >>> >>> > > From gorry at erg.abdn.ac.uk Mon Feb 7 13:54:06 2005 From: gorry at erg.abdn.ac.uk (Gorry Fairhurst) Date: Mon, 07 Feb 2005 13:54:06 +0000 Subject: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto rs In-Reply-To: <420763AB.50107@cosy.sbg.ac.at> References: <08259490B3BC3140B549DD0907A5644811D664@admsrvnt10.enet.sharplabs.com> <420763AB.50107@cosy.sbg.ac.at> Message-ID: <420772FE.7050201@erg.abdn.ac.uk> So.... 1. The term "TS Logical Channel" was discussed a lot at the begining of the WG. As I recall, the reason for the new term, was that at this time the WG could not find a suitably "unbiased" term for the set of TS Packets with a common PID value (raw TS, DSMCC, Private Section, PES, etc). One key objective was to find a term that did not carry extra semantics, and was understandable by the networking community - this is after all intended as a part of the RFC-series, and we need to make this accessible to people familiar with using IP over Ethernet, MPLS, ATM, Fibre Channel, Firewire, SDH/SONET, etc. T we shoudl note that the term "TS Logical Channel term already appears (and is discussed in some detail) in the document draft-ietf-ipvb-arch-xx.txt and that this HAS already complete WGLC. If it IS WRONG we still have a chance to fix the definition/term, if we have to. Specifically, is there already a well-accepted term for the set of TS Packets with a common PID value (raw TS, DSMCC, Private Section, PES, etc) that we should use or refer to? 2. I'm not against defining another term "ULE Stream", "SNDU Stream", etc if that helps to describe the set of TS packets with a specific PID used for ULE, especially when talking about PSI. Bernhard, is there an opportunity of inserting a simple statement as the final paragraph of the introduction which says that to use ULE streams within an MPEG-2 compliant multiplex may require appropriate PSI entries... I think Art already proposed some specific wording that could be used or modified? 3) Once teh ULE spec is agreed and an RFC number issued, I can also see great advantage in assigning a descriptor for this in ATSC. I think the WG SHOULD should explore this at the next stage. Gorry Bernhard Collini-Nocker wrote: > Hello, > > let me try to summarize the two major points being raised and what the > discussion is about: > 1. the name/definition of "TS Logical Channel" is not well received and > the name/definition of a "SNDU stream" is proposed instead > 2. it is proposed to consider MPEG-2 conformance in specifying that ULE > requires a specific stream_type value for the PMT > > Personally I have no objection against 1., because it is easy to change > and improves wording and naming (unless somebody has an even better > name for it). > For 2. my concern is that mentioning stream_type may require some > additional wording about PSI/SI in general, which is likely out of scope > of the ULE draft. Even worse, in introducing a "world" besides the > encapsulation/decapsulation of ULE, this may result in further confusion > about what the MPEG-2/Section layer does in addition to and/or in > comparison to ULE/IP. Actually some difficult question may arise from > this direction, for example whether it is a wishful requirement for ULE > to support PAT/PMT/NIT/INT/... table parsing? > > Any opinions, recommendations or suggestions about this? > > Regards, > Bernhard > > Goldberg, Adam wrote: > >> ARGH. I fat-fingered 'send' before completing the email. See below. >> >> Adam Goldberg >> Director, Television Standards & Policy Development >> Sharp Laboratories of America >> 8605 Westwood Center Drive, Suite 206 >> Vienna, VA 22182 >> +1-703-556-4406 >> +1-703-556-4410 fax >> +1-571-276-0305 cell >> >> >> >>> -----Original Message----- >>> From: Goldberg, Adam >>> Sent: Monday, February 07, 2005 12:42 AM >>> To: 'Bernhard Collini-Nocker'; Goldberg, Adam >>> Cc: ipdvb at erg.abdn.ac.uk; Allison, Art; Matthew Goldman >>> Subject: RE: Forward from Art Alison: WGLC ULE - Data Broadcast >>> Descripto >>> rs >>> >>> See below... >>> >>> Adam Goldberg >>> Director, Television Standards & Policy Development >>> Sharp Laboratories of America >>> 8605 Westwood Center Drive, Suite 206 >>> Vienna, VA 22182 >>> +1-703-556-4406 >>> +1-703-556-4410 fax >>> +1-571-276-0305 cell >>> >>> >>> Bernhard Collini-Nocker wrote: >>> >>>> Goldberg, Adam wrote: >>>> >>>>> I apologize for being "late to the party", but: >>>>> >>>>> I do not see a particular need to define new term "TS Logical >> >> >> Channel", >> >>>> and >>>> >>>>> indeed doing so creates risks of ill-specification (such as those Art >>>> >>>> >>>> points >>>> >>>>> out), as well as confusion heaped upon someone familiar with MPEG-2 >>>>> Transport (as typically used in entertainment delivery). >>>> >>>> >>>> Unfortunately the MPEG-2 standards do not provide a reasonable term for >>>> the purpose of networking. The question is whether other terms, for >>>> example "PID network" or "PID stream" would be better received and >>>> understood? >>>> The term "TS logical channel" tries to verbally visualize that the >>>> encapsulation uses a continouos stream of transport stream packets >>>> using >>>> one specific packet identifier to transport subnetwork data units. >>>> Maybe >>>> the term "TS (virtual) circuit" better names this? >>> >>> >>> It is perhaps not well defined in 13818-1, but the term of art is >>> "streams". Many people use "PID stream" which is a poor combination of >>> words. I'd have no objection to defining a "SNDU Stream" as something >>> like "a sequence of MPEG-2 Transport Stream packets identified by a >>> common >>> PID value" (or some such). >>> >>> Perhaps discussing 'virtual circuits' relative to a Transport Stream is >>> begging for confusion. Use of any such words ("TS (virtual) circuit") >>> needs careful definition, likely requiring the above SNDU Stream >>> definition plus an explanation of what it means for multiple SNDU >>> Streams >>> to exist in a single Transport Stream. >>> >>> >>>>> Furthermore, the definition is quite wrong with respect to ATSC and >>> >>> >>> DVB >>> >>>> use >>>> >>>>> of "specific TS Logical Channels". To my knowledge, this internet- >>> >>> >>> draft >>> >>>> is >>>> >>>>> the only document anywhere which uses such terms. It is certainly >>> >>> >>> true >>> >>>> that >>>> >>>>> MPEG, DVB and ATSC define //elementary streams// identified by >>>> >>>> >>>> stream_type >>>> >>>>> values. I suspect this is what is meant by "TS Logical Channel", but >>> >>> >>> it >>> >>>> is >>>> >>>>> difficult for me to tell. >>>> >>>> >>>> I am not so sure, whether this analysis is correct. Elementary streams >>>> are those that are transported as Packetized ES, whereas "auxillary" >>>> data and signalling is transported as sections. Although a stream_type >>>> in the program map section is used to reference both PESs and sections >>>> the term elementary stream is used very vague and we tried to avoid >>>> using it in the same vague manner. >>> >>> >>> Perhaps I overstepped with "elementary stream". >>> >>> Consider the 13818-1 definition of "Packetized Elementary Stream": "A >>> continuous sequence of PES packets of one elementary stream with one >>> stream ID may be used to construct a PES Stream." (ISO/IEC >>> 13818-1:2000 p. >>> xiii) >>> >>> Stuff carried as payload of Transport Stream packets are merely >>> 'payload'. >>> What the draft starts to define is a new type of payload stream (that >>> is, >>> a new way to carry data in a transport stream). The definition is not >>> compete. >>> >>> >>>> According to, for example EN301192 v1.3.1, defines Data Piping as: >>>> " The data broadcast service shall insert the data to be broadcast >>>> directly in the payload of MPEG-2 TS packets." >>>> That raises the question, how to call a continouos stream of MPEG-2 TS >>>> packets with a certain PID? >>>> >>>> Further the standard details that: >>>> "The data broadcast service may use the payload_unit_start_indicator >>>> field and the transport_priority field of the MPEG-2 Transport Stream >>>> packets in a service private way. The use of the adaptation_field shall >>>> be MPEG-2 compliant." >>>> ULE uses PUSI and does not utilize the AF. >>>> >>>> "The delivery of the bits in time through a data pipe is service >>>> private >>>> and is not specified in the present document." >>>> It seems obvious that the use of the term "TS Data Pipe" would lead to >>>> the wrong conclusion that ULE equals Data Piping. But Data Piping is >>>> not >>>> detailed at all, whereas ULE tries to be. >>> >>> >>> I'm not going to argue that DVB's specification is complete. I will >>> argue >>> that ULE isn't complete. >>> >>> >>>>> (from the draft) >>>>> TS Logical Channel: Transport Stream Logical Channel. In this >>>>> document, this term identifies a channel at the MPEG-2 level [ISO- >>>>> MPEG]. It exists at level 2 of the ISO/OSI reference model. All >>>>> packets sent over a TS Logical Channel carry the same PID value >>>>> (this value is unique within a specific TS Multiplex). According to >>>>> MPEG-2, some TS Logical Channels are reserved for specific >>>>> signalling purposes. Other standards (e.g., ATSC, DVB) also reserve >>>>> specific TS Logical Channels. >>>>> >>>>> While I'm commenting on this definition, it also seems to me that >>>> >>>> >>>> "channel >>>> >>>>> at the MPEG-2 level" is either wrong or also ill-specified. What's a >>>>> channel? If you're talking about MPEG-2, it's certainly conceivable >>>> >>>> >>>> that >>>> >>>>> the reader may associate "channel" with "[television] channel" - which >>>> >>>> >>>> are >>>> >>>>> the subject of a large amount of ATSC and DVB systems. >>>> >>>> >>>> The term channel is indeed problematic in the context of television, >>>> however, network engineers might have a different understanding about >>>> what a channel is. >>>> According to ATIS a channel is "1. A connection between initiating and >>>> terminating nodes of a circuit. 2. A single path provided by a >>>> transmission medium via either (a) physical separation, such as by >>>> multipair cable or (b) electrical separation, such as by frequency- or >>>> time-division multiplexing. ..." >>> >>> >>> I understand that 'channel' vis-?-vis networking has a different meaning >>> than 'channel' vis-?-vis television. This was my point actually, that >>> those familiar with MPEG transport should not be assumed to be >>> networking- >>> types (even when speaking with respect to ULE). >>> >>> >>>>> Additionally, it is also wrong or ill-specified to say "According to >>>> >>>> >>>> MPEG-2 >>>> >>>>> ... TS Logical Channels ...". There is no such concept defined or >>> >>> >>> used >>> >>>>> within MPEG (unless what you really mean is elementary stream, in >>> >>> >>> which >>> >>>> case >>>> >>>>> what do you need this extraneous term for anyhow?). >>>> >>>> >>>> Again, elementary stream is not exactly what is being meant: >>>> For example EN 300468 v1.5.1 defines: >>>> "component (ELEMENTARY Stream): one or more entities which together >>>> make >>>> up an event, e.g. video, audio, teletext" >>>> >>>> and says further: >>>> "The component descriptor identifies the type of component stream and >>>> may be used to provide a text description of the elementary stream" >>>> >>>> where: >>>> "component_type: This 8-bit field specifies the type of the video, >>>> audio >>>> or EBU-data component. The coding of this field is specified in table >>> >>> >>> 26." >>> >>>> Table 26 then lists all kinds of video, audio, and teletext formats, >>>> but >>>> unfortunately no networking formats. >>>> >>>> At other places this standard is as innovative/creative in naming: >>>> "event: grouping of elementary broadcast data streams with a defined >>>> start and end time belonging to a common service, e.g. first half of a >>>> football match, News Flash, first part of an entertainment show" >>>> What is a "elementary broadcast data streams"? Not by guessing but by >>>> definition? >>>> >>>> >>>>> In any case, Art is certainly correct that merely identifying a "TS >>>> >>>> >>>> Logical >>>> >>>>> Channel" as a sequence of packets identified with a common PID value >>>> >>>> >>>> without >>>> >>>>> identifying the PSI details is an invitation to multiplexers and >>>>> remultiplexers to drop those packets on the floor. >>>> >>>> >>>> Oh yes, this is the real problem of defining something outside >>>> television standardiszation bodies: one risks that ULE packets are >>>> being >>>> dropped. >>>> We have discussed basically two approaches: >>>> 1. define the PSI and get an ID, or tag, or "stream_type" for ULE, >>>> or 2. >>>> define ULE and let somebody else do the PSI work. >>>> We have had some reasons for choice 2. >>> >>> >>> This is a very easy thing to fix and something which should be done. >>> Without defining a stream_type for ULE data, it is neither possible to >>> construct a transport stream compliant with MPEG-2 nor one that >>> interoperates with other ULE equipment. >>> >>> ATSC maintains a 'codepoint registry', and would be happy to allocate a >>> stream_type value for ULE data upon request from IETF. Furthermore, the >>> text to specify usage of the stream_type would be reasonably easy (and >>> perhaps ties in to my suggested "SNDU Stream" definition (that is, >>> define >>> it as >> >> >> >> SNDU Stream: a sequence of MPEG-2 Transport Stream packets identified >> by a >> common PID value of stream_type <0xnn>. >> >> All that then remains, I think, would be to signal when a Program carries >> SNDU Stream(s), and what it means when there are more than one SNDU >> Stream >> per program, or more than one Program that carries one or more SNDU >> Streams. >> >> >>>>> If there remains an opportunity to repair what I believe to be errors >>> >>> >>> in >>> >>>> the >>>> >>>>> draft, I'm eager and willing to participate from a MPEG-2 >>> >>> >>> entertainment >>> >>>>> (which is to say, legacy use of MPEG-2 Transport) point of view. >>>> >>>> >>>> Of course the terms in the document should not conflict with meaning in >>>> another context. However, ambiguous terms in other documents should be >>>> avoided as well. >>>> >>>> >>>>> [Apologies for being strident at all, to say nothing of at such an >>>>> apparently late stage - if the above is perceived as such] >>>>> >>>>> Regards, >>>>> Adam Goldberg >>>>> Director, Television Standards & Policy Development >>>>> Sharp Laboratories of America >>>>> 8605 Westwood Center Drive, Suite 206 >>>>> Vienna, VA 22182 >>>>> +1-703-556-4406 >>>>> +1-703-556-4410 fax >>>>> +1-571-276-0305 cell >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: owner-ipdvb at erg.abdn.ac.uk [mailto:owner-ipdvb at erg.abdn.ac.uk] >>> >>> >>> On >>> >>>>> Behalf Of Gorry Fairhurst >>>>> Sent: Friday, February 04, 2005 6:56 AM >>>>> To: ipdvb at erg.abdn.ac.uk; Bernhard Collini-Nocker >>>>> Cc: AAllison at nab.org >>>>> Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast >>>> >>>> >>>> Descriptors >>>> >>>>> >>>>> 1) Done - point 1 was an edit mistake. >>>>> >>>>> 2) I think some text on data broadcast descriptors, stream-type, >>> >>> >>> or/and >>> >>>> PSI >>>> >>>>> entries would be a valuable addition. >>>>> >>>>> On thinking about this, I wonder if the text about this should go at >>> >>> >>> the >>> >>>> end >>>> >>>>> of the Introduction (1.0) to the whole document, where people can see >>> >>> >>> it >>> >>>>> clearly and then undesrtand that there may be something else needed >>> >>> >>> for >>> >>>>> those >>>>> networks that rely on PSI for remultiplexing! >>>>> >>>>> - Bernhard & others who understand PSI, can you work with Art to agree >>>> >>>> >>>> the >>>> >>>>> exact wording please? >>>>> >>>>> Gorry Fairhurst >>>>> (ipdvb WG Chair) >>>>> >>>>> Gorry Fairhurst wrote: >>>>> >>>>> >>>>> >>>>>> WG please read and respond to this message. >>>>>> >>>>>> The following message was received on January 22nd before WGLC, but >>> >>> >>> was >>> >>>>>> dropped because the email source address was not verified by the list >>>>>> server. >>>>>> >>>>>> The exact text of the message follows. >>>>>> >>>>>> best wishes, >>>>>> >>>>>> Gorry >>>>>> (ipdvb WG Chair) >>>>>> >>>>>> ----- >>>>>> >>>>> >>>>> 1) >>>>> >>>>> >>>>>> Thanks for considering my previous input... >>>>>> I note that the new draft has an editorial oversight in that it >>> >>> >>> contains >>> >>>>>> two definitions of PSI. I suggest the second should be deleted. >>>>>> >>>>> >>>>> 2) >>>>> >>>>> >>>>>> I previously made a comment about the ancillary requirements when >>> >>> >>> adding >>> >>>> a >>>> >>>>>> TS logical channel to a TS multiplex and asserted there appeared >>>>>> to be >>>>>> under >>>>>> specification. Perhaps it was viewed as out of scope, or perhaps I >>>> >>>> >>>> simply >>>> >>>>>> don't recognize the change that resulted. I can not find what >>>> >>>> >>>> stream_type >>>> >>>>>> is required to be used for the ULE stream when a "TS Logical Channel" >>> >>> >>> is >>> >>>>>> added to a multiplex. >>>> >>>> >>>> The problem here is the same as above. Without "applying" for a >>>> "stream_type" for ULE there is no stream_type for ULE. In contrary why >>>> should one register a stream_type value for ULE earlier than ULE is >>>> standardized? >>>> >>>> >>>>>> I suggest at least an informative note be added in Section 6 (after >>> >>> >>> the >>> >>>>>> third line which says: "These are transmitted using a single TS >>> >>> >>> Logical >>> >>>>>> Channel over a TS Multiplex.") The note should say "PSI entries to be >>>>>> consistent with [ISO-MPEG] when constructing a conformant TS >>>>>> Multiplex >>>> >>>> >>>> and >>>> >>>>>> means for Receivers to locate each such TS Logical Channel are >>>>>> outside >>>> >>>> >>>> the >>>> >>>>>> scope of this recommendation." >>>> >>>> >>>> Thanks, this is a very helpful suggestion for potential readers. In >>>> addition the ipdvb-wg works on providing signalling other than PSI/SI. >>>> >>>> >>>>>> Reason: >>>>>> Just inserting a "TS Logical Channel" without including a >>>>>> TS_Program_map_section that lists the PID and a stream_type does not >>>>>> appear to me to result in a strictly MPEG-2 conformant bit stream; >>> >>> >>> and >>> >>>>>> practically >>>>>> could result in the PIDs being dropped by a remultiplexer. If the >>>> >>>> >>>> means >>>> >>>>>> for binding the inserted element into a multiplex and subsequent >>>> >>>> >>>> discovery >>>> >>>>>> is to be covered in another document, a pointer to that document >>>>>> would >>>> >>>> >>>> be >>>> >>>>>> more helpful than this warning. It seems at least a warning is needed >>>> >>>> >>>> and >>>> >>>>>> preferably a pointer to where this next level of TS construction is >>>>>> defined. >>>> >>>> >>>> From an architectural point of view it is a reasonable assupmption that >>>> whatever is being sent in a TS multiplex should be referenced. However, >>>> the reality is that "ghost" PIDs do occur in many services either >>>> accidentially or for well-defined reasons. >>>> >>>> What is the penalty for not being strictly MPEG-2 conformant/compliant? >>>> >>>> >>>>>> Art Allison >>>>>> Director, Advanced Engineering >>>>>> NAB Science & Technology >>>>>> 1771 N St NW, Washington Dc 20036 >>>>>> 202 429 5418 >>>> >>>> >>>> >>>> Regards, >>>> Bernhard Collini-Nocker >>>> >>>> >> >> > > From david.mcgovern at bt.com Mon Feb 7 15:39:21 2005 From: david.mcgovern at bt.com (david.mcgovern at bt.com) Date: Mon, 7 Feb 2005 15:39:21 -0000 Subject: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto rs Message-ID: <981038F72E40E04D8F80A194E5F7102B0E2B3D84@i2km04-ukbr.domain1.systemhost.net> Gorry, could you unsubscribe me from this list. I'm not really doing this now. Dave -----Original Message----- From: owner-ipdvb at erg.abdn.ac.uk [mailto:owner-ipdvb at erg.abdn.ac.uk]On Behalf Of Gorry Fairhurst Sent: 07 February 2005 13:54 To: ipdvb at erg.abdn.ac.uk Cc: Goldberg, Adam; Allison, Art; Matthew Goldman Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto rs So.... 1. The term "TS Logical Channel" was discussed a lot at the begining of the WG. As I recall, the reason for the new term, was that at this time the WG could not find a suitably "unbiased" term for the set of TS Packets with a common PID value (raw TS, DSMCC, Private Section, PES, etc). One key objective was to find a term that did not carry extra semantics, and was understandable by the networking community - this is after all intended as a part of the RFC-series, and we need to make this accessible to people familiar with using IP over Ethernet, MPLS, ATM, Fibre Channel, Firewire, SDH/SONET, etc. T we shoudl note that the term "TS Logical Channel term already appears (and is discussed in some detail) in the document draft-ietf-ipvb-arch-xx.txt and that this HAS already complete WGLC. If it IS WRONG we still have a chance to fix the definition/term, if we have to. Specifically, is there already a well-accepted term for the set of TS Packets with a common PID value (raw TS, DSMCC, Private Section, PES, etc) that we should use or refer to? 2. I'm not against defining another term "ULE Stream", "SNDU Stream", etc if that helps to describe the set of TS packets with a specific PID used for ULE, especially when talking about PSI. Bernhard, is there an opportunity of inserting a simple statement as the final paragraph of the introduction which says that to use ULE streams within an MPEG-2 compliant multiplex may require appropriate PSI entries... I think Art already proposed some specific wording that could be used or modified? 3) Once teh ULE spec is agreed and an RFC number issued, I can also see great advantage in assigning a descriptor for this in ATSC. I think the WG SHOULD should explore this at the next stage. Gorry Bernhard Collini-Nocker wrote: > Hello, > > let me try to summarize the two major points being raised and what the > discussion is about: > 1. the name/definition of "TS Logical Channel" is not well received and > the name/definition of a "SNDU stream" is proposed instead > 2. it is proposed to consider MPEG-2 conformance in specifying that ULE > requires a specific stream_type value for the PMT > > Personally I have no objection against 1., because it is easy to change > and improves wording and naming (unless somebody has an even better > name for it). > For 2. my concern is that mentioning stream_type may require some > additional wording about PSI/SI in general, which is likely out of scope > of the ULE draft. Even worse, in introducing a "world" besides the > encapsulation/decapsulation of ULE, this may result in further confusion > about what the MPEG-2/Section layer does in addition to and/or in > comparison to ULE/IP. Actually some difficult question may arise from > this direction, for example whether it is a wishful requirement for ULE > to support PAT/PMT/NIT/INT/... table parsing? > > Any opinions, recommendations or suggestions about this? > > Regards, > Bernhard > > Goldberg, Adam wrote: > >> ARGH. I fat-fingered 'send' before completing the email. See below. >> >> Adam Goldberg >> Director, Television Standards & Policy Development >> Sharp Laboratories of America >> 8605 Westwood Center Drive, Suite 206 >> Vienna, VA 22182 >> +1-703-556-4406 >> +1-703-556-4410 fax >> +1-571-276-0305 cell >> >> >> >>> -----Original Message----- >>> From: Goldberg, Adam >>> Sent: Monday, February 07, 2005 12:42 AM >>> To: 'Bernhard Collini-Nocker'; Goldberg, Adam >>> Cc: ipdvb at erg.abdn.ac.uk; Allison, Art; Matthew Goldman >>> Subject: RE: Forward from Art Alison: WGLC ULE - Data Broadcast >>> Descripto >>> rs >>> >>> See below... >>> >>> Adam Goldberg >>> Director, Television Standards & Policy Development >>> Sharp Laboratories of America >>> 8605 Westwood Center Drive, Suite 206 >>> Vienna, VA 22182 >>> +1-703-556-4406 >>> +1-703-556-4410 fax >>> +1-571-276-0305 cell >>> >>> >>> Bernhard Collini-Nocker wrote: >>> >>>> Goldberg, Adam wrote: >>>> >>>>> I apologize for being "late to the party", but: >>>>> >>>>> I do not see a particular need to define new term "TS Logical >> >> >> Channel", >> >>>> and >>>> >>>>> indeed doing so creates risks of ill-specification (such as those Art >>>> >>>> >>>> points >>>> >>>>> out), as well as confusion heaped upon someone familiar with MPEG-2 >>>>> Transport (as typically used in entertainment delivery). >>>> >>>> >>>> Unfortunately the MPEG-2 standards do not provide a reasonable term for >>>> the purpose of networking. The question is whether other terms, for >>>> example "PID network" or "PID stream" would be better received and >>>> understood? >>>> The term "TS logical channel" tries to verbally visualize that the >>>> encapsulation uses a continouos stream of transport stream packets >>>> using >>>> one specific packet identifier to transport subnetwork data units. >>>> Maybe >>>> the term "TS (virtual) circuit" better names this? >>> >>> >>> It is perhaps not well defined in 13818-1, but the term of art is >>> "streams". Many people use "PID stream" which is a poor combination of >>> words. I'd have no objection to defining a "SNDU Stream" as something >>> like "a sequence of MPEG-2 Transport Stream packets identified by a >>> common >>> PID value" (or some such). >>> >>> Perhaps discussing 'virtual circuits' relative to a Transport Stream is >>> begging for confusion. Use of any such words ("TS (virtual) circuit") >>> needs careful definition, likely requiring the above SNDU Stream >>> definition plus an explanation of what it means for multiple SNDU >>> Streams >>> to exist in a single Transport Stream. >>> >>> >>>>> Furthermore, the definition is quite wrong with respect to ATSC and >>> >>> >>> DVB >>> >>>> use >>>> >>>>> of "specific TS Logical Channels". To my knowledge, this internet- >>> >>> >>> draft >>> >>>> is >>>> >>>>> the only document anywhere which uses such terms. It is certainly >>> >>> >>> true >>> >>>> that >>>> >>>>> MPEG, DVB and ATSC define //elementary streams// identified by >>>> >>>> >>>> stream_type >>>> >>>>> values. I suspect this is what is meant by "TS Logical Channel", but >>> >>> >>> it >>> >>>> is >>>> >>>>> difficult for me to tell. >>>> >>>> >>>> I am not so sure, whether this analysis is correct. Elementary streams >>>> are those that are transported as Packetized ES, whereas "auxillary" >>>> data and signalling is transported as sections. Although a stream_type >>>> in the program map section is used to reference both PESs and sections >>>> the term elementary stream is used very vague and we tried to avoid >>>> using it in the same vague manner. >>> >>> >>> Perhaps I overstepped with "elementary stream". >>> >>> Consider the 13818-1 definition of "Packetized Elementary Stream": "A >>> continuous sequence of PES packets of one elementary stream with one >>> stream ID may be used to construct a PES Stream." (ISO/IEC >>> 13818-1:2000 p. >>> xiii) >>> >>> Stuff carried as payload of Transport Stream packets are merely >>> 'payload'. >>> What the draft starts to define is a new type of payload stream (that >>> is, >>> a new way to carry data in a transport stream). The definition is not >>> compete. >>> >>> >>>> According to, for example EN301192 v1.3.1, defines Data Piping as: >>>> " The data broadcast service shall insert the data to be broadcast >>>> directly in the payload of MPEG-2 TS packets." >>>> That raises the question, how to call a continouos stream of MPEG-2 TS >>>> packets with a certain PID? >>>> >>>> Further the standard details that: >>>> "The data broadcast service may use the payload_unit_start_indicator >>>> field and the transport_priority field of the MPEG-2 Transport Stream >>>> packets in a service private way. The use of the adaptation_field shall >>>> be MPEG-2 compliant." >>>> ULE uses PUSI and does not utilize the AF. >>>> >>>> "The delivery of the bits in time through a data pipe is service >>>> private >>>> and is not specified in the present document." >>>> It seems obvious that the use of the term "TS Data Pipe" would lead to >>>> the wrong conclusion that ULE equals Data Piping. But Data Piping is >>>> not >>>> detailed at all, whereas ULE tries to be. >>> >>> >>> I'm not going to argue that DVB's specification is complete. I will >>> argue >>> that ULE isn't complete. >>> >>> >>>>> (from the draft) >>>>> TS Logical Channel: Transport Stream Logical Channel. In this >>>>> document, this term identifies a channel at the MPEG-2 level [ISO- >>>>> MPEG]. It exists at level 2 of the ISO/OSI reference model. All >>>>> packets sent over a TS Logical Channel carry the same PID value >>>>> (this value is unique within a specific TS Multiplex). According to >>>>> MPEG-2, some TS Logical Channels are reserved for specific >>>>> signalling purposes. Other standards (e.g., ATSC, DVB) also reserve >>>>> specific TS Logical Channels. >>>>> >>>>> While I'm commenting on this definition, it also seems to me that >>>> >>>> >>>> "channel >>>> >>>>> at the MPEG-2 level" is either wrong or also ill-specified. What's a >>>>> channel? If you're talking about MPEG-2, it's certainly conceivable >>>> >>>> >>>> that >>>> >>>>> the reader may associate "channel" with "[television] channel" - which >>>> >>>> >>>> are >>>> >>>>> the subject of a large amount of ATSC and DVB systems. >>>> >>>> >>>> The term channel is indeed problematic in the context of television, >>>> however, network engineers might have a different understanding about >>>> what a channel is. >>>> According to ATIS a channel is "1. A connection between initiating and >>>> terminating nodes of a circuit. 2. A single path provided by a >>>> transmission medium via either (a) physical separation, such as by >>>> multipair cable or (b) electrical separation, such as by frequency- or >>>> time-division multiplexing. ..." >>> >>> >>> I understand that 'channel' vis-?-vis networking has a different meaning >>> than 'channel' vis-?-vis television. This was my point actually, that >>> those familiar with MPEG transport should not be assumed to be >>> networking- >>> types (even when speaking with respect to ULE). >>> >>> >>>>> Additionally, it is also wrong or ill-specified to say "According to >>>> >>>> >>>> MPEG-2 >>>> >>>>> ... TS Logical Channels ...". There is no such concept defined or >>> >>> >>> used >>> >>>>> within MPEG (unless what you really mean is elementary stream, in >>> >>> >>> which >>> >>>> case >>>> >>>>> what do you need this extraneous term for anyhow?). >>>> >>>> >>>> Again, elementary stream is not exactly what is being meant: >>>> For example EN 300468 v1.5.1 defines: >>>> "component (ELEMENTARY Stream): one or more entities which together >>>> make >>>> up an event, e.g. video, audio, teletext" >>>> >>>> and says further: >>>> "The component descriptor identifies the type of component stream and >>>> may be used to provide a text description of the elementary stream" >>>> >>>> where: >>>> "component_type: This 8-bit field specifies the type of the video, >>>> audio >>>> or EBU-data component. The coding of this field is specified in table >>> >>> >>> 26." >>> >>>> Table 26 then lists all kinds of video, audio, and teletext formats, >>>> but >>>> unfortunately no networking formats. >>>> >>>> At other places this standard is as innovative/creative in naming: >>>> "event: grouping of elementary broadcast data streams with a defined >>>> start and end time belonging to a common service, e.g. first half of a >>>> football match, News Flash, first part of an entertainment show" >>>> What is a "elementary broadcast data streams"? Not by guessing but by >>>> definition? >>>> >>>> >>>>> In any case, Art is certainly correct that merely identifying a "TS >>>> >>>> >>>> Logical >>>> >>>>> Channel" as a sequence of packets identified with a common PID value >>>> >>>> >>>> without >>>> >>>>> identifying the PSI details is an invitation to multiplexers and >>>>> remultiplexers to drop those packets on the floor. >>>> >>>> >>>> Oh yes, this is the real problem of defining something outside >>>> television standardiszation bodies: one risks that ULE packets are >>>> being >>>> dropped. >>>> We have discussed basically two approaches: >>>> 1. define the PSI and get an ID, or tag, or "stream_type" for ULE, >>>> or 2. >>>> define ULE and let somebody else do the PSI work. >>>> We have had some reasons for choice 2. >>> >>> >>> This is a very easy thing to fix and something which should be done. >>> Without defining a stream_type for ULE data, it is neither possible to >>> construct a transport stream compliant with MPEG-2 nor one that >>> interoperates with other ULE equipment. >>> >>> ATSC maintains a 'codepoint registry', and would be happy to allocate a >>> stream_type value for ULE data upon request from IETF. Furthermore, the >>> text to specify usage of the stream_type would be reasonably easy (and >>> perhaps ties in to my suggested "SNDU Stream" definition (that is, >>> define >>> it as >> >> >> >> SNDU Stream: a sequence of MPEG-2 Transport Stream packets identified >> by a >> common PID value of stream_type <0xnn>. >> >> All that then remains, I think, would be to signal when a Program carries >> SNDU Stream(s), and what it means when there are more than one SNDU >> Stream >> per program, or more than one Program that carries one or more SNDU >> Streams. >> >> >>>>> If there remains an opportunity to repair what I believe to be errors >>> >>> >>> in >>> >>>> the >>>> >>>>> draft, I'm eager and willing to participate from a MPEG-2 >>> >>> >>> entertainment >>> >>>>> (which is to say, legacy use of MPEG-2 Transport) point of view. >>>> >>>> >>>> Of course the terms in the document should not conflict with meaning in >>>> another context. However, ambiguous terms in other documents should be >>>> avoided as well. >>>> >>>> >>>>> [Apologies for being strident at all, to say nothing of at such an >>>>> apparently late stage - if the above is perceived as such] >>>>> >>>>> Regards, >>>>> Adam Goldberg >>>>> Director, Television Standards & Policy Development >>>>> Sharp Laboratories of America >>>>> 8605 Westwood Center Drive, Suite 206 >>>>> Vienna, VA 22182 >>>>> +1-703-556-4406 >>>>> +1-703-556-4410 fax >>>>> +1-571-276-0305 cell >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: owner-ipdvb at erg.abdn.ac.uk [mailto:owner-ipdvb at erg.abdn.ac.uk] >>> >>> >>> On >>> >>>>> Behalf Of Gorry Fairhurst >>>>> Sent: Friday, February 04, 2005 6:56 AM >>>>> To: ipdvb at erg.abdn.ac.uk; Bernhard Collini-Nocker >>>>> Cc: AAllison at nab.org >>>>> Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast >>>> >>>> >>>> Descriptors >>>> >>>>> >>>>> 1) Done - point 1 was an edit mistake. >>>>> >>>>> 2) I think some text on data broadcast descriptors, stream-type, >>> >>> >>> or/and >>> >>>> PSI >>>> >>>>> entries would be a valuable addition. >>>>> >>>>> On thinking about this, I wonder if the text about this should go at >>> >>> >>> the >>> >>>> end >>>> >>>>> of the Introduction (1.0) to the whole document, where people can see >>> >>> >>> it >>> >>>>> clearly and then undesrtand that there may be something else needed >>> >>> >>> for >>> >>>>> those >>>>> networks that rely on PSI for remultiplexing! >>>>> >>>>> - Bernhard & others who understand PSI, can you work with Art to agree >>>> >>>> >>>> the >>>> >>>>> exact wording please? >>>>> >>>>> Gorry Fairhurst >>>>> (ipdvb WG Chair) >>>>> >>>>> Gorry Fairhurst wrote: >>>>> >>>>> >>>>> >>>>>> WG please read and respond to this message. >>>>>> >>>>>> The following message was received on January 22nd before WGLC, but >>> >>> >>> was >>> >>>>>> dropped because the email source address was not verified by the list >>>>>> server. >>>>>> >>>>>> The exact text of the message follows. >>>>>> >>>>>> best wishes, >>>>>> >>>>>> Gorry >>>>>> (ipdvb WG Chair) >>>>>> >>>>>> ----- >>>>>> >>>>> >>>>> 1) >>>>> >>>>> >>>>>> Thanks for considering my previous input... >>>>>> I note that the new draft has an editorial oversight in that it >>> >>> >>> contains >>> >>>>>> two definitions of PSI. I suggest the second should be deleted. >>>>>> >>>>> >>>>> 2) >>>>> >>>>> >>>>>> I previously made a comment about the ancillary requirements when >>> >>> >>> adding >>> >>>> a >>>> >>>>>> TS logical channel to a TS multiplex and asserted there appeared >>>>>> to be >>>>>> under >>>>>> specification. Perhaps it was viewed as out of scope, or perhaps I >>>> >>>> >>>> simply >>>> >>>>>> don't recognize the change that resulted. I can not find what >>>> >>>> >>>> stream_type >>>> >>>>>> is required to be used for the ULE stream when a "TS Logical Channel" >>> >>> >>> is >>> >>>>>> added to a multiplex. >>>> >>>> >>>> The problem here is the same as above. Without "applying" for a >>>> "stream_type" for ULE there is no stream_type for ULE. In contrary why >>>> should one register a stream_type value for ULE earlier than ULE is >>>> standardized? >>>> >>>> >>>>>> I suggest at least an informative note be added in Section 6 (after >>> >>> >>> the >>> >>>>>> third line which says: "These are transmitted using a single TS >>> >>> >>> Logical >>> >>>>>> Channel over a TS Multiplex.") The note should say "PSI entries to be >>>>>> consistent with [ISO-MPEG] when constructing a conformant TS >>>>>> Multiplex >>>> >>>> >>>> and >>>> >>>>>> means for Receivers to locate each such TS Logical Channel are >>>>>> outside >>>> >>>> >>>> the >>>> >>>>>> scope of this recommendation." >>>> >>>> >>>> Thanks, this is a very helpful suggestion for potential readers. In >>>> addition the ipdvb-wg works on providing signalling other than PSI/SI. >>>> >>>> >>>>>> Reason: >>>>>> Just inserting a "TS Logical Channel" without including a >>>>>> TS_Program_map_section that lists the PID and a stream_type does not >>>>>> appear to me to result in a strictly MPEG-2 conformant bit stream; >>> >>> >>> and >>> >>>>>> practically >>>>>> could result in the PIDs being dropped by a remultiplexer. If the >>>> >>>> >>>> means >>>> >>>>>> for binding the inserted element into a multiplex and subsequent >>>> >>>> >>>> discovery >>>> >>>>>> is to be covered in another document, a pointer to that document >>>>>> would >>>> >>>> >>>> be >>>> >>>>>> more helpful than this warning. It seems at least a warning is needed >>>> >>>> >>>> and >>>> >>>>>> preferably a pointer to where this next level of TS construction is >>>>>> defined. >>>> >>>> >>>> From an architectural point of view it is a reasonable assupmption that >>>> whatever is being sent in a TS multiplex should be referenced. However, >>>> the reality is that "ghost" PIDs do occur in many services either >>>> accidentially or for well-defined reasons. >>>> >>>> What is the penalty for not being strictly MPEG-2 conformant/compliant? >>>> >>>> >>>>>> Art Allison >>>>>> Director, Advanced Engineering >>>>>> NAB Science & Technology >>>>>> 1771 N St NW, Washington Dc 20036 >>>>>> 202 429 5418 >>>> >>>> >>>> >>>> Regards, >>>> Bernhard Collini-Nocker >>>> >>>> >> >> > > From gorry at erg.abdn.ac.uk Mon Feb 7 16:44:44 2005 From: gorry at erg.abdn.ac.uk (Gorry Fairhurst) Date: Mon, 07 Feb 2005 16:44:44 +0000 Subject: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto rs In-Reply-To: <981038F72E40E04D8F80A194E5F7102B0E2B3D84@i2km04-ukbr.domain1.systemhost.net> References: <981038F72E40E04D8F80A194E5F7102B0E2B3D84@i2km04-ukbr.domain1.systemhost.net> Message-ID: <42079AFC.20306@erg.abdn.ac.uk> Sure, Just send a message with "unsubscribe ipdvb" in the body of the message (not title) to "majordomo at erg.abdn.ac.uk". Gorr david.mcgovern at bt.com wrote: > Gorry, could you unsubscribe me from this list. I'm not really doing this now. > > Dave > > -----Original Message----- > From: owner-ipdvb at erg.abdn.ac.uk [mailto:owner-ipdvb at erg.abdn.ac.uk]On > Behalf Of Gorry Fairhurst > Sent: 07 February 2005 13:54 > To: ipdvb at erg.abdn.ac.uk > Cc: Goldberg, Adam; Allison, Art; Matthew Goldman > Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast > Descripto rs > > > > So.... > > 1. The term "TS Logical Channel" was discussed a lot at the begining of the > WG. As I recall, the reason for the new term, was that at this time the WG > could not find a suitably "unbiased" term for the set of TS Packets with a > common PID value (raw TS, DSMCC, Private Section, PES, etc). One key objective > was to find a term that did not carry extra semantics, and was understandable > by the networking community - this is after all intended as a part of the > RFC-series, and we need to make this accessible to people familiar with using > IP over Ethernet, MPLS, ATM, Fibre Channel, Firewire, SDH/SONET, etc. > T > > we shoudl note that the term "TS Logical Channel term already appears (and is > discussed in some detail) in the document draft-ietf-ipvb-arch-xx.txt and that > this HAS already complete WGLC. If it IS WRONG we still have a chance to fix > the definition/term, if we have to. Specifically, is there already a > well-accepted term for the set of TS Packets with a common PID value (raw TS, > DSMCC, Private Section, PES, etc) that we should use or refer to? > > > 2. I'm not against defining another term "ULE Stream", "SNDU Stream", etc if > that helps to describe the set of TS packets with a specific PID used for ULE, > especially when talking about PSI. > > Bernhard, is there an opportunity of inserting a simple statement as the final > paragraph of the introduction which says that to use ULE streams within an > MPEG-2 compliant multiplex may require appropriate PSI entries... I think Art > already proposed some specific wording that could be used or modified? > > > 3) Once teh ULE spec is agreed and an RFC number issued, I can also see great > advantage in assigning a descriptor for this in ATSC. I think the WG SHOULD > should explore this at the next stage. > > > Gorry > > Bernhard Collini-Nocker wrote: > > >>Hello, >> >>let me try to summarize the two major points being raised and what the >>discussion is about: >>1. the name/definition of "TS Logical Channel" is not well received and >>the name/definition of a "SNDU stream" is proposed instead >>2. it is proposed to consider MPEG-2 conformance in specifying that ULE >>requires a specific stream_type value for the PMT >> >>Personally I have no objection against 1., because it is easy to change >>and improves wording and naming (unless somebody has an even better >>name for it). >>For 2. my concern is that mentioning stream_type may require some >>additional wording about PSI/SI in general, which is likely out of scope >>of the ULE draft. Even worse, in introducing a "world" besides the >>encapsulation/decapsulation of ULE, this may result in further confusion >>about what the MPEG-2/Section layer does in addition to and/or in >>comparison to ULE/IP. Actually some difficult question may arise from >>this direction, for example whether it is a wishful requirement for ULE >>to support PAT/PMT/NIT/INT/... table parsing? >> >>Any opinions, recommendations or suggestions about this? >> >>Regards, >>Bernhard >> >>Goldberg, Adam wrote: >> >> >>>ARGH. I fat-fingered 'send' before completing the email. See below. >>> >>>Adam Goldberg >>>Director, Television Standards & Policy Development >>>Sharp Laboratories of America >>>8605 Westwood Center Drive, Suite 206 >>>Vienna, VA 22182 >>>+1-703-556-4406 >>>+1-703-556-4410 fax >>>+1-571-276-0305 cell >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: Goldberg, Adam >>>>Sent: Monday, February 07, 2005 12:42 AM >>>>To: 'Bernhard Collini-Nocker'; Goldberg, Adam >>>>Cc: ipdvb at erg.abdn.ac.uk; Allison, Art; Matthew Goldman >>>>Subject: RE: Forward from Art Alison: WGLC ULE - Data Broadcast >>>>Descripto >>>>rs >>>> >>>>See below... >>>> >>>>Adam Goldberg >>>>Director, Television Standards & Policy Development >>>>Sharp Laboratories of America >>>>8605 Westwood Center Drive, Suite 206 >>>>Vienna, VA 22182 >>>>+1-703-556-4406 >>>>+1-703-556-4410 fax >>>>+1-571-276-0305 cell >>>> >>>> >>>>Bernhard Collini-Nocker wrote: >>>> >>>> >>>>>Goldberg, Adam wrote: >>>>> >>>>> >>>>>>I apologize for being "late to the party", but: >>>>>> >>>>>>I do not see a particular need to define new term "TS Logical >>> >>> >>>Channel", >>> >>> >>>>>and >>>>> >>>>> >>>>>>indeed doing so creates risks of ill-specification (such as those Art >>>>> >>>>> >>>>>points >>>>> >>>>> >>>>>>out), as well as confusion heaped upon someone familiar with MPEG-2 >>>>>>Transport (as typically used in entertainment delivery). >>>>> >>>>> >>>>>Unfortunately the MPEG-2 standards do not provide a reasonable term for >>>>>the purpose of networking. The question is whether other terms, for >>>>>example "PID network" or "PID stream" would be better received and >>>>>understood? >>>>>The term "TS logical channel" tries to verbally visualize that the >>>>>encapsulation uses a continouos stream of transport stream packets >>>>>using >>>>>one specific packet identifier to transport subnetwork data units. >>>>>Maybe >>>>>the term "TS (virtual) circuit" better names this? >>>> >>>> >>>>It is perhaps not well defined in 13818-1, but the term of art is >>>>"streams". Many people use "PID stream" which is a poor combination of >>>>words. I'd have no objection to defining a "SNDU Stream" as something >>>>like "a sequence of MPEG-2 Transport Stream packets identified by a >>>>common >>>>PID value" (or some such). >>>> >>>>Perhaps discussing 'virtual circuits' relative to a Transport Stream is >>>>begging for confusion. Use of any such words ("TS (virtual) circuit") >>>>needs careful definition, likely requiring the above SNDU Stream >>>>definition plus an explanation of what it means for multiple SNDU >>>>Streams >>>>to exist in a single Transport Stream. >>>> >>>> >>>> >>>>>>Furthermore, the definition is quite wrong with respect to ATSC and >>>> >>>> >>>>DVB >>>> >>>> >>>>>use >>>>> >>>>> >>>>>>of "specific TS Logical Channels". To my knowledge, this internet- >>>> >>>> >>>>draft >>>> >>>> >>>>>is >>>>> >>>>> >>>>>>the only document anywhere which uses such terms. It is certainly >>>> >>>> >>>>true >>>> >>>> >>>>>that >>>>> >>>>> >>>>>>MPEG, DVB and ATSC define //elementary streams// identified by >>>>> >>>>> >>>>>stream_type >>>>> >>>>> >>>>>>values. I suspect this is what is meant by "TS Logical Channel", but >>>> >>>> >>>>it >>>> >>>> >>>>>is >>>>> >>>>> >>>>>>difficult for me to tell. >>>>> >>>>> >>>>>I am not so sure, whether this analysis is correct. Elementary streams >>>>>are those that are transported as Packetized ES, whereas "auxillary" >>>>>data and signalling is transported as sections. Although a stream_type >>>>>in the program map section is used to reference both PESs and sections >>>>>the term elementary stream is used very vague and we tried to avoid >>>>>using it in the same vague manner. >>>> >>>> >>>>Perhaps I overstepped with "elementary stream". >>>> >>>>Consider the 13818-1 definition of "Packetized Elementary Stream": "A >>>>continuous sequence of PES packets of one elementary stream with one >>>>stream ID may be used to construct a PES Stream." (ISO/IEC >>>>13818-1:2000 p. >>>>xiii) >>>> >>>>Stuff carried as payload of Transport Stream packets are merely >>>>'payload'. >>>>What the draft starts to define is a new type of payload stream (that >>>>is, >>>>a new way to carry data in a transport stream). The definition is not >>>>compete. >>>> >>>> >>>> >>>>>According to, for example EN301192 v1.3.1, defines Data Piping as: >>>>>" The data broadcast service shall insert the data to be broadcast >>>>>directly in the payload of MPEG-2 TS packets." >>>>>That raises the question, how to call a continouos stream of MPEG-2 TS >>>>>packets with a certain PID? >>>>> >>>>>Further the standard details that: >>>>>"The data broadcast service may use the payload_unit_start_indicator >>>>>field and the transport_priority field of the MPEG-2 Transport Stream >>>>>packets in a service private way. The use of the adaptation_field shall >>>>>be MPEG-2 compliant." >>>>>ULE uses PUSI and does not utilize the AF. >>>>> >>>>>"The delivery of the bits in time through a data pipe is service >>>>>private >>>>>and is not specified in the present document." >>>>>It seems obvious that the use of the term "TS Data Pipe" would lead to >>>>>the wrong conclusion that ULE equals Data Piping. But Data Piping is >>>>>not >>>>>detailed at all, whereas ULE tries to be. >>>> >>>> >>>>I'm not going to argue that DVB's specification is complete. I will >>>>argue >>>>that ULE isn't complete. >>>> >>>> >>>> >>>>>>(from the draft) >>>>>> TS Logical Channel: Transport Stream Logical Channel. In this >>>>>> document, this term identifies a channel at the MPEG-2 level [ISO- >>>>>> MPEG]. It exists at level 2 of the ISO/OSI reference model. All >>>>>> packets sent over a TS Logical Channel carry the same PID value >>>>>> (this value is unique within a specific TS Multiplex). According to >>>>>> MPEG-2, some TS Logical Channels are reserved for specific >>>>>> signalling purposes. Other standards (e.g., ATSC, DVB) also reserve >>>>>> specific TS Logical Channels. >>>>>> >>>>>>While I'm commenting on this definition, it also seems to me that >>>>> >>>>> >>>>>"channel >>>>> >>>>> >>>>>>at the MPEG-2 level" is either wrong or also ill-specified. What's a >>>>>>channel? If you're talking about MPEG-2, it's certainly conceivable >>>>> >>>>> >>>>>that >>>>> >>>>> >>>>>>the reader may associate "channel" with "[television] channel" - which >>>>> >>>>> >>>>>are >>>>> >>>>> >>>>>>the subject of a large amount of ATSC and DVB systems. >>>>> >>>>> >>>>>The term channel is indeed problematic in the context of television, >>>>>however, network engineers might have a different understanding about >>>>>what a channel is. >>>>>According to ATIS a channel is "1. A connection between initiating and >>>>>terminating nodes of a circuit. 2. A single path provided by a >>>>>transmission medium via either (a) physical separation, such as by >>>>>multipair cable or (b) electrical separation, such as by frequency- or >>>>>time-division multiplexing. ..." >>>> >>>> >>>>I understand that 'channel' vis-?-vis networking has a different meaning >>>>than 'channel' vis-?-vis television. This was my point actually, that >>>>those familiar with MPEG transport should not be assumed to be >>>>networking- >>>>types (even when speaking with respect to ULE). >>>> >>>> >>>> >>>>>>Additionally, it is also wrong or ill-specified to say "According to >>>>> >>>>> >>>>>MPEG-2 >>>>> >>>>> >>>>>>... TS Logical Channels ...". There is no such concept defined or >>>> >>>> >>>>used >>>> >>>> >>>>>>within MPEG (unless what you really mean is elementary stream, in >>>> >>>> >>>>which >>>> >>>> >>>>>case >>>>> >>>>> >>>>>>what do you need this extraneous term for anyhow?). >>>>> >>>>> >>>>>Again, elementary stream is not exactly what is being meant: >>>>>For example EN 300468 v1.5.1 defines: >>>>>"component (ELEMENTARY Stream): one or more entities which together >>>>>make >>>>>up an event, e.g. video, audio, teletext" >>>>> >>>>>and says further: >>>>>"The component descriptor identifies the type of component stream and >>>>>may be used to provide a text description of the elementary stream" >>>>> >>>>>where: >>>>>"component_type: This 8-bit field specifies the type of the video, >>>>>audio >>>>>or EBU-data component. The coding of this field is specified in table >>>> >>>> >>>>26." >>>> >>>> >>>>>Table 26 then lists all kinds of video, audio, and teletext formats, >>>>>but >>>>>unfortunately no networking formats. >>>>> >>>>>At other places this standard is as innovative/creative in naming: >>>>>"event: grouping of elementary broadcast data streams with a defined >>>>>start and end time belonging to a common service, e.g. first half of a >>>>>football match, News Flash, first part of an entertainment show" >>>>>What is a "elementary broadcast data streams"? Not by guessing but by >>>>>definition? >>>>> >>>>> >>>>> >>>>>>In any case, Art is certainly correct that merely identifying a "TS >>>>> >>>>> >>>>>Logical >>>>> >>>>> >>>>>>Channel" as a sequence of packets identified with a common PID value >>>>> >>>>> >>>>>without >>>>> >>>>> >>>>>>identifying the PSI details is an invitation to multiplexers and >>>>>>remultiplexers to drop those packets on the floor. >>>>> >>>>> >>>>>Oh yes, this is the real problem of defining something outside >>>>>television standardiszation bodies: one risks that ULE packets are >>>>>being >>>>>dropped. >>>>>We have discussed basically two approaches: >>>>>1. define the PSI and get an ID, or tag, or "stream_type" for ULE, >>>>>or 2. >>>>>define ULE and let somebody else do the PSI work. >>>>>We have had some reasons for choice 2. >>>> >>>> >>>>This is a very easy thing to fix and something which should be done. >>>>Without defining a stream_type for ULE data, it is neither possible to >>>>construct a transport stream compliant with MPEG-2 nor one that >>>>interoperates with other ULE equipment. >>>> >>>>ATSC maintains a 'codepoint registry', and would be happy to allocate a >>>>stream_type value for ULE data upon request from IETF. Furthermore, the >>>>text to specify usage of the stream_type would be reasonably easy (and >>>>perhaps ties in to my suggested "SNDU Stream" definition (that is, >>>>define >>>>it as >>> >>> >>> >>>SNDU Stream: a sequence of MPEG-2 Transport Stream packets identified >>>by a >>>common PID value of stream_type <0xnn>. >>> >>>All that then remains, I think, would be to signal when a Program carries >>>SNDU Stream(s), and what it means when there are more than one SNDU >>>Stream >>>per program, or more than one Program that carries one or more SNDU >>>Streams. >>> >>> >>> >>>>>>If there remains an opportunity to repair what I believe to be errors >>>> >>>> >>>>in >>>> >>>> >>>>>the >>>>> >>>>> >>>>>>draft, I'm eager and willing to participate from a MPEG-2 >>>> >>>> >>>>entertainment >>>> >>>> >>>>>>(which is to say, legacy use of MPEG-2 Transport) point of view. >>>>> >>>>> >>>>>Of course the terms in the document should not conflict with meaning in >>>>>another context. However, ambiguous terms in other documents should be >>>>>avoided as well. >>>>> >>>>> >>>>> >>>>>>[Apologies for being strident at all, to say nothing of at such an >>>>>>apparently late stage - if the above is perceived as such] >>>>>> >>>>>>Regards, >>>>>>Adam Goldberg >>>>>>Director, Television Standards & Policy Development >>>>>>Sharp Laboratories of America >>>>>>8605 Westwood Center Drive, Suite 206 >>>>>>Vienna, VA 22182 >>>>>>+1-703-556-4406 >>>>>>+1-703-556-4410 fax >>>>>>+1-571-276-0305 cell >>>>>> >>>>>> >>>>>>-----Original Message----- >>>>>>From: owner-ipdvb at erg.abdn.ac.uk [mailto:owner-ipdvb at erg.abdn.ac.uk] >>>> >>>> >>>>On >>>> >>>> >>>>>>Behalf Of Gorry Fairhurst >>>>>>Sent: Friday, February 04, 2005 6:56 AM >>>>>>To: ipdvb at erg.abdn.ac.uk; Bernhard Collini-Nocker >>>>>>Cc: AAllison at nab.org >>>>>>Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast >>>>> >>>>> >>>>>Descriptors >>>>> >>>>> >>>>>>1) Done - point 1 was an edit mistake. >>>>>> >>>>>>2) I think some text on data broadcast descriptors, stream-type, >>>> >>>> >>>>or/and >>>> >>>> >>>>>PSI >>>>> >>>>> >>>>>>entries would be a valuable addition. >>>>>> >>>>>>On thinking about this, I wonder if the text about this should go at >>>> >>>> >>>>the >>>> >>>> >>>>>end >>>>> >>>>> >>>>>>of the Introduction (1.0) to the whole document, where people can see >>>> >>>> >>>>it >>>> >>>> >>>>>>clearly and then undesrtand that there may be something else needed >>>> >>>> >>>>for >>>> >>>> >>>>>>those >>>>>>networks that rely on PSI for remultiplexing! >>>>>> >>>>>>- Bernhard & others who understand PSI, can you work with Art to agree >>>>> >>>>> >>>>>the >>>>> >>>>> >>>>>>exact wording please? >>>>>> >>>>>>Gorry Fairhurst >>>>>>(ipdvb WG Chair) >>>>>> >>>>>>Gorry Fairhurst wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>WG please read and respond to this message. >>>>>>> >>>>>>>The following message was received on January 22nd before WGLC, but >>>> >>>> >>>>was >>>> >>>> >>>>>>>dropped because the email source address was not verified by the list >>>>>>>server. >>>>>>> >>>>>>>The exact text of the message follows. >>>>>>> >>>>>>>best wishes, >>>>>>> >>>>>>>Gorry >>>>>>>(ipdvb WG Chair) >>>>>>> >>>>>>>----- >>>>>>> >>>>>> >>>>>>1) >>>>>> >>>>>> >>>>>> >>>>>>>Thanks for considering my previous input... >>>>>>>I note that the new draft has an editorial oversight in that it >>>> >>>> >>>>contains >>>> >>>> >>>>>>>two definitions of PSI. I suggest the second should be deleted. >>>>>>> >>>>>> >>>>>>2) >>>>>> >>>>>> >>>>>> >>>>>>>I previously made a comment about the ancillary requirements when >>>> >>>> >>>>adding >>>> >>>> >>>>>a >>>>> >>>>> >>>>>>>TS logical channel to a TS multiplex and asserted there appeared >>>>>>>to be >>>>>>>under >>>>>>>specification. Perhaps it was viewed as out of scope, or perhaps I >>>>> >>>>> >>>>>simply >>>>> >>>>> >>>>>>>don't recognize the change that resulted. I can not find what >>>>> >>>>> >>>>>stream_type >>>>> >>>>> >>>>>>>is required to be used for the ULE stream when a "TS Logical Channel" >>>> >>>> >>>>is >>>> >>>> >>>>>>>added to a multiplex. >>>>> >>>>> >>>>>The problem here is the same as above. Without "applying" for a >>>>>"stream_type" for ULE there is no stream_type for ULE. In contrary why >>>>>should one register a stream_type value for ULE earlier than ULE is >>>>>standardized? >>>>> >>>>> >>>>> >>>>>>>I suggest at least an informative note be added in Section 6 (after >>>> >>>> >>>>the >>>> >>>> >>>>>>>third line which says: "These are transmitted using a single TS >>>> >>>> >>>>Logical >>>> >>>> >>>>>>>Channel over a TS Multiplex.") The note should say "PSI entries to be >>>>>>>consistent with [ISO-MPEG] when constructing a conformant TS >>>>>>>Multiplex >>>>> >>>>> >>>>>and >>>>> >>>>> >>>>>>>means for Receivers to locate each such TS Logical Channel are >>>>>>>outside >>>>> >>>>> >>>>>the >>>>> >>>>> >>>>>>>scope of this recommendation." >>>>> >>>>> >>>>>Thanks, this is a very helpful suggestion for potential readers. In >>>>>addition the ipdvb-wg works on providing signalling other than PSI/SI. >>>>> >>>>> >>>>> >>>>>>>Reason: >>>>>>>Just inserting a "TS Logical Channel" without including a >>>>>>>TS_Program_map_section that lists the PID and a stream_type does not >>>>>>>appear to me to result in a strictly MPEG-2 conformant bit stream; >>>> >>>> >>>>and >>>> >>>> >>>>>>>practically >>>>>>>could result in the PIDs being dropped by a remultiplexer. If the >>>>> >>>>> >>>>>means >>>>> >>>>> >>>>>>>for binding the inserted element into a multiplex and subsequent >>>>> >>>>> >>>>>discovery >>>>> >>>>> >>>>>>>is to be covered in another document, a pointer to that document >>>>>>>would >>>>> >>>>> >>>>>be >>>>> >>>>> >>>>>>>more helpful than this warning. It seems at least a warning is needed >>>>> >>>>> >>>>>and >>>>> >>>>> >>>>>>>preferably a pointer to where this next level of TS construction is >>>>>>>defined. >>>>> >>>>> >>>>>From an architectural point of view it is a reasonable assupmption that >>>>>whatever is being sent in a TS multiplex should be referenced. However, >>>>>the reality is that "ghost" PIDs do occur in many services either >>>>>accidentially or for well-defined reasons. >>>>> >>>>>What is the penalty for not being strictly MPEG-2 conformant/compliant? >>>>> >>>>> >>>>> >>>>>>>Art Allison >>>>>>>Director, Advanced Engineering >>>>>>>NAB Science & Technology >>>>>>>1771 N St NW, Washington Dc 20036 >>>>>>>202 429 5418 >>>>> >>>>> >>>>> >>>>>Regards, >>>>>Bernhard Collini-Nocker >>>>> >>>>> >>> >>> >> > > > From mariejose.montpetit at verizon.net Mon Feb 7 20:55:57 2005 From: mariejose.montpetit at verizon.net (Marie-Jose Montpetit) Date: Mon, 7 Feb 2005 15:55:57 -0500 Subject: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto rs References: <08259490B3BC3140B549DD0907A5644811D664@admsrvnt10.enet.sharplabs.com> <420763AB.50107@cosy.sbg.ac.at> <420772FE.7050201@erg.abdn.ac.uk> Message-ID: <01d401c50d57$74092780$ad02a8c0@copernicus> I think we need to close on some of those issues and move forward. Here is what I propose which would be inline with the conclusions of the Architecture Draft: (1) ULE is encapsulation only - it is not the purpose nor the usage of ULE to dwell in SI/PSI table issues nor any other protocol; so we leave the draft to be mostly what it is now (pending small changes proposed by Gorry) (2) PSI/SI scanning is part of the Address Resolution Draft as regard management of addressing; it will be further discussed there and focus given to the issues raised in this thread (3) Someone (Adam and/or team) proposes WG work and a draft on ATSC concerns on PSI/SI issues and ULE; inclusion of cable TV concerns in addition to satellite would be welcome and has been one of my goals for the group (4) we close on ULE and get to discuss the other items further at IETF Thanks Marie-Jose ----- Original Message ----- From: "Gorry Fairhurst" To: Cc: "Goldberg, Adam" ; "Allison, Art" ; "Matthew Goldman" Sent: Monday, February 07, 2005 8:54 AM Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto rs > > So.... > > 1. The term "TS Logical Channel" was discussed a lot at the begining of the > WG. As I recall, the reason for the new term, was that at this time the WG > could not find a suitably "unbiased" term for the set of TS Packets with a > common PID value (raw TS, DSMCC, Private Section, PES, etc). One key objective > was to find a term that did not carry extra semantics, and was understandable > by the networking community - this is after all intended as a part of the > RFC-series, and we need to make this accessible to people familiar with using > IP over Ethernet, MPLS, ATM, Fibre Channel, Firewire, SDH/SONET, etc. > T > > we shoudl note that the term "TS Logical Channel term already appears (and is > discussed in some detail) in the document draft-ietf-ipvb-arch-xx.txt and that > this HAS already complete WGLC. If it IS WRONG we still have a chance to fix > the definition/term, if we have to. Specifically, is there already a > well-accepted term for the set of TS Packets with a common PID value (raw TS, > DSMCC, Private Section, PES, etc) that we should use or refer to? > > > 2. I'm not against defining another term "ULE Stream", "SNDU Stream", etc if > that helps to describe the set of TS packets with a specific PID used for ULE, > especially when talking about PSI. > > Bernhard, is there an opportunity of inserting a simple statement as the final > paragraph of the introduction which says that to use ULE streams within an > MPEG-2 compliant multiplex may require appropriate PSI entries... I think Art > already proposed some specific wording that could be used or modified? > > > 3) Once teh ULE spec is agreed and an RFC number issued, I can also see great > advantage in assigning a descriptor for this in ATSC. I think the WG SHOULD > should explore this at the next stage. > > > Gorry > > Bernhard Collini-Nocker wrote: > > > Hello, > > > > let me try to summarize the two major points being raised and what the > > discussion is about: > > 1. the name/definition of "TS Logical Channel" is not well received and > > the name/definition of a "SNDU stream" is proposed instead > > 2. it is proposed to consider MPEG-2 conformance in specifying that ULE > > requires a specific stream_type value for the PMT > > > > Personally I have no objection against 1., because it is easy to change > > and improves wording and naming (unless somebody has an even better > > name for it). > > For 2. my concern is that mentioning stream_type may require some > > additional wording about PSI/SI in general, which is likely out of scope > > of the ULE draft. Even worse, in introducing a "world" besides the > > encapsulation/decapsulation of ULE, this may result in further confusion > > about what the MPEG-2/Section layer does in addition to and/or in > > comparison to ULE/IP. Actually some difficult question may arise from > > this direction, for example whether it is a wishful requirement for ULE > > to support PAT/PMT/NIT/INT/... table parsing? > > > > Any opinions, recommendations or suggestions about this? > > > > Regards, > > Bernhard > > > > Goldberg, Adam wrote: > > > >> ARGH. I fat-fingered 'send' before completing the email. See below. > >> > >> Adam Goldberg > >> Director, Television Standards & Policy Development > >> Sharp Laboratories of America > >> 8605 Westwood Center Drive, Suite 206 > >> Vienna, VA 22182 > >> +1-703-556-4406 > >> +1-703-556-4410 fax > >> +1-571-276-0305 cell > >> > >> > >> > >>> -----Original Message----- > >>> From: Goldberg, Adam > >>> Sent: Monday, February 07, 2005 12:42 AM > >>> To: 'Bernhard Collini-Nocker'; Goldberg, Adam > >>> Cc: ipdvb at erg.abdn.ac.uk; Allison, Art; Matthew Goldman > >>> Subject: RE: Forward from Art Alison: WGLC ULE - Data Broadcast > >>> Descripto > >>> rs > >>> > >>> See below... > >>> > >>> Adam Goldberg > >>> Director, Television Standards & Policy Development > >>> Sharp Laboratories of America > >>> 8605 Westwood Center Drive, Suite 206 > >>> Vienna, VA 22182 > >>> +1-703-556-4406 > >>> +1-703-556-4410 fax > >>> +1-571-276-0305 cell > >>> > >>> > >>> Bernhard Collini-Nocker wrote: > >>> > >>>> Goldberg, Adam wrote: > >>>> > >>>>> I apologize for being "late to the party", but: > >>>>> > >>>>> I do not see a particular need to define new term "TS Logical > >> > >> > >> Channel", > >> > >>>> and > >>>> > >>>>> indeed doing so creates risks of ill-specification (such as those Art > >>>> > >>>> > >>>> points > >>>> > >>>>> out), as well as confusion heaped upon someone familiar with MPEG-2 > >>>>> Transport (as typically used in entertainment delivery). > >>>> > >>>> > >>>> Unfortunately the MPEG-2 standards do not provide a reasonable term for > >>>> the purpose of networking. The question is whether other terms, for > >>>> example "PID network" or "PID stream" would be better received and > >>>> understood? > >>>> The term "TS logical channel" tries to verbally visualize that the > >>>> encapsulation uses a continouos stream of transport stream packets > >>>> using > >>>> one specific packet identifier to transport subnetwork data units. > >>>> Maybe > >>>> the term "TS (virtual) circuit" better names this? > >>> > >>> > >>> It is perhaps not well defined in 13818-1, but the term of art is > >>> "streams". Many people use "PID stream" which is a poor combination of > >>> words. I'd have no objection to defining a "SNDU Stream" as something > >>> like "a sequence of MPEG-2 Transport Stream packets identified by a > >>> common > >>> PID value" (or some such). > >>> > >>> Perhaps discussing 'virtual circuits' relative to a Transport Stream is > >>> begging for confusion. Use of any such words ("TS (virtual) circuit") > >>> needs careful definition, likely requiring the above SNDU Stream > >>> definition plus an explanation of what it means for multiple SNDU > >>> Streams > >>> to exist in a single Transport Stream. > >>> > >>> > >>>>> Furthermore, the definition is quite wrong with respect to ATSC and > >>> > >>> > >>> DVB > >>> > >>>> use > >>>> > >>>>> of "specific TS Logical Channels". To my knowledge, this internet- > >>> > >>> > >>> draft > >>> > >>>> is > >>>> > >>>>> the only document anywhere which uses such terms. It is certainly > >>> > >>> > >>> true > >>> > >>>> that > >>>> > >>>>> MPEG, DVB and ATSC define //elementary streams// identified by > >>>> > >>>> > >>>> stream_type > >>>> > >>>>> values. I suspect this is what is meant by "TS Logical Channel", but > >>> > >>> > >>> it > >>> > >>>> is > >>>> > >>>>> difficult for me to tell. > >>>> > >>>> > >>>> I am not so sure, whether this analysis is correct. Elementary streams > >>>> are those that are transported as Packetized ES, whereas "auxillary" > >>>> data and signalling is transported as sections. Although a stream_type > >>>> in the program map section is used to reference both PESs and sections > >>>> the term elementary stream is used very vague and we tried to avoid > >>>> using it in the same vague manner. > >>> > >>> > >>> Perhaps I overstepped with "elementary stream". > >>> > >>> Consider the 13818-1 definition of "Packetized Elementary Stream": "A > >>> continuous sequence of PES packets of one elementary stream with one > >>> stream ID may be used to construct a PES Stream." (ISO/IEC > >>> 13818-1:2000 p. > >>> xiii) > >>> > >>> Stuff carried as payload of Transport Stream packets are merely > >>> 'payload'. > >>> What the draft starts to define is a new type of payload stream (that > >>> is, > >>> a new way to carry data in a transport stream). The definition is not > >>> compete. > >>> > >>> > >>>> According to, for example EN301192 v1.3.1, defines Data Piping as: > >>>> " The data broadcast service shall insert the data to be broadcast > >>>> directly in the payload of MPEG-2 TS packets." > >>>> That raises the question, how to call a continouos stream of MPEG-2 TS > >>>> packets with a certain PID? > >>>> > >>>> Further the standard details that: > >>>> "The data broadcast service may use the payload_unit_start_indicator > >>>> field and the transport_priority field of the MPEG-2 Transport Stream > >>>> packets in a service private way. The use of the adaptation_field shall > >>>> be MPEG-2 compliant." > >>>> ULE uses PUSI and does not utilize the AF. > >>>> > >>>> "The delivery of the bits in time through a data pipe is service > >>>> private > >>>> and is not specified in the present document." > >>>> It seems obvious that the use of the term "TS Data Pipe" would lead to > >>>> the wrong conclusion that ULE equals Data Piping. But Data Piping is > >>>> not > >>>> detailed at all, whereas ULE tries to be. > >>> > >>> > >>> I'm not going to argue that DVB's specification is complete. I will > >>> argue > >>> that ULE isn't complete. > >>> > >>> > >>>>> (from the draft) > >>>>> TS Logical Channel: Transport Stream Logical Channel. In this > >>>>> document, this term identifies a channel at the MPEG-2 level [ISO- > >>>>> MPEG]. It exists at level 2 of the ISO/OSI reference model. All > >>>>> packets sent over a TS Logical Channel carry the same PID value > >>>>> (this value is unique within a specific TS Multiplex). According to > >>>>> MPEG-2, some TS Logical Channels are reserved for specific > >>>>> signalling purposes. Other standards (e.g., ATSC, DVB) also reserve > >>>>> specific TS Logical Channels. > >>>>> > >>>>> While I'm commenting on this definition, it also seems to me that > >>>> > >>>> > >>>> "channel > >>>> > >>>>> at the MPEG-2 level" is either wrong or also ill-specified. What's a > >>>>> channel? If you're talking about MPEG-2, it's certainly conceivable > >>>> > >>>> > >>>> that > >>>> > >>>>> the reader may associate "channel" with "[television] channel" - which > >>>> > >>>> > >>>> are > >>>> > >>>>> the subject of a large amount of ATSC and DVB systems. > >>>> > >>>> > >>>> The term channel is indeed problematic in the context of television, > >>>> however, network engineers might have a different understanding about > >>>> what a channel is. > >>>> According to ATIS a channel is "1. A connection between initiating and > >>>> terminating nodes of a circuit. 2. A single path provided by a > >>>> transmission medium via either (a) physical separation, such as by > >>>> multipair cable or (b) electrical separation, such as by frequency- or > >>>> time-division multiplexing. ..." > >>> > >>> > >>> I understand that 'channel' vis-?-vis networking has a different meaning > >>> than 'channel' vis-?-vis television. This was my point actually, that > >>> those familiar with MPEG transport should not be assumed to be > >>> networking- > >>> types (even when speaking with respect to ULE). > >>> > >>> > >>>>> Additionally, it is also wrong or ill-specified to say "According to > >>>> > >>>> > >>>> MPEG-2 > >>>> > >>>>> ... TS Logical Channels ...". There is no such concept defined or > >>> > >>> > >>> used > >>> > >>>>> within MPEG (unless what you really mean is elementary stream, in > >>> > >>> > >>> which > >>> > >>>> case > >>>> > >>>>> what do you need this extraneous term for anyhow?). > >>>> > >>>> > >>>> Again, elementary stream is not exactly what is being meant: > >>>> For example EN 300468 v1.5.1 defines: > >>>> "component (ELEMENTARY Stream): one or more entities which together > >>>> make > >>>> up an event, e.g. video, audio, teletext" > >>>> > >>>> and says further: > >>>> "The component descriptor identifies the type of component stream and > >>>> may be used to provide a text description of the elementary stream" > >>>> > >>>> where: > >>>> "component_type: This 8-bit field specifies the type of the video, > >>>> audio > >>>> or EBU-data component. The coding of this field is specified in table > >>> > >>> > >>> 26." > >>> > >>>> Table 26 then lists all kinds of video, audio, and teletext formats, > >>>> but > >>>> unfortunately no networking formats. > >>>> > >>>> At other places this standard is as innovative/creative in naming: > >>>> "event: grouping of elementary broadcast data streams with a defined > >>>> start and end time belonging to a common service, e.g. first half of a > >>>> football match, News Flash, first part of an entertainment show" > >>>> What is a "elementary broadcast data streams"? Not by guessing but by > >>>> definition? > >>>> > >>>> > >>>>> In any case, Art is certainly correct that merely identifying a "TS > >>>> > >>>> > >>>> Logical > >>>> > >>>>> Channel" as a sequence of packets identified with a common PID value > >>>> > >>>> > >>>> without > >>>> > >>>>> identifying the PSI details is an invitation to multiplexers and > >>>>> remultiplexers to drop those packets on the floor. > >>>> > >>>> > >>>> Oh yes, this is the real problem of defining something outside > >>>> television standardiszation bodies: one risks that ULE packets are > >>>> being > >>>> dropped. > >>>> We have discussed basically two approaches: > >>>> 1. define the PSI and get an ID, or tag, or "stream_type" for ULE, > >>>> or 2. > >>>> define ULE and let somebody else do the PSI work. > >>>> We have had some reasons for choice 2. > >>> > >>> > >>> This is a very easy thing to fix and something which should be done. > >>> Without defining a stream_type for ULE data, it is neither possible to > >>> construct a transport stream compliant with MPEG-2 nor one that > >>> interoperates with other ULE equipment. > >>> > >>> ATSC maintains a 'codepoint registry', and would be happy to allocate a > >>> stream_type value for ULE data upon request from IETF. Furthermore, the > >>> text to specify usage of the stream_type would be reasonably easy (and > >>> perhaps ties in to my suggested "SNDU Stream" definition (that is, > >>> define > >>> it as > >> > >> > >> > >> SNDU Stream: a sequence of MPEG-2 Transport Stream packets identified > >> by a > >> common PID value of stream_type <0xnn>. > >> > >> All that then remains, I think, would be to signal when a Program carries > >> SNDU Stream(s), and what it means when there are more than one SNDU > >> Stream > >> per program, or more than one Program that carries one or more SNDU > >> Streams. > >> > >> > >>>>> If there remains an opportunity to repair what I believe to be errors > >>> > >>> > >>> in > >>> > >>>> the > >>>> > >>>>> draft, I'm eager and willing to participate from a MPEG-2 > >>> > >>> > >>> entertainment > >>> > >>>>> (which is to say, legacy use of MPEG-2 Transport) point of view. > >>>> > >>>> > >>>> Of course the terms in the document should not conflict with meaning in > >>>> another context. However, ambiguous terms in other documents should be > >>>> avoided as well. > >>>> > >>>> > >>>>> [Apologies for being strident at all, to say nothing of at such an > >>>>> apparently late stage - if the above is perceived as such] > >>>>> > >>>>> Regards, > >>>>> Adam Goldberg > >>>>> Director, Television Standards & Policy Development > >>>>> Sharp Laboratories of America > >>>>> 8605 Westwood Center Drive, Suite 206 > >>>>> Vienna, VA 22182 > >>>>> +1-703-556-4406 > >>>>> +1-703-556-4410 fax > >>>>> +1-571-276-0305 cell > >>>>> > >>>>> > >>>>> -----Original Message----- > >>>>> From: owner-ipdvb at erg.abdn.ac.uk [mailto:owner-ipdvb at erg.abdn.ac.uk] > >>> > >>> > >>> On > >>> > >>>>> Behalf Of Gorry Fairhurst > >>>>> Sent: Friday, February 04, 2005 6:56 AM > >>>>> To: ipdvb at erg.abdn.ac.uk; Bernhard Collini-Nocker > >>>>> Cc: AAllison at nab.org > >>>>> Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast > >>>> > >>>> > >>>> Descriptors > >>>> > >>>>> > >>>>> 1) Done - point 1 was an edit mistake. > >>>>> > >>>>> 2) I think some text on data broadcast descriptors, stream-type, > >>> > >>> > >>> or/and > >>> > >>>> PSI > >>>> > >>>>> entries would be a valuable addition. > >>>>> > >>>>> On thinking about this, I wonder if the text about this should go at > >>> > >>> > >>> the > >>> > >>>> end > >>>> > >>>>> of the Introduction (1.0) to the whole document, where people can see > >>> > >>> > >>> it > >>> > >>>>> clearly and then undesrtand that there may be something else needed > >>> > >>> > >>> for > >>> > >>>>> those > >>>>> networks that rely on PSI for remultiplexing! > >>>>> > >>>>> - Bernhard & others who understand PSI, can you work with Art to agree > >>>> > >>>> > >>>> the > >>>> > >>>>> exact wording please? > >>>>> > >>>>> Gorry Fairhurst > >>>>> (ipdvb WG Chair) > >>>>> > >>>>> Gorry Fairhurst wrote: > >>>>> > >>>>> > >>>>> > >>>>>> WG please read and respond to this message. > >>>>>> > >>>>>> The following message was received on January 22nd before WGLC, but > >>> > >>> > >>> was > >>> > >>>>>> dropped because the email source address was not verified by the list > >>>>>> server. > >>>>>> > >>>>>> The exact text of the message follows. > >>>>>> > >>>>>> best wishes, > >>>>>> > >>>>>> Gorry > >>>>>> (ipdvb WG Chair) > >>>>>> > >>>>>> ----- > >>>>>> > >>>>> > >>>>> 1) > >>>>> > >>>>> > >>>>>> Thanks for considering my previous input... > >>>>>> I note that the new draft has an editorial oversight in that it > >>> > >>> > >>> contains > >>> > >>>>>> two definitions of PSI. I suggest the second should be deleted. > >>>>>> > >>>>> > >>>>> 2) > >>>>> > >>>>> > >>>>>> I previously made a comment about the ancillary requirements when > >>> > >>> > >>> adding > >>> > >>>> a > >>>> > >>>>>> TS logical channel to a TS multiplex and asserted there appeared > >>>>>> to be > >>>>>> under > >>>>>> specification. Perhaps it was viewed as out of scope, or perhaps I > >>>> > >>>> > >>>> simply > >>>> > >>>>>> don't recognize the change that resulted. I can not find what > >>>> > >>>> > >>>> stream_type > >>>> > >>>>>> is required to be used for the ULE stream when a "TS Logical Channel" > >>> > >>> > >>> is > >>> > >>>>>> added to a multiplex. > >>>> > >>>> > >>>> The problem here is the same as above. Without "applying" for a > >>>> "stream_type" for ULE there is no stream_type for ULE. In contrary why > >>>> should one register a stream_type value for ULE earlier than ULE is > >>>> standardized? > >>>> > >>>> > >>>>>> I suggest at least an informative note be added in Section 6 (after > >>> > >>> > >>> the > >>> > >>>>>> third line which says: "These are transmitted using a single TS > >>> > >>> > >>> Logical > >>> > >>>>>> Channel over a TS Multiplex.") The note should say "PSI entries to be > >>>>>> consistent with [ISO-MPEG] when constructing a conformant TS > >>>>>> Multiplex > >>>> > >>>> > >>>> and > >>>> > >>>>>> means for Receivers to locate each such TS Logical Channel are > >>>>>> outside > >>>> > >>>> > >>>> the > >>>> > >>>>>> scope of this recommendation." > >>>> > >>>> > >>>> Thanks, this is a very helpful suggestion for potential readers. In > >>>> addition the ipdvb-wg works on providing signalling other than PSI/SI. > >>>> > >>>> > >>>>>> Reason: > >>>>>> Just inserting a "TS Logical Channel" without including a > >>>>>> TS_Program_map_section that lists the PID and a stream_type does not > >>>>>> appear to me to result in a strictly MPEG-2 conformant bit stream; > >>> > >>> > >>> and > >>> > >>>>>> practically > >>>>>> could result in the PIDs being dropped by a remultiplexer. If the > >>>> > >>>> > >>>> means > >>>> > >>>>>> for binding the inserted element into a multiplex and subsequent > >>>> > >>>> > >>>> discovery > >>>> > >>>>>> is to be covered in another document, a pointer to that document > >>>>>> would > >>>> > >>>> > >>>> be > >>>> > >>>>>> more helpful than this warning. It seems at least a warning is needed > >>>> > >>>> > >>>> and > >>>> > >>>>>> preferably a pointer to where this next level of TS construction is > >>>>>> defined. > >>>> > >>>> > >>>> From an architectural point of view it is a reasonable assupmption that > >>>> whatever is being sent in a TS multiplex should be referenced. However, > >>>> the reality is that "ghost" PIDs do occur in many services either > >>>> accidentially or for well-defined reasons. > >>>> > >>>> What is the penalty for not being strictly MPEG-2 conformant/compliant? > >>>> > >>>> > >>>>>> Art Allison > >>>>>> Director, Advanced Engineering > >>>>>> NAB Science & Technology > >>>>>> 1771 N St NW, Washington Dc 20036 > >>>>>> 202 429 5418 > >>>> > >>>> > >>>> > >>>> Regards, > >>>> Bernhard Collini-Nocker > >>>> > >>>> > >> > >> > > > > > From agoldberg at sharplabs.com Tue Feb 8 05:25:11 2005 From: agoldberg at sharplabs.com (Goldberg, Adam) Date: Mon, 7 Feb 2005 21:25:11 -0800 Subject: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto rs Message-ID: <08259490B3BC3140B549DD0907A5644811D697@admsrvnt10.enet.sharplabs.com> Re #2 below, without discussion of PSI it will be both (1) difficult for equipment to interoperate in that they may not be able to find the PID value in use for SNDU streams, and (2) passing through non-SNDU-aware MPEG Transport equipment (of which none exists, I suppose) is not likely (certainly not guaranteed). I note from another response that the carriage may be specified in another document. That seems fine, but perhaps mention should be made about it. In any case, 'TS Logical Channel' remains irksome to me. I'll respond separately to other responses. Adam Goldberg Director, Television Standards & Policy Development Sharp Laboratories of America 8605 Westwood Center Drive, Suite 206 Vienna, VA 22182 +1-703-556-4406 +1-703-556-4410 fax +1-571-276-0305 cell > -----Original Message----- > From: Bernhard Collini-Nocker [mailto:bnocker at cosy.sbg.ac.at] > Sent: Monday, February 07, 2005 7:49 AM > To: ipdvb at erg.abdn.ac.uk > Cc: Goldberg, Adam; Allison, Art; Matthew Goldman > Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto > rs > > Hello, > > let me try to summarize the two major points being raised and what the > discussion is about: > 1. the name/definition of "TS Logical Channel" is not well received and > the name/definition of a "SNDU stream" is proposed instead > 2. it is proposed to consider MPEG-2 conformance in specifying that ULE > requires a specific stream_type value for the PMT > > Personally I have no objection against 1., because it is easy to change > and improves wording and naming (unless somebody has an even better > name for it). > For 2. my concern is that mentioning stream_type may require some > additional wording about PSI/SI in general, which is likely out of scope > of the ULE draft. Even worse, in introducing a "world" besides the > encapsulation/decapsulation of ULE, this may result in further confusion > about what the MPEG-2/Section layer does in addition to and/or in > comparison to ULE/IP. Actually some difficult question may arise from > this direction, for example whether it is a wishful requirement for ULE > to support PAT/PMT/NIT/INT/... table parsing? > > Any opinions, recommendations or suggestions about this? > > Regards, > Bernhard > > Goldberg, Adam wrote: > > ARGH. I fat-fingered 'send' before completing the email. See below. > > > > Adam Goldberg > > Director, Television Standards & Policy Development > > Sharp Laboratories of America > > 8605 Westwood Center Drive, Suite 206 > > Vienna, VA 22182 > > +1-703-556-4406 > > +1-703-556-4410 fax > > +1-571-276-0305 cell > > > > > > > >>-----Original Message----- > >>From: Goldberg, Adam > >>Sent: Monday, February 07, 2005 12:42 AM > >>To: 'Bernhard Collini-Nocker'; Goldberg, Adam > >>Cc: ipdvb at erg.abdn.ac.uk; Allison, Art; Matthew Goldman > >>Subject: RE: Forward from Art Alison: WGLC ULE - Data Broadcast > Descripto > >>rs > >> > >>See below... > >> > >>Adam Goldberg > >>Director, Television Standards & Policy Development > >>Sharp Laboratories of America > >>8605 Westwood Center Drive, Suite 206 > >>Vienna, VA 22182 > >>+1-703-556-4406 > >>+1-703-556-4410 fax > >>+1-571-276-0305 cell > >> > >> > >>Bernhard Collini-Nocker wrote: > >> > >>>Goldberg, Adam wrote: > >>> > >>>>I apologize for being "late to the party", but: > >>>> > >>>>I do not see a particular need to define new term "TS Logical > > > > Channel", > > > >>>and > >>> > >>>>indeed doing so creates risks of ill-specification (such as those Art > >>> > >>>points > >>> > >>>>out), as well as confusion heaped upon someone familiar with MPEG-2 > >>>>Transport (as typically used in entertainment delivery). > >>> > >>>Unfortunately the MPEG-2 standards do not provide a reasonable term for > >>>the purpose of networking. The question is whether other terms, for > >>>example "PID network" or "PID stream" would be better received and > >>>understood? > >>>The term "TS logical channel" tries to verbally visualize that the > >>>encapsulation uses a continouos stream of transport stream packets > using > >>>one specific packet identifier to transport subnetwork data units. > Maybe > >>>the term "TS (virtual) circuit" better names this? > >> > >>It is perhaps not well defined in 13818-1, but the term of art is > >>"streams". Many people use "PID stream" which is a poor combination of > >>words. I'd have no objection to defining a "SNDU Stream" as something > >>like "a sequence of MPEG-2 Transport Stream packets identified by a > common > >>PID value" (or some such). > >> > >>Perhaps discussing 'virtual circuits' relative to a Transport Stream is > >>begging for confusion. Use of any such words ("TS (virtual) circuit") > >>needs careful definition, likely requiring the above SNDU Stream > >>definition plus an explanation of what it means for multiple SNDU > Streams > >>to exist in a single Transport Stream. > >> > >> > >>>>Furthermore, the definition is quite wrong with respect to ATSC and > >> > >>DVB > >> > >>>use > >>> > >>>>of "specific TS Logical Channels". To my knowledge, this internet- > >> > >>draft > >> > >>>is > >>> > >>>>the only document anywhere which uses such terms. It is certainly > >> > >>true > >> > >>>that > >>> > >>>>MPEG, DVB and ATSC define //elementary streams// identified by > >>> > >>>stream_type > >>> > >>>>values. I suspect this is what is meant by "TS Logical Channel", but > >> > >>it > >> > >>>is > >>> > >>>>difficult for me to tell. > >>> > >>>I am not so sure, whether this analysis is correct. Elementary streams > >>>are those that are transported as Packetized ES, whereas "auxillary" > >>>data and signalling is transported as sections. Although a stream_type > >>>in the program map section is used to reference both PESs and sections > >>>the term elementary stream is used very vague and we tried to avoid > >>>using it in the same vague manner. > >> > >>Perhaps I overstepped with "elementary stream". > >> > >>Consider the 13818-1 definition of "Packetized Elementary Stream": "A > >>continuous sequence of PES packets of one elementary stream with one > >>stream ID may be used to construct a PES Stream." (ISO/IEC 13818-1:2000 > p. > >>xiii) > >> > >>Stuff carried as payload of Transport Stream packets are merely > 'payload'. > >>What the draft starts to define is a new type of payload stream (that is, > >>a new way to carry data in a transport stream). The definition is not > >>compete. > >> > >> > >>>According to, for example EN301192 v1.3.1, defines Data Piping as: > >>>" The data broadcast service shall insert the data to be broadcast > >>>directly in the payload of MPEG-2 TS packets." > >>>That raises the question, how to call a continouos stream of MPEG-2 TS > >>>packets with a certain PID? > >>> > >>>Further the standard details that: > >>>"The data broadcast service may use the payload_unit_start_indicator > >>>field and the transport_priority field of the MPEG-2 Transport Stream > >>>packets in a service private way. The use of the adaptation_field shall > >>>be MPEG-2 compliant." > >>>ULE uses PUSI and does not utilize the AF. > >>> > >>>"The delivery of the bits in time through a data pipe is service > private > >>>and is not specified in the present document." > >>>It seems obvious that the use of the term "TS Data Pipe" would lead to > >>>the wrong conclusion that ULE equals Data Piping. But Data Piping is > not > >>>detailed at all, whereas ULE tries to be. > >> > >>I'm not going to argue that DVB's specification is complete. I will > argue > >>that ULE isn't complete. > >> > >> > >>>>(from the draft) > >>>> TS Logical Channel: Transport Stream Logical Channel. In this > >>>> document, this term identifies a channel at the MPEG-2 level [ISO- > >>>> MPEG]. It exists at level 2 of the ISO/OSI reference model. All > >>>> packets sent over a TS Logical Channel carry the same PID value > >>>> (this value is unique within a specific TS Multiplex). According to > >>>> MPEG-2, some TS Logical Channels are reserved for specific > >>>> signalling purposes. Other standards (e.g., ATSC, DVB) also reserve > >>>> specific TS Logical Channels. > >>>> > >>>>While I'm commenting on this definition, it also seems to me that > >>> > >>>"channel > >>> > >>>>at the MPEG-2 level" is either wrong or also ill-specified. What's a > >>>>channel? If you're talking about MPEG-2, it's certainly conceivable > >>> > >>>that > >>> > >>>>the reader may associate "channel" with "[television] channel" - which > >>> > >>>are > >>> > >>>>the subject of a large amount of ATSC and DVB systems. > >>> > >>>The term channel is indeed problematic in the context of television, > >>>however, network engineers might have a different understanding about > >>>what a channel is. > >>>According to ATIS a channel is "1. A connection between initiating and > >>>terminating nodes of a circuit. 2. A single path provided by a > >>>transmission medium via either (a) physical separation, such as by > >>>multipair cable or (b) electrical separation, such as by frequency- or > >>>time-division multiplexing. ..." > >> > >>I understand that 'channel' vis-?-vis networking has a different meaning > >>than 'channel' vis-?-vis television. This was my point actually, that > >>those familiar with MPEG transport should not be assumed to be > networking- > >>types (even when speaking with respect to ULE). > >> > >> > >>>>Additionally, it is also wrong or ill-specified to say "According to > >>> > >>>MPEG-2 > >>> > >>>>... TS Logical Channels ...". There is no such concept defined or > >> > >>used > >> > >>>>within MPEG (unless what you really mean is elementary stream, in > >> > >>which > >> > >>>case > >>> > >>>>what do you need this extraneous term for anyhow?). > >>> > >>>Again, elementary stream is not exactly what is being meant: > >>>For example EN 300468 v1.5.1 defines: > >>>"component (ELEMENTARY Stream): one or more entities which together > make > >>>up an event, e.g. video, audio, teletext" > >>> > >>>and says further: > >>>"The component descriptor identifies the type of component stream and > >>>may be used to provide a text description of the elementary stream" > >>> > >>>where: > >>>"component_type: This 8-bit field specifies the type of the video, > audio > >>>or EBU-data component. The coding of this field is specified in table > >> > >>26." > >> > >>>Table 26 then lists all kinds of video, audio, and teletext formats, > but > >>>unfortunately no networking formats. > >>> > >>>At other places this standard is as innovative/creative in naming: > >>>"event: grouping of elementary broadcast data streams with a defined > >>>start and end time belonging to a common service, e.g. first half of a > >>>football match, News Flash, first part of an entertainment show" > >>>What is a "elementary broadcast data streams"? Not by guessing but by > >>>definition? > >>> > >>> > >>>>In any case, Art is certainly correct that merely identifying a "TS > >>> > >>>Logical > >>> > >>>>Channel" as a sequence of packets identified with a common PID value > >>> > >>>without > >>> > >>>>identifying the PSI details is an invitation to multiplexers and > >>>>remultiplexers to drop those packets on the floor. > >>> > >>>Oh yes, this is the real problem of defining something outside > >>>television standardiszation bodies: one risks that ULE packets are > being > >>>dropped. > >>>We have discussed basically two approaches: > >>>1. define the PSI and get an ID, or tag, or "stream_type" for ULE, or 2. > >>>define ULE and let somebody else do the PSI work. > >>>We have had some reasons for choice 2. > >> > >>This is a very easy thing to fix and something which should be done. > >>Without defining a stream_type for ULE data, it is neither possible to > >>construct a transport stream compliant with MPEG-2 nor one that > >>interoperates with other ULE equipment. > >> > >>ATSC maintains a 'codepoint registry', and would be happy to allocate a > >>stream_type value for ULE data upon request from IETF. Furthermore, the > >>text to specify usage of the stream_type would be reasonably easy (and > >>perhaps ties in to my suggested "SNDU Stream" definition (that is, > define > >>it as > > > > > > SNDU Stream: a sequence of MPEG-2 Transport Stream packets identified by > a > > common PID value of stream_type <0xnn>. > > > > All that then remains, I think, would be to signal when a Program > carries > > SNDU Stream(s), and what it means when there are more than one SNDU > Stream > > per program, or more than one Program that carries one or more SNDU > Streams. > > > > > >>>>If there remains an opportunity to repair what I believe to be errors > >> > >>in > >> > >>>the > >>> > >>>>draft, I'm eager and willing to participate from a MPEG-2 > >> > >>entertainment > >> > >>>>(which is to say, legacy use of MPEG-2 Transport) point of view. > >>> > >>>Of course the terms in the document should not conflict with meaning in > >>>another context. However, ambiguous terms in other documents should be > >>>avoided as well. > >>> > >>> > >>>>[Apologies for being strident at all, to say nothing of at such an > >>>>apparently late stage - if the above is perceived as such] > >>>> > >>>>Regards, > >>>>Adam Goldberg > >>>>Director, Television Standards & Policy Development > >>>>Sharp Laboratories of America > >>>>8605 Westwood Center Drive, Suite 206 > >>>>Vienna, VA 22182 > >>>>+1-703-556-4406 > >>>>+1-703-556-4410 fax > >>>>+1-571-276-0305 cell > >>>> > >>>> > >>>>-----Original Message----- > >>>>From: owner-ipdvb at erg.abdn.ac.uk [mailto:owner-ipdvb at erg.abdn.ac.uk] > >> > >>On > >> > >>>>Behalf Of Gorry Fairhurst > >>>>Sent: Friday, February 04, 2005 6:56 AM > >>>>To: ipdvb at erg.abdn.ac.uk; Bernhard Collini-Nocker > >>>>Cc: AAllison at nab.org > >>>>Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast > >>> > >>>Descriptors > >>> > >>>> > >>>>1) Done - point 1 was an edit mistake. > >>>> > >>>>2) I think some text on data broadcast descriptors, stream-type, > >> > >>or/and > >> > >>>PSI > >>> > >>>>entries would be a valuable addition. > >>>> > >>>>On thinking about this, I wonder if the text about this should go at > >> > >>the > >> > >>>end > >>> > >>>>of the Introduction (1.0) to the whole document, where people can see > >> > >>it > >> > >>>>clearly and then undesrtand that there may be something else needed > >> > >>for > >> > >>>>those > >>>>networks that rely on PSI for remultiplexing! > >>>> > >>>>- Bernhard & others who understand PSI, can you work with Art to agree > >>> > >>>the > >>> > >>>>exact wording please? > >>>> > >>>>Gorry Fairhurst > >>>>(ipdvb WG Chair) > >>>> > >>>>Gorry Fairhurst wrote: > >>>> > >>>> > >>>> > >>>>>WG please read and respond to this message. > >>>>> > >>>>>The following message was received on January 22nd before WGLC, but > >> > >>was > >> > >>>>>dropped because the email source address was not verified by the list > >>>>>server. > >>>>> > >>>>>The exact text of the message follows. > >>>>> > >>>>>best wishes, > >>>>> > >>>>>Gorry > >>>>>(ipdvb WG Chair) > >>>>> > >>>>>----- > >>>>> > >>>> > >>>>1) > >>>> > >>>> > >>>>>Thanks for considering my previous input... > >>>>>I note that the new draft has an editorial oversight in that it > >> > >>contains > >> > >>>>>two definitions of PSI. I suggest the second should be deleted. > >>>>> > >>>> > >>>>2) > >>>> > >>>> > >>>>>I previously made a comment about the ancillary requirements when > >> > >>adding > >> > >>>a > >>> > >>>>>TS logical channel to a TS multiplex and asserted there appeared to > be > >>>>>under > >>>>>specification. Perhaps it was viewed as out of scope, or perhaps I > >>> > >>>simply > >>> > >>>>>don't recognize the change that resulted. I can not find what > >>> > >>>stream_type > >>> > >>>>>is required to be used for the ULE stream when a "TS Logical Channel" > >> > >>is > >> > >>>>>added to a multiplex. > >>> > >>>The problem here is the same as above. Without "applying" for a > >>>"stream_type" for ULE there is no stream_type for ULE. In contrary why > >>>should one register a stream_type value for ULE earlier than ULE is > >>>standardized? > >>> > >>> > >>>>>I suggest at least an informative note be added in Section 6 (after > >> > >>the > >> > >>>>>third line which says: "These are transmitted using a single TS > >> > >>Logical > >> > >>>>>Channel over a TS Multiplex.") The note should say "PSI entries to be > >>>>>consistent with [ISO-MPEG] when constructing a conformant TS > Multiplex > >>> > >>>and > >>> > >>>>>means for Receivers to locate each such TS Logical Channel are > outside > >>> > >>>the > >>> > >>>>>scope of this recommendation." > >>> > >>>Thanks, this is a very helpful suggestion for potential readers. In > >>>addition the ipdvb-wg works on providing signalling other than PSI/SI. > >>> > >>> > >>>>>Reason: > >>>>>Just inserting a "TS Logical Channel" without including a > >>>>>TS_Program_map_section that lists the PID and a stream_type does not > >>>>>appear to me to result in a strictly MPEG-2 conformant bit stream; > >> > >>and > >> > >>>>>practically > >>>>>could result in the PIDs being dropped by a remultiplexer. If the > >>> > >>>means > >>> > >>>>>for binding the inserted element into a multiplex and subsequent > >>> > >>>discovery > >>> > >>>>>is to be covered in another document, a pointer to that document > would > >>> > >>>be > >>> > >>>>>more helpful than this warning. It seems at least a warning is needed > >>> > >>>and > >>> > >>>>>preferably a pointer to where this next level of TS construction is > >>>>>defined. > >>> > >>> From an architectural point of view it is a reasonable assupmption > that > >>>whatever is being sent in a TS multiplex should be referenced. However, > >>>the reality is that "ghost" PIDs do occur in many services either > >>>accidentially or for well-defined reasons. > >>> > >>>What is the penalty for not being strictly MPEG-2 conformant/compliant? > >>> > >>> > >>>>>Art Allison > >>>>>Director, Advanced Engineering > >>>>>NAB Science & Technology > >>>>>1771 N St NW, Washington Dc 20036 > >>>>>202 429 5418 > >>> > >>> > >>>Regards, > >>>Bernhard Collini-Nocker > >>> > >>> > > > > From agoldberg at sharplabs.com Tue Feb 8 05:32:02 2005 From: agoldberg at sharplabs.com (Goldberg, Adam) Date: Mon, 7 Feb 2005 21:32:02 -0800 Subject: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto rs Message-ID: <08259490B3BC3140B549DD0907A5644811D698@admsrvnt10.enet.sharplabs.com> Below Adam Goldberg Director, Television Standards & Policy Development Sharp Laboratories of America 8605 Westwood Center Drive, Suite 206 Vienna, VA 22182 +1-703-556-4406 +1-703-556-4410 fax +1-571-276-0305 cell > -----Original Message----- > From: Gorry Fairhurst [mailto:gorry at erg.abdn.ac.uk] > Sent: Monday, February 07, 2005 8:54 AM > To: ipdvb at erg.abdn.ac.uk > Cc: Goldberg, Adam; Allison, Art; Matthew Goldman > Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto > rs > > > So.... > > 1. The term "TS Logical Channel" was discussed a lot at the begining of > the > WG. As I recall, the reason for the new term, was that at this time the WG > could not find a suitably "unbiased" term for the set of TS Packets with a > common PID value (raw TS, DSMCC, Private Section, PES, etc). One key > objective > was to find a term that did not carry extra semantics, and was > understandable > by the networking community - this is after all intended as a part of the > RFC-series, and we need to make this accessible to people familiar with > using > IP over Ethernet, MPLS, ATM, Fibre Channel, Firewire, SDH/SONET, etc. > T > > we shoudl note that the term "TS Logical Channel term already appears (and > is > discussed in some detail) in the document draft-ietf-ipvb-arch-xx.txt and > that > this HAS already complete WGLC. If it IS WRONG we still have a chance to > fix > the definition/term, if we have to. Specifically, is there already a > well-accepted term for the set of TS Packets with a common PID value (raw > TS, > DSMCC, Private Section, PES, etc) that we should use or refer to? "TS Logical Channel" is perhaps defined well enough (that is, perhaps is not "wrong"), but it is at least inventing new words for an existing thing. The fact that a close examination of MPEG (or DVB or ATSC, for that matter) documents does not show a single defined term that means "sequence of transport packets each identified by a single PID value" doesn't mean that the term doesn't exist. The term is "stream". Hence, the field stream_type. Note, e.g., that stream_type 0x05 is defined to be a stream of private_sections, and 0x06 defined to be a stream of PES packets containing private data. What this document (or the set of documents we're talking about, I suppose) is defining is a new "type of stream" (transport packets containing ULE or SNDU data without private_section or PES syntax), and should have a stream_type (well, must have a stream_type to be identified by PSI). > 2. I'm not against defining another term "ULE Stream", "SNDU Stream", etc > if > that helps to describe the set of TS packets with a specific PID used for > ULE, > especially when talking about PSI. > > Bernhard, is there an opportunity of inserting a simple statement as the > final > paragraph of the introduction which says that to use ULE streams within an > MPEG-2 compliant multiplex may require appropriate PSI entries... I think > Art > already proposed some specific wording that could be used or modified? > > > 3) Once teh ULE spec is agreed and an RFC number issued, I can also see > great > advantage in assigning a descriptor for this in ATSC. I think the WG > SHOULD > should explore this at the next stage. You need not wait for this - a mere letter to ATSC asking for allocation of a stream_type codepoint for ULE data will be sufficient for ATSC to respond favorably. > Gorry > > Bernhard Collini-Nocker wrote: > > > Hello, > > > > let me try to summarize the two major points being raised and what the > > discussion is about: > > 1. the name/definition of "TS Logical Channel" is not well received and > > the name/definition of a "SNDU stream" is proposed instead > > 2. it is proposed to consider MPEG-2 conformance in specifying that ULE > > requires a specific stream_type value for the PMT > > > > Personally I have no objection against 1., because it is easy to change > > and improves wording and naming (unless somebody has an even better > > name for it). > > For 2. my concern is that mentioning stream_type may require some > > additional wording about PSI/SI in general, which is likely out of scope > > of the ULE draft. Even worse, in introducing a "world" besides the > > encapsulation/decapsulation of ULE, this may result in further confusion > > about what the MPEG-2/Section layer does in addition to and/or in > > comparison to ULE/IP. Actually some difficult question may arise from > > this direction, for example whether it is a wishful requirement for ULE > > to support PAT/PMT/NIT/INT/... table parsing? > > > > Any opinions, recommendations or suggestions about this? > > > > Regards, > > Bernhard > > > > Goldberg, Adam wrote: > > > >> ARGH. I fat-fingered 'send' before completing the email. See below. > >> > >> Adam Goldberg > >> Director, Television Standards & Policy Development > >> Sharp Laboratories of America > >> 8605 Westwood Center Drive, Suite 206 > >> Vienna, VA 22182 > >> +1-703-556-4406 > >> +1-703-556-4410 fax > >> +1-571-276-0305 cell > >> > >> > >> > >>> -----Original Message----- > >>> From: Goldberg, Adam > >>> Sent: Monday, February 07, 2005 12:42 AM > >>> To: 'Bernhard Collini-Nocker'; Goldberg, Adam > >>> Cc: ipdvb at erg.abdn.ac.uk; Allison, Art; Matthew Goldman > >>> Subject: RE: Forward from Art Alison: WGLC ULE - Data Broadcast > >>> Descripto > >>> rs > >>> > >>> See below... > >>> > >>> Adam Goldberg > >>> Director, Television Standards & Policy Development > >>> Sharp Laboratories of America > >>> 8605 Westwood Center Drive, Suite 206 > >>> Vienna, VA 22182 > >>> +1-703-556-4406 > >>> +1-703-556-4410 fax > >>> +1-571-276-0305 cell > >>> > >>> > >>> Bernhard Collini-Nocker wrote: > >>> > >>>> Goldberg, Adam wrote: > >>>> > >>>>> I apologize for being "late to the party", but: > >>>>> > >>>>> I do not see a particular need to define new term "TS Logical > >> > >> > >> Channel", > >> > >>>> and > >>>> > >>>>> indeed doing so creates risks of ill-specification (such as those > Art > >>>> > >>>> > >>>> points > >>>> > >>>>> out), as well as confusion heaped upon someone familiar with MPEG-2 > >>>>> Transport (as typically used in entertainment delivery). > >>>> > >>>> > >>>> Unfortunately the MPEG-2 standards do not provide a reasonable term > for > >>>> the purpose of networking. The question is whether other terms, for > >>>> example "PID network" or "PID stream" would be better received and > >>>> understood? > >>>> The term "TS logical channel" tries to verbally visualize that the > >>>> encapsulation uses a continouos stream of transport stream packets > >>>> using > >>>> one specific packet identifier to transport subnetwork data units. > >>>> Maybe > >>>> the term "TS (virtual) circuit" better names this? > >>> > >>> > >>> It is perhaps not well defined in 13818-1, but the term of art is > >>> "streams". Many people use "PID stream" which is a poor combination > of > >>> words. I'd have no objection to defining a "SNDU Stream" as something > >>> like "a sequence of MPEG-2 Transport Stream packets identified by a > >>> common > >>> PID value" (or some such). > >>> > >>> Perhaps discussing 'virtual circuits' relative to a Transport Stream > is > >>> begging for confusion. Use of any such words ("TS (virtual) circuit") > >>> needs careful definition, likely requiring the above SNDU Stream > >>> definition plus an explanation of what it means for multiple SNDU > >>> Streams > >>> to exist in a single Transport Stream. > >>> > >>> > >>>>> Furthermore, the definition is quite wrong with respect to ATSC and > >>> > >>> > >>> DVB > >>> > >>>> use > >>>> > >>>>> of "specific TS Logical Channels". To my knowledge, this internet- > >>> > >>> > >>> draft > >>> > >>>> is > >>>> > >>>>> the only document anywhere which uses such terms. It is certainly > >>> > >>> > >>> true > >>> > >>>> that > >>>> > >>>>> MPEG, DVB and ATSC define //elementary streams// identified by > >>>> > >>>> > >>>> stream_type > >>>> > >>>>> values. I suspect this is what is meant by "TS Logical Channel", but > >>> > >>> > >>> it > >>> > >>>> is > >>>> > >>>>> difficult for me to tell. > >>>> > >>>> > >>>> I am not so sure, whether this analysis is correct. Elementary > streams > >>>> are those that are transported as Packetized ES, whereas "auxillary" > >>>> data and signalling is transported as sections. Although a > stream_type > >>>> in the program map section is used to reference both PESs and > sections > >>>> the term elementary stream is used very vague and we tried to avoid > >>>> using it in the same vague manner. > >>> > >>> > >>> Perhaps I overstepped with "elementary stream". > >>> > >>> Consider the 13818-1 definition of "Packetized Elementary Stream": "A > >>> continuous sequence of PES packets of one elementary stream with one > >>> stream ID may be used to construct a PES Stream." (ISO/IEC > >>> 13818-1:2000 p. > >>> xiii) > >>> > >>> Stuff carried as payload of Transport Stream packets are merely > >>> 'payload'. > >>> What the draft starts to define is a new type of payload stream (that > >>> is, > >>> a new way to carry data in a transport stream). The definition is not > >>> compete. > >>> > >>> > >>>> According to, for example EN301192 v1.3.1, defines Data Piping as: > >>>> " The data broadcast service shall insert the data to be broadcast > >>>> directly in the payload of MPEG-2 TS packets." > >>>> That raises the question, how to call a continouos stream of MPEG-2 > TS > >>>> packets with a certain PID? > >>>> > >>>> Further the standard details that: > >>>> "The data broadcast service may use the payload_unit_start_indicator > >>>> field and the transport_priority field of the MPEG-2 Transport Stream > >>>> packets in a service private way. The use of the adaptation_field > shall > >>>> be MPEG-2 compliant." > >>>> ULE uses PUSI and does not utilize the AF. > >>>> > >>>> "The delivery of the bits in time through a data pipe is service > >>>> private > >>>> and is not specified in the present document." > >>>> It seems obvious that the use of the term "TS Data Pipe" would lead > to > >>>> the wrong conclusion that ULE equals Data Piping. But Data Piping is > >>>> not > >>>> detailed at all, whereas ULE tries to be. > >>> > >>> > >>> I'm not going to argue that DVB's specification is complete. I will > >>> argue > >>> that ULE isn't complete. > >>> > >>> > >>>>> (from the draft) > >>>>> TS Logical Channel: Transport Stream Logical Channel. In this > >>>>> document, this term identifies a channel at the MPEG-2 level [ISO- > >>>>> MPEG]. It exists at level 2 of the ISO/OSI reference model. All > >>>>> packets sent over a TS Logical Channel carry the same PID value > >>>>> (this value is unique within a specific TS Multiplex). According > to > >>>>> MPEG-2, some TS Logical Channels are reserved for specific > >>>>> signalling purposes. Other standards (e.g., ATSC, DVB) also > reserve > >>>>> specific TS Logical Channels. > >>>>> > >>>>> While I'm commenting on this definition, it also seems to me that > >>>> > >>>> > >>>> "channel > >>>> > >>>>> at the MPEG-2 level" is either wrong or also ill-specified. What's > a > >>>>> channel? If you're talking about MPEG-2, it's certainly conceivable > >>>> > >>>> > >>>> that > >>>> > >>>>> the reader may associate "channel" with "[television] channel" - > which > >>>> > >>>> > >>>> are > >>>> > >>>>> the subject of a large amount of ATSC and DVB systems. > >>>> > >>>> > >>>> The term channel is indeed problematic in the context of television, > >>>> however, network engineers might have a different understanding about > >>>> what a channel is. > >>>> According to ATIS a channel is "1. A connection between initiating > and > >>>> terminating nodes of a circuit. 2. A single path provided by a > >>>> transmission medium via either (a) physical separation, such as by > >>>> multipair cable or (b) electrical separation, such as by frequency- > or > >>>> time-division multiplexing. ..." > >>> > >>> > >>> I understand that 'channel' vis-?-vis networking has a different > meaning > >>> than 'channel' vis-?-vis television. This was my point actually, that > >>> those familiar with MPEG transport should not be assumed to be > >>> networking- > >>> types (even when speaking with respect to ULE). > >>> > >>> > >>>>> Additionally, it is also wrong or ill-specified to say "According to > >>>> > >>>> > >>>> MPEG-2 > >>>> > >>>>> ... TS Logical Channels ...". There is no such concept defined or > >>> > >>> > >>> used > >>> > >>>>> within MPEG (unless what you really mean is elementary stream, in > >>> > >>> > >>> which > >>> > >>>> case > >>>> > >>>>> what do you need this extraneous term for anyhow?). > >>>> > >>>> > >>>> Again, elementary stream is not exactly what is being meant: > >>>> For example EN 300468 v1.5.1 defines: > >>>> "component (ELEMENTARY Stream): one or more entities which together > >>>> make > >>>> up an event, e.g. video, audio, teletext" > >>>> > >>>> and says further: > >>>> "The component descriptor identifies the type of component stream and > >>>> may be used to provide a text description of the elementary stream" > >>>> > >>>> where: > >>>> "component_type: This 8-bit field specifies the type of the video, > >>>> audio > >>>> or EBU-data component. The coding of this field is specified in table > >>> > >>> > >>> 26." > >>> > >>>> Table 26 then lists all kinds of video, audio, and teletext formats, > >>>> but > >>>> unfortunately no networking formats. > >>>> > >>>> At other places this standard is as innovative/creative in naming: > >>>> "event: grouping of elementary broadcast data streams with a defined > >>>> start and end time belonging to a common service, e.g. first half of > a > >>>> football match, News Flash, first part of an entertainment show" > >>>> What is a "elementary broadcast data streams"? Not by guessing but by > >>>> definition? > >>>> > >>>> > >>>>> In any case, Art is certainly correct that merely identifying a "TS > >>>> > >>>> > >>>> Logical > >>>> > >>>>> Channel" as a sequence of packets identified with a common PID value > >>>> > >>>> > >>>> without > >>>> > >>>>> identifying the PSI details is an invitation to multiplexers and > >>>>> remultiplexers to drop those packets on the floor. > >>>> > >>>> > >>>> Oh yes, this is the real problem of defining something outside > >>>> television standardiszation bodies: one risks that ULE packets are > >>>> being > >>>> dropped. > >>>> We have discussed basically two approaches: > >>>> 1. define the PSI and get an ID, or tag, or "stream_type" for ULE, > >>>> or 2. > >>>> define ULE and let somebody else do the PSI work. > >>>> We have had some reasons for choice 2. > >>> > >>> > >>> This is a very easy thing to fix and something which should be done. > >>> Without defining a stream_type for ULE data, it is neither possible to > >>> construct a transport stream compliant with MPEG-2 nor one that > >>> interoperates with other ULE equipment. > >>> > >>> ATSC maintains a 'codepoint registry', and would be happy to allocate > a > >>> stream_type value for ULE data upon request from IETF. Furthermore, > the > >>> text to specify usage of the stream_type would be reasonably easy (and > >>> perhaps ties in to my suggested "SNDU Stream" definition (that is, > >>> define > >>> it as > >> > >> > >> > >> SNDU Stream: a sequence of MPEG-2 Transport Stream packets identified > >> by a > >> common PID value of stream_type <0xnn>. > >> > >> All that then remains, I think, would be to signal when a Program > carries > >> SNDU Stream(s), and what it means when there are more than one SNDU > >> Stream > >> per program, or more than one Program that carries one or more SNDU > >> Streams. > >> > >> > >>>>> If there remains an opportunity to repair what I believe to be > errors > >>> > >>> > >>> in > >>> > >>>> the > >>>> > >>>>> draft, I'm eager and willing to participate from a MPEG-2 > >>> > >>> > >>> entertainment > >>> > >>>>> (which is to say, legacy use of MPEG-2 Transport) point of view. > >>>> > >>>> > >>>> Of course the terms in the document should not conflict with meaning > in > >>>> another context. However, ambiguous terms in other documents should > be > >>>> avoided as well. > >>>> > >>>> > >>>>> [Apologies for being strident at all, to say nothing of at such an > >>>>> apparently late stage - if the above is perceived as such] > >>>>> > >>>>> Regards, > >>>>> Adam Goldberg > >>>>> Director, Television Standards & Policy Development > >>>>> Sharp Laboratories of America > >>>>> 8605 Westwood Center Drive, Suite 206 > >>>>> Vienna, VA 22182 > >>>>> +1-703-556-4406 > >>>>> +1-703-556-4410 fax > >>>>> +1-571-276-0305 cell > >>>>> > >>>>> > >>>>> -----Original Message----- > >>>>> From: owner-ipdvb at erg.abdn.ac.uk [mailto:owner-ipdvb at erg.abdn.ac.uk] > >>> > >>> > >>> On > >>> > >>>>> Behalf Of Gorry Fairhurst > >>>>> Sent: Friday, February 04, 2005 6:56 AM > >>>>> To: ipdvb at erg.abdn.ac.uk; Bernhard Collini-Nocker > >>>>> Cc: AAllison at nab.org > >>>>> Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast > >>>> > >>>> > >>>> Descriptors > >>>> > >>>>> > >>>>> 1) Done - point 1 was an edit mistake. > >>>>> > >>>>> 2) I think some text on data broadcast descriptors, stream-type, > >>> > >>> > >>> or/and > >>> > >>>> PSI > >>>> > >>>>> entries would be a valuable addition. > >>>>> > >>>>> On thinking about this, I wonder if the text about this should go at > >>> > >>> > >>> the > >>> > >>>> end > >>>> > >>>>> of the Introduction (1.0) to the whole document, where people can > see > >>> > >>> > >>> it > >>> > >>>>> clearly and then undesrtand that there may be something else needed > >>> > >>> > >>> for > >>> > >>>>> those > >>>>> networks that rely on PSI for remultiplexing! > >>>>> > >>>>> - Bernhard & others who understand PSI, can you work with Art to > agree > >>>> > >>>> > >>>> the > >>>> > >>>>> exact wording please? > >>>>> > >>>>> Gorry Fairhurst > >>>>> (ipdvb WG Chair) > >>>>> > >>>>> Gorry Fairhurst wrote: > >>>>> > >>>>> > >>>>> > >>>>>> WG please read and respond to this message. > >>>>>> > >>>>>> The following message was received on January 22nd before WGLC, but > >>> > >>> > >>> was > >>> > >>>>>> dropped because the email source address was not verified by the > list > >>>>>> server. > >>>>>> > >>>>>> The exact text of the message follows. > >>>>>> > >>>>>> best wishes, > >>>>>> > >>>>>> Gorry > >>>>>> (ipdvb WG Chair) > >>>>>> > >>>>>> ----- > >>>>>> > >>>>> > >>>>> 1) > >>>>> > >>>>> > >>>>>> Thanks for considering my previous input... > >>>>>> I note that the new draft has an editorial oversight in that it > >>> > >>> > >>> contains > >>> > >>>>>> two definitions of PSI. I suggest the second should be deleted. > >>>>>> > >>>>> > >>>>> 2) > >>>>> > >>>>> > >>>>>> I previously made a comment about the ancillary requirements when > >>> > >>> > >>> adding > >>> > >>>> a > >>>> > >>>>>> TS logical channel to a TS multiplex and asserted there appeared > >>>>>> to be > >>>>>> under > >>>>>> specification. Perhaps it was viewed as out of scope, or perhaps I > >>>> > >>>> > >>>> simply > >>>> > >>>>>> don't recognize the change that resulted. I can not find what > >>>> > >>>> > >>>> stream_type > >>>> > >>>>>> is required to be used for the ULE stream when a "TS Logical > Channel" > >>> > >>> > >>> is > >>> > >>>>>> added to a multiplex. > >>>> > >>>> > >>>> The problem here is the same as above. Without "applying" for a > >>>> "stream_type" for ULE there is no stream_type for ULE. In contrary > why > >>>> should one register a stream_type value for ULE earlier than ULE is > >>>> standardized? > >>>> > >>>> > >>>>>> I suggest at least an informative note be added in Section 6 (after > >>> > >>> > >>> the > >>> > >>>>>> third line which says: "These are transmitted using a single TS > >>> > >>> > >>> Logical > >>> > >>>>>> Channel over a TS Multiplex.") The note should say "PSI entries to > be > >>>>>> consistent with [ISO-MPEG] when constructing a conformant TS > >>>>>> Multiplex > >>>> > >>>> > >>>> and > >>>> > >>>>>> means for Receivers to locate each such TS Logical Channel are > >>>>>> outside > >>>> > >>>> > >>>> the > >>>> > >>>>>> scope of this recommendation." > >>>> > >>>> > >>>> Thanks, this is a very helpful suggestion for potential readers. In > >>>> addition the ipdvb-wg works on providing signalling other than PSI/SI. > >>>> > >>>> > >>>>>> Reason: > >>>>>> Just inserting a "TS Logical Channel" without including a > >>>>>> TS_Program_map_section that lists the PID and a stream_type does > not > >>>>>> appear to me to result in a strictly MPEG-2 conformant bit stream; > >>> > >>> > >>> and > >>> > >>>>>> practically > >>>>>> could result in the PIDs being dropped by a remultiplexer. If the > >>>> > >>>> > >>>> means > >>>> > >>>>>> for binding the inserted element into a multiplex and subsequent > >>>> > >>>> > >>>> discovery > >>>> > >>>>>> is to be covered in another document, a pointer to that document > >>>>>> would > >>>> > >>>> > >>>> be > >>>> > >>>>>> more helpful than this warning. It seems at least a warning is > needed > >>>> > >>>> > >>>> and > >>>> > >>>>>> preferably a pointer to where this next level of TS construction is > >>>>>> defined. > >>>> > >>>> > >>>> From an architectural point of view it is a reasonable assupmption > that > >>>> whatever is being sent in a TS multiplex should be referenced. > However, > >>>> the reality is that "ghost" PIDs do occur in many services either > >>>> accidentially or for well-defined reasons. > >>>> > >>>> What is the penalty for not being strictly MPEG-2 > conformant/compliant? > >>>> > >>>> > >>>>>> Art Allison > >>>>>> Director, Advanced Engineering > >>>>>> NAB Science & Technology > >>>>>> 1771 N St NW, Washington Dc 20036 > >>>>>> 202 429 5418 > >>>> > >>>> > >>>> > >>>> Regards, > >>>> Bernhard Collini-Nocker > >>>> > >>>> > >> > >> > > > > From agoldberg at sharplabs.com Tue Feb 8 05:35:02 2005 From: agoldberg at sharplabs.com (Goldberg, Adam) Date: Mon, 7 Feb 2005 21:35:02 -0800 Subject: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto rs Message-ID: <08259490B3BC3140B549DD0907A5644811D699@admsrvnt10.enet.sharplabs.com> Below Adam Goldberg Director, Television Standards & Policy Development Sharp Laboratories of America 8605 Westwood Center Drive, Suite 206 Vienna, VA 22182 +1-703-556-4406 +1-703-556-4410 fax +1-571-276-0305 cell > -----Original Message----- > From: Marie-Jose Montpetit [mailto:mariejose.montpetit at verizon.net] > Sent: Monday, February 07, 2005 3:56 PM > To: ipdvb at erg.abdn.ac.uk > Cc: Goldberg, Adam; Allison, Art; Matthew Goldman > Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto > rs > > I think we need to close on some of those issues and move forward. > > Here is what I propose which would be inline with the conclusions of the > Architecture Draft: > (1) ULE is encapsulation only - it is not the purpose nor the usage of ULE > to dwell in SI/PSI table issues nor any other protocol; so we leave the > draft to be mostly what it is now (pending small changes proposed by > Gorry) This becomes a bit self-referential. The proper definition of the data stream is to say something like "a stream of stream_type 0xNN", but you propose not doing this until later. > (2) PSI/SI scanning is part of the Address Resolution Draft as regard > management of addressing; it will be further discussed there and focus > given > to the issues raised in this thread Can someone provide a pointer to the "Address Resolution Draft"? > (3) Someone (Adam and/or team) proposes WG work and a draft on ATSC > concerns > on PSI/SI issues and ULE; inclusion of cable TV concerns in addition to > satellite would be welcome and has been one of my goals for the group > (4) we close on ULE and get to discuss the other items further at IETF Don't misunderstand my concerns (or Art's, I suppose) - they are not "ATSC concerns" so much as concerns from one overly familiar with MPEG-2 Transport Streams and their widespread use. > > Thanks > > Marie-Jose > > ----- Original Message ----- > From: "Gorry Fairhurst" > To: > Cc: "Goldberg, Adam" ; "Allison, Art" > ; "Matthew Goldman" > Sent: Monday, February 07, 2005 8:54 AM > Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto > rs > > > > > > So.... > > > > 1. The term "TS Logical Channel" was discussed a lot at the begining of > the > > WG. As I recall, the reason for the new term, was that at this time the > WG > > could not find a suitably "unbiased" term for the set of TS Packets with > a > > common PID value (raw TS, DSMCC, Private Section, PES, etc). One key > objective > > was to find a term that did not carry extra semantics, and was > understandable > > by the networking community - this is after all intended as a part of > the > > RFC-series, and we need to make this accessible to people familiar with > using > > IP over Ethernet, MPLS, ATM, Fibre Channel, Firewire, SDH/SONET, etc. > > T > > > > we shoudl note that the term "TS Logical Channel term already appears > (and > is > > discussed in some detail) in the document draft-ietf-ipvb-arch-xx.txt > and > that > > this HAS already complete WGLC. If it IS WRONG we still have a chance > to > fix > > the definition/term, if we have to. Specifically, is there already a > > well-accepted term for the set of TS Packets with a common PID value > (raw > TS, > > DSMCC, Private Section, PES, etc) that we should use or refer to? > > > > > > 2. I'm not against defining another term "ULE Stream", "SNDU Stream", > etc > if > > that helps to describe the set of TS packets with a specific PID used > for > ULE, > > especially when talking about PSI. > > > > Bernhard, is there an opportunity of inserting a simple statement as the > final > > paragraph of the introduction which says that to use ULE streams within > an > > MPEG-2 compliant multiplex may require appropriate PSI entries... I > think > Art > > already proposed some specific wording that could be used or modified? > > > > > > 3) Once teh ULE spec is agreed and an RFC number issued, I can also see > great > > advantage in assigning a descriptor for this in ATSC. I think the WG > SHOULD > > should explore this at the next stage. > > > > > > Gorry > > > > Bernhard Collini-Nocker wrote: > > > > > Hello, > > > > > > let me try to summarize the two major points being raised and what the > > > discussion is about: > > > 1. the name/definition of "TS Logical Channel" is not well received > and > > > the name/definition of a "SNDU stream" is proposed instead > > > 2. it is proposed to consider MPEG-2 conformance in specifying that > ULE > > > requires a specific stream_type value for the PMT > > > > > > Personally I have no objection against 1., because it is easy to > change > > > and improves wording and naming (unless somebody has an even better > > > name for it). > > > For 2. my concern is that mentioning stream_type may require some > > > additional wording about PSI/SI in general, which is likely out of > scope > > > of the ULE draft. Even worse, in introducing a "world" besides the > > > encapsulation/decapsulation of ULE, this may result in further > confusion > > > about what the MPEG-2/Section layer does in addition to and/or in > > > comparison to ULE/IP. Actually some difficult question may arise from > > > this direction, for example whether it is a wishful requirement for > ULE > > > to support PAT/PMT/NIT/INT/... table parsing? > > > > > > Any opinions, recommendations or suggestions about this? > > > > > > Regards, > > > Bernhard > > > > > > Goldberg, Adam wrote: > > > > > >> ARGH. I fat-fingered 'send' before completing the email. See below. > > >> > > >> Adam Goldberg > > >> Director, Television Standards & Policy Development > > >> Sharp Laboratories of America > > >> 8605 Westwood Center Drive, Suite 206 > > >> Vienna, VA 22182 > > >> +1-703-556-4406 > > >> +1-703-556-4410 fax > > >> +1-571-276-0305 cell > > >> > > >> > > >> > > >>> -----Original Message----- > > >>> From: Goldberg, Adam > > >>> Sent: Monday, February 07, 2005 12:42 AM > > >>> To: 'Bernhard Collini-Nocker'; Goldberg, Adam > > >>> Cc: ipdvb at erg.abdn.ac.uk; Allison, Art; Matthew Goldman > > >>> Subject: RE: Forward from Art Alison: WGLC ULE - Data Broadcast > > >>> Descripto > > >>> rs > > >>> > > >>> See below... > > >>> > > >>> Adam Goldberg > > >>> Director, Television Standards & Policy Development > > >>> Sharp Laboratories of America > > >>> 8605 Westwood Center Drive, Suite 206 > > >>> Vienna, VA 22182 > > >>> +1-703-556-4406 > > >>> +1-703-556-4410 fax > > >>> +1-571-276-0305 cell > > >>> > > >>> > > >>> Bernhard Collini-Nocker wrote: > > >>> > > >>>> Goldberg, Adam wrote: > > >>>> > > >>>>> I apologize for being "late to the party", but: > > >>>>> > > >>>>> I do not see a particular need to define new term "TS Logical > > >> > > >> > > >> Channel", > > >> > > >>>> and > > >>>> > > >>>>> indeed doing so creates risks of ill-specification (such as those > Art > > >>>> > > >>>> > > >>>> points > > >>>> > > >>>>> out), as well as confusion heaped upon someone familiar with MPEG- > 2 > > >>>>> Transport (as typically used in entertainment delivery). > > >>>> > > >>>> > > >>>> Unfortunately the MPEG-2 standards do not provide a reasonable term > for > > >>>> the purpose of networking. The question is whether other terms, for > > >>>> example "PID network" or "PID stream" would be better received and > > >>>> understood? > > >>>> The term "TS logical channel" tries to verbally visualize that the > > >>>> encapsulation uses a continouos stream of transport stream packets > > >>>> using > > >>>> one specific packet identifier to transport subnetwork data units. > > >>>> Maybe > > >>>> the term "TS (virtual) circuit" better names this? > > >>> > > >>> > > >>> It is perhaps not well defined in 13818-1, but the term of art is > > >>> "streams". Many people use "PID stream" which is a poor combination > of > > >>> words. I'd have no objection to defining a "SNDU Stream" as > something > > >>> like "a sequence of MPEG-2 Transport Stream packets identified by a > > >>> common > > >>> PID value" (or some such). > > >>> > > >>> Perhaps discussing 'virtual circuits' relative to a Transport Stream > is > > >>> begging for confusion. Use of any such words ("TS (virtual) > circuit") > > >>> needs careful definition, likely requiring the above SNDU Stream > > >>> definition plus an explanation of what it means for multiple SNDU > > >>> Streams > > >>> to exist in a single Transport Stream. > > >>> > > >>> > > >>>>> Furthermore, the definition is quite wrong with respect to ATSC > and > > >>> > > >>> > > >>> DVB > > >>> > > >>>> use > > >>>> > > >>>>> of "specific TS Logical Channels". To my knowledge, this > internet- > > >>> > > >>> > > >>> draft > > >>> > > >>>> is > > >>>> > > >>>>> the only document anywhere which uses such terms. It is certainly > > >>> > > >>> > > >>> true > > >>> > > >>>> that > > >>>> > > >>>>> MPEG, DVB and ATSC define //elementary streams// identified by > > >>>> > > >>>> > > >>>> stream_type > > >>>> > > >>>>> values. I suspect this is what is meant by "TS Logical Channel", > but > > >>> > > >>> > > >>> it > > >>> > > >>>> is > > >>>> > > >>>>> difficult for me to tell. > > >>>> > > >>>> > > >>>> I am not so sure, whether this analysis is correct. Elementary > streams > > >>>> are those that are transported as Packetized ES, whereas > "auxillary" > > >>>> data and signalling is transported as sections. Although a > stream_type > > >>>> in the program map section is used to reference both PESs and > sections > > >>>> the term elementary stream is used very vague and we tried to avoid > > >>>> using it in the same vague manner. > > >>> > > >>> > > >>> Perhaps I overstepped with "elementary stream". > > >>> > > >>> Consider the 13818-1 definition of "Packetized Elementary Stream": > "A > > >>> continuous sequence of PES packets of one elementary stream with one > > >>> stream ID may be used to construct a PES Stream." (ISO/IEC > > >>> 13818-1:2000 p. > > >>> xiii) > > >>> > > >>> Stuff carried as payload of Transport Stream packets are merely > > >>> 'payload'. > > >>> What the draft starts to define is a new type of payload stream > (that > > >>> is, > > >>> a new way to carry data in a transport stream). The definition is > not > > >>> compete. > > >>> > > >>> > > >>>> According to, for example EN301192 v1.3.1, defines Data Piping as: > > >>>> " The data broadcast service shall insert the data to be broadcast > > >>>> directly in the payload of MPEG-2 TS packets." > > >>>> That raises the question, how to call a continouos stream of MPEG-2 > TS > > >>>> packets with a certain PID? > > >>>> > > >>>> Further the standard details that: > > >>>> "The data broadcast service may use the > payload_unit_start_indicator > > >>>> field and the transport_priority field of the MPEG-2 Transport > Stream > > >>>> packets in a service private way. The use of the adaptation_field > shall > > >>>> be MPEG-2 compliant." > > >>>> ULE uses PUSI and does not utilize the AF. > > >>>> > > >>>> "The delivery of the bits in time through a data pipe is service > > >>>> private > > >>>> and is not specified in the present document." > > >>>> It seems obvious that the use of the term "TS Data Pipe" would lead > to > > >>>> the wrong conclusion that ULE equals Data Piping. But Data Piping > is > > >>>> not > > >>>> detailed at all, whereas ULE tries to be. > > >>> > > >>> > > >>> I'm not going to argue that DVB's specification is complete. I will > > >>> argue > > >>> that ULE isn't complete. > > >>> > > >>> > > >>>>> (from the draft) > > >>>>> TS Logical Channel: Transport Stream Logical Channel. In this > > >>>>> document, this term identifies a channel at the MPEG-2 level > [ISO- > > >>>>> MPEG]. It exists at level 2 of the ISO/OSI reference model. All > > >>>>> packets sent over a TS Logical Channel carry the same PID value > > >>>>> (this value is unique within a specific TS Multiplex). According > to > > >>>>> MPEG-2, some TS Logical Channels are reserved for specific > > >>>>> signalling purposes. Other standards (e.g., ATSC, DVB) also > reserve > > >>>>> specific TS Logical Channels. > > >>>>> > > >>>>> While I'm commenting on this definition, it also seems to me that > > >>>> > > >>>> > > >>>> "channel > > >>>> > > >>>>> at the MPEG-2 level" is either wrong or also ill-specified. > What's > a > > >>>>> channel? If you're talking about MPEG-2, it's certainly > conceivable > > >>>> > > >>>> > > >>>> that > > >>>> > > >>>>> the reader may associate "channel" with "[television] channel" - > which > > >>>> > > >>>> > > >>>> are > > >>>> > > >>>>> the subject of a large amount of ATSC and DVB systems. > > >>>> > > >>>> > > >>>> The term channel is indeed problematic in the context of television, > > >>>> however, network engineers might have a different understanding > about > > >>>> what a channel is. > > >>>> According to ATIS a channel is "1. A connection between initiating > and > > >>>> terminating nodes of a circuit. 2. A single path provided by a > > >>>> transmission medium via either (a) physical separation, such as by > > >>>> multipair cable or (b) electrical separation, such as by frequency- > or > > >>>> time-division multiplexing. ..." > > >>> > > >>> > > >>> I understand that 'channel' vis-?-vis networking has a different > meaning > > >>> than 'channel' vis-?-vis television. This was my point actually, > that > > >>> those familiar with MPEG transport should not be assumed to be > > >>> networking- > > >>> types (even when speaking with respect to ULE). > > >>> > > >>> > > >>>>> Additionally, it is also wrong or ill-specified to say "According > to > > >>>> > > >>>> > > >>>> MPEG-2 > > >>>> > > >>>>> ... TS Logical Channels ...". There is no such concept defined or > > >>> > > >>> > > >>> used > > >>> > > >>>>> within MPEG (unless what you really mean is elementary stream, in > > >>> > > >>> > > >>> which > > >>> > > >>>> case > > >>>> > > >>>>> what do you need this extraneous term for anyhow?). > > >>>> > > >>>> > > >>>> Again, elementary stream is not exactly what is being meant: > > >>>> For example EN 300468 v1.5.1 defines: > > >>>> "component (ELEMENTARY Stream): one or more entities which together > > >>>> make > > >>>> up an event, e.g. video, audio, teletext" > > >>>> > > >>>> and says further: > > >>>> "The component descriptor identifies the type of component stream > and > > >>>> may be used to provide a text description of the elementary stream" > > >>>> > > >>>> where: > > >>>> "component_type: This 8-bit field specifies the type of the video, > > >>>> audio > > >>>> or EBU-data component. The coding of this field is specified in > table > > >>> > > >>> > > >>> 26." > > >>> > > >>>> Table 26 then lists all kinds of video, audio, and teletext formats, > > >>>> but > > >>>> unfortunately no networking formats. > > >>>> > > >>>> At other places this standard is as innovative/creative in naming: > > >>>> "event: grouping of elementary broadcast data streams with a > defined > > >>>> start and end time belonging to a common service, e.g. first half > of > a > > >>>> football match, News Flash, first part of an entertainment show" > > >>>> What is a "elementary broadcast data streams"? Not by guessing but > by > > >>>> definition? > > >>>> > > >>>> > > >>>>> In any case, Art is certainly correct that merely identifying a > "TS > > >>>> > > >>>> > > >>>> Logical > > >>>> > > >>>>> Channel" as a sequence of packets identified with a common PID > value > > >>>> > > >>>> > > >>>> without > > >>>> > > >>>>> identifying the PSI details is an invitation to multiplexers and > > >>>>> remultiplexers to drop those packets on the floor. > > >>>> > > >>>> > > >>>> Oh yes, this is the real problem of defining something outside > > >>>> television standardiszation bodies: one risks that ULE packets are > > >>>> being > > >>>> dropped. > > >>>> We have discussed basically two approaches: > > >>>> 1. define the PSI and get an ID, or tag, or "stream_type" for ULE, > > >>>> or 2. > > >>>> define ULE and let somebody else do the PSI work. > > >>>> We have had some reasons for choice 2. > > >>> > > >>> > > >>> This is a very easy thing to fix and something which should be done. > > >>> Without defining a stream_type for ULE data, it is neither possible > to > > >>> construct a transport stream compliant with MPEG-2 nor one that > > >>> interoperates with other ULE equipment. > > >>> > > >>> ATSC maintains a 'codepoint registry', and would be happy to > allocate > a > > >>> stream_type value for ULE data upon request from IETF. Furthermore, > the > > >>> text to specify usage of the stream_type would be reasonably easy > (and > > >>> perhaps ties in to my suggested "SNDU Stream" definition (that is, > > >>> define > > >>> it as > > >> > > >> > > >> > > >> SNDU Stream: a sequence of MPEG-2 Transport Stream packets identified > > >> by a > > >> common PID value of stream_type <0xnn>. > > >> > > >> All that then remains, I think, would be to signal when a Program > carries > > >> SNDU Stream(s), and what it means when there are more than one SNDU > > >> Stream > > >> per program, or more than one Program that carries one or more SNDU > > >> Streams. > > >> > > >> > > >>>>> If there remains an opportunity to repair what I believe to be > errors > > >>> > > >>> > > >>> in > > >>> > > >>>> the > > >>>> > > >>>>> draft, I'm eager and willing to participate from a MPEG-2 > > >>> > > >>> > > >>> entertainment > > >>> > > >>>>> (which is to say, legacy use of MPEG-2 Transport) point of view. > > >>>> > > >>>> > > >>>> Of course the terms in the document should not conflict with > meaning > in > > >>>> another context. However, ambiguous terms in other documents should > be > > >>>> avoided as well. > > >>>> > > >>>> > > >>>>> [Apologies for being strident at all, to say nothing of at such an > > >>>>> apparently late stage - if the above is perceived as such] > > >>>>> > > >>>>> Regards, > > >>>>> Adam Goldberg > > >>>>> Director, Television Standards & Policy Development > > >>>>> Sharp Laboratories of America > > >>>>> 8605 Westwood Center Drive, Suite 206 > > >>>>> Vienna, VA 22182 > > >>>>> +1-703-556-4406 > > >>>>> +1-703-556-4410 fax > > >>>>> +1-571-276-0305 cell > > >>>>> > > >>>>> > > >>>>> -----Original Message----- > > >>>>> From: owner-ipdvb at erg.abdn.ac.uk [mailto:owner- > ipdvb at erg.abdn.ac.uk] > > >>> > > >>> > > >>> On > > >>> > > >>>>> Behalf Of Gorry Fairhurst > > >>>>> Sent: Friday, February 04, 2005 6:56 AM > > >>>>> To: ipdvb at erg.abdn.ac.uk; Bernhard Collini-Nocker > > >>>>> Cc: AAllison at nab.org > > >>>>> Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast > > >>>> > > >>>> > > >>>> Descriptors > > >>>> > > >>>>> > > >>>>> 1) Done - point 1 was an edit mistake. > > >>>>> > > >>>>> 2) I think some text on data broadcast descriptors, stream-type, > > >>> > > >>> > > >>> or/and > > >>> > > >>>> PSI > > >>>> > > >>>>> entries would be a valuable addition. > > >>>>> > > >>>>> On thinking about this, I wonder if the text about this should go > at > > >>> > > >>> > > >>> the > > >>> > > >>>> end > > >>>> > > >>>>> of the Introduction (1.0) to the whole document, where people can > see > > >>> > > >>> > > >>> it > > >>> > > >>>>> clearly and then undesrtand that there may be something else > needed > > >>> > > >>> > > >>> for > > >>> > > >>>>> those > > >>>>> networks that rely on PSI for remultiplexing! > > >>>>> > > >>>>> - Bernhard & others who understand PSI, can you work with Art to > agree > > >>>> > > >>>> > > >>>> the > > >>>> > > >>>>> exact wording please? > > >>>>> > > >>>>> Gorry Fairhurst > > >>>>> (ipdvb WG Chair) > > >>>>> > > >>>>> Gorry Fairhurst wrote: > > >>>>> > > >>>>> > > >>>>> > > >>>>>> WG please read and respond to this message. > > >>>>>> > > >>>>>> The following message was received on January 22nd before WGLC, > but > > >>> > > >>> > > >>> was > > >>> > > >>>>>> dropped because the email source address was not verified by the > list > > >>>>>> server. > > >>>>>> > > >>>>>> The exact text of the message follows. > > >>>>>> > > >>>>>> best wishes, > > >>>>>> > > >>>>>> Gorry > > >>>>>> (ipdvb WG Chair) > > >>>>>> > > >>>>>> ----- > > >>>>>> > > >>>>> > > >>>>> 1) > > >>>>> > > >>>>> > > >>>>>> Thanks for considering my previous input... > > >>>>>> I note that the new draft has an editorial oversight in that it > > >>> > > >>> > > >>> contains > > >>> > > >>>>>> two definitions of PSI. I suggest the second should be deleted. > > >>>>>> > > >>>>> > > >>>>> 2) > > >>>>> > > >>>>> > > >>>>>> I previously made a comment about the ancillary requirements when > > >>> > > >>> > > >>> adding > > >>> > > >>>> a > > >>>> > > >>>>>> TS logical channel to a TS multiplex and asserted there appeared > > >>>>>> to be > > >>>>>> under > > >>>>>> specification. Perhaps it was viewed as out of scope, or perhaps > I > > >>>> > > >>>> > > >>>> simply > > >>>> > > >>>>>> don't recognize the change that resulted. I can not find what > > >>>> > > >>>> > > >>>> stream_type > > >>>> > > >>>>>> is required to be used for the ULE stream when a "TS Logical > Channel" > > >>> > > >>> > > >>> is > > >>> > > >>>>>> added to a multiplex. > > >>>> > > >>>> > > >>>> The problem here is the same as above. Without "applying" for a > > >>>> "stream_type" for ULE there is no stream_type for ULE. In contrary > why > > >>>> should one register a stream_type value for ULE earlier than ULE is > > >>>> standardized? > > >>>> > > >>>> > > >>>>>> I suggest at least an informative note be added in Section 6 > (after > > >>> > > >>> > > >>> the > > >>> > > >>>>>> third line which says: "These are transmitted using a single TS > > >>> > > >>> > > >>> Logical > > >>> > > >>>>>> Channel over a TS Multiplex.") The note should say "PSI entries > to > be > > >>>>>> consistent with [ISO-MPEG] when constructing a conformant TS > > >>>>>> Multiplex > > >>>> > > >>>> > > >>>> and > > >>>> > > >>>>>> means for Receivers to locate each such TS Logical Channel are > > >>>>>> outside > > >>>> > > >>>> > > >>>> the > > >>>> > > >>>>>> scope of this recommendation." > > >>>> > > >>>> > > >>>> Thanks, this is a very helpful suggestion for potential readers. In > > >>>> addition the ipdvb-wg works on providing signalling other than > PSI/SI. > > >>>> > > >>>> > > >>>>>> Reason: > > >>>>>> Just inserting a "TS Logical Channel" without including a > > >>>>>> TS_Program_map_section that lists the PID and a stream_type does > not > > >>>>>> appear to me to result in a strictly MPEG-2 conformant bit > stream; > > >>> > > >>> > > >>> and > > >>> > > >>>>>> practically > > >>>>>> could result in the PIDs being dropped by a remultiplexer. If > the > > >>>> > > >>>> > > >>>> means > > >>>> > > >>>>>> for binding the inserted element into a multiplex and subsequent > > >>>> > > >>>> > > >>>> discovery > > >>>> > > >>>>>> is to be covered in another document, a pointer to that document > > >>>>>> would > > >>>> > > >>>> > > >>>> be > > >>>> > > >>>>>> more helpful than this warning. It seems at least a warning is > needed > > >>>> > > >>>> > > >>>> and > > >>>> > > >>>>>> preferably a pointer to where this next level of TS construction > is > > >>>>>> defined. > > >>>> > > >>>> > > >>>> From an architectural point of view it is a reasonable assupmption > that > > >>>> whatever is being sent in a TS multiplex should be referenced. > However, > > >>>> the reality is that "ghost" PIDs do occur in many services either > > >>>> accidentially or for well-defined reasons. > > >>>> > > >>>> What is the penalty for not being strictly MPEG-2 > conformant/compliant? > > >>>> > > >>>> > > >>>>>> Art Allison > > >>>>>> Director, Advanced Engineering > > >>>>>> NAB Science & Technology > > >>>>>> 1771 N St NW, Washington Dc 20036 > > >>>>>> 202 429 5418 > > >>>> > > >>>> > > >>>> > > >>>> Regards, > > >>>> Bernhard Collini-Nocker > > >>>> > > >>>> > > >> > > >> > > > > > > > > From bnocker at cosy.sbg.ac.at Tue Feb 8 07:16:34 2005 From: bnocker at cosy.sbg.ac.at (Bernhard Collini-Nocker) Date: Tue, 08 Feb 2005 08:16:34 +0100 Subject: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto rs In-Reply-To: <08259490B3BC3140B549DD0907A5644811D697@admsrvnt10.enet.sharplabs.com> References: <08259490B3BC3140B549DD0907A5644811D697@admsrvnt10.enet.sharplabs.com> Message-ID: <42086752.107@cosy.sbg.ac.at> Please read below. Goldberg, Adam wrote: > Re #2 below, without discussion of PSI it will be both (1) difficult for > equipment to interoperate in that they may not be able to find the PID value My question wrt this is, why should not someone propose a dedicated ULE Stream Table (UST) for that purpose? Even on a dedicated PID, say 0x16, and registered/reserved for that purpose? It could well serve also INT/IMT/... purposes, without having to parse other sections. Consequently, the responsibility would be there, where it should be. Although, it wold make sense if someone would take responsibility for registration and someone else for semantics? But that seems quite innovative. Would ATSC/DVB let IETF/... come up with a draft/standard for a MPEG-2 section after having only reserved a dedicate PID for that? > in use for SNDU streams, and (2) passing through non-SNDU-aware MPEG > Transport equipment (of which none exists, I suppose) is not likely > (certainly not guaranteed). It is very difficult to compare television equipment (what MPEG-2 still primarily is?) with network equipment. Whether a unreferenced (ghost) PID is being dropped by a multiplexer or not is probably just a configuration issue. But, in what way can an IP router can tell (MPEG-2) receivers, where (on what PID) a specific ULE Stream is available? In a carneval like statement one could argue, that MPEG-2 is like a room with 8K Ethernet plugs, guess which is the right one to connect to your local network. Of course we know, that it is physically more the opposite: one plug, where 8K networks are on it, so more the nightmare for security admins. > I note from another response that the carriage may be specified in another > document. That seems fine, but perhaps mention should be made about it. Yes, information about the 8K PID Networks is essential for routing/addressing/... purposes. > In any case, 'TS Logical Channel' remains irksome to me. I'll respond > separately to other responses. Well, meanwhile my favourite is ULE Stream instead (thanks Gorry). It simply says what it is. > Adam Goldberg > Director, Television Standards & Policy Development > Sharp Laboratories of America > 8605 Westwood Center Drive, Suite 206 > Vienna, VA 22182 > +1-703-556-4406 > +1-703-556-4410 fax > +1-571-276-0305 cell Thanks for the interesting discussion, which is unfortunately a liitle bit late, yet fundamental. Kind regards, Bernhard Ass.Prof.Dr. Bernhard Collini-Nocker Head of Multimedia Communication Group University of Salzburg, Department of Scientific Computing Jakob Haringer Str. 1 A-5020 Salzburg Tel: *43 662 8044 6316 Fax: +43 662 8044 172 > >>-----Original Message----- >>From: Bernhard Collini-Nocker [mailto:bnocker at cosy.sbg.ac.at] >>Sent: Monday, February 07, 2005 7:49 AM >>To: ipdvb at erg.abdn.ac.uk >>Cc: Goldberg, Adam; Allison, Art; Matthew Goldman >>Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto >>rs >> >>Hello, >> >>let me try to summarize the two major points being raised and what the >>discussion is about: >>1. the name/definition of "TS Logical Channel" is not well received and >>the name/definition of a "SNDU stream" is proposed instead >>2. it is proposed to consider MPEG-2 conformance in specifying that ULE >>requires a specific stream_type value for the PMT >> >>Personally I have no objection against 1., because it is easy to change >>and improves wording and naming (unless somebody has an even better >>name for it). >>For 2. my concern is that mentioning stream_type may require some >>additional wording about PSI/SI in general, which is likely out of scope >>of the ULE draft. Even worse, in introducing a "world" besides the >>encapsulation/decapsulation of ULE, this may result in further confusion >>about what the MPEG-2/Section layer does in addition to and/or in >>comparison to ULE/IP. Actually some difficult question may arise from >>this direction, for example whether it is a wishful requirement for ULE >>to support PAT/PMT/NIT/INT/... table parsing? >> >>Any opinions, recommendations or suggestions about this? >> >>Regards, >>Bernhard >> >>Goldberg, Adam wrote: >> >>>ARGH. I fat-fingered 'send' before completing the email. See below. >>> >>>Adam Goldberg >>>Director, Television Standards & Policy Development >>>Sharp Laboratories of America >>>8605 Westwood Center Drive, Suite 206 >>>Vienna, VA 22182 >>>+1-703-556-4406 >>>+1-703-556-4410 fax >>>+1-571-276-0305 cell >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: Goldberg, Adam >>>>Sent: Monday, February 07, 2005 12:42 AM >>>>To: 'Bernhard Collini-Nocker'; Goldberg, Adam >>>>Cc: ipdvb at erg.abdn.ac.uk; Allison, Art; Matthew Goldman >>>>Subject: RE: Forward from Art Alison: WGLC ULE - Data Broadcast >> >>Descripto >> >>>>rs >>>> >>>>See below... >>>> >>>>Adam Goldberg >>>>Director, Television Standards & Policy Development >>>>Sharp Laboratories of America >>>>8605 Westwood Center Drive, Suite 206 >>>>Vienna, VA 22182 >>>>+1-703-556-4406 >>>>+1-703-556-4410 fax >>>>+1-571-276-0305 cell >>>> >>>> >>>>Bernhard Collini-Nocker wrote: >>>> >>>> >>>>>Goldberg, Adam wrote: >>>>> >>>>> >>>>>>I apologize for being "late to the party", but: >>>>>> >>>>>>I do not see a particular need to define new term "TS Logical >>> >>>Channel", >>> >>> >>>>>and >>>>> >>>>> >>>>>>indeed doing so creates risks of ill-specification (such as those Art >>>>> >>>>>points >>>>> >>>>> >>>>>>out), as well as confusion heaped upon someone familiar with MPEG-2 >>>>>>Transport (as typically used in entertainment delivery). >>>>> >>>>>Unfortunately the MPEG-2 standards do not provide a reasonable term for >>>>>the purpose of networking. The question is whether other terms, for >>>>>example "PID network" or "PID stream" would be better received and >>>>>understood? >>>>>The term "TS logical channel" tries to verbally visualize that the >>>>>encapsulation uses a continouos stream of transport stream packets >> >>using >> >>>>>one specific packet identifier to transport subnetwork data units. >> >>Maybe >> >>>>>the term "TS (virtual) circuit" better names this? >>>> >>>>It is perhaps not well defined in 13818-1, but the term of art is >>>>"streams". Many people use "PID stream" which is a poor combination of >>>>words. I'd have no objection to defining a "SNDU Stream" as something >>>>like "a sequence of MPEG-2 Transport Stream packets identified by a >> >>common >> >>>>PID value" (or some such). >>>> >>>>Perhaps discussing 'virtual circuits' relative to a Transport Stream is >>>>begging for confusion. Use of any such words ("TS (virtual) circuit") >>>>needs careful definition, likely requiring the above SNDU Stream >>>>definition plus an explanation of what it means for multiple SNDU >> >>Streams >> >>>>to exist in a single Transport Stream. >>>> >>>> >>>> >>>>>>Furthermore, the definition is quite wrong with respect to ATSC and >>>> >>>>DVB >>>> >>>> >>>>>use >>>>> >>>>> >>>>>>of "specific TS Logical Channels". To my knowledge, this internet- >>>> >>>>draft >>>> >>>> >>>>>is >>>>> >>>>> >>>>>>the only document anywhere which uses such terms. It is certainly >>>> >>>>true >>>> >>>> >>>>>that >>>>> >>>>> >>>>>>MPEG, DVB and ATSC define //elementary streams// identified by >>>>> >>>>>stream_type >>>>> >>>>> >>>>>>values. I suspect this is what is meant by "TS Logical Channel", but >>>> >>>>it >>>> >>>> >>>>>is >>>>> >>>>> >>>>>>difficult for me to tell. >>>>> >>>>>I am not so sure, whether this analysis is correct. Elementary streams >>>>>are those that are transported as Packetized ES, whereas "auxillary" >>>>>data and signalling is transported as sections. Although a stream_type >>>>>in the program map section is used to reference both PESs and sections >>>>>the term elementary stream is used very vague and we tried to avoid >>>>>using it in the same vague manner. >>>> >>>>Perhaps I overstepped with "elementary stream". >>>> >>>>Consider the 13818-1 definition of "Packetized Elementary Stream": "A >>>>continuous sequence of PES packets of one elementary stream with one >>>>stream ID may be used to construct a PES Stream." (ISO/IEC 13818-1:2000 >> >>p. >> >>>>xiii) >>>> >>>>Stuff carried as payload of Transport Stream packets are merely >> >>'payload'. >> >>>>What the draft starts to define is a new type of payload stream (that > > is, > >>>>a new way to carry data in a transport stream). The definition is not >>>>compete. >>>> >>>> >>>> >>>>>According to, for example EN301192 v1.3.1, defines Data Piping as: >>>>>" The data broadcast service shall insert the data to be broadcast >>>>>directly in the payload of MPEG-2 TS packets." >>>>>That raises the question, how to call a continouos stream of MPEG-2 TS >>>>>packets with a certain PID? >>>>> >>>>>Further the standard details that: >>>>>"The data broadcast service may use the payload_unit_start_indicator >>>>>field and the transport_priority field of the MPEG-2 Transport Stream >>>>>packets in a service private way. The use of the adaptation_field shall >>>>>be MPEG-2 compliant." >>>>>ULE uses PUSI and does not utilize the AF. >>>>> >>>>>"The delivery of the bits in time through a data pipe is service >> >>private >> >>>>>and is not specified in the present document." >>>>>It seems obvious that the use of the term "TS Data Pipe" would lead to >>>>>the wrong conclusion that ULE equals Data Piping. But Data Piping is >> >>not >> >>>>>detailed at all, whereas ULE tries to be. >>>> >>>>I'm not going to argue that DVB's specification is complete. I will >> >>argue >> >>>>that ULE isn't complete. >>>> >>>> >>>> >>>>>>(from the draft) >>>>>> TS Logical Channel: Transport Stream Logical Channel. In this >>>>>> document, this term identifies a channel at the MPEG-2 level [ISO- >>>>>> MPEG]. It exists at level 2 of the ISO/OSI reference model. All >>>>>> packets sent over a TS Logical Channel carry the same PID value >>>>>> (this value is unique within a specific TS Multiplex). According to >>>>>> MPEG-2, some TS Logical Channels are reserved for specific >>>>>> signalling purposes. Other standards (e.g., ATSC, DVB) also reserve >>>>>> specific TS Logical Channels. >>>>>> >>>>>>While I'm commenting on this definition, it also seems to me that >>>>> >>>>>"channel >>>>> >>>>> >>>>>>at the MPEG-2 level" is either wrong or also ill-specified. What's a >>>>>>channel? If you're talking about MPEG-2, it's certainly conceivable >>>>> >>>>>that >>>>> >>>>> >>>>>>the reader may associate "channel" with "[television] channel" - which >>>>> >>>>>are >>>>> >>>>> >>>>>>the subject of a large amount of ATSC and DVB systems. >>>>> >>>>>The term channel is indeed problematic in the context of television, >>>>>however, network engineers might have a different understanding about >>>>>what a channel is. >>>>>According to ATIS a channel is "1. A connection between initiating and >>>>>terminating nodes of a circuit. 2. A single path provided by a >>>>>transmission medium via either (a) physical separation, such as by >>>>>multipair cable or (b) electrical separation, such as by frequency- or >>>>>time-division multiplexing. ..." >>>> >>>>I understand that 'channel' vis-?-vis networking has a different meaning >>>>than 'channel' vis-?-vis television. This was my point actually, that >>>>those familiar with MPEG transport should not be assumed to be >> >>networking- >> >>>>types (even when speaking with respect to ULE). >>>> >>>> >>>> >>>>>>Additionally, it is also wrong or ill-specified to say "According to >>>>> >>>>>MPEG-2 >>>>> >>>>> >>>>>>... TS Logical Channels ...". There is no such concept defined or >>>> >>>>used >>>> >>>> >>>>>>within MPEG (unless what you really mean is elementary stream, in >>>> >>>>which >>>> >>>> >>>>>case >>>>> >>>>> >>>>>>what do you need this extraneous term for anyhow?). >>>>> >>>>>Again, elementary stream is not exactly what is being meant: >>>>>For example EN 300468 v1.5.1 defines: >>>>>"component (ELEMENTARY Stream): one or more entities which together >> >>make >> >>>>>up an event, e.g. video, audio, teletext" >>>>> >>>>>and says further: >>>>>"The component descriptor identifies the type of component stream and >>>>>may be used to provide a text description of the elementary stream" >>>>> >>>>>where: >>>>>"component_type: This 8-bit field specifies the type of the video, >> >>audio >> >>>>>or EBU-data component. The coding of this field is specified in table >>>> >>>>26." >>>> >>>> >>>>>Table 26 then lists all kinds of video, audio, and teletext formats, >> >>but >> >>>>>unfortunately no networking formats. >>>>> >>>>>At other places this standard is as innovative/creative in naming: >>>>>"event: grouping of elementary broadcast data streams with a defined >>>>>start and end time belonging to a common service, e.g. first half of a >>>>>football match, News Flash, first part of an entertainment show" >>>>>What is a "elementary broadcast data streams"? Not by guessing but by >>>>>definition? >>>>> >>>>> >>>>> >>>>>>In any case, Art is certainly correct that merely identifying a "TS >>>>> >>>>>Logical >>>>> >>>>> >>>>>>Channel" as a sequence of packets identified with a common PID value >>>>> >>>>>without >>>>> >>>>> >>>>>>identifying the PSI details is an invitation to multiplexers and >>>>>>remultiplexers to drop those packets on the floor. >>>>> >>>>>Oh yes, this is the real problem of defining something outside >>>>>television standardiszation bodies: one risks that ULE packets are >> >>being >> >>>>>dropped. >>>>>We have discussed basically two approaches: >>>>>1. define the PSI and get an ID, or tag, or "stream_type" for ULE, or > > 2. > >>>>>define ULE and let somebody else do the PSI work. >>>>>We have had some reasons for choice 2. >>>> >>>>This is a very easy thing to fix and something which should be done. >>>>Without defining a stream_type for ULE data, it is neither possible to >>>>construct a transport stream compliant with MPEG-2 nor one that >>>>interoperates with other ULE equipment. >>>> >>>>ATSC maintains a 'codepoint registry', and would be happy to allocate a >>>>stream_type value for ULE data upon request from IETF. Furthermore, the >>>>text to specify usage of the stream_type would be reasonably easy (and >>>>perhaps ties in to my suggested "SNDU Stream" definition (that is, >> >>define >> >>>>it as >>> >>> >>>SNDU Stream: a sequence of MPEG-2 Transport Stream packets identified by >> >>a >> >>>common PID value of stream_type <0xnn>. >>> >>>All that then remains, I think, would be to signal when a Program >> >>carries >> >>>SNDU Stream(s), and what it means when there are more than one SNDU >> >>Stream >> >>>per program, or more than one Program that carries one or more SNDU >> >>Streams. >> >>> >>>>>>If there remains an opportunity to repair what I believe to be errors >>>> >>>>in >>>> >>>> >>>>>the >>>>> >>>>> >>>>>>draft, I'm eager and willing to participate from a MPEG-2 >>>> >>>>entertainment >>>> >>>> >>>>>>(which is to say, legacy use of MPEG-2 Transport) point of view. >>>>> >>>>>Of course the terms in the document should not conflict with meaning in >>>>>another context. However, ambiguous terms in other documents should be >>>>>avoided as well. >>>>> >>>>> >>>>> >>>>>>[Apologies for being strident at all, to say nothing of at such an >>>>>>apparently late stage - if the above is perceived as such] >>>>>> >>>>>>Regards, >>>>>>Adam Goldberg >>>>>>Director, Television Standards & Policy Development >>>>>>Sharp Laboratories of America >>>>>>8605 Westwood Center Drive, Suite 206 >>>>>>Vienna, VA 22182 >>>>>>+1-703-556-4406 >>>>>>+1-703-556-4410 fax >>>>>>+1-571-276-0305 cell >>>>>> >>>>>> >>>>>>-----Original Message----- >>>>>>From: owner-ipdvb at erg.abdn.ac.uk [mailto:owner-ipdvb at erg.abdn.ac.uk] >>>> >>>>On >>>> >>>> >>>>>>Behalf Of Gorry Fairhurst >>>>>>Sent: Friday, February 04, 2005 6:56 AM >>>>>>To: ipdvb at erg.abdn.ac.uk; Bernhard Collini-Nocker >>>>>>Cc: AAllison at nab.org >>>>>>Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast >>>>> >>>>>Descriptors >>>>> >>>>> >>>>>>1) Done - point 1 was an edit mistake. >>>>>> >>>>>>2) I think some text on data broadcast descriptors, stream-type, >>>> >>>>or/and >>>> >>>> >>>>>PSI >>>>> >>>>> >>>>>>entries would be a valuable addition. >>>>>> >>>>>>On thinking about this, I wonder if the text about this should go at >>>> >>>>the >>>> >>>> >>>>>end >>>>> >>>>> >>>>>>of the Introduction (1.0) to the whole document, where people can see >>>> >>>>it >>>> >>>> >>>>>>clearly and then undesrtand that there may be something else needed >>>> >>>>for >>>> >>>> >>>>>>those >>>>>>networks that rely on PSI for remultiplexing! >>>>>> >>>>>>- Bernhard & others who understand PSI, can you work with Art to agree >>>>> >>>>>the >>>>> >>>>> >>>>>>exact wording please? >>>>>> >>>>>>Gorry Fairhurst >>>>>>(ipdvb WG Chair) >>>>>> >>>>>>Gorry Fairhurst wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>WG please read and respond to this message. >>>>>>> >>>>>>>The following message was received on January 22nd before WGLC, but >>>> >>>>was >>>> >>>> >>>>>>>dropped because the email source address was not verified by the list >>>>>>>server. >>>>>>> >>>>>>>The exact text of the message follows. >>>>>>> >>>>>>>best wishes, >>>>>>> >>>>>>>Gorry >>>>>>>(ipdvb WG Chair) >>>>>>> >>>>>>>----- >>>>>>> >>>>>> >>>>>>1) >>>>>> >>>>>> >>>>>> >>>>>>>Thanks for considering my previous input... >>>>>>>I note that the new draft has an editorial oversight in that it >>>> >>>>contains >>>> >>>> >>>>>>>two definitions of PSI. I suggest the second should be deleted. >>>>>>> >>>>>> >>>>>>2) >>>>>> >>>>>> >>>>>> >>>>>>>I previously made a comment about the ancillary requirements when >>>> >>>>adding >>>> >>>> >>>>>a >>>>> >>>>> >>>>>>>TS logical channel to a TS multiplex and asserted there appeared to >> >>be >> >>>>>>>under >>>>>>>specification. Perhaps it was viewed as out of scope, or perhaps I >>>>> >>>>>simply >>>>> >>>>> >>>>>>>don't recognize the change that resulted. I can not find what >>>>> >>>>>stream_type >>>>> >>>>> >>>>>>>is required to be used for the ULE stream when a "TS Logical Channel" >>>> >>>>is >>>> >>>> >>>>>>>added to a multiplex. >>>>> >>>>>The problem here is the same as above. Without "applying" for a >>>>>"stream_type" for ULE there is no stream_type for ULE. In contrary why >>>>>should one register a stream_type value for ULE earlier than ULE is >>>>>standardized? >>>>> >>>>> >>>>> >>>>>>>I suggest at least an informative note be added in Section 6 (after >>>> >>>>the >>>> >>>> >>>>>>>third line which says: "These are transmitted using a single TS >>>> >>>>Logical >>>> >>>> >>>>>>>Channel over a TS Multiplex.") The note should say "PSI entries to be >>>>>>>consistent with [ISO-MPEG] when constructing a conformant TS >> >>Multiplex >> >>>>>and >>>>> >>>>> >>>>>>>means for Receivers to locate each such TS Logical Channel are >> >>outside >> >>>>>the >>>>> >>>>> >>>>>>>scope of this recommendation." >>>>> >>>>>Thanks, this is a very helpful suggestion for potential readers. In >>>>>addition the ipdvb-wg works on providing signalling other than PSI/SI. >>>>> >>>>> >>>>> >>>>>>>Reason: >>>>>>>Just inserting a "TS Logical Channel" without including a >>>>>>>TS_Program_map_section that lists the PID and a stream_type does not >>>>>>>appear to me to result in a strictly MPEG-2 conformant bit stream; >>>> >>>>and >>>> >>>> >>>>>>>practically >>>>>>>could result in the PIDs being dropped by a remultiplexer. If the >>>>> >>>>>means >>>>> >>>>> >>>>>>>for binding the inserted element into a multiplex and subsequent >>>>> >>>>>discovery >>>>> >>>>> >>>>>>>is to be covered in another document, a pointer to that document >> >>would >> >>>>>be >>>>> >>>>> >>>>>>>more helpful than this warning. It seems at least a warning is needed >>>>> >>>>>and >>>>> >>>>> >>>>>>>preferably a pointer to where this next level of TS construction is >>>>>>>defined. >>>>> >>>>>From an architectural point of view it is a reasonable assupmption >> >>that >> >>>>>whatever is being sent in a TS multiplex should be referenced. However, >>>>>the reality is that "ghost" PIDs do occur in many services either >>>>>accidentially or for well-defined reasons. >>>>> >>>>>What is the penalty for not being strictly MPEG-2 conformant/compliant? >>>>> >>>>> >>>>> >>>>>>>Art Allison >>>>>>>Director, Advanced Engineering >>>>>>>NAB Science & Technology >>>>>>>1771 N St NW, Washington Dc 20036 >>>>>>>202 429 5418 >>>>> >>>>> >>>>>Regards, >>>>>Bernhard Collini-Nocker >>>>> >>>>> >>> >>> > From bnocker at cosy.sbg.ac.at Tue Feb 8 07:38:12 2005 From: bnocker at cosy.sbg.ac.at (Bernhard Collini-Nocker) Date: Tue, 08 Feb 2005 08:38:12 +0100 Subject: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto rs In-Reply-To: <08259490B3BC3140B549DD0907A5644811D699@admsrvnt10.enet.sharplabs.com> References: <08259490B3BC3140B549DD0907A5644811D699@admsrvnt10.enet.sharplabs.com> Message-ID: <42086C64.4080900@cosy.sbg.ac.at> Nothin more to say than: http://www.ietf.org/internet-drafts/draft-fair-ipdvb-ar-02.txt Regards, Bernhard Goldberg, Adam wrote: > Below > > Adam Goldberg > Director, Television Standards & Policy Development > Sharp Laboratories of America > 8605 Westwood Center Drive, Suite 206 > Vienna, VA 22182 > +1-703-556-4406 > +1-703-556-4410 fax > +1-571-276-0305 cell > > > >>-----Original Message----- >>From: Marie-Jose Montpetit [mailto:mariejose.montpetit at verizon.net] >>Sent: Monday, February 07, 2005 3:56 PM >>To: ipdvb at erg.abdn.ac.uk >>Cc: Goldberg, Adam; Allison, Art; Matthew Goldman >>Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto >>rs >> >>I think we need to close on some of those issues and move forward. >> >>Here is what I propose which would be inline with the conclusions of the >>Architecture Draft: >>(1) ULE is encapsulation only - it is not the purpose nor the usage of ULE >>to dwell in SI/PSI table issues nor any other protocol; so we leave the >>draft to be mostly what it is now (pending small changes proposed by >>Gorry) > > > This becomes a bit self-referential. The proper definition of the data > stream is to say something like "a stream of stream_type 0xNN", but you > propose not doing this until later. > > >>(2) PSI/SI scanning is part of the Address Resolution Draft as regard >>management of addressing; it will be further discussed there and focus >>given >>to the issues raised in this thread > > > Can someone provide a pointer to the "Address Resolution Draft"? > > >>(3) Someone (Adam and/or team) proposes WG work and a draft on ATSC >>concerns >>on PSI/SI issues and ULE; inclusion of cable TV concerns in addition to >>satellite would be welcome and has been one of my goals for the group >>(4) we close on ULE and get to discuss the other items further at IETF > > > Don't misunderstand my concerns (or Art's, I suppose) - they are not "ATSC > concerns" so much as concerns from one overly familiar with MPEG-2 Transport > Streams and their widespread use. > > > >>Thanks >> >>Marie-Jose >> >>----- Original Message ----- >>From: "Gorry Fairhurst" >>To: >>Cc: "Goldberg, Adam" ; "Allison, Art" >>; "Matthew Goldman" >>Sent: Monday, February 07, 2005 8:54 AM >>Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto >>rs >> >> >> >>>So.... >>> >>>1. The term "TS Logical Channel" was discussed a lot at the begining of >> >>the >> >>>WG. As I recall, the reason for the new term, was that at this time the >> >>WG >> >>>could not find a suitably "unbiased" term for the set of TS Packets with >> >>a >> >>>common PID value (raw TS, DSMCC, Private Section, PES, etc). One key >> >>objective >> >>>was to find a term that did not carry extra semantics, and was >> >>understandable >> >>>by the networking community - this is after all intended as a part of >> >>the >> >>>RFC-series, and we need to make this accessible to people familiar with >> >>using >> >>>IP over Ethernet, MPLS, ATM, Fibre Channel, Firewire, SDH/SONET, etc. >>>T >>> >>>we shoudl note that the term "TS Logical Channel term already appears >> >>(and >>is >> >>>discussed in some detail) in the document draft-ietf-ipvb-arch-xx.txt >> >>and >>that >> >>>this HAS already complete WGLC. If it IS WRONG we still have a chance >> >>to >>fix >> >>>the definition/term, if we have to. Specifically, is there already a >>>well-accepted term for the set of TS Packets with a common PID value >> >>(raw >>TS, >> >>>DSMCC, Private Section, PES, etc) that we should use or refer to? >>> >>> >>>2. I'm not against defining another term "ULE Stream", "SNDU Stream", >> >>etc >>if >> >>>that helps to describe the set of TS packets with a specific PID used >> >>for >>ULE, >> >>>especially when talking about PSI. >>> >>>Bernhard, is there an opportunity of inserting a simple statement as the >> >>final >> >>>paragraph of the introduction which says that to use ULE streams within >> >>an >> >>>MPEG-2 compliant multiplex may require appropriate PSI entries... I >> >>think >>Art >> >>>already proposed some specific wording that could be used or modified? >>> >>> >>>3) Once teh ULE spec is agreed and an RFC number issued, I can also see >> >>great >> >>>advantage in assigning a descriptor for this in ATSC. I think the WG >> >>SHOULD >> >>>should explore this at the next stage. >>> >>> >>>Gorry >>> >>>Bernhard Collini-Nocker wrote: >>> >>> >>>>Hello, >>>> >>>>let me try to summarize the two major points being raised and what the >>>>discussion is about: >>>>1. the name/definition of "TS Logical Channel" is not well received >> >>and >> >>>>the name/definition of a "SNDU stream" is proposed instead >>>>2. it is proposed to consider MPEG-2 conformance in specifying that >> >>ULE >> >>>>requires a specific stream_type value for the PMT >>>> >>>>Personally I have no objection against 1., because it is easy to >> >>change >> >>>>and improves wording and naming (unless somebody has an even better >>>>name for it). >>>>For 2. my concern is that mentioning stream_type may require some >>>>additional wording about PSI/SI in general, which is likely out of >> >>scope >> >>>>of the ULE draft. Even worse, in introducing a "world" besides the >>>>encapsulation/decapsulation of ULE, this may result in further >> >>confusion >> >>>>about what the MPEG-2/Section layer does in addition to and/or in >>>>comparison to ULE/IP. Actually some difficult question may arise from >>>>this direction, for example whether it is a wishful requirement for >> >>ULE >> >>>>to support PAT/PMT/NIT/INT/... table parsing? >>>> >>>>Any opinions, recommendations or suggestions about this? >>>> >>>>Regards, >>>>Bernhard >>>> >>>>Goldberg, Adam wrote: >>>> >>>> >>>>>ARGH. I fat-fingered 'send' before completing the email. See below. >>>>> >>>>>Adam Goldberg >>>>>Director, Television Standards & Policy Development >>>>>Sharp Laboratories of America >>>>>8605 Westwood Center Drive, Suite 206 >>>>>Vienna, VA 22182 >>>>>+1-703-556-4406 >>>>>+1-703-556-4410 fax >>>>>+1-571-276-0305 cell >>>>> >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: Goldberg, Adam >>>>>>Sent: Monday, February 07, 2005 12:42 AM >>>>>>To: 'Bernhard Collini-Nocker'; Goldberg, Adam >>>>>>Cc: ipdvb at erg.abdn.ac.uk; Allison, Art; Matthew Goldman >>>>>>Subject: RE: Forward from Art Alison: WGLC ULE - Data Broadcast >>>>>>Descripto >>>>>>rs >>>>>> >>>>>>See below... >>>>>> >>>>>>Adam Goldberg >>>>>>Director, Television Standards & Policy Development >>>>>>Sharp Laboratories of America >>>>>>8605 Westwood Center Drive, Suite 206 >>>>>>Vienna, VA 22182 >>>>>>+1-703-556-4406 >>>>>>+1-703-556-4410 fax >>>>>>+1-571-276-0305 cell >>>>>> >>>>>> >>>>>>Bernhard Collini-Nocker wrote: >>>>>> >>>>>> >>>>>>>Goldberg, Adam wrote: >>>>>>> >>>>>>> >>>>>>>>I apologize for being "late to the party", but: >>>>>>>> >>>>>>>>I do not see a particular need to define new term "TS Logical >>>>> >>>>> >>>>>Channel", >>>>> >>>>> >>>>>>>and >>>>>>> >>>>>>> >>>>>>>>indeed doing so creates risks of ill-specification (such as those >> >>Art >> >>>>>>> >>>>>>>points >>>>>>> >>>>>>> >>>>>>>>out), as well as confusion heaped upon someone familiar with MPEG- >> >>2 >> >>>>>>>>Transport (as typically used in entertainment delivery). >>>>>>> >>>>>>> >>>>>>>Unfortunately the MPEG-2 standards do not provide a reasonable term >> >>for >> >>>>>>>the purpose of networking. The question is whether other terms, for >>>>>>>example "PID network" or "PID stream" would be better received and >>>>>>>understood? >>>>>>>The term "TS logical channel" tries to verbally visualize that the >>>>>>>encapsulation uses a continouos stream of transport stream packets >>>>>>>using >>>>>>>one specific packet identifier to transport subnetwork data units. >>>>>>>Maybe >>>>>>>the term "TS (virtual) circuit" better names this? >>>>>> >>>>>> >>>>>>It is perhaps not well defined in 13818-1, but the term of art is >>>>>>"streams". Many people use "PID stream" which is a poor combination >> >>of >> >>>>>>words. I'd have no objection to defining a "SNDU Stream" as >> >>something >> >>>>>>like "a sequence of MPEG-2 Transport Stream packets identified by a >>>>>>common >>>>>>PID value" (or some such). >>>>>> >>>>>>Perhaps discussing 'virtual circuits' relative to a Transport Stream >> >>is >> >>>>>>begging for confusion. Use of any such words ("TS (virtual) >> >>circuit") >> >>>>>>needs careful definition, likely requiring the above SNDU Stream >>>>>>definition plus an explanation of what it means for multiple SNDU >>>>>>Streams >>>>>>to exist in a single Transport Stream. >>>>>> >>>>>> >>>>>> >>>>>>>>Furthermore, the definition is quite wrong with respect to ATSC >> >>and >> >>>>>> >>>>>>DVB >>>>>> >>>>>> >>>>>>>use >>>>>>> >>>>>>> >>>>>>>>of "specific TS Logical Channels". To my knowledge, this >> >>internet- >> >>>>>> >>>>>>draft >>>>>> >>>>>> >>>>>>>is >>>>>>> >>>>>>> >>>>>>>>the only document anywhere which uses such terms. It is certainly >>>>>> >>>>>> >>>>>>true >>>>>> >>>>>> >>>>>>>that >>>>>>> >>>>>>> >>>>>>>>MPEG, DVB and ATSC define //elementary streams// identified by >>>>>>> >>>>>>> >>>>>>>stream_type >>>>>>> >>>>>>> >>>>>>>>values. I suspect this is what is meant by "TS Logical Channel", >> >>but >> >>>>>> >>>>>>it >>>>>> >>>>>> >>>>>>>is >>>>>>> >>>>>>> >>>>>>>>difficult for me to tell. >>>>>>> >>>>>>> >>>>>>>I am not so sure, whether this analysis is correct. Elementary >> >>streams >> >>>>>>>are those that are transported as Packetized ES, whereas >> >>"auxillary" >> >>>>>>>data and signalling is transported as sections. Although a >> >>stream_type >> >>>>>>>in the program map section is used to reference both PESs and >> >>sections >> >>>>>>>the term elementary stream is used very vague and we tried to avoid >>>>>>>using it in the same vague manner. >>>>>> >>>>>> >>>>>>Perhaps I overstepped with "elementary stream". >>>>>> >>>>>>Consider the 13818-1 definition of "Packetized Elementary Stream": >> >>"A >> >>>>>>continuous sequence of PES packets of one elementary stream with one >>>>>>stream ID may be used to construct a PES Stream." (ISO/IEC >>>>>>13818-1:2000 p. >>>>>>xiii) >>>>>> >>>>>>Stuff carried as payload of Transport Stream packets are merely >>>>>>'payload'. >>>>>>What the draft starts to define is a new type of payload stream >> >>(that >> >>>>>>is, >>>>>>a new way to carry data in a transport stream). The definition is >> >>not >> >>>>>>compete. >>>>>> >>>>>> >>>>>> >>>>>>>According to, for example EN301192 v1.3.1, defines Data Piping as: >>>>>>>" The data broadcast service shall insert the data to be broadcast >>>>>>>directly in the payload of MPEG-2 TS packets." >>>>>>>That raises the question, how to call a continouos stream of MPEG-2 >> >>TS >> >>>>>>>packets with a certain PID? >>>>>>> >>>>>>>Further the standard details that: >>>>>>>"The data broadcast service may use the >> >>payload_unit_start_indicator >> >>>>>>>field and the transport_priority field of the MPEG-2 Transport >> >>Stream >> >>>>>>>packets in a service private way. The use of the adaptation_field >> >>shall >> >>>>>>>be MPEG-2 compliant." >>>>>>>ULE uses PUSI and does not utilize the AF. >>>>>>> >>>>>>>"The delivery of the bits in time through a data pipe is service >>>>>>>private >>>>>>>and is not specified in the present document." >>>>>>>It seems obvious that the use of the term "TS Data Pipe" would lead >> >>to >> >>>>>>>the wrong conclusion that ULE equals Data Piping. But Data Piping >> >>is >> >>>>>>>not >>>>>>>detailed at all, whereas ULE tries to be. >>>>>> >>>>>> >>>>>>I'm not going to argue that DVB's specification is complete. I will >>>>>>argue >>>>>>that ULE isn't complete. >>>>>> >>>>>> >>>>>> >>>>>>>>(from the draft) >>>>>>>> TS Logical Channel: Transport Stream Logical Channel. In this >>>>>>>> document, this term identifies a channel at the MPEG-2 level >> >>[ISO- >> >>>>>>>> MPEG]. It exists at level 2 of the ISO/OSI reference model. All >>>>>>>> packets sent over a TS Logical Channel carry the same PID value >>>>>>>> (this value is unique within a specific TS Multiplex). According >> >>to >> >>>>>>>> MPEG-2, some TS Logical Channels are reserved for specific >>>>>>>> signalling purposes. Other standards (e.g., ATSC, DVB) also >> >>reserve >> >>>>>>>> specific TS Logical Channels. >>>>>>>> >>>>>>>>While I'm commenting on this definition, it also seems to me that >>>>>>> >>>>>>> >>>>>>>"channel >>>>>>> >>>>>>> >>>>>>>>at the MPEG-2 level" is either wrong or also ill-specified. >> >>What's >>a >> >>>>>>>>channel? If you're talking about MPEG-2, it's certainly >> >>conceivable >> >>>>>>> >>>>>>>that >>>>>>> >>>>>>> >>>>>>>>the reader may associate "channel" with "[television] channel" - >> >>which >> >>>>>>> >>>>>>>are >>>>>>> >>>>>>> >>>>>>>>the subject of a large amount of ATSC and DVB systems. >>>>>>> >>>>>>> >>>>>>>The term channel is indeed problematic in the context of > > television, > >>>>>>>however, network engineers might have a different understanding >> >>about >> >>>>>>>what a channel is. >>>>>>>According to ATIS a channel is "1. A connection between initiating >> >>and >> >>>>>>>terminating nodes of a circuit. 2. A single path provided by a >>>>>>>transmission medium via either (a) physical separation, such as by >>>>>>>multipair cable or (b) electrical separation, such as by frequency- >> >>or >> >>>>>>>time-division multiplexing. ..." >>>>>> >>>>>> >>>>>>I understand that 'channel' vis-?-vis networking has a different >> >>meaning >> >>>>>>than 'channel' vis-?-vis television. This was my point actually, >> >>that >> >>>>>>those familiar with MPEG transport should not be assumed to be >>>>>>networking- >>>>>>types (even when speaking with respect to ULE). >>>>>> >>>>>> >>>>>> >>>>>>>>Additionally, it is also wrong or ill-specified to say "According >> >>to >> >>>>>>> >>>>>>>MPEG-2 >>>>>>> >>>>>>> >>>>>>>>... TS Logical Channels ...". There is no such concept defined or >>>>>> >>>>>> >>>>>>used >>>>>> >>>>>> >>>>>>>>within MPEG (unless what you really mean is elementary stream, in >>>>>> >>>>>> >>>>>>which >>>>>> >>>>>> >>>>>>>case >>>>>>> >>>>>>> >>>>>>>>what do you need this extraneous term for anyhow?). >>>>>>> >>>>>>> >>>>>>>Again, elementary stream is not exactly what is being meant: >>>>>>>For example EN 300468 v1.5.1 defines: >>>>>>>"component (ELEMENTARY Stream): one or more entities which together >>>>>>>make >>>>>>>up an event, e.g. video, audio, teletext" >>>>>>> >>>>>>>and says further: >>>>>>>"The component descriptor identifies the type of component stream >> >>and >> >>>>>>>may be used to provide a text description of the elementary stream" >>>>>>> >>>>>>>where: >>>>>>>"component_type: This 8-bit field specifies the type of the video, >>>>>>>audio >>>>>>>or EBU-data component. The coding of this field is specified in >> >>table >> >>>>>> >>>>>>26." >>>>>> >>>>>> >>>>>>>Table 26 then lists all kinds of video, audio, and teletext > > formats, > >>>>>>>but >>>>>>>unfortunately no networking formats. >>>>>>> >>>>>>>At other places this standard is as innovative/creative in naming: >>>>>>>"event: grouping of elementary broadcast data streams with a >> >>defined >> >>>>>>>start and end time belonging to a common service, e.g. first half >> >>of >>a >> >>>>>>>football match, News Flash, first part of an entertainment show" >>>>>>>What is a "elementary broadcast data streams"? Not by guessing but >> >>by >> >>>>>>>definition? >>>>>>> >>>>>>> >>>>>>> >>>>>>>>In any case, Art is certainly correct that merely identifying a >> >>"TS >> >>>>>>> >>>>>>>Logical >>>>>>> >>>>>>> >>>>>>>>Channel" as a sequence of packets identified with a common PID >> >>value >> >>>>>>> >>>>>>>without >>>>>>> >>>>>>> >>>>>>>>identifying the PSI details is an invitation to multiplexers and >>>>>>>>remultiplexers to drop those packets on the floor. >>>>>>> >>>>>>> >>>>>>>Oh yes, this is the real problem of defining something outside >>>>>>>television standardiszation bodies: one risks that ULE packets are >>>>>>>being >>>>>>>dropped. >>>>>>>We have discussed basically two approaches: >>>>>>>1. define the PSI and get an ID, or tag, or "stream_type" for ULE, >>>>>>>or 2. >>>>>>>define ULE and let somebody else do the PSI work. >>>>>>>We have had some reasons for choice 2. >>>>>> >>>>>> >>>>>>This is a very easy thing to fix and something which should be done. >>>>>>Without defining a stream_type for ULE data, it is neither possible >> >>to >> >>>>>>construct a transport stream compliant with MPEG-2 nor one that >>>>>>interoperates with other ULE equipment. >>>>>> >>>>>>ATSC maintains a 'codepoint registry', and would be happy to >> >>allocate >>a >> >>>>>>stream_type value for ULE data upon request from IETF. Furthermore, >> >>the >> >>>>>>text to specify usage of the stream_type would be reasonably easy >> >>(and >> >>>>>>perhaps ties in to my suggested "SNDU Stream" definition (that is, >>>>>>define >>>>>>it as >>>>> >>>>> >>>>> >>>>>SNDU Stream: a sequence of MPEG-2 Transport Stream packets identified >>>>>by a >>>>>common PID value of stream_type <0xnn>. >>>>> >>>>>All that then remains, I think, would be to signal when a Program >> >>carries >> >>>>>SNDU Stream(s), and what it means when there are more than one SNDU >>>>>Stream >>>>>per program, or more than one Program that carries one or more SNDU >>>>>Streams. >>>>> >>>>> >>>>> >>>>>>>>If there remains an opportunity to repair what I believe to be >> >>errors >> >>>>>> >>>>>>in >>>>>> >>>>>> >>>>>>>the >>>>>>> >>>>>>> >>>>>>>>draft, I'm eager and willing to participate from a MPEG-2 >>>>>> >>>>>> >>>>>>entertainment >>>>>> >>>>>> >>>>>>>>(which is to say, legacy use of MPEG-2 Transport) point of view. >>>>>>> >>>>>>> >>>>>>>Of course the terms in the document should not conflict with >> >>meaning >>in >> >>>>>>>another context. However, ambiguous terms in other documents should >> >>be >> >>>>>>>avoided as well. >>>>>>> >>>>>>> >>>>>>> >>>>>>>>[Apologies for being strident at all, to say nothing of at such an >>>>>>>>apparently late stage - if the above is perceived as such] >>>>>>>> >>>>>>>>Regards, >>>>>>>>Adam Goldberg >>>>>>>>Director, Television Standards & Policy Development >>>>>>>>Sharp Laboratories of America >>>>>>>>8605 Westwood Center Drive, Suite 206 >>>>>>>>Vienna, VA 22182 >>>>>>>>+1-703-556-4406 >>>>>>>>+1-703-556-4410 fax >>>>>>>>+1-571-276-0305 cell >>>>>>>> >>>>>>>> >>>>>>>>-----Original Message----- >>>>>>>>From: owner-ipdvb at erg.abdn.ac.uk [mailto:owner- >> >>ipdvb at erg.abdn.ac.uk] >> >>>>>> >>>>>>On >>>>>> >>>>>> >>>>>>>>Behalf Of Gorry Fairhurst >>>>>>>>Sent: Friday, February 04, 2005 6:56 AM >>>>>>>>To: ipdvb at erg.abdn.ac.uk; Bernhard Collini-Nocker >>>>>>>>Cc: AAllison at nab.org >>>>>>>>Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast >>>>>>> >>>>>>> >>>>>>>Descriptors >>>>>>> >>>>>>> >>>>>>>>1) Done - point 1 was an edit mistake. >>>>>>>> >>>>>>>>2) I think some text on data broadcast descriptors, stream-type, >>>>>> >>>>>> >>>>>>or/and >>>>>> >>>>>> >>>>>>>PSI >>>>>>> >>>>>>> >>>>>>>>entries would be a valuable addition. >>>>>>>> >>>>>>>>On thinking about this, I wonder if the text about this should go >> >>at >> >>>>>> >>>>>>the >>>>>> >>>>>> >>>>>>>end >>>>>>> >>>>>>> >>>>>>>>of the Introduction (1.0) to the whole document, where people can >> >>see >> >>>>>> >>>>>>it >>>>>> >>>>>> >>>>>>>>clearly and then undesrtand that there may be something else >> >>needed >> >>>>>> >>>>>>for >>>>>> >>>>>> >>>>>>>>those >>>>>>>>networks that rely on PSI for remultiplexing! >>>>>>>> >>>>>>>>- Bernhard & others who understand PSI, can you work with Art to >> >>agree >> >>>>>>> >>>>>>>the >>>>>>> >>>>>>> >>>>>>>>exact wording please? >>>>>>>> >>>>>>>>Gorry Fairhurst >>>>>>>>(ipdvb WG Chair) >>>>>>>> >>>>>>>>Gorry Fairhurst wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>WG please read and respond to this message. >>>>>>>>> >>>>>>>>>The following message was received on January 22nd before WGLC, >> >>but >> >>>>>> >>>>>>was >>>>>> >>>>>> >>>>>>>>>dropped because the email source address was not verified by the >> >>list >> >>>>>>>>>server. >>>>>>>>> >>>>>>>>>The exact text of the message follows. >>>>>>>>> >>>>>>>>>best wishes, >>>>>>>>> >>>>>>>>>Gorry >>>>>>>>>(ipdvb WG Chair) >>>>>>>>> >>>>>>>>>----- >>>>>>>>> >>>>>>>> >>>>>>>>1) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>Thanks for considering my previous input... >>>>>>>>>I note that the new draft has an editorial oversight in that it >>>>>> >>>>>> >>>>>>contains >>>>>> >>>>>> >>>>>>>>>two definitions of PSI. I suggest the second should be deleted. >>>>>>>>> >>>>>>>> >>>>>>>>2) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>I previously made a comment about the ancillary requirements when >>>>>> >>>>>> >>>>>>adding >>>>>> >>>>>> >>>>>>>a >>>>>>> >>>>>>> >>>>>>>>>TS logical channel to a TS multiplex and asserted there appeared >>>>>>>>>to be >>>>>>>>>under >>>>>>>>>specification. Perhaps it was viewed as out of scope, or perhaps >> >>I >> >>>>>>> >>>>>>>simply >>>>>>> >>>>>>> >>>>>>>>>don't recognize the change that resulted. I can not find what >>>>>>> >>>>>>> >>>>>>>stream_type >>>>>>> >>>>>>> >>>>>>>>>is required to be used for the ULE stream when a "TS Logical >> >>Channel" >> >>>>>> >>>>>>is >>>>>> >>>>>> >>>>>>>>>added to a multiplex. >>>>>>> >>>>>>> >>>>>>>The problem here is the same as above. Without "applying" for a >>>>>>>"stream_type" for ULE there is no stream_type for ULE. In contrary >> >>why >> >>>>>>>should one register a stream_type value for ULE earlier than ULE is >>>>>>>standardized? >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>I suggest at least an informative note be added in Section 6 >> >>(after >> >>>>>> >>>>>>the >>>>>> >>>>>> >>>>>>>>>third line which says: "These are transmitted using a single TS >>>>>> >>>>>> >>>>>>Logical >>>>>> >>>>>> >>>>>>>>>Channel over a TS Multiplex.") The note should say "PSI entries >> >>to >>be >> >>>>>>>>>consistent with [ISO-MPEG] when constructing a conformant TS >>>>>>>>>Multiplex >>>>>>> >>>>>>> >>>>>>>and >>>>>>> >>>>>>> >>>>>>>>>means for Receivers to locate each such TS Logical Channel are >>>>>>>>>outside >>>>>>> >>>>>>> >>>>>>>the >>>>>>> >>>>>>> >>>>>>>>>scope of this recommendation." >>>>>>> >>>>>>> >>>>>>>Thanks, this is a very helpful suggestion for potential readers. In >>>>>>>addition the ipdvb-wg works on providing signalling other than >> >>PSI/SI. >> >>>>>>> >>>>>>>>>Reason: >>>>>>>>>Just inserting a "TS Logical Channel" without including a >>>>>>>>>TS_Program_map_section that lists the PID and a stream_type does >> >>not >> >>>>>>>>>appear to me to result in a strictly MPEG-2 conformant bit >> >>stream; >> >>>>>> >>>>>>and >>>>>> >>>>>> >>>>>>>>>practically >>>>>>>>>could result in the PIDs being dropped by a remultiplexer. If >> >>the >> >>>>>>> >>>>>>>means >>>>>>> >>>>>>> >>>>>>>>>for binding the inserted element into a multiplex and subsequent >>>>>>> >>>>>>> >>>>>>>discovery >>>>>>> >>>>>>> >>>>>>>>>is to be covered in another document, a pointer to that document >>>>>>>>>would >>>>>>> >>>>>>> >>>>>>>be >>>>>>> >>>>>>> >>>>>>>>>more helpful than this warning. It seems at least a warning is >> >>needed >> >>>>>>> >>>>>>>and >>>>>>> >>>>>>> >>>>>>>>>preferably a pointer to where this next level of TS construction >> >>is >> >>>>>>>>>defined. >>>>>>> >>>>>>> >>>>>>>From an architectural point of view it is a reasonable assupmption >> >>that >> >>>>>>>whatever is being sent in a TS multiplex should be referenced. >> >>However, >> >>>>>>>the reality is that "ghost" PIDs do occur in many services either >>>>>>>accidentially or for well-defined reasons. >>>>>>> >>>>>>>What is the penalty for not being strictly MPEG-2 >> >>conformant/compliant? >> >>>>>>> >>>>>>>>>Art Allison >>>>>>>>>Director, Advanced Engineering >>>>>>>>>NAB Science & Technology >>>>>>>>>1771 N St NW, Washington Dc 20036 >>>>>>>>>202 429 5418 >>>>>>> >>>>>>> >>>>>>> >>>>>>>Regards, >>>>>>>Bernhard Collini-Nocker >>>>>>> >>>>>>> >>>>> >>>>> >>>> > From agoldberg at sharplabs.com Tue Feb 8 08:23:47 2005 From: agoldberg at sharplabs.com (Goldberg, Adam) Date: Tue, 8 Feb 2005 00:23:47 -0800 Subject: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto rs Message-ID: <08259490B3BC3140B549DD0907A5644811D69B@admsrvnt10.enet.sharplabs.com> > My question wrt this is, why should not someone propose a dedicated ULE > Stream Table (UST) for that purpose? Even on a dedicated PID, say 0x16, > and registered/reserved for that purpose? It could well serve also > INT/IMT/... purposes, without having to parse other sections. > Consequently, the responsibility would be there, where it should be. > Although, it wold make sense if someone would take responsibility for > registration and someone else for semantics? But that seems quite > innovative. Would ATSC/DVB let IETF/... come up with a draft/standard > for a MPEG-2 section after having only reserved a dedicate PID for that? I'm afraid we're miscommunicating. I don't see a need for dedicated PID, nor for a UST. There are perfectly good mechanisms for this already. (1) Ask for a stream_type value for "ULE Stream", which is a stream of ULE packets as defined in the draft. (2) Define (in some document, this one or another) that a Program which has any streams of the ULE stream_type may not have any other streams in that program. Each Program would therefore carry exactly one 'logical channel' (that is, exactly one of the 8k plugs). The PSI is rather easy to deal with: the PAT points to the PMT sections, each Program listed in the PMT which contains a ULE Stream has only that ULE Stream. Easy enough to parse, existing MPEG equipment won't drop things, you can simultaneously carry ULE and entertainment content ... and the only thing you need is to merely ask ATSC to allocate a stream_type. Adam Goldberg Director, Television Standards & Policy Development Sharp Laboratories of America 8605 Westwood Center Drive, Suite 206 Vienna, VA 22182 +1-703-556-4406 +1-703-556-4410 fax +1-571-276-0305 cell > -----Original Message----- > From: Bernhard Collini-Nocker [mailto:bnocker at cosy.sbg.ac.at] > Sent: Tuesday, February 08, 2005 2:17 AM > To: ipdvb at erg.abdn.ac.uk > Cc: Goldberg, Adam; Allison, Art; Matthew Goldman > Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto > rs > > Please read below. > > Goldberg, Adam wrote: > > Re #2 below, without discussion of PSI it will be both (1) difficult for > > equipment to interoperate in that they may not be able to find the PID > value > > My question wrt this is, why should not someone propose a dedicated ULE > Stream Table (UST) for that purpose? Even on a dedicated PID, say 0x16, > and registered/reserved for that purpose? It could well serve also > INT/IMT/... purposes, without having to parse other sections. > Consequently, the responsibility would be there, where it should be. > Although, it wold make sense if someone would take responsibility for > registration and someone else for semantics? But that seems quite > innovative. Would ATSC/DVB let IETF/... come up with a draft/standard > for a MPEG-2 section after having only reserved a dedicate PID for that? > > > in use for SNDU streams, and (2) passing through non-SNDU-aware MPEG > > Transport equipment (of which none exists, I suppose) is not likely > > (certainly not guaranteed). > > It is very difficult to compare television equipment (what MPEG-2 still > primarily is?) with network equipment. Whether a unreferenced (ghost) > PID is being dropped by a multiplexer or not is probably just a > configuration issue. But, in what way can an IP router can tell (MPEG-2) > receivers, where (on what PID) a specific ULE Stream is available? In a > carneval like statement one could argue, that MPEG-2 is like a room with > 8K Ethernet plugs, guess which is the right one to connect to your local > network. Of course we know, that it is physically more the opposite: one > plug, where 8K networks are on it, so more the nightmare for security > admins. > > > I note from another response that the carriage may be specified in > another > > document. That seems fine, but perhaps mention should be made about it. > > Yes, information about the 8K PID Networks is essential for > routing/addressing/... purposes. > > > In any case, 'TS Logical Channel' remains irksome to me. I'll respond > > separately to other responses. > > Well, meanwhile my favourite is ULE Stream instead (thanks Gorry). It > simply says what it is. > > > Adam Goldberg > > Director, Television Standards & Policy Development > > Sharp Laboratories of America > > 8605 Westwood Center Drive, Suite 206 > > Vienna, VA 22182 > > +1-703-556-4406 > > +1-703-556-4410 fax > > +1-571-276-0305 cell > > Thanks for the interesting discussion, which is unfortunately a liitle > bit late, yet fundamental. > > Kind regards, > Bernhard > > Ass.Prof.Dr. Bernhard Collini-Nocker > Head of Multimedia Communication Group > University of Salzburg, Department of Scientific Computing > Jakob Haringer Str. 1 > A-5020 Salzburg > Tel: *43 662 8044 6316 > Fax: +43 662 8044 172 > > > > >>-----Original Message----- > >>From: Bernhard Collini-Nocker [mailto:bnocker at cosy.sbg.ac.at] > >>Sent: Monday, February 07, 2005 7:49 AM > >>To: ipdvb at erg.abdn.ac.uk > >>Cc: Goldberg, Adam; Allison, Art; Matthew Goldman > >>Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast > Descripto > >>rs > >> > >>Hello, > >> > >>let me try to summarize the two major points being raised and what the > >>discussion is about: > >>1. the name/definition of "TS Logical Channel" is not well received and > >>the name/definition of a "SNDU stream" is proposed instead > >>2. it is proposed to consider MPEG-2 conformance in specifying that ULE > >>requires a specific stream_type value for the PMT > >> > >>Personally I have no objection against 1., because it is easy to change > >>and improves wording and naming (unless somebody has an even better > >>name for it). > >>For 2. my concern is that mentioning stream_type may require some > >>additional wording about PSI/SI in general, which is likely out of scope > >>of the ULE draft. Even worse, in introducing a "world" besides the > >>encapsulation/decapsulation of ULE, this may result in further confusion > >>about what the MPEG-2/Section layer does in addition to and/or in > >>comparison to ULE/IP. Actually some difficult question may arise from > >>this direction, for example whether it is a wishful requirement for ULE > >>to support PAT/PMT/NIT/INT/... table parsing? > >> > >>Any opinions, recommendations or suggestions about this? > >> > >>Regards, > >>Bernhard > >> > >>Goldberg, Adam wrote: > >> > >>>ARGH. I fat-fingered 'send' before completing the email. See below. > >>> > >>>Adam Goldberg > >>>Director, Television Standards & Policy Development > >>>Sharp Laboratories of America > >>>8605 Westwood Center Drive, Suite 206 > >>>Vienna, VA 22182 > >>>+1-703-556-4406 > >>>+1-703-556-4410 fax > >>>+1-571-276-0305 cell > >>> > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: Goldberg, Adam > >>>>Sent: Monday, February 07, 2005 12:42 AM > >>>>To: 'Bernhard Collini-Nocker'; Goldberg, Adam > >>>>Cc: ipdvb at erg.abdn.ac.uk; Allison, Art; Matthew Goldman > >>>>Subject: RE: Forward from Art Alison: WGLC ULE - Data Broadcast > >> > >>Descripto > >> > >>>>rs > >>>> > >>>>See below... > >>>> > >>>>Adam Goldberg > >>>>Director, Television Standards & Policy Development > >>>>Sharp Laboratories of America > >>>>8605 Westwood Center Drive, Suite 206 > >>>>Vienna, VA 22182 > >>>>+1-703-556-4406 > >>>>+1-703-556-4410 fax > >>>>+1-571-276-0305 cell > >>>> > >>>> > >>>>Bernhard Collini-Nocker wrote: > >>>> > >>>> > >>>>>Goldberg, Adam wrote: > >>>>> > >>>>> > >>>>>>I apologize for being "late to the party", but: > >>>>>> > >>>>>>I do not see a particular need to define new term "TS Logical > >>> > >>>Channel", > >>> > >>> > >>>>>and > >>>>> > >>>>> > >>>>>>indeed doing so creates risks of ill-specification (such as those > Art > >>>>> > >>>>>points > >>>>> > >>>>> > >>>>>>out), as well as confusion heaped upon someone familiar with MPEG-2 > >>>>>>Transport (as typically used in entertainment delivery). > >>>>> > >>>>>Unfortunately the MPEG-2 standards do not provide a reasonable term > for > >>>>>the purpose of networking. The question is whether other terms, for > >>>>>example "PID network" or "PID stream" would be better received and > >>>>>understood? > >>>>>The term "TS logical channel" tries to verbally visualize that the > >>>>>encapsulation uses a continouos stream of transport stream packets > >> > >>using > >> > >>>>>one specific packet identifier to transport subnetwork data units. > >> > >>Maybe > >> > >>>>>the term "TS (virtual) circuit" better names this? > >>>> > >>>>It is perhaps not well defined in 13818-1, but the term of art is > >>>>"streams". Many people use "PID stream" which is a poor combination > of > >>>>words. I'd have no objection to defining a "SNDU Stream" as something > >>>>like "a sequence of MPEG-2 Transport Stream packets identified by a > >> > >>common > >> > >>>>PID value" (or some such). > >>>> > >>>>Perhaps discussing 'virtual circuits' relative to a Transport Stream > is > >>>>begging for confusion. Use of any such words ("TS (virtual) circuit") > >>>>needs careful definition, likely requiring the above SNDU Stream > >>>>definition plus an explanation of what it means for multiple SNDU > >> > >>Streams > >> > >>>>to exist in a single Transport Stream. > >>>> > >>>> > >>>> > >>>>>>Furthermore, the definition is quite wrong with respect to ATSC and > >>>> > >>>>DVB > >>>> > >>>> > >>>>>use > >>>>> > >>>>> > >>>>>>of "specific TS Logical Channels". To my knowledge, this internet- > >>>> > >>>>draft > >>>> > >>>> > >>>>>is > >>>>> > >>>>> > >>>>>>the only document anywhere which uses such terms. It is certainly > >>>> > >>>>true > >>>> > >>>> > >>>>>that > >>>>> > >>>>> > >>>>>>MPEG, DVB and ATSC define //elementary streams// identified by > >>>>> > >>>>>stream_type > >>>>> > >>>>> > >>>>>>values. I suspect this is what is meant by "TS Logical Channel", but > >>>> > >>>>it > >>>> > >>>> > >>>>>is > >>>>> > >>>>> > >>>>>>difficult for me to tell. > >>>>> > >>>>>I am not so sure, whether this analysis is correct. Elementary > streams > >>>>>are those that are transported as Packetized ES, whereas "auxillary" > >>>>>data and signalling is transported as sections. Although a > stream_type > >>>>>in the program map section is used to reference both PESs and > sections > >>>>>the term elementary stream is used very vague and we tried to avoid > >>>>>using it in the same vague manner. > >>>> > >>>>Perhaps I overstepped with "elementary stream". > >>>> > >>>>Consider the 13818-1 definition of "Packetized Elementary Stream": "A > >>>>continuous sequence of PES packets of one elementary stream with one > >>>>stream ID may be used to construct a PES Stream." (ISO/IEC 13818- > 1:2000 > >> > >>p. > >> > >>>>xiii) > >>>> > >>>>Stuff carried as payload of Transport Stream packets are merely > >> > >>'payload'. > >> > >>>>What the draft starts to define is a new type of payload stream (that > > > > is, > > > >>>>a new way to carry data in a transport stream). The definition is not > >>>>compete. > >>>> > >>>> > >>>> > >>>>>According to, for example EN301192 v1.3.1, defines Data Piping as: > >>>>>" The data broadcast service shall insert the data to be broadcast > >>>>>directly in the payload of MPEG-2 TS packets." > >>>>>That raises the question, how to call a continouos stream of MPEG-2 > TS > >>>>>packets with a certain PID? > >>>>> > >>>>>Further the standard details that: > >>>>>"The data broadcast service may use the payload_unit_start_indicator > >>>>>field and the transport_priority field of the MPEG-2 Transport Stream > >>>>>packets in a service private way. The use of the adaptation_field > shall > >>>>>be MPEG-2 compliant." > >>>>>ULE uses PUSI and does not utilize the AF. > >>>>> > >>>>>"The delivery of the bits in time through a data pipe is service > >> > >>private > >> > >>>>>and is not specified in the present document." > >>>>>It seems obvious that the use of the term "TS Data Pipe" would lead > to > >>>>>the wrong conclusion that ULE equals Data Piping. But Data Piping is > >> > >>not > >> > >>>>>detailed at all, whereas ULE tries to be. > >>>> > >>>>I'm not going to argue that DVB's specification is complete. I will > >> > >>argue > >> > >>>>that ULE isn't complete. > >>>> > >>>> > >>>> > >>>>>>(from the draft) > >>>>>> TS Logical Channel: Transport Stream Logical Channel. In this > >>>>>> document, this term identifies a channel at the MPEG-2 level [ISO- > >>>>>> MPEG]. It exists at level 2 of the ISO/OSI reference model. All > >>>>>> packets sent over a TS Logical Channel carry the same PID value > >>>>>> (this value is unique within a specific TS Multiplex). According > to > >>>>>> MPEG-2, some TS Logical Channels are reserved for specific > >>>>>> signalling purposes. Other standards (e.g., ATSC, DVB) also > reserve > >>>>>> specific TS Logical Channels. > >>>>>> > >>>>>>While I'm commenting on this definition, it also seems to me that > >>>>> > >>>>>"channel > >>>>> > >>>>> > >>>>>>at the MPEG-2 level" is either wrong or also ill-specified. What's > a > >>>>>>channel? If you're talking about MPEG-2, it's certainly conceivable > >>>>> > >>>>>that > >>>>> > >>>>> > >>>>>>the reader may associate "channel" with "[television] channel" - > which > >>>>> > >>>>>are > >>>>> > >>>>> > >>>>>>the subject of a large amount of ATSC and DVB systems. > >>>>> > >>>>>The term channel is indeed problematic in the context of television, > >>>>>however, network engineers might have a different understanding about > >>>>>what a channel is. > >>>>>According to ATIS a channel is "1. A connection between initiating > and > >>>>>terminating nodes of a circuit. 2. A single path provided by a > >>>>>transmission medium via either (a) physical separation, such as by > >>>>>multipair cable or (b) electrical separation, such as by frequency- > or > >>>>>time-division multiplexing. ..." > >>>> > >>>>I understand that 'channel' vis-?-vis networking has a different > meaning > >>>>than 'channel' vis-?-vis television. This was my point actually, that > >>>>those familiar with MPEG transport should not be assumed to be > >> > >>networking- > >> > >>>>types (even when speaking with respect to ULE). > >>>> > >>>> > >>>> > >>>>>>Additionally, it is also wrong or ill-specified to say "According to > >>>>> > >>>>>MPEG-2 > >>>>> > >>>>> > >>>>>>... TS Logical Channels ...". There is no such concept defined or > >>>> > >>>>used > >>>> > >>>> > >>>>>>within MPEG (unless what you really mean is elementary stream, in > >>>> > >>>>which > >>>> > >>>> > >>>>>case > >>>>> > >>>>> > >>>>>>what do you need this extraneous term for anyhow?). > >>>>> > >>>>>Again, elementary stream is not exactly what is being meant: > >>>>>For example EN 300468 v1.5.1 defines: > >>>>>"component (ELEMENTARY Stream): one or more entities which together > >> > >>make > >> > >>>>>up an event, e.g. video, audio, teletext" > >>>>> > >>>>>and says further: > >>>>>"The component descriptor identifies the type of component stream and > >>>>>may be used to provide a text description of the elementary stream" > >>>>> > >>>>>where: > >>>>>"component_type: This 8-bit field specifies the type of the video, > >> > >>audio > >> > >>>>>or EBU-data component. The coding of this field is specified in table > >>>> > >>>>26." > >>>> > >>>> > >>>>>Table 26 then lists all kinds of video, audio, and teletext formats, > >> > >>but > >> > >>>>>unfortunately no networking formats. > >>>>> > >>>>>At other places this standard is as innovative/creative in naming: > >>>>>"event: grouping of elementary broadcast data streams with a defined > >>>>>start and end time belonging to a common service, e.g. first half of > a > >>>>>football match, News Flash, first part of an entertainment show" > >>>>>What is a "elementary broadcast data streams"? Not by guessing but by > >>>>>definition? > >>>>> > >>>>> > >>>>> > >>>>>>In any case, Art is certainly correct that merely identifying a "TS > >>>>> > >>>>>Logical > >>>>> > >>>>> > >>>>>>Channel" as a sequence of packets identified with a common PID value > >>>>> > >>>>>without > >>>>> > >>>>> > >>>>>>identifying the PSI details is an invitation to multiplexers and > >>>>>>remultiplexers to drop those packets on the floor. > >>>>> > >>>>>Oh yes, this is the real problem of defining something outside > >>>>>television standardiszation bodies: one risks that ULE packets are > >> > >>being > >> > >>>>>dropped. > >>>>>We have discussed basically two approaches: > >>>>>1. define the PSI and get an ID, or tag, or "stream_type" for ULE, or > > > > 2. > > > >>>>>define ULE and let somebody else do the PSI work. > >>>>>We have had some reasons for choice 2. > >>>> > >>>>This is a very easy thing to fix and something which should be done. > >>>>Without defining a stream_type for ULE data, it is neither possible to > >>>>construct a transport stream compliant with MPEG-2 nor one that > >>>>interoperates with other ULE equipment. > >>>> > >>>>ATSC maintains a 'codepoint registry', and would be happy to allocate > a > >>>>stream_type value for ULE data upon request from IETF. Furthermore, > the > >>>>text to specify usage of the stream_type would be reasonably easy (and > >>>>perhaps ties in to my suggested "SNDU Stream" definition (that is, > >> > >>define > >> > >>>>it as > >>> > >>> > >>>SNDU Stream: a sequence of MPEG-2 Transport Stream packets identified > by > >> > >>a > >> > >>>common PID value of stream_type <0xnn>. > >>> > >>>All that then remains, I think, would be to signal when a Program > >> > >>carries > >> > >>>SNDU Stream(s), and what it means when there are more than one SNDU > >> > >>Stream > >> > >>>per program, or more than one Program that carries one or more SNDU > >> > >>Streams. > >> > >>> > >>>>>>If there remains an opportunity to repair what I believe to be > errors > >>>> > >>>>in > >>>> > >>>> > >>>>>the > >>>>> > >>>>> > >>>>>>draft, I'm eager and willing to participate from a MPEG-2 > >>>> > >>>>entertainment > >>>> > >>>> > >>>>>>(which is to say, legacy use of MPEG-2 Transport) point of view. > >>>>> > >>>>>Of course the terms in the document should not conflict with meaning > in > >>>>>another context. However, ambiguous terms in other documents should > be > >>>>>avoided as well. > >>>>> > >>>>> > >>>>> > >>>>>>[Apologies for being strident at all, to say nothing of at such an > >>>>>>apparently late stage - if the above is perceived as such] > >>>>>> > >>>>>>Regards, > >>>>>>Adam Goldberg > >>>>>>Director, Television Standards & Policy Development > >>>>>>Sharp Laboratories of America > >>>>>>8605 Westwood Center Drive, Suite 206 > >>>>>>Vienna, VA 22182 > >>>>>>+1-703-556-4406 > >>>>>>+1-703-556-4410 fax > >>>>>>+1-571-276-0305 cell > >>>>>> > >>>>>> > >>>>>>-----Original Message----- > >>>>>>From: owner-ipdvb at erg.abdn.ac.uk [mailto:owner-ipdvb at erg.abdn.ac.uk] > >>>> > >>>>On > >>>> > >>>> > >>>>>>Behalf Of Gorry Fairhurst > >>>>>>Sent: Friday, February 04, 2005 6:56 AM > >>>>>>To: ipdvb at erg.abdn.ac.uk; Bernhard Collini-Nocker > >>>>>>Cc: AAllison at nab.org > >>>>>>Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast > >>>>> > >>>>>Descriptors > >>>>> > >>>>> > >>>>>>1) Done - point 1 was an edit mistake. > >>>>>> > >>>>>>2) I think some text on data broadcast descriptors, stream-type, > >>>> > >>>>or/and > >>>> > >>>> > >>>>>PSI > >>>>> > >>>>> > >>>>>>entries would be a valuable addition. > >>>>>> > >>>>>>On thinking about this, I wonder if the text about this should go at > >>>> > >>>>the > >>>> > >>>> > >>>>>end > >>>>> > >>>>> > >>>>>>of the Introduction (1.0) to the whole document, where people can > see > >>>> > >>>>it > >>>> > >>>> > >>>>>>clearly and then undesrtand that there may be something else needed > >>>> > >>>>for > >>>> > >>>> > >>>>>>those > >>>>>>networks that rely on PSI for remultiplexing! > >>>>>> > >>>>>>- Bernhard & others who understand PSI, can you work with Art to > agree > >>>>> > >>>>>the > >>>>> > >>>>> > >>>>>>exact wording please? > >>>>>> > >>>>>>Gorry Fairhurst > >>>>>>(ipdvb WG Chair) > >>>>>> > >>>>>>Gorry Fairhurst wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>>WG please read and respond to this message. > >>>>>>> > >>>>>>>The following message was received on January 22nd before WGLC, but > >>>> > >>>>was > >>>> > >>>> > >>>>>>>dropped because the email source address was not verified by the > list > >>>>>>>server. > >>>>>>> > >>>>>>>The exact text of the message follows. > >>>>>>> > >>>>>>>best wishes, > >>>>>>> > >>>>>>>Gorry > >>>>>>>(ipdvb WG Chair) > >>>>>>> > >>>>>>>----- > >>>>>>> > >>>>>> > >>>>>>1) > >>>>>> > >>>>>> > >>>>>> > >>>>>>>Thanks for considering my previous input... > >>>>>>>I note that the new draft has an editorial oversight in that it > >>>> > >>>>contains > >>>> > >>>> > >>>>>>>two definitions of PSI. I suggest the second should be deleted. > >>>>>>> > >>>>>> > >>>>>>2) > >>>>>> > >>>>>> > >>>>>> > >>>>>>>I previously made a comment about the ancillary requirements when > >>>> > >>>>adding > >>>> > >>>> > >>>>>a > >>>>> > >>>>> > >>>>>>>TS logical channel to a TS multiplex and asserted there appeared to > >> > >>be > >> > >>>>>>>under > >>>>>>>specification. Perhaps it was viewed as out of scope, or perhaps I > >>>>> > >>>>>simply > >>>>> > >>>>> > >>>>>>>don't recognize the change that resulted. I can not find what > >>>>> > >>>>>stream_type > >>>>> > >>>>> > >>>>>>>is required to be used for the ULE stream when a "TS Logical > Channel" > >>>> > >>>>is > >>>> > >>>> > >>>>>>>added to a multiplex. > >>>>> > >>>>>The problem here is the same as above. Without "applying" for a > >>>>>"stream_type" for ULE there is no stream_type for ULE. In contrary > why > >>>>>should one register a stream_type value for ULE earlier than ULE is > >>>>>standardized? > >>>>> > >>>>> > >>>>> > >>>>>>>I suggest at least an informative note be added in Section 6 (after > >>>> > >>>>the > >>>> > >>>> > >>>>>>>third line which says: "These are transmitted using a single TS > >>>> > >>>>Logical > >>>> > >>>> > >>>>>>>Channel over a TS Multiplex.") The note should say "PSI entries to > be > >>>>>>>consistent with [ISO-MPEG] when constructing a conformant TS > >> > >>Multiplex > >> > >>>>>and > >>>>> > >>>>> > >>>>>>>means for Receivers to locate each such TS Logical Channel are > >> > >>outside > >> > >>>>>the > >>>>> > >>>>> > >>>>>>>scope of this recommendation." > >>>>> > >>>>>Thanks, this is a very helpful suggestion for potential readers. In > >>>>>addition the ipdvb-wg works on providing signalling other than PSI/SI. > >>>>> > >>>>> > >>>>> > >>>>>>>Reason: > >>>>>>>Just inserting a "TS Logical Channel" without including a > >>>>>>>TS_Program_map_section that lists the PID and a stream_type does > not > >>>>>>>appear to me to result in a strictly MPEG-2 conformant bit stream; > >>>> > >>>>and > >>>> > >>>> > >>>>>>>practically > >>>>>>>could result in the PIDs being dropped by a remultiplexer. If the > >>>>> > >>>>>means > >>>>> > >>>>> > >>>>>>>for binding the inserted element into a multiplex and subsequent > >>>>> > >>>>>discovery > >>>>> > >>>>> > >>>>>>>is to be covered in another document, a pointer to that document > >> > >>would > >> > >>>>>be > >>>>> > >>>>> > >>>>>>>more helpful than this warning. It seems at least a warning is > needed > >>>>> > >>>>>and > >>>>> > >>>>> > >>>>>>>preferably a pointer to where this next level of TS construction is > >>>>>>>defined. > >>>>> > >>>>>From an architectural point of view it is a reasonable assupmption > >> > >>that > >> > >>>>>whatever is being sent in a TS multiplex should be referenced. > However, > >>>>>the reality is that "ghost" PIDs do occur in many services either > >>>>>accidentially or for well-defined reasons. > >>>>> > >>>>>What is the penalty for not being strictly MPEG-2 > conformant/compliant? > >>>>> > >>>>> > >>>>> > >>>>>>>Art Allison > >>>>>>>Director, Advanced Engineering > >>>>>>>NAB Science & Technology > >>>>>>>1771 N St NW, Washington Dc 20036 > >>>>>>>202 429 5418 > >>>>> > >>>>> > >>>>>Regards, > >>>>>Bernhard Collini-Nocker > >>>>> > >>>>> > >>> > >>> > > From gorry at erg.abdn.ac.uk Tue Feb 8 09:32:39 2005 From: gorry at erg.abdn.ac.uk (Gorry Fairhurst) Date: Tue, 08 Feb 2005 09:32:39 +0000 Subject: ATSC Data Broadcast Descriptors In-Reply-To: <08259490B3BC3140B549DD0907A5644811D698@admsrvnt10.enet.sharplabs.com> References: <08259490B3BC3140B549DD0907A5644811D698@admsrvnt10.enet.sharplabs.com> Message-ID: <42088737.3020707@erg.abdn.ac.uk> See comment in-line. Goldberg, Adam wrote: > Below > > Adam Goldberg > Director, Television Standards & Policy Development > Sharp Laboratories of America > 8605 Westwood Center Drive, Suite 206 > Vienna, VA 22182 > +1-703-556-4406 > +1-703-556-4410 fax > +1-571-276-0305 cell > > > >>-----Original Message----- >>From: Gorry Fairhurst [mailto:gorry at erg.abdn.ac.uk] >>Sent: Monday, February 07, 2005 8:54 AM >>To: ipdvb at erg.abdn.ac.uk >>Cc: Goldberg, Adam; Allison, Art; Matthew Goldman >>Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto >>rs >> >> >>3) Once teh ULE spec is agreed and an RFC number issued, I can also see >>great >>advantage in assigning a descriptor for this in ATSC. I think the WG >>SHOULD >>should explore this at the next stage. > > > You need not wait for this - a mere letter to ATSC asking for allocation of > a stream_type codepoint for ULE data will be sufficient for ATSC to respond > favorably. > > Excellent That is good. I'll make sure this is done (and liase with DVB, etc to ensure we get things correct). However, I'd be happier if we get the IETF approval (i.e. IESG approval) for the ULE Spec first, this should be only a few months away - this will be soon followed by an RFC number that can be a normative reference. >>Gorry >> Gorry From gorry at erg.abdn.ac.uk Tue Feb 8 09:45:51 2005 From: gorry at erg.abdn.ac.uk (Gorry Fairhurst) Date: Tue, 08 Feb 2005 09:45:51 +0000 Subject: Forward from Art Alison: WGLC ULE - Data Broadcast Descriptors In-Reply-To: <08259490B3BC3140B549DD0907A5644811D699@admsrvnt10.enet.sharplabs.com> References: <08259490B3BC3140B549DD0907A5644811D699@admsrvnt10.enet.sharplabs.com> Message-ID: <42088A4F.2090109@erg.abdn.ac.uk> The -ar- draft covers addressing and address resolution (at both IP and MPEG-2 layers). This draft is a proposal for a new work (and not yet adopted by the IETF). It will need inputs on all the topics, at the moment it is incomplete. The draft is currently being revised, and a new revision is expected prior to the next IETF meeting, but the current version is at: http://www.ietf.org/internet-drafts/draft-fair-ipdvb-ar-02.txt The above draft could certainly benefit from some of these discussions, and inputs. This thread is useful. I don't want to stop this discussion, but concerning the ULE Spec, we do seem near to an agreement.... let's now move to complete this and get the document submitted! I can work from this thread to make a proposal to the WG for the final text to be inserted in ULE. Gorry Goldberg, Adam wrote: > Below > > Adam Goldberg > Director, Television Standards & Policy Development > Sharp Laboratories of America > 8605 Westwood Center Drive, Suite 206 > Vienna, VA 22182 > +1-703-556-4406 > +1-703-556-4410 fax > +1-571-276-0305 cell > > > >>-----Original Message----- >>From: Marie-Jose Montpetit [mailto:mariejose.montpetit at verizon.net] >>Sent: Monday, February 07, 2005 3:56 PM >>To: ipdvb at erg.abdn.ac.uk >>Cc: Goldberg, Adam; Allison, Art; Matthew Goldman >>Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto >>rs >> >>I think we need to close on some of those issues and move forward. >> >>Here is what I propose which would be inline with the conclusions of the >>Architecture Draft: >>(1) ULE is encapsulation only - it is not the purpose nor the usage of ULE >>to dwell in SI/PSI table issues nor any other protocol; so we leave the >>draft to be mostly what it is now (pending small changes proposed by >>Gorry) > > > This becomes a bit self-referential. The proper definition of the data > stream is to say something like "a stream of stream_type 0xNN", but you > propose not doing this until later. > > >>(2) PSI/SI scanning is part of the Address Resolution Draft as regard >>management of addressing; it will be further discussed there and focus >>given >>to the issues raised in this thread > > > Can someone provide a pointer to the "Address Resolution Draft"? > > >>(3) Someone (Adam and/or team) proposes WG work and a draft on ATSC >>concerns >>on PSI/SI issues and ULE; inclusion of cable TV concerns in addition to >>satellite would be welcome and has been one of my goals for the group >>(4) we close on ULE and get to discuss the other items further at IETF > > > Don't misunderstand my concerns (or Art's, I suppose) - they are not "ATSC > concerns" so much as concerns from one overly familiar with MPEG-2 Transport > Streams and their widespread use. > > > >>Thanks >> >>Marie-Jose >> >>----- Original Message ----- >>From: "Gorry Fairhurst" >>To: >>Cc: "Goldberg, Adam" ; "Allison, Art" >>; "Matthew Goldman" >>Sent: Monday, February 07, 2005 8:54 AM >>Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto >>rs >> >> >> >>>So.... >>> >>>1. The term "TS Logical Channel" was discussed a lot at the begining of >> >>the >> >>>WG. As I recall, the reason for the new term, was that at this time the >> >>WG >> >>>could not find a suitably "unbiased" term for the set of TS Packets with >> >>a >> >>>common PID value (raw TS, DSMCC, Private Section, PES, etc). One key >> >>objective >> >>>was to find a term that did not carry extra semantics, and was >> >>understandable >> >>>by the networking community - this is after all intended as a part of >> >>the >> >>>RFC-series, and we need to make this accessible to people familiar with >> >>using >> >>>IP over Ethernet, MPLS, ATM, Fibre Channel, Firewire, SDH/SONET, etc. >>>T >>> >>>we shoudl note that the term "TS Logical Channel term already appears >> >>(and >>is >> >>>discussed in some detail) in the document draft-ietf-ipvb-arch-xx.txt >> >>and >>that >> >>>this HAS already complete WGLC. If it IS WRONG we still have a chance >> >>to >>fix >> >>>the definition/term, if we have to. Specifically, is there already a >>>well-accepted term for the set of TS Packets with a common PID value >> >>(raw >>TS, >> >>>DSMCC, Private Section, PES, etc) that we should use or refer to? >>> >>> >>>2. I'm not against defining another term "ULE Stream", "SNDU Stream", >> >>etc >>if >> >>>that helps to describe the set of TS packets with a specific PID used >> >>for >>ULE, >> >>>especially when talking about PSI. >>> >>>Bernhard, is there an opportunity of inserting a simple statement as the >> >>final >> >>>paragraph of the introduction which says that to use ULE streams within >> >>an >> >>>MPEG-2 compliant multiplex may require appropriate PSI entries... I >> >>think >>Art >> >>>already proposed some specific wording that could be used or modified? >>> >>> >>>3) Once teh ULE spec is agreed and an RFC number issued, I can also see >> >>great >> >>>advantage in assigning a descriptor for this in ATSC. I think the WG >> >>SHOULD >> >>>should explore this at the next stage. >>> >>> >>>Gorry >>> >>>Bernhard Collini-Nocker wrote: >>> >>> >>>>Hello, >>>> >>>>let me try to summarize the two major points being raised and what the >>>>discussion is about: >>>>1. the name/definition of "TS Logical Channel" is not well received >> >>and >> >>>>the name/definition of a "SNDU stream" is proposed instead >>>>2. it is proposed to consider MPEG-2 conformance in specifying that >> >>ULE >> >>>>requires a specific stream_type value for the PMT >>>> >>>>Personally I have no objection against 1., because it is easy to >> >>change >> >>>>and improves wording and naming (unless somebody has an even better >>>>name for it). >>>>For 2. my concern is that mentioning stream_type may require some >>>>additional wording about PSI/SI in general, which is likely out of >> >>scope >> >>>>of the ULE draft. Even worse, in introducing a "world" besides the >>>>encapsulation/decapsulation of ULE, this may result in further >> >>confusion >> >>>>about what the MPEG-2/Section layer does in addition to and/or in >>>>comparison to ULE/IP. Actually some difficult question may arise from >>>>this direction, for example whether it is a wishful requirement for >> >>ULE >> >>>>to support PAT/PMT/NIT/INT/... table parsing? >>>> >>>>Any opinions, recommendations or suggestions about this? >>>> >>>>Regards, >>>>Bernhard >>>> >>>>Goldberg, Adam wrote: >>>> >>>> >>>>>ARGH. I fat-fingered 'send' before completing the email. See below. >>>>> >>>>>Adam Goldberg >>>>>Director, Television Standards & Policy Development >>>>>Sharp Laboratories of America >>>>>8605 Westwood Center Drive, Suite 206 >>>>>Vienna, VA 22182 >>>>>+1-703-556-4406 >>>>>+1-703-556-4410 fax >>>>>+1-571-276-0305 cell >>>>> >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: Goldberg, Adam >>>>>>Sent: Monday, February 07, 2005 12:42 AM >>>>>>To: 'Bernhard Collini-Nocker'; Goldberg, Adam >>>>>>Cc: ipdvb at erg.abdn.ac.uk; Allison, Art; Matthew Goldman >>>>>>Subject: RE: Forward from Art Alison: WGLC ULE - Data Broadcast >>>>>>Descripto >>>>>>rs >>>>>> >>>>>>See below... >>>>>> >>>>>>Adam Goldberg >>>>>>Director, Television Standards & Policy Development >>>>>>Sharp Laboratories of America >>>>>>8605 Westwood Center Drive, Suite 206 >>>>>>Vienna, VA 22182 >>>>>>+1-703-556-4406 >>>>>>+1-703-556-4410 fax >>>>>>+1-571-276-0305 cell >>>>>> >>>>>> >>>>>>Bernhard Collini-Nocker wrote: >>>>>> >>>>>> >>>>>>>Goldberg, Adam wrote: >>>>>>> >>>>>>> >>>>>>>>I apologize for being "late to the party", but: >>>>>>>> >>>>>>>>I do not see a particular need to define new term "TS Logical >>>>> >>>>> >>>>>Channel", >>>>> >>>>> >>>>>>>and >>>>>>> >>>>>>> >>>>>>>>indeed doing so creates risks of ill-specification (such as those >> >>Art >> >>>>>>> >>>>>>>points >>>>>>> >>>>>>> >>>>>>>>out), as well as confusion heaped upon someone familiar with MPEG- >> >>2 >> >>>>>>>>Transport (as typically used in entertainment delivery). >>>>>>> >>>>>>> >>>>>>>Unfortunately the MPEG-2 standards do not provide a reasonable term >> >>for >> >>>>>>>the purpose of networking. The question is whether other terms, for >>>>>>>example "PID network" or "PID stream" would be better received and >>>>>>>understood? >>>>>>>The term "TS logical channel" tries to verbally visualize that the >>>>>>>encapsulation uses a continouos stream of transport stream packets >>>>>>>using >>>>>>>one specific packet identifier to transport subnetwork data units. >>>>>>>Maybe >>>>>>>the term "TS (virtual) circuit" better names this? >>>>>> >>>>>> >>>>>>It is perhaps not well defined in 13818-1, but the term of art is >>>>>>"streams". Many people use "PID stream" which is a poor combination >> >>of >> >>>>>>words. I'd have no objection to defining a "SNDU Stream" as >> >>something >> >>>>>>like "a sequence of MPEG-2 Transport Stream packets identified by a >>>>>>common >>>>>>PID value" (or some such). >>>>>> >>>>>>Perhaps discussing 'virtual circuits' relative to a Transport Stream >> >>is >> >>>>>>begging for confusion. Use of any such words ("TS (virtual) >> >>circuit") >> >>>>>>needs careful definition, likely requiring the above SNDU Stream >>>>>>definition plus an explanation of what it means for multiple SNDU >>>>>>Streams >>>>>>to exist in a single Transport Stream. >>>>>> >>>>>> >>>>>> >>>>>>>>Furthermore, the definition is quite wrong with respect to ATSC >> >>and >> >>>>>> >>>>>>DVB >>>>>> >>>>>> >>>>>>>use >>>>>>> >>>>>>> >>>>>>>>of "specific TS Logical Channels". To my knowledge, this >> >>internet- >> >>>>>> >>>>>>draft >>>>>> >>>>>> >>>>>>>is >>>>>>> >>>>>>> >>>>>>>>the only document anywhere which uses such terms. It is certainly >>>>>> >>>>>> >>>>>>true >>>>>> >>>>>> >>>>>>>that >>>>>>> >>>>>>> >>>>>>>>MPEG, DVB and ATSC define //elementary streams// identified by >>>>>>> >>>>>>> >>>>>>>stream_type >>>>>>> >>>>>>> >>>>>>>>values. I suspect this is what is meant by "TS Logical Channel", >> >>but >> >>>>>> >>>>>>it >>>>>> >>>>>> >>>>>>>is >>>>>>> >>>>>>> >>>>>>>>difficult for me to tell. >>>>>>> >>>>>>> >>>>>>>I am not so sure, whether this analysis is correct. Elementary >> >>streams >> >>>>>>>are those that are transported as Packetized ES, whereas >> >>"auxillary" >> >>>>>>>data and signalling is transported as sections. Although a >> >>stream_type >> >>>>>>>in the program map section is used to reference both PESs and >> >>sections >> >>>>>>>the term elementary stream is used very vague and we tried to avoid >>>>>>>using it in the same vague manner. >>>>>> >>>>>> >>>>>>Perhaps I overstepped with "elementary stream". >>>>>> >>>>>>Consider the 13818-1 definition of "Packetized Elementary Stream": >> >>"A >> >>>>>>continuous sequence of PES packets of one elementary stream with one >>>>>>stream ID may be used to construct a PES Stream." (ISO/IEC >>>>>>13818-1:2000 p. >>>>>>xiii) >>>>>> >>>>>>Stuff carried as payload of Transport Stream packets are merely >>>>>>'payload'. >>>>>>What the draft starts to define is a new type of payload stream >> >>(that >> >>>>>>is, >>>>>>a new way to carry data in a transport stream). The definition is >> >>not >> >>>>>>compete. >>>>>> >>>>>> >>>>>> >>>>>>>According to, for example EN301192 v1.3.1, defines Data Piping as: >>>>>>>" The data broadcast service shall insert the data to be broadcast >>>>>>>directly in the payload of MPEG-2 TS packets." >>>>>>>That raises the question, how to call a continouos stream of MPEG-2 >> >>TS >> >>>>>>>packets with a certain PID? >>>>>>> >>>>>>>Further the standard details that: >>>>>>>"The data broadcast service may use the >> >>payload_unit_start_indicator >> >>>>>>>field and the transport_priority field of the MPEG-2 Transport >> >>Stream >> >>>>>>>packets in a service private way. The use of the adaptation_field >> >>shall >> >>>>>>>be MPEG-2 compliant." >>>>>>>ULE uses PUSI and does not utilize the AF. >>>>>>> >>>>>>>"The delivery of the bits in time through a data pipe is service >>>>>>>private >>>>>>>and is not specified in the present document." >>>>>>>It seems obvious that the use of the term "TS Data Pipe" would lead >> >>to >> >>>>>>>the wrong conclusion that ULE equals Data Piping. But Data Piping >> >>is >> >>>>>>>not >>>>>>>detailed at all, whereas ULE tries to be. >>>>>> >>>>>> >>>>>>I'm not going to argue that DVB's specification is complete. I will >>>>>>argue >>>>>>that ULE isn't complete. >>>>>> >>>>>> >>>>>> >>>>>>>>(from the draft) >>>>>>>> TS Logical Channel: Transport Stream Logical Channel. In this >>>>>>>> document, this term identifies a channel at the MPEG-2 level >> >>[ISO- >> >>>>>>>> MPEG]. It exists at level 2 of the ISO/OSI reference model. All >>>>>>>> packets sent over a TS Logical Channel carry the same PID value >>>>>>>> (this value is unique within a specific TS Multiplex). According >> >>to >> >>>>>>>> MPEG-2, some TS Logical Channels are reserved for specific >>>>>>>> signalling purposes. Other standards (e.g., ATSC, DVB) also >> >>reserve >> >>>>>>>> specific TS Logical Channels. >>>>>>>> >>>>>>>>While I'm commenting on this definition, it also seems to me that >>>>>>> >>>>>>> >>>>>>>"channel >>>>>>> >>>>>>> >>>>>>>>at the MPEG-2 level" is either wrong or also ill-specified. >> >>What's >>a >> >>>>>>>>channel? If you're talking about MPEG-2, it's certainly >> >>conceivable >> >>>>>>> >>>>>>>that >>>>>>> >>>>>>> >>>>>>>>the reader may associate "channel" with "[television] channel" - >> >>which >> >>>>>>> >>>>>>>are >>>>>>> >>>>>>> >>>>>>>>the subject of a large amount of ATSC and DVB systems. >>>>>>> >>>>>>> >>>>>>>The term channel is indeed problematic in the context of > > television, > >>>>>>>however, network engineers might have a different understanding >> >>about >> >>>>>>>what a channel is. >>>>>>>According to ATIS a channel is "1. A connection between initiating >> >>and >> >>>>>>>terminating nodes of a circuit. 2. A single path provided by a >>>>>>>transmission medium via either (a) physical separation, such as by >>>>>>>multipair cable or (b) electrical separation, such as by frequency- >> >>or >> >>>>>>>time-division multiplexing. ..." >>>>>> >>>>>> >>>>>>I understand that 'channel' vis-?-vis networking has a different >> >>meaning >> >>>>>>than 'channel' vis-?-vis television. This was my point actually, >> >>that >> >>>>>>those familiar with MPEG transport should not be assumed to be >>>>>>networking- >>>>>>types (even when speaking with respect to ULE). >>>>>> >>>>>> >>>>>> >>>>>>>>Additionally, it is also wrong or ill-specified to say "According >> >>to >> >>>>>>> >>>>>>>MPEG-2 >>>>>>> >>>>>>> >>>>>>>>... TS Logical Channels ...". There is no such concept defined or >>>>>> >>>>>> >>>>>>used >>>>>> >>>>>> >>>>>>>>within MPEG (unless what you really mean is elementary stream, in >>>>>> >>>>>> >>>>>>which >>>>>> >>>>>> >>>>>>>case >>>>>>> >>>>>>> >>>>>>>>what do you need this extraneous term for anyhow?). >>>>>>> >>>>>>> >>>>>>>Again, elementary stream is not exactly what is being meant: >>>>>>>For example EN 300468 v1.5.1 defines: >>>>>>>"component (ELEMENTARY Stream): one or more entities which together >>>>>>>make >>>>>>>up an event, e.g. video, audio, teletext" >>>>>>> >>>>>>>and says further: >>>>>>>"The component descriptor identifies the type of component stream >> >>and >> >>>>>>>may be used to provide a text description of the elementary stream" >>>>>>> >>>>>>>where: >>>>>>>"component_type: This 8-bit field specifies the type of the video, >>>>>>>audio >>>>>>>or EBU-data component. The coding of this field is specified in >> >>table >> >>>>>> >>>>>>26." >>>>>> >>>>>> >>>>>>>Table 26 then lists all kinds of video, audio, and teletext > > formats, > >>>>>>>but >>>>>>>unfortunately no networking formats. >>>>>>> >>>>>>>At other places this standard is as innovative/creative in naming: >>>>>>>"event: grouping of elementary broadcast data streams with a >> >>defined >> >>>>>>>start and end time belonging to a common service, e.g. first half >> >>of >>a >> >>>>>>>football match, News Flash, first part of an entertainment show" >>>>>>>What is a "elementary broadcast data streams"? Not by guessing but >> >>by >> >>>>>>>definition? >>>>>>> >>>>>>> >>>>>>> >>>>>>>>In any case, Art is certainly correct that merely identifying a >> >>"TS >> >>>>>>> >>>>>>>Logical >>>>>>> >>>>>>> >>>>>>>>Channel" as a sequence of packets identified with a common PID >> >>value >> >>>>>>> >>>>>>>without >>>>>>> >>>>>>> >>>>>>>>identifying the PSI details is an invitation to multiplexers and >>>>>>>>remultiplexers to drop those packets on the floor. >>>>>>> >>>>>>> >>>>>>>Oh yes, this is the real problem of defining something outside >>>>>>>television standardiszation bodies: one risks that ULE packets are >>>>>>>being >>>>>>>dropped. >>>>>>>We have discussed basically two approaches: >>>>>>>1. define the PSI and get an ID, or tag, or "stream_type" for ULE, >>>>>>>or 2. >>>>>>>define ULE and let somebody else do the PSI work. >>>>>>>We have had some reasons for choice 2. >>>>>> >>>>>> >>>>>>This is a very easy thing to fix and something which should be done. >>>>>>Without defining a stream_type for ULE data, it is neither possible >> >>to >> >>>>>>construct a transport stream compliant with MPEG-2 nor one that >>>>>>interoperates with other ULE equipment. >>>>>> >>>>>>ATSC maintains a 'codepoint registry', and would be happy to >> >>allocate >>a >> >>>>>>stream_type value for ULE data upon request from IETF. Furthermore, >> >>the >> >>>>>>text to specify usage of the stream_type would be reasonably easy >> >>(and >> >>>>>>perhaps ties in to my suggested "SNDU Stream" definition (that is, >>>>>>define >>>>>>it as >>>>> >>>>> >>>>> >>>>>SNDU Stream: a sequence of MPEG-2 Transport Stream packets identified >>>>>by a >>>>>common PID value of stream_type <0xnn>. >>>>> >>>>>All that then remains, I think, would be to signal when a Program >> >>carries >> >>>>>SNDU Stream(s), and what it means when there are more than one SNDU >>>>>Stream >>>>>per program, or more than one Program that carries one or more SNDU >>>>>Streams. >>>>> >>>>> >>>>> >>>>>>>>If there remains an opportunity to repair what I believe to be >> >>errors >> >>>>>> >>>>>>in >>>>>> >>>>>> >>>>>>>the >>>>>>> >>>>>>> >>>>>>>>draft, I'm eager and willing to participate from a MPEG-2 >>>>>> >>>>>> >>>>>>entertainment >>>>>> >>>>>> >>>>>>>>(which is to say, legacy use of MPEG-2 Transport) point of view. >>>>>>> >>>>>>> >>>>>>>Of course the terms in the document should not conflict with >> >>meaning >>in >> >>>>>>>another context. However, ambiguous terms in other documents should >> >>be >> >>>>>>>avoided as well. >>>>>>> >>>>>>> >>>>>>> >>>>>>>>[Apologies for being strident at all, to say nothing of at such an >>>>>>>>apparently late stage - if the above is perceived as such] >>>>>>>> >>>>>>>>Regards, >>>>>>>>Adam Goldberg >>>>>>>>Director, Television Standards & Policy Development >>>>>>>>Sharp Laboratories of America >>>>>>>>8605 Westwood Center Drive, Suite 206 >>>>>>>>Vienna, VA 22182 >>>>>>>>+1-703-556-4406 >>>>>>>>+1-703-556-4410 fax >>>>>>>>+1-571-276-0305 cell >>>>>>>> >>>>>>>> >>>>>>>>-----Original Message----- >>>>>>>>From: owner-ipdvb at erg.abdn.ac.uk [mailto:owner- >> >>ipdvb at erg.abdn.ac.uk] >> >>>>>> >>>>>>On >>>>>> >>>>>> >>>>>>>>Behalf Of Gorry Fairhurst >>>>>>>>Sent: Friday, February 04, 2005 6:56 AM >>>>>>>>To: ipdvb at erg.abdn.ac.uk; Bernhard Collini-Nocker >>>>>>>>Cc: AAllison at nab.org >>>>>>>>Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast >>>>>>> >>>>>>> >>>>>>>Descriptors >>>>>>> >>>>>>> >>>>>>>>1) Done - point 1 was an edit mistake. >>>>>>>> >>>>>>>>2) I think some text on data broadcast descriptors, stream-type, >>>>>> >>>>>> >>>>>>or/and >>>>>> >>>>>> >>>>>>>PSI >>>>>>> >>>>>>> >>>>>>>>entries would be a valuable addition. >>>>>>>> >>>>>>>>On thinking about this, I wonder if the text about this should go >> >>at >> >>>>>> >>>>>>the >>>>>> >>>>>> >>>>>>>end >>>>>>> >>>>>>> >>>>>>>>of the Introduction (1.0) to the whole document, where people can >> >>see >> >>>>>> >>>>>>it >>>>>> >>>>>> >>>>>>>>clearly and then undesrtand that there may be something else >> >>needed >> >>>>>> >>>>>>for >>>>>> >>>>>> >>>>>>>>those >>>>>>>>networks that rely on PSI for remultiplexing! >>>>>>>> >>>>>>>>- Bernhard & others who understand PSI, can you work with Art to >> >>agree >> >>>>>>> >>>>>>>the >>>>>>> >>>>>>> >>>>>>>>exact wording please? >>>>>>>> >>>>>>>>Gorry Fairhurst >>>>>>>>(ipdvb WG Chair) >>>>>>>> >>>>>>>>Gorry Fairhurst wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>WG please read and respond to this message. >>>>>>>>> >>>>>>>>>The following message was received on January 22nd before WGLC, >> >>but >> >>>>>> >>>>>>was >>>>>> >>>>>> >>>>>>>>>dropped because the email source address was not verified by the >> >>list >> >>>>>>>>>server. >>>>>>>>> >>>>>>>>>The exact text of the message follows. >>>>>>>>> >>>>>>>>>best wishes, >>>>>>>>> >>>>>>>>>Gorry >>>>>>>>>(ipdvb WG Chair) >>>>>>>>> >>>>>>>>>----- >>>>>>>>> >>>>>>>> >>>>>>>>1) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>Thanks for considering my previous input... >>>>>>>>>I note that the new draft has an editorial oversight in that it >>>>>> >>>>>> >>>>>>contains >>>>>> >>>>>> >>>>>>>>>two definitions of PSI. I suggest the second should be deleted. >>>>>>>>> >>>>>>>> >>>>>>>>2) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>I previously made a comment about the ancillary requirements when >>>>>> >>>>>> >>>>>>adding >>>>>> >>>>>> >>>>>>>a >>>>>>> >>>>>>> >>>>>>>>>TS logical channel to a TS multiplex and asserted there appeared >>>>>>>>>to be >>>>>>>>>under >>>>>>>>>specification. Perhaps it was viewed as out of scope, or perhaps >> >>I >> >>>>>>> >>>>>>>simply >>>>>>> >>>>>>> >>>>>>>>>don't recognize the change that resulted. I can not find what >>>>>>> >>>>>>> >>>>>>>stream_type >>>>>>> >>>>>>> >>>>>>>>>is required to be used for the ULE stream when a "TS Logical >> >>Channel" >> >>>>>> >>>>>>is >>>>>> >>>>>> >>>>>>>>>added to a multiplex. >>>>>>> >>>>>>> >>>>>>>The problem here is the same as above. Without "applying" for a >>>>>>>"stream_type" for ULE there is no stream_type for ULE. In contrary >> >>why >> >>>>>>>should one register a stream_type value for ULE earlier than ULE is >>>>>>>standardized? >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>I suggest at least an informative note be added in Section 6 >> >>(after >> >>>>>> >>>>>>the >>>>>> >>>>>> >>>>>>>>>third line which says: "These are transmitted using a single TS >>>>>> >>>>>> >>>>>>Logical >>>>>> >>>>>> >>>>>>>>>Channel over a TS Multiplex.") The note should say "PSI entries >> >>to >>be >> >>>>>>>>>consistent with [ISO-MPEG] when constructing a conformant TS >>>>>>>>>Multiplex >>>>>>> >>>>>>> >>>>>>>and >>>>>>> >>>>>>> >>>>>>>>>means for Receivers to locate each such TS Logical Channel are >>>>>>>>>outside >>>>>>> >>>>>>> >>>>>>>the >>>>>>> >>>>>>> >>>>>>>>>scope of this recommendation." >>>>>>> >>>>>>> >>>>>>>Thanks, this is a very helpful suggestion for potential readers. In >>>>>>>addition the ipdvb-wg works on providing signalling other than >> >>PSI/SI. >> >>>>>>> >>>>>>>>>Reason: >>>>>>>>>Just inserting a "TS Logical Channel" without including a >>>>>>>>>TS_Program_map_section that lists the PID and a stream_type does >> >>not >> >>>>>>>>>appear to me to result in a strictly MPEG-2 conformant bit >> >>stream; >> >>>>>> >>>>>>and >>>>>> >>>>>> >>>>>>>>>practically >>>>>>>>>could result in the PIDs being dropped by a remultiplexer. If >> >>the >> >>>>>>> >>>>>>>means >>>>>>> >>>>>>> >>>>>>>>>for binding the inserted element into a multiplex and subsequent >>>>>>> >>>>>>> >>>>>>>discovery >>>>>>> >>>>>>> >>>>>>>>>is to be covered in another document, a pointer to that document >>>>>>>>>would >>>>>>> >>>>>>> >>>>>>>be >>>>>>> >>>>>>> >>>>>>>>>more helpful than this warning. It seems at least a warning is >> >>needed >> >>>>>>> >>>>>>>and >>>>>>> >>>>>>> >>>>>>>>>preferably a pointer to where this next level of TS construction >> >>is >> >>>>>>>>>defined. >>>>>>> >>>>>>> >>>>>>>From an architectural point of view it is a reasonable assupmption >> >>that >> >>>>>>>whatever is being sent in a TS multiplex should be referenced. >> >>However, >> >>>>>>>the reality is that "ghost" PIDs do occur in many services either >>>>>>>accidentially or for well-defined reasons. >>>>>>> >>>>>>>What is the penalty for not being strictly MPEG-2 >> >>conformant/compliant? >> >>>>>>> >>>>>>>>>Art Allison >>>>>>>>>Director, Advanced Engineering >>>>>>>>>NAB Science & Technology >>>>>>>>>1771 N St NW, Washington Dc 20036 >>>>>>>>>202 429 5418 >>>>>>> >>>>>>> >>>>>>> >>>>>>>Regards, >>>>>>>Bernhard Collini-Nocker >>>>>>> >>>>>>> >>>>> >>>>> >>>> > > From gorry at erg.abdn.ac.uk Tue Feb 8 11:46:47 2005 From: gorry at erg.abdn.ac.uk (Gorry Fairhurst) Date: Tue, 08 Feb 2005 11:46:47 +0000 Subject: Repost: WGLC ULE - Data Broadcast Message-ID: <4208A6A7.5070304@erg.abdn.ac.uk> This mail failed to reach the ipdvb list yesterday. I am forwarding it to the list, see below. Best wishes, Gorry Fairhurst (ipdvb WG Chair) -------- Original Message -------- Subject: (Fwd) Re: Forward from Art Alison: WGLC ULE - Data Broadcast Date: Tue, 08 Feb 2005 09:10:38 -0000 From: Rupert Goodings Reply-To: rupert at ecotel.demon.co.uk To: Gorry Here is a copy of the mail I *thought* I sent..it went ok and no bounce seen here. Rupert ------- Forwarded message follows ------- From: Rupert Goodings To: ipdvb at erg.abdn.ac.uk Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto rs Send reply to: rupert at ecotel.demon.co.uk Date sent: Mon, 07 Feb 2005 14:32:30 -0000 Dear all, As an interested observer to this discussion there seems to be a possible confusion here. For me it is unclear whether the concept of TS Logical Channel (and the discussions) refer to: a) all of the MPEG packets/segments in a given PID b) all of the MPEG packets/segments in a given ULE session. For (a) I think TS logical channel is good. Second choice "PID stream". Note that I am *assuming* that a single PID can support multiple "sessions" (I'm not sure what level of submux exactly is supported here). For (b) I suggest a new term "ULE Stream". I don't like the new proposal "SNDU stream" since it doesn't resolve this ambiguity and possibly makes it worse. best regards Rupert Goodings (observing, not wearing my ETSI hat!) Date sent: Mon, 07 Feb 2005 13:48:43 +0100 From: Bernhard Collini-Nocker To: ipdvb at erg.abdn.ac.uk Copies to: "Goldberg, Adam" , "Allison, Art" , Matthew Goldman Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto rs Send reply to: ipdvb at erg.abdn.ac.uk > Hello, > > let me try to summarize the two major points being raised and what the > discussion is about: > 1. the name/definition of "TS Logical Channel" is not well received and > the name/definition of a "SNDU stream" is proposed instead > 2. it is proposed to consider MPEG-2 conformance in specifying that ULE > requires a specific stream_type value for the PMT > > Personally I have no objection against 1., because it is easy to change > and improves wording and naming (unless somebody has an even better > name for it). > For 2. my concern is that mentioning stream_type may require some > additional wording about PSI/SI in general, which is likely out of scope > of the ULE draft. Even worse, in introducing a "world" besides the > encapsulation/decapsulation of ULE, this may result in further confusion > about what the MPEG-2/Section layer does in addition to and/or in > comparison to ULE/IP. Actually some difficult question may arise from > this direction, for example whether it is a wishful requirement for ULE > to support PAT/PMT/NIT/INT/... table parsing? > > Any opinions, recommendations or suggestions about this? > > Regards, > Bernhard > > Goldberg, Adam wrote: > > ARGH. I fat-fingered 'send' before completing the email. See below. > > > > Adam Goldberg > > Director, Television Standards & Policy Development > > Sharp Laboratories of America > > 8605 Westwood Center Drive, Suite 206 > > Vienna, VA 22182 > > +1-703-556-4406 > > +1-703-556-4410 fax > > +1-571-276-0305 cell > > > > > > > >>-----Original Message----- > >>From: Goldberg, Adam > >>Sent: Monday, February 07, 2005 12:42 AM > >>To: 'Bernhard Collini-Nocker'; Goldberg, Adam > >>Cc: ipdvb at erg.abdn.ac.uk; Allison, Art; Matthew Goldman > >>Subject: RE: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto > >>rs > >> > >>See below... > >> > >>Adam Goldberg > >>Director, Television Standards & Policy Development > >>Sharp Laboratories of America > >>8605 Westwood Center Drive, Suite 206 > >>Vienna, VA 22182 > >>+1-703-556-4406 > >>+1-703-556-4410 fax > >>+1-571-276-0305 cell > >> > >> > >>Bernhard Collini-Nocker wrote: > >> > >>>Goldberg, Adam wrote: > >>> > >>>>I apologize for being "late to the party", but: > >>>> > >>>>I do not see a particular need to define new term "TS Logical > > > > Channel", > > > >>>and > >>> > >>>>indeed doing so creates risks of ill-specification (such as those Art > >>> > >>>points > >>> > >>>>out), as well as confusion heaped upon someone familiar with MPEG-2 > >>>>Transport (as typically used in entertainment delivery). > >>> > >>>Unfortunately the MPEG-2 standards do not provide a reasonable term for > >>>the purpose of networking. The question is whether other terms, for > >>>example "PID network" or "PID stream" would be better received and > >>>understood? > >>>The term "TS logical channel" tries to verbally visualize that the > >>>encapsulation uses a continouos stream of transport stream packets using > >>>one specific packet identifier to transport subnetwork data units. Maybe > >>>the term "TS (virtual) circuit" better names this? > >> > >>It is perhaps not well defined in 13818-1, but the term of art is > >>"streams". Many people use "PID stream" which is a poor combination of > >>words. I'd have no objection to defining a "SNDU Stream" as something > >>like "a sequence of MPEG-2 Transport Stream packets identified by a common > >>PID value" (or some such). > >> > >>Perhaps discussing 'virtual circuits' relative to a Transport Stream is > >>begging for confusion. Use of any such words ("TS (virtual) circuit") > >>needs careful definition, likely requiring the above SNDU Stream > >>definition plus an explanation of what it means for multiple SNDU Streams > >>to exist in a single Transport Stream. > >> > >> > >>>>Furthermore, the definition is quite wrong with respect to ATSC and > >> > >>DVB > >> > >>>use > >>> > >>>>of "specific TS Logical Channels". To my knowledge, this internet- > >> > >>draft > >> > >>>is > >>> > >>>>the only document anywhere which uses such terms. It is certainly > >> > >>true > >> > >>>that > >>> > >>>>MPEG, DVB and ATSC define //elementary streams// identified by > >>> > >>>stream_type > >>> > >>>>values. I suspect this is what is meant by "TS Logical Channel", but > >> > >>it > >> > >>>is > >>> > >>>>difficult for me to tell. > >>> > >>>I am not so sure, whether this analysis is correct. Elementary streams > >>>are those that are transported as Packetized ES, whereas "auxillary" > >>>data and signalling is transported as sections. Although a stream_type > >>>in the program map section is used to reference both PESs and sections > >>>the term elementary stream is used very vague and we tried to avoid > >>>using it in the same vague manner. > >> > >>Perhaps I overstepped with "elementary stream". > >> > >>Consider the 13818-1 definition of "Packetized Elementary Stream": "A > >>continuous sequence of PES packets of one elementary stream with one > >>stream ID may be used to construct a PES Stream." (ISO/IEC 13818-1:2000 p. > >>xiii) > >> > >>Stuff carried as payload of Transport Stream packets are merely 'payload'. > >>What the draft starts to define is a new type of payload stream (that is, > >>a new way to carry data in a transport stream). The definition is not > >>compete. > >> > >> > >>>According to, for example EN301192 v1.3.1, defines Data Piping as: > >>>" The data broadcast service shall insert the data to be broadcast > >>>directly in the payload of MPEG-2 TS packets." > >>>That raises the question, how to call a continouos stream of MPEG-2 TS > >>>packets with a certain PID? > >>> > >>>Further the standard details that: > >>>"The data broadcast service may use the payload_unit_start_indicator > >>>field and the transport_priority field of the MPEG-2 Transport Stream > >>>packets in a service private way. The use of the adaptation_field shall > >>>be MPEG-2 compliant." > >>>ULE uses PUSI and does not utilize the AF. > >>> > >>>"The delivery of the bits in time through a data pipe is service private > >>>and is not specified in the present document." > >>>It seems obvious that the use of the term "TS Data Pipe" would lead to > >>>the wrong conclusion that ULE equals Data Piping. But Data Piping is not > >>>detailed at all, whereas ULE tries to be. > >> > >>I'm not going to argue that DVB's specification is complete. I will argue > >>that ULE isn't complete. > >> > >> > >>>>(from the draft) > >>>> TS Logical Channel: Transport Stream Logical Channel. In this > >>>> document, this term identifies a channel at the MPEG-2 level [ISO- > >>>> MPEG]. It exists at level 2 of the ISO/OSI reference model. All > >>>> packets sent over a TS Logical Channel carry the same PID value > >>>> (this value is unique within a specific TS Multiplex). According to > >>>> MPEG-2, some TS Logical Channels are reserved for specific > >>>> signalling purposes. Other standards (e.g., ATSC, DVB) also reserve > >>>> specific TS Logical Channels. > >>>> > >>>>While I'm commenting on this definition, it also seems to me that > >>> > >>>"channel > >>> > >>>>at the MPEG-2 level" is either wrong or also ill-specified. What's a > >>>>channel? If you're talking about MPEG-2, it's certainly conceivable > >>> > >>>that > >>> > >>>>the reader may associate "channel" with "[television] channel" - which > >>> > >>>are > >>> > >>>>the subject of a large amount of ATSC and DVB systems. > >>> > >>>The term channel is indeed problematic in the context of television, > >>>however, network engineers might have a different understanding about > >>>what a channel is. > >>>According to ATIS a channel is "1. A connection between initiating and > >>>terminating nodes of a circuit. 2. A single path provided by a > >>>transmission medium via either (a) physical separation, such as by > >>>multipair cable or (b) electrical separation, such as by frequency- or > >>>time-division multiplexing. ..." > >> > >>I understand that 'channel' vis-?-vis networking has a different meaning > >>than 'channel' vis-?-vis television. This was my point actually, that > >>those familiar with MPEG transport should not be assumed to be networking- > >>types (even when speaking with respect to ULE). > >> > >> > >>>>Additionally, it is also wrong or ill-specified to say "According to > >>> > >>>MPEG-2 > >>> > >>>>... TS Logical Channels ...". There is no such concept defined or > >> > >>used > >> > >>>>within MPEG (unless what you really mean is elementary stream, in > >> > >>which > >> > >>>case > >>> > >>>>what do you need this extraneous term for anyhow?). > >>> > >>>Again, elementary stream is not exactly what is being meant: > >>>For example EN 300468 v1.5.1 defines: > >>>"component (ELEMENTARY Stream): one or more entities which together make > >>>up an event, e.g. video, audio, teletext" > >>> > >>>and says further: > >>>"The component descriptor identifies the type of component stream and > >>>may be used to provide a text description of the elementary stream" > >>> > >>>where: > >>>"component_type: This 8-bit field specifies the type of the video, audio > >>>or EBU-data component. The coding of this field is specified in table > >> > >>26." > >> > >>>Table 26 then lists all kinds of video, audio, and teletext formats, but > >>>unfortunately no networking formats. > >>> > >>>At other places this standard is as innovative/creative in naming: > >>>"event: grouping of elementary broadcast data streams with a defined > >>>start and end time belonging to a common service, e.g. first half of a > >>>football match, News Flash, first part of an entertainment show" > >>>What is a "elementary broadcast data streams"? Not by guessing but by > >>>definition? > >>> > >>> > >>>>In any case, Art is certainly correct that merely identifying a "TS > >>> > >>>Logical > >>> > >>>>Channel" as a sequence of packets identified with a common PID value > >>> > >>>without > >>> > >>>>identifying the PSI details is an invitation to multiplexers and > >>>>remultiplexers to drop those packets on the floor. > >>> > >>>Oh yes, this is the real problem of defining something outside > >>>television standardiszation bodies: one risks that ULE packets are being > >>>dropped. > >>>We have discussed basically two approaches: > >>>1. define the PSI and get an ID, or tag, or "stream_type" for ULE, or 2. > >>>define ULE and let somebody else do the PSI work. > >>>We have had some reasons for choice 2. > >> > >>This is a very easy thing to fix and something which should be done. > >>Without defining a stream_type for ULE data, it is neither possible to > >>construct a transport stream compliant with MPEG-2 nor one that > >>interoperates with other ULE equipment. > >> > >>ATSC maintains a 'codepoint registry', and would be happy to allocate a > >>stream_type value for ULE data upon request from IETF. Furthermore, the > >>text to specify usage of the stream_type would be reasonably easy (and > >>perhaps ties in to my suggested "SNDU Stream" definition (that is, define > >>it as > > > > > > SNDU Stream: a sequence of MPEG-2 Transport Stream packets identified by a > > common PID value of stream_type <0xnn>. > > > > All that then remains, I think, would be to signal when a Program carries > > SNDU Stream(s), and what it means when there are more than one SNDU Stream > > per program, or more than one Program that carries one or more SNDU Streams. > > > > > >>>>If there remains an opportunity to repair what I believe to be errors > >> > >>in > >> > >>>the > >>> > >>>>draft, I'm eager and willing to participate from a MPEG-2 > >> > >>entertainment > >> > >>>>(which is to say, legacy use of MPEG-2 Transport) point of view. > >>> > >>>Of course the terms in the document should not conflict with meaning in > >>>another context. However, ambiguous terms in other documents should be > >>>avoided as well. > >>> > >>> > >>>>[Apologies for being strident at all, to say nothing of at such an > >>>>apparently late stage - if the above is perceived as such] > >>>> > >>>>Regards, > >>>>Adam Goldberg > >>>>Director, Television Standards & Policy Development > >>>>Sharp Laboratories of America > >>>>8605 Westwood Center Drive, Suite 206 > >>>>Vienna, VA 22182 > >>>>+1-703-556-4406 > >>>>+1-703-556-4410 fax > >>>>+1-571-276-0305 cell > >>>> > >>>> > >>>>-----Original Message----- > >>>>From: owner-ipdvb at erg.abdn.ac.uk [mailto:owner-ipdvb at erg.abdn.ac.uk] > >> > >>On > >> > >>>>Behalf Of Gorry Fairhurst > >>>>Sent: Friday, February 04, 2005 6:56 AM > >>>>To: ipdvb at erg.abdn.ac.uk; Bernhard Collini-Nocker > >>>>Cc: AAllison at nab.org > >>>>Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast > >>> > >>>Descriptors > >>> > >>>> > >>>>1) Done - point 1 was an edit mistake. > >>>> > >>>>2) I think some text on data broadcast descriptors, stream-type, > >> > >>or/and > >> > >>>PSI > >>> > >>>>entries would be a valuable addition. > >>>> > >>>>On thinking about this, I wonder if the text about this should go at > >> > >>the > >> > >>>end > >>> > >>>>of the Introduction (1.0) to the whole document, where people can see > >> > >>it > >> > >>>>clearly and then undesrtand that there may be something else needed > >> > >>for > >> > >>>>those > >>>>networks that rely on PSI for remultiplexing! > >>>> > >>>>- Bernhard & others who understand PSI, can you work with Art to agree > >>> > >>>the > >>> > >>>>exact wording please? > >>>> > >>>>Gorry Fairhurst > >>>>(ipdvb WG Chair) > >>>> > >>>>Gorry Fairhurst wrote: > >>>> > >>>> > >>>> > >>>>>WG please read and respond to this message. > >>>>> > >>>>>The following message was received on January 22nd before WGLC, but > >> > >>was > >> > >>>>>dropped because the email source address was not verified by the list > >>>>>server. > >>>>> > >>>>>The exact text of the message follows. > >>>>> > >>>>>best wishes, > >>>>> > >>>>>Gorry > >>>>>(ipdvb WG Chair) > >>>>> > >>>>>----- > >>>>> > >>>> > >>>>1) > >>>> > >>>> > >>>>>Thanks for considering my previous input... > >>>>>I note that the new draft has an editorial oversight in that it > >> > >>contains > >> > >>>>>two definitions of PSI. I suggest the second should be deleted. > >>>>> > >>>> > >>>>2) > >>>> > >>>> > >>>>>I previously made a comment about the ancillary requirements when > >> > >>adding > >> > >>>a > >>> > >>>>>TS logical channel to a TS multiplex and asserted there appeared to be > >>>>>under > >>>>>specification. Perhaps it was viewed as out of scope, or perhaps I > >>> > >>>simply > >>> > >>>>>don't recognize the change that resulted. I can not find what > >>> > >>>stream_type > >>> > >>>>>is required to be used for the ULE stream when a "TS Logical Channel" > >> > >>is > >> > >>>>>added to a multiplex. > >>> > >>>The problem here is the same as above. Without "applying" for a > >>>"stream_type" for ULE there is no stream_type for ULE. In contrary why > >>>should one register a stream_type value for ULE earlier than ULE is > >>>standardized? > >>> > >>> > >>>>>I suggest at least an informative note be added in Section 6 (after > >> > >>the > >> > >>>>>third line which says: "These are transmitted using a single TS > >> > >>Logical > >> > >>>>>Channel over a TS Multiplex.") The note should say "PSI entries to be > >>>>>consistent with [ISO-MPEG] when constructing a conformant TS Multiplex > >>> > >>>and > >>> > >>>>>means for Receivers to locate each such TS Logical Channel are outside > >>> > >>>the > >>> > >>>>>scope of this recommendation." > >>> > >>>Thanks, this is a very helpful suggestion for potential readers. In > >>>addition the ipdvb-wg works on providing signalling other than PSI/SI. > >>> > >>> > >>>>>Reason: > >>>>>Just inserting a "TS Logical Channel" without including a > >>>>>TS_Program_map_section that lists the PID and a stream_type does not > >>>>>appear to me to result in a strictly MPEG-2 conformant bit stream; > >> > >>and > >> > >>>>>practically > >>>>>could result in the PIDs being dropped by a remultiplexer. If the > >>> > >>>means > >>> > >>>>>for binding the inserted element into a multiplex and subsequent > >>> > >>>discovery > >>> > >>>>>is to be covered in another document, a pointer to that document would > >>> > >>>be > >>> > >>>>>more helpful than this warning. It seems at least a warning is needed > >>> > >>>and > >>> > >>>>>preferably a pointer to where this next level of TS construction is > >>>>>defined. > >>> > >>> From an architectural point of view it is a reasonable assupmption that > >>>whatever is being sent in a TS multiplex should be referenced. However, > >>>the reality is that "ghost" PIDs do occur in many services either > >>>accidentially or for well-defined reasons. > >>> > >>>What is the penalty for not being strictly MPEG-2 conformant/compliant? > >>> > >>> > >>>>>Art Allison > >>>>>Director, Advanced Engineering > >>>>>NAB Science & Technology > >>>>>1771 N St NW, Washington Dc 20036 > >>>>>202 429 5418 > >>> > >>> > >>>Regards, > >>>Bernhard Collini-Nocker > >>> > >>> > > > > > ------- End of forwarded message ------- From gorry at erg.abdn.ac.uk Tue Feb 8 21:36:05 2005 From: gorry at erg.abdn.ac.uk (Gorry Fairhurst) Date: Tue, 08 Feb 2005 21:36:05 +0000 Subject: WGLC: ULE --- Questions to this WG. In-Reply-To: <420763AB.50107@cosy.sbg.ac.at> References: <08259490B3BC3140B549DD0907A5644811D664@admsrvnt10.enet.sharplabs.com> <420763AB.50107@cosy.sbg.ac.at> Message-ID: <420930C5.4080705@erg.abdn.ac.uk> As the ipdvb WG Chair, let me see if I can frame some questions to the WG as a whole (dervied from my understanding of this mail thread)? - This isn't an intention to stop discussions (we should address some of the issues raised onm the lists in the documents we plan to write), but I am aware that we have a document to deliver to the IESG following the WGLC. ---- My three questions are: A) There was a proposal by a reviewer to change the TITLE of the RFC, to make this clearer. The currently suggested new title is: "Ultra Lightweight Encapsulation (ULE) for transmission of IP datagrams over an MPEG-2 Transport Stream" Instead of the existing title: "Ultra Lightweight Encapsulation (ULE) for transmission of IP datagrams over MPEG-2/DVB networks" Is the new title acceptable? ---- B) I propose the following text is added to the Introduction, are these useful/sufficient? The MPEG-2 specification [ISO-MPEG2] requires conformant TS Multiplexes to provide Program Specific Information (PSI) for each stream in the TS Multiplex. Other MPEG-2 based transmission standards may also define Service Information (SI). This information may allow Receivers and Re-multiplexors [draft-ipdvb-arch] to locate a specific ULE Stream (i.e., the PID value of the TS Logical Channel that carries a ULE Stream). The conditions under which this information is required, and the format in which it is to be provided is beyond the scope of this document. Addressing and mapping issues for IP over MPEG-2 are described in [draft-ipdvb-ar]. ---- C) The terminology "TS Logical Channel" has already been used in another document that has passed WGLC. Is it now sufficiently flawed that we MUST be replaced in the ULE document, if so why?, If not, I propose we change the definition to: TS Logical Channel: Transport Stream Logical Channel. In this document, this term identifies a channel at the MPEG-2 level [ISO- MPEG2]. This exists at level 2 of the ISO/OSI reference model. All packets sent over a TS Logical Channel carry the same PID value (this value is unique within a specific TS Multiplex). The term "Stream" is defined in MPEG-2 [ISO-MPEG2]. This describes the content carried by a specific TS Logical Channel (see, ULE Stream). Some PID values are reserved (by MPEG-2) for specific signalling. Other standards (e.g., ATSC, DVB) also reserve specific PID values. I propose we also add: ULE Stream: An MPEG-2 TS Logical Channel that carries only ULE encapsulated PDUs. ULE Streams may be identified by definition of a ULE stream_type in SI/PSI [ISO_MPEG2]. ---- A number of minor corrections have also been made to wording and format, as requested by the various reviewers and WG feedback. The complete set of proposed changes are listed at: http://www.erg.abdn.ac.uk/ip-dvb/ids/rfcdiff-ule-05f-04.html Please respond whether you think this revision, is now ready, and we'll try to reach a conclusion on whether this document is finally ready to submit. Gorry Fairhurst (ipdvb WG Chair) From gorry at erg.abdn.ac.uk Thu Feb 10 10:29:41 2005 From: gorry at erg.abdn.ac.uk (Gorry Fairhurst) Date: Thu, 10 Feb 2005 10:29:41 +0000 Subject: I-D ACTION:draft-fair-ipdvb-ar-03.txt Message-ID: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Address Resolution for IP datagrams over MPEG-2 networks Author(s) : G. Fairhurst, et al. Filename : draft-fair-ipdvb-ar-03.txt Pages : 17 Date : 2005-2-9 This document describes the current mechanisms to bind IPv4/IPv6 addresses and flows to MPEG-2 Transport Streams (TS)and how these methods interact with well known protocols for address management like DHCP, ARP, NAT and DNS. For MPEG-2 subnetworks like any other IP networks methods are required to signal IPv4/v6 addresses to the link receivers and transmitters; this is known as Address Resolution (AR), or Neighbour Discovery (ND). Although AR is often associated with Ethernet [RFC803], it is essential to the operation of any L2 network. In MPEG-2 networks, an IP address must be associated with a Packet ID (PID) and specific transmission multiplex either statically or via the use of some specific tables. Address resolution complements the higher layer resource discovery tools that are used to advertise IP sessions. In this document the different mechanisms for address resolution for MPEG-2 networking as well as their usage are reviewed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-fair-ipdvb-ar-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-fair-ipdvb-ar-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-fair-ipdvb-ar-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce From gorry at erg.abdn.ac.uk Thu Feb 10 10:39:17 2005 From: gorry at erg.abdn.ac.uk (Gorry Fairhurst) Date: Thu, 10 Feb 2005 10:39:17 +0000 Subject: I-D ACTION:draft-aoki-arib-uri-00.txt Message-ID: The following ID was announced yesterday, and is not currently associated with an IETF WG. Although the topic (URI definitions) relates to the work of a different IETF WG, I'm reposting it to ipdvb, since this topic may also be of interest to a number of people on this list. Gorry Fairhurst (ipdvb WG Chair) ----- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The broadcast program resource identifier in the MPEG-2 transport stream over ISDB system Author(s) : S. Aoki, M. Kawamori Filename : draft-aoki-arib-uri-00.txt Pages : 8 Date : 2005-2-8 The Uniform Resource Identifier (URI) scheme "arib:" has been devised to allow acquiring the current or future scheduled publications of broadcast media content from the internet. These broadcast media contents are distributed with the MPEG-2 TS [ISO/IEC 13818-1] on the ISDB (Integrated Services Digital Broadcasting) broadcast system, which is specified in the [ITU-R BT.1306] and [ITU-R BS.1114]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-aoki-arib-uri-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-aoki-arib-uri-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From gorry at erg.abdn.ac.uk Fri Feb 11 11:58:29 2005 From: gorry at erg.abdn.ac.uk (Gorry Fairhurst) Date: Fri, 11 Feb 2005 11:58:29 +0000 Subject: PLEASE REPLY by 15th Feb 2005 - Final Sign-off of ULE In-Reply-To: <420930C5.4080705@erg.abdn.ac.uk> References: <08259490B3BC3140B549DD0907A5644811D664@admsrvnt10.enet.sharplabs.com> <420763AB.50107@cosy.sbg.ac.at> <420930C5.4080705@erg.abdn.ac.uk> Message-ID: <420C9DE5.4070600@erg.abdn.ac.uk> I'm going to allow a few days for a "final signoff" of the ULE spec, until 15th Feb 2005 (one week from the email below). Specifically, I'm looking for the folks who made comments during last call to check the doc and either indicate "looks OK" or if necessary, submit replacement text. At this stage, it is important to get "positive" responses (as well as raising any issues), so if you have looked at the changes and agree with them, please do send a brief email to the list saying so. Once submitted, there will be only one last chance to correct this, during the final IETF Last Call period, after which this document will be published. The document is at: http://www.erg.abdn.ac.uk/ip-dvb/ids/draft-ietf-ipdvb-ule-05f.txt The complete set of proposed changes are listed at: http://www.erg.abdn.ac.uk/ip-dvb/ids/rfcdiff-ule-05f-04.html -- Gorry. Gorry Fairhurst wrote: > > As the ipdvb WG Chair, let me see if I can frame some questions to the > WG as a whole (dervied from my understanding of this mail thread)? - > This isn't an intention to stop discussions (we should address some of > the issues raised onm the lists in the documents we plan to write), but > I am aware that we have a document to deliver to the IESG following the > WGLC. > > ---- > > My three questions are: > > A) There was a proposal by a reviewer to change the TITLE of the RFC, to > make this clearer. The currently suggested new title is: > > "Ultra Lightweight Encapsulation (ULE) for transmission of > IP datagrams over an MPEG-2 Transport Stream" > > Instead of the existing title: > "Ultra Lightweight Encapsulation (ULE) for transmission of > IP datagrams over MPEG-2/DVB networks" > > Is the new title acceptable? > > ---- > > B) I propose the following text is added to the Introduction, are these > useful/sufficient? > > The MPEG-2 specification [ISO-MPEG2] requires conformant TS > Multiplexes to provide Program Specific Information (PSI) for > each stream in the TS Multiplex. Other MPEG-2 based transmission > standards may also define Service Information (SI). This > information may allow Receivers and Re-multiplexors [draft-ipdvb-arch] > to locate a specific ULE Stream (i.e., the PID value of the TS Logical > Channel that carries a ULE Stream). The conditions under which this > information is required, and the format in which it is to be provided > is beyond the scope of this document. Addressing and mapping issues > for IP over MPEG-2 are described in [draft-ipdvb-ar]. > > ---- > > C) The terminology "TS Logical Channel" has already been used in another > document that has passed WGLC. Is it now sufficiently flawed that we > MUST be replaced in the ULE document, if so why?, If not, I propose we > change the definition to: > > TS Logical Channel: Transport Stream Logical Channel. In this > document, this term identifies a channel at the MPEG-2 level [ISO- > MPEG2]. This exists at level 2 of the ISO/OSI reference model. All > packets sent over a TS Logical Channel carry the same PID value > (this value is unique within a specific TS Multiplex). The term > "Stream" is defined in MPEG-2 [ISO-MPEG2]. This describes the content > carried by a specific TS Logical Channel (see, ULE Stream). Some > PID values are reserved (by MPEG-2) for specific signalling. > Other standards (e.g., ATSC, DVB) also reserve specific PID values. > > I propose we also add: > > ULE Stream: An MPEG-2 TS Logical Channel that carries only ULE > encapsulated PDUs. ULE Streams may be identified by definition > of a ULE stream_type in SI/PSI [ISO_MPEG2]. > > > ---- > > > A number of minor corrections have also been made to wording and format, > as requested by the various reviewers and WG feedback. > > The complete set of proposed changes are listed at: > http://www.erg.abdn.ac.uk/ip-dvb/ids/rfcdiff-ule-05f-04.html > > Please respond whether you think this revision, is now ready, and we'll > try to reach a conclusion on whether this document is finally ready to > submit. > > Gorry Fairhurst > (ipdvb WG Chair) > > From AAllison at nab.org Fri Feb 11 15:18:21 2005 From: AAllison at nab.org (Allison, Art) Date: Fri, 11 Feb 2005 10:18:21 -0500 Subject: PLEASE REPLY by 15th Feb 2005 - Final Sign-off of ULE Message-ID: This is getting very close: Comment 1 The revised language about TS mapping at the end of section 1 is much appreciated and a valuable addition; but overreached a bit in the last sentence. The last sentence before section 2 is: "Addressing and mapping issues for IP over MPEG-2 are described in [draft-ipdvb-ar]. " I suggest this should say: "Addressing and mapping issues for ULE over MPEG-2 are also described in [draft-ipdvb-ar]." Reasons: A) There are other means for sending IP over MPEG-2 (e.g., those that are in daily operation in the US per ATSC standards, and undoubtly per other standards in other countries). Draft-ipdvb-ar does not attempt to cover all other standards bodies' approaches to sending IP over MPEG-2, but rather just ULE, and narrowing the above statement to just ULE removes the potential for false impressions. B) The word 'also' was inserted as draft-ipdvb-ar will supplement not replace the ISO standards. Comment 2 I don't think the declarative sentence about Byte order after the definition of Byte is in the optimal location (but since I do not suggest an alternative location, I do not object to it being there). I leave it to the commenter to measure if it is an adequate change to address the comment about the need to define Byte order. Comment 3 In the new definition for 'ULE Stream' I think the last ULE is redundant and the prediction of what will be done elsewhere too strong. Revise last sentence to read: "ULE Streams may be identified by definition of a stream_type in SI/PSI [ISO_MPEG2]." Reason: This change avoids prejudging what we do not know. We do not know whether this stream_type will be one common value that is defined by various MPEG-2 Standard Users (e.g. ATSC,ESTI,ARIB) or if it will be a private stream_type with a MPEG-2 Registration Descriptor in some systems. A world-wide single coordinated value will require some effort, but could reduce complexity of implementations. Comment 4 Ref [ATSC-PSIP-TC] should read: "[ATSC-PSIP-TC] A/65B Program and System Information Protocol for Terrestrial Broadcast and Cable", Advanced Television Systems Committee (ATSC), Doc. A/65B, 18 March 2003." Comment 5 I noted that some references have dates, and some do not. Does the lack of a date in an RFC mean that no matter what changes are made to that reference, the new change immediately becomes effective and all deployed ULE devices must comply or be in violation of the RFC? If this is the meaning of "no date" ; it is a serious commitment. With a date it is clear that just the specific version applies. I suggest dates should be on all normative references. Comment 6 WRT to the TS logical channel issue, while I agree with Mr. Goldberg about what would have been a better approach; the decision was taken by the group and the term was created for better or worse. So as we are married to it, the only issue is definition of the new term being accurate and sufficient, and I find that this draft is acceptable in that regard. Comment 7 As you asked for affirmations, the remaining changes are to me. ____________ Art Allison Director, Advanced Engineering NAB Science & Technology 1771 N St NW, Washington Dc 20036 202 429 5418 -----Original Message----- From: Gorry Fairhurst [mailto:gorry at erg.abdn.ac.uk] Sent: Friday, February 11, 2005 6:58 AM To: ipdvb at erg.abdn.ac.uk Cc: Goldberg, Adam; Allison, Art; Matthew Goldman Subject: PLEASE REPLY by 15th Feb 2005 - Final Sign-off of ULE I'm going to allow a few days for a "final signoff" of the ULE spec, until 15th Feb 2005 (one week from the email below). Specifically, I'm looking for the folks who made comments during last call to check the doc and either indicate "looks OK" or if necessary, submit replacement text. At this stage, it is important to get "positive" responses (as well as raising any issues), so if you have looked at the changes and agree with them, please do send a brief email to the list saying so. Once submitted, there will be only one last chance to correct this, during the final IETF Last Call period, after which this document will be published. The document is at: http://www.erg.abdn.ac.uk/ip-dvb/ids/draft-ietf-ipdvb-ule-05f.txt The complete set of proposed changes are listed at: http://www.erg.abdn.ac.uk/ip-dvb/ids/rfcdiff-ule-05f-04.html -- Gorry. From gorry at erg.abdn.ac.uk Fri Feb 11 17:35:27 2005 From: gorry at erg.abdn.ac.uk (Gorry Fairhurst) Date: Fri, 11 Feb 2005 17:35:27 +0000 Subject: PLEASE REPLY by 15th Feb 2005 - Final Sign-off of ULE In-Reply-To: References: Message-ID: <420CECDF.7010908@erg.abdn.ac.uk> Thanks, Art, your comments have much improved this document, Gorry Allison, Art wrote: > This is getting very close: > Comment 1 > The revised language about TS mapping at the end of section 1 is much > appreciated and a valuable addition; but overreached a bit in the last > sentence. The last sentence before section 2 is: > "Addressing and mapping issues for IP over MPEG-2 are described in > [draft-ipdvb-ar]. " > > I suggest this should say: > "Addressing and mapping issues for ULE over MPEG-2 are also described in > [draft-ipdvb-ar]." We take your text, no problem with that. > > Reasons: > A) There are other means for sending IP over MPEG-2 (e.g., > those that are in daily operation in the US per ATSC standards, and > undoubtly per other standards in other countries). Draft-ipdvb-ar does not > attempt to cover all other standards bodies' approaches to sending IP over > MPEG-2, but rather just ULE, and narrowing the above statement to just ULE > removes the potential for false impressions. draft-ipdvb-ar-xx *should* also talk about a number of scenarios including common uses of MPE (but this will require more inputs and text - Marie Jose, I'm sure would appreciate inputs to this). > B) The word 'also' was inserted as draft-ipdvb-ar will supplement not > replace the ISO standards. > Absolutely appropriate to this document. > Comment 2 > I don't think the declarative sentence about Byte order after the definition > of Byte is in the optimal location (but since I do not suggest an > alternative location, I do not object to it being there). I leave it to the > commenter to measure if it is an adequate change to address the comment > about the need to define Byte order. No text change - Byte-order should not be an issue, since all RFCs should order bytes in the same way. > Comment 3 > In the new definition for 'ULE Stream' I think the last ULE is redundant and > the prediction of what will be done elsewhere too strong. Revise last > sentence to read: "ULE Streams may be identified by definition of a > stream_type in SI/PSI [ISO_MPEG2]." > Reason: This change avoids prejudging what we do not know. We do not know > whether this stream_type will be one common value that is defined by various > MPEG-2 Standard Users (e.g. ATSC,ESTI,ARIB) or if it will be a private > stream_type with a MPEG-2 Registration Descriptor in some systems. A > world-wide single coordinated value will require some effort, but could > reduce complexity of implementations. OK, then we use your text. > Comment 4 > Ref [ATSC-PSIP-TC] should read: > "[ATSC-PSIP-TC] A/65B Program and System Information Protocol for > Terrestrial Broadcast and Cable", Advanced Television Systems Committee > (ATSC), Doc. A/65B, 18 March 2003." Done, thanks. > Comment 5 > I noted that some references have dates, and some do not. Does the lack of a > date in an RFC mean that no matter what changes are made to that reference, > the new change immediately becomes effective and all deployed ULE devices > must comply or be in violation of the RFC? If this is the meaning of "no > date" ; it is a serious commitment. With a date it is clear that just the > specific version applies. I suggest dates should be on all normative > references. I don't think the IETF has a single convention on this, but I'd agree with your statement. The problem is that since RFCs are not updated, the normative references are simply those that were normative when the document was written. So, I have changed this to: [ISO-MPEG2] ISO/IEC IS 13818-1 "Information technology -- Generic coding of moving pictures and associated audio information -- Part 1: Systems", International Standards Organisation (ISO), 2000. > Comment 6 > WRT to the TS logical channel issue, while I agree with Mr. Goldberg about > what would have been a better approach; the decision was taken by the group > and the term was created for better or worse. So as we are married to it, > the only issue is definition of the new term being accurate and sufficient, > and I find that this draft is acceptable in that regard. > OK - and we do need to bear the usage of this term in mind when this WG produces other documents. > Comment 7 > As you asked for affirmations, the remaining changes are to me. > OK, Thanks. > ____________ > Art Allison > Director, Advanced Engineering > NAB Science & Technology > 1771 N St NW, Washington Dc 20036 > 202 429 5418 > -----Original Message----- > From: Gorry Fairhurst [mailto:gorry at erg.abdn.ac.uk] > Sent: Friday, February 11, 2005 6:58 AM > To: ipdvb at erg.abdn.ac.uk > Cc: Goldberg, Adam; Allison, Art; Matthew Goldman > Subject: PLEASE REPLY by 15th Feb 2005 - Final Sign-off of ULE > > > I'm going to allow a few days for a "final signoff" of the ULE spec, until > 15th Feb 2005 (one week from the email below). > > Specifically, I'm looking for the folks who made comments during last call > to check the doc and either indicate "looks OK" or if necessary, submit > replacement text. At this stage, it is important to get "positive" responses > (as well as raising any issues), so if you have looked at the changes and > agree with them, please do send a brief email to the list saying so. > > Once submitted, there will be only one last chance to correct this, during > the final IETF Last Call period, after which this document will be > published. > > The document is at: > http://www.erg.abdn.ac.uk/ip-dvb/ids/draft-ietf-ipdvb-ule-05f.txt > > The complete set of proposed changes are listed at: > http://www.erg.abdn.ac.uk/ip-dvb/ids/rfcdiff-ule-05f-04.html > > > -- Gorry. > > > > From bnocker at cosy.sbg.ac.at Mon Feb 14 17:06:48 2005 From: bnocker at cosy.sbg.ac.at (Bernhard Collini-Nocker) Date: Mon, 14 Feb 2005 18:06:48 +0100 Subject: PLEASE REPLY by 15th Feb 2005 - Final Sign-off of ULE Message-ID: <4210DAA8.4060809@cosy.sbg.ac.at> Hello readers, thanks to everybody (special thanks to Art Allison and Adam Goldberg) for the constructive discussion and helpful support in getting the ULE text fixed. This is to give my OK to the final rev of the ULE text, including the title change (sent via the list). Regards, Bernhard From stiemerling at netlab.nec.de Thu Feb 17 20:39:57 2005 From: stiemerling at netlab.nec.de (Martin Stiemerling) Date: Thu, 17 Feb 2005 21:39:57 +0100 Subject: I-D ACTION:draft-stiemerling-ipdvb-config-00.txt (fwd) Message-ID: <3FE10A5C09BEE173EDC46BFA@[10.0.1.2]> Hi all, FYI about a new draft on IP Address Configuration for IPDVB. Martin ------------ Forwarded Message ------------ Date: Mittwoch, 16. Februar 2005 10:15 Uhr -0500 From: Internet-Drafts at ietf.org To: i-d-announce at ietf.org Subject: I-D ACTION:draft-stiemerling-ipdvb-config-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Problem Statement: IP Address Configuration for IPDVB Author(s) : M. Stiemerling Filename : draft-stiemerling-ipdvb-config-00.txt Pages : 12 Date : 2005-2-15 Future IPDVB networks will require a more powerful IP address configuration management as currently provided in such networks. Current discussions within the IPDVB working group have shown that the future usage scenarios and requirements for dynamic configuration of IP addresses are not yet clear defined. This memo identifies the problem space for IP address resolution and configuration in IPDVB networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-stiemerling-ipdvb-config-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-stiemerling-ipdvb-config-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-stiemerling-ipdvb-config-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ---------- End Forwarded Message ---------- -------------- next part -------------- An embedded message was scrubbed... From: Internet-Drafts at ietf.org Subject: I-D ACTION:draft-stiemerling-ipdvb-config-00.txt Date: Wed, 16 Feb 2005 10:15:56 -0500 Size: 5624 URL: From gorry at erg.abdn.ac.uk Fri Feb 18 12:53:55 2005 From: gorry at erg.abdn.ac.uk (Gorry Fairhurst) Date: Fri, 18 Feb 2005 13:53:55 +0100 Subject: I-D ACTION:draft-ietf-ipdvb-ule-05.txt Message-ID: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over DVB Working Group of the IETF. Title : Ultra Lightweight Encapsulation (ULE) for transmission of IP datagrams over an MPEG-2 Transport Stream Author(s) : G. Fairhurst, B. Collini-Nocker Filename : draft-ietf-ipdvb-ule-05.txt Pages : 45 Date : 2005-2-16 The MPEG-2 Transport Stream (TS) has been widely accepted not only for providing digital TV services, but also as a subnetwork technology for building IP networks. This document describes an Ultra Lightweight Encapsulation (ULE) mechanism for the transport of IPv4 and IPv6 Datagrams and other network protocol packets directly over the ISO MPEG-2 Transport Stream as TS Private Data. ULE specifies a base encapsulation format and supports an extension format that allows it to carry additional header information to assist in network/Receiver processing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipdvb-ule-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipdvb-ule-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipdvb-ule-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From gorry at erg.abdn.ac.uk Mon Feb 21 10:13:43 2005 From: gorry at erg.abdn.ac.uk (Gorry Fairhurst) Date: Mon, 21 Feb 2005 10:13:43 +0000 Subject: I-D ACTION:draft-stiemerling-ipdvb-config-00.txt (fwd) In-Reply-To: <3FE10A5C09BEE173EDC46BFA@[10.0.1.2]> References: <3FE10A5C09BEE173EDC46BFA@[10.0.1.2]> Message-ID: <4219B457.6090409@erg.abdn.ac.uk> Thanks Martin! This comes at a good time, I'd like to take the discussion of addressing and address configuration as a major Agenda item at the next IETF meeting. Gorry Martin Stiemerling wrote: > Hi all, > > FYI about a new draft on IP Address Configuration for IPDVB. > > Martin > > ------------ Forwarded Message ------------ > Date: Mittwoch, 16. Februar 2005 10:15 Uhr -0500 > From: Internet-Drafts at ietf.org > To: i-d-announce at ietf.org > Subject: I-D ACTION:draft-stiemerling-ipdvb-config-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Problem Statement: IP Address Configuration for IPDVB > Author(s) : M. Stiemerling > Filename : draft-stiemerling-ipdvb-config-00.txt > Pages : 12 > Date : 2005-2-15 > > Future IPDVB networks will require a more powerful IP address > configuration management as currently provided in such networks. > Current discussions within the IPDVB working group have shown that > the future usage scenarios and requirements for dynamic configuration > of IP addresses are not yet clear defined. This memo identifies the > problem space for IP address resolution and configuration in IPDVB > networks. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-stiemerling-ipdvb-config-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request at ietf.org with the word unsubscribe in the body of the > message. You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce to change your > subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-stiemerling-ipdvb-config-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv at ietf.org. > In the body type: > "FILE /internet-drafts/draft-stiemerling-ipdvb-config-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > ---------- End Forwarded Message ---------- > From gorry at erg.abdn.ac.uk Mon Feb 21 10:24:35 2005 From: gorry at erg.abdn.ac.uk (Gorry Fairhurst) Date: Mon, 21 Feb 2005 10:24:35 +0000 Subject: Request to Publish as an RFC: draft-ietf-ipdvb-ule-05.txt In-Reply-To: References: Message-ID: <4219B6E3.6050409@erg.abdn.ac.uk> This document has now successfully completd the second WGLC and a new ID was isseued. On behalf of the ipdvb WG, I am now forwarding this for AD review with a request that it is published as an Standards Track RFC. The progress of this ID can be tracked through the IETD ID Tracker interface at: https://datatracker.ietf.org/public/pidtracker.cgi A copy of the Request-to-Publish write-up is enclosed below. Best wishes, Gorry Faihurst (ipdvb WG Chair) ---------- WG Internet Draft: draft-ietf-ipdvb-ule-05.txt Ultra Lightweight Encapsulation (ULE) for transmission of IP datagrams over MPEG-2/DVB networks ipdvb WG Chair: G Fairhurst - Technical Summary The MPEG-2 Transport Stream (TS) has been widely accepted, not only for providing digital TV services, but also as a subnetwork technology for building IP networks. This document describes an Ultra Lightweight Encapsulation (ULE) mechanism for the transport of IPv4 and IPv6 Datagrams and other network protocol packets directly over the ISO MPEG-2 Transport Stream as TS Private Data. ULE specifies a base encapsulation format and supports an extension format that allows it to carry additional header information to assist in network/Receiver processing. - Working Group Summary This document is a chartered item of the ipdvb WG. Two approaches were considered by the WG - ULE was chosen by the WG and was the simplest. The specification is now thought to be both clear and unambiguous. The support for extension headers will enable the protocol to be maintained and support additional features once these are well-understood and can be clearly defined, this includes support for optional link layer security. This ID has WG support and would be a valuable Standards Track RFC. - Protocol Quality The protocol is simple and efficient, yet provides scope for extensions - some of which will be very desirable for future work. Specific examples of possible future extensions include: L2 encryption support, header compression support (e.g. using the ROHC framework). There is some early implementation experience of the protocol by commercial vendors. rev-03 of this spec is supported by the current Linux kernel, no major protocol changes have taken place since this rev. Interoperability tests between two independent teams were also performed using an early release of the spec (without extension header support), and were summarised to the list. IPv4 and IPv6 were both tested, and the results posted to the ipdvb list. Extended trials using this early rev of ULE and IPv6 were performed via a satellite link to Eastern Europe sites as a part of the SILK Project. The WG has not yet been notified of any interoperability tests for the final protocol. Gorry Fairhurst wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IP over DVB Working Group of the IETF. > > Title : Ultra Lightweight Encapsulation (ULE) for > transmission of IP datagrams over an MPEG-2 > Transport Stream > Author(s) : G. Fairhurst, B. Collini-Nocker > Filename : draft-ietf-ipdvb-ule-05.txt > Pages : 45 > Date : 2005-2-16 > > The MPEG-2 Transport Stream (TS) has been widely accepted not only > for providing digital TV services, but also as a subnetwork > technology for building IP networks. > > This document describes an Ultra Lightweight Encapsulation (ULE) > mechanism for the transport of IPv4 and IPv6 Datagrams and other > network protocol packets directly over the ISO MPEG-2 Transport > Stream as TS Private Data. ULE specifies a base encapsulation format > and supports an extension format that allows it to carry additional > header information to assist in network/Receiver processing. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipdvb-ule-05.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request at ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-ipdvb-ule-05.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv at ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ipdvb-ule-05.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > > From gorry at erg.abdn.ac.uk Mon Feb 21 10:46:30 2005 From: gorry at erg.abdn.ac.uk (Gorry Fairhurst) Date: Mon, 21 Feb 2005 10:46:30 +0000 Subject: FIRST DRAFT of AGENDA for ipdvb meeting, at IETF-62, Monday 7th March 1930-2200 Message-ID: <4219BC06.4040801@erg.abdn.ac.uk> Please find below the first-cut at the Agenda for the ipdvb WG to be held in Minneapolis. The full draft meeting Agenda for IETF-62 is now available. This draft timetable is now stable, and meeting times and dates are not expected to change. (Please see: http://www.ietf.org/meetings/agenda_62.txt). * This is an open meeting, all are welcome to attend (see http://www.ietf.org/meetings/meetings.html) * We are particularly looking for inputs on the two topics of: use of the ULE Extension Header mechanism and the subject of how to manage/assign IP addresses to traffic flows within MPEG-2 networks. I am keen to accept new inputs (e.g. especially from those who have not previously contributed). All people who wish to present (or see specific issues discussed), please let me know as soon as possible. * All presenters/authors please confirm that you are willing to contribute slides, and that the timeslot and title are correct. The Agenda needs to be submitted to the IETF secretariat by the end of this week (25th March). Best wishes, Gorry (ipdvb WG Chair) gorry at erg.abdn.ac.uk ------ IPDVB WG IP over Digital Video Broadcast ======== MONDAY, March 7, 2005 19:30-22:00 Evening Session Internet Area 1. Agenda Bashing (5 minutes) - Chair * Agenda changes * Election of Scribe for proceedings * Jabber Scribe 2. Working Group Status and Plans (10 minutes) - Chair * Documents in Last Call NONE * Documents in AD Review http://www.ietf.org/internet-drafts/draft-ietf-arch-03.txt http://www.ietf.org/internet-drafts/draft-ietf-ule-05.txt * Documents in RFC Editor Queue NONE * Published RFCs NONE 3. Ultra Lighweight Encapsulation (ULE) (10 minutes) - G Fairhurst/B Collini-Nocker http://www.ietf.org/internet-drafts/draft-ietf-arch-03.txt * Update on status of known implementations * SI information * ATSC proposal to allocate a stream_type identifier 4. Liason RObust Header Compression (20 minutes) - C Borman http://www.ietf.org/internet-drafts/draft-bormann-rohc-over-802-00.txt * Purpose of draft * Applicability to MPEG-2 Transmission Networks * Implications on usage with ULE 5. Problem Statement: IP Address Configuration for IPDVB (20 minutes) - M Stiemerling http://www.ietf.org/internet-drafts/draft-stiemerling-ipdvb-config-00.txt 6. Address Resolution (15 minutes) - M-J Montpetit/I Hidetaka http://www.ietf.org/internet-drafts/draft-fair-ipdvb-ar-03.txt * Discussion of requirements for different scenarios * Proposal to adopt as a WG ID? 7. Protocols for MPEG-2 network configuration (5 minutes) - M-J Montpetit http://www.ietf.org/internet-drafts/draft-montpetit-ipdvb-config-00.txt * Discussion of proposed work within ipdvb * Way forward. 8. Review of Milestones (10 minutes) - Chair Archive: http://www.erg.abdn.ac.uk/ipdvb/archive Gorry Fairhurst IPDVB WG Chair From gorry at erg.abdn.ac.uk Mon Feb 21 10:13:43 2005 From: gorry at erg.abdn.ac.uk (Gorry Fairhurst) Date: Mon, 21 Feb 2005 10:13:43 +0000 Subject: I-D ACTION:draft-stiemerling-ipdvb-config-00.txt (fwd) In-Reply-To: <3FE10A5C09BEE173EDC46BFA@[10.0.1.2]> References: <3FE10A5C09BEE173EDC46BFA@[10.0.1.2]> Message-ID: <4219B457.6090409@erg.abdn.ac.uk> Thanks Martin! This comes at a good time, I'd like to take the discussion of addressing and address configuration as a major Agenda item at the next IETF meeting. Gorry Martin Stiemerling wrote: > Hi all, > > FYI about a new draft on IP Address Configuration for IPDVB. > > Martin > > ------------ Forwarded Message ------------ > Date: Mittwoch, 16. Februar 2005 10:15 Uhr -0500 > From: Internet-Drafts at ietf.org > To: i-d-announce at ietf.org > Subject: I-D ACTION:draft-stiemerling-ipdvb-config-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Problem Statement: IP Address Configuration for IPDVB > Author(s) : M. Stiemerling > Filename : draft-stiemerling-ipdvb-config-00.txt > Pages : 12 > Date : 2005-2-15 > > Future IPDVB networks will require a more powerful IP address > configuration management as currently provided in such networks. > Current discussions within the IPDVB working group have shown that > the future usage scenarios and requirements for dynamic configuration > of IP addresses are not yet clear defined. This memo identifies the > problem space for IP address resolution and configuration in IPDVB > networks. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-stiemerling-ipdvb-config-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request at ietf.org with the word unsubscribe in the body of the > message. You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce to change your > subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-stiemerling-ipdvb-config-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv at ietf.org. > In the body type: > "FILE /internet-drafts/draft-stiemerling-ipdvb-config-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > ---------- End Forwarded Message ---------- > From H.Cruickshank at surrey.ac.uk Wed Feb 23 17:16:01 2005 From: H.Cruickshank at surrey.ac.uk (H.Cruickshank) Date: Wed, 23 Feb 2005 17:16:01 -0000 Subject: Call for inputs for IETF-62 (Minneapolis) 6-11 March 2005 Message-ID: Hi Gorry and IP-over-DVB members, We (University of Surrey UK; and Alcatel Space France) had intended to submit an ID for the IETF-62 meeting, on L2 security for ULE, but we am sorry that we missed the cut-off for new -00 IDs. However, I'd like to make some slides that express our main objectives. In a summary, we plan to work on designing a link layer (L2) encryption for ULE. we plan to define the ULE header types and header extension to accommodate this encryption. ULE authentication is a possibility but the presence of CRC-32 makes its use fairly limited. Also we will define the key management system that is need for the key exchange. All this work will be strongly linked to the existing security work in IPsec and MSEC working groups and DVB-RCS security procedures. Regarding the D field in ULE header, we will consider whether it is worth separating the two cases with D=1 (no NPA/MAC address before the encryption header) and D=0 (an NPA/MAC address is present as clear text). The ability to hide the final recipient may be of interest to some customers. Would it be possible for this to be presented to the ipdvb WG meeting, to see if there is interest in the group in this topic? We'll submit the draft once the ID archives open after the IETF-62 meeting, and possibly, if all goes well, I'll be able to present it at IETF-63, in Paris. Haitham --- Dr. Haitham S. Cruickshank Senior Research Fellow Communications Centre for Communication Systems Research (CCSR) School of Electronics, Computing and Mathematics University of Surrey, Guildford, Surrey GU2 7XH, UK Tel: +44 1483 686007 (indirect 689844) Fax: +44 1483 686011 e-mail: H.Cruickshank at surrey.ac.uk http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ -----Original Message----- From: owner-ipdvb at erg.abdn.ac.uk [mailto:owner-ipdvb at erg.abdn.ac.uk] On Behalf Of Gorry Fairhurst Sent: 17 January 2005 17:59 To: ipdvb at erg.abdn.ac.uk Subject: Call for inputs for IETF-62 (Minneapolis) 6-11 March 2005 The Sixty-second IETF meeting will be held 6-11 March 2005. We don't normally ask so far in advance for Agenda items for the next meeting, but with two documents currently in/completed WGLC, I'd like a sense of the likley inputs for the 62nd IETF in Minneapolis, MN, USA. A number of people promised inputs at the last IETF, and it's a good time to take stock on the current chartered milestones: * Done Draft of a WG Architecture ID describing usage of MPEG-2 transport for IP transmission. * Done Draft of a WG ID on the new Encapsulation. * Done Submit Architecture to IESG * Jan 05 Draft of a WG ID on the AR Framework, specifying mechanisms to perform address resolution. * Jan 05 Submit Encapsulation to IESG * Feb 05 Draft of a WG ID or the AR Protocol, defining a protocol to perform IP address resolution. * Oct 05 Submit AR Framework to IESG * Dec 05 Submit AR Protocol to IESG * Dec 05 Progress the Encapsulation RFC along the IETF standards track Could you please email me directly (or to the ipdvb list) if: * You intend to prepare/revise an Internet Draft for this meeting. * You would like to present/discuss a specific issue at the next IETF. Best wishes, Gorry Fairhurst (ipdvb WG Chair). From gorry at erg.abdn.ac.uk Thu Feb 24 07:53:00 2005 From: gorry at erg.abdn.ac.uk (Gorry Fairhurst) Date: Thu, 24 Feb 2005 07:53:00 +0000 Subject: Call for inputs for IETF-62 (Minneapolis) 6-11 March 2005 In-Reply-To: Message-ID: Thanks Haitham, The slides you sent seem to address a topic that may be of interest to the group. It's normal practice to write an Internet Draft to explain your contribution before allocating Agenda time. However, the brief presentation seems to be in line with the Security Considerations of the -arch- and -ule- drafts. I don't want to delay this until the following IETF, so I will allocate some time in the Agenda to look at this topic (I'll post copies of the slides to the list when the Agenda is finalised). I look forward to submission of the ID as soon as the ID archives open. Gorry On 23/2/05 5:16 pm, "H.Cruickshank" wrote: > Hi Gorry and IP-over-DVB members, > > We (University of Surrey UK; and Alcatel Space France) had intended to > submit an ID for the IETF-62 meeting, on L2 security for ULE, but we am > sorry that we missed the cut-off for new -00 IDs. However, I'd like to > make some slides that express our main objectives. > > In a summary, we plan to work on designing a link layer (L2) encryption > for ULE. we plan to define the ULE header types and header extension to > accommodate this encryption. ULE authentication is a possibility but > the presence of CRC-32 makes its use fairly limited. Also we will define > the key management system that is need for the key exchange. All this > work will be strongly linked to the existing security work in IPsec and > MSEC working groups and DVB-RCS security procedures. > > Regarding the D field in ULE header, we will consider whether it is > worth separating the two cases with D=1 (no NPA/MAC address before the > encryption header) and D=0 (an NPA/MAC address is > present as clear text). The ability to hide the final recipient may be > of interest to some customers. > > Would it be possible for this to be presented to the ipdvb WG meeting, > to see if there is interest in the group in this topic? > > We'll submit the draft once the ID archives open after the IETF-62 > meeting, and possibly, if all goes well, I'll be able to present it at > IETF-63, in Paris. > > > Haitham > --- > Dr. Haitham S. Cruickshank > Senior Research Fellow > Communications Centre for Communication Systems Research (CCSR) > School of Electronics, Computing and Mathematics > University of Surrey, Guildford, Surrey GU2 7XH, UK > > Tel: +44 1483 686007 (indirect 689844) > Fax: +44 1483 686011 > e-mail: H.Cruickshank at surrey.ac.uk > http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ > > > > -----Original Message----- > From: owner-ipdvb at erg.abdn.ac.uk [mailto:owner-ipdvb at erg.abdn.ac.uk] On > Behalf Of Gorry Fairhurst > Sent: 17 January 2005 17:59 > To: ipdvb at erg.abdn.ac.uk > Subject: Call for inputs for IETF-62 (Minneapolis) 6-11 March 2005 > > > The Sixty-second IETF meeting will be held 6-11 March 2005. We don't > normally > ask so far in advance for Agenda items for the next meeting, but with > two > documents currently in/completed WGLC, I'd like a sense of the likley > inputs > for the 62nd IETF in Minneapolis, MN, USA. > > A number of people promised inputs at the last IETF, and it's a good > time to > take stock on the current chartered milestones: > > > * Done Draft of a WG Architecture ID describing usage of MPEG-2 > transport for > IP transmission. > * Done Draft of a WG ID on the new Encapsulation. > * Done Submit Architecture to IESG > > * Jan 05 Draft of a WG ID on the AR Framework, specifying mechanisms to > perform address resolution. > * Jan 05 Submit Encapsulation to IESG > * Feb 05 Draft of a WG ID or the AR Protocol, defining a protocol to > perform > IP address resolution. > * Oct 05 Submit AR Framework to IESG > * Dec 05 Submit AR Protocol to IESG > * Dec 05 Progress the Encapsulation RFC along the IETF standards track > > > Could you please email me directly (or to the ipdvb list) if: > > * You intend to prepare/revise an Internet Draft for this meeting. > * You would like to present/discuss a specific issue at the next IETF. > > Best wishes, > > Gorry Fairhurst > (ipdvb WG Chair). > > > > From gorry at erg.abdn.ac.uk Thu Feb 24 21:06:43 2005 From: gorry at erg.abdn.ac.uk (Gorry Fairhurst) Date: Thu, 24 Feb 2005 21:06:43 +0000 Subject: I-D ACTION:draft-bormann-rohc-over-802-01.txt Message-ID: <421E41E3.3070104@erg.abdn.ac.uk> For your info, I have allocated some Agenda time to discuss this ID, and specifically to look at the relevence to the ULE encapsulation. Please look at it and send comments to the list - or ask at the IETF WG meeting. Gorry ----------------------- New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Robust Header Compression (ROHC) over 802 networks Author(s) : C. Bormann Filename : draft-bormann-rohc-over-802-01.txt Pages : 12 Date : 2005-2-23 Various proposals have been submitted to the ROHC working group for enabling the use of ROHC [RFC 3095] header compression over Ethernet, 802.11 and other 802-based links. Previous proposals generally suffered from a lack of systems perspective on 802 networks. The present document attempts to supply some systems perspective and provides a rough outline for a solution. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bormann-rohc-over-802-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-bormann-rohc-over-802-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-bormann-rohc-over-802-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From gorry at erg.abdn.ac.uk Thu Feb 24 21:21:38 2005 From: gorry at erg.abdn.ac.uk (Gorry Fairhurst) Date: Thu, 24 Feb 2005 21:21:38 +0000 Subject: AGENDA for ipdvb meeting, at IETF-62, Monday 7th March 19:30-22:00 Message-ID: <421E4562.9060101@erg.abdn.ac.uk> Please find below the Agenda for the ipdvb WG to be held at IETF-62. Best wishes, Gorry (ipdvb WG Chair) gorry at erg.abdn.ac.uk ------ IP over Digital Video Broadcast (IPDVB) WG MONDAY, March 7, 2005 19:30-22:00 Evening Session Internet Area 1. Agenda Bashing (5 minutes) - Chair * Agenda changes * Election of Scribe for Proceedings * Jabber Scribe 2. Working Group Status and Plans (10 minutes) - Chair * Documents in Last Call * Documents in AD Review * Documents in RFC Editor Queue * Published RFCs 3. Architecture/Framework (5 minutes) - M-J Montpetit/ Chair http://www.ietf.org/internet-drafts/draft-ipdvb-arch-03.txt * Changes in rev 03 4.Ultra Lighweight Encapsulation (ULE) (10 minutes) - G Fairhurst/B Collini-Nocker http://www.ietf.org/internet-drafts/draft-ietf-arch-03.txt * Update on status of known implementations * SI information * ATSC proposal to allocate a stream_type identifier 5. ULE Security Extension (10 minutes) - Haitham Cruikshank No current ID (see WG mailing list for slides). * Rationale * Security Extension proposal 6. ipdvb and RObust Header Compression (20 minutes) - Carsten Borman http://www.ietf.org/internet-drafts/draft-bormann-rohc-over-802-01.txt * Purpose of draft * Applicability to MPEG-2 Transmission Networks * Implications on usage with ULE 7. Problem Statement: IP Address Configuration for IPDVB (20 minutes) - M Stiemerling http://www.ietf.org/internet-drafts/draft-stiemerling-ipdvb-config-00.txt * Discussion of requirements for different scenarios 8. Address Resolution (15 minutes) - M-J Montpetit/I Hidetaka http://www.ietf.org/internet-drafts/draft-fair-ipdvb-ar-03.txt * Document structure * ND and UDLR * Proposal to adopt as a WG ID? 9. Protocols for MPEG-2 network configuration (5 minutes) - M-J Montpetit http://www.ietf.org/internet-drafts/draft-montpetit-ipdvb-config-00.txt * Discussion of proposed work within ipdvb * Way forward. 10. ARIB broadcast program resource identifier (5 minutes) http://www.ietf.org/internet-drafts/draft-aoki-arib-uri-00.txt - Kirilka Nikolova * Transport stream discovery 11. Review of Milestones (10 minutes) - Chair Archive: http://www.erg.abdn.ac.uk/ipdvb/archive Gorry Fairhurst IPDVB WG Chair From stevebullers at yahoo.co.uk Fri Feb 25 14:43:43 2005 From: stevebullers at yahoo.co.uk (Stephen Bullers) Date: Fri, 25 Feb 2005 14:43:43 +0000 (GMT) Subject: ULE Downlink required for decoding test Message-ID: <20050225144343.47406.qmail@web25702.mail.ukl.yahoo.com> Please could anybody advise of an existing Downlink carrying ULE coded data that is currently operation so that I may perform some decoding tests... Many Thanks ___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com