From owner-ipdvb@erg.abdn.ac.uk Wed Feb 2 15:19:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23963 for ; Wed, 2 Feb 2005 15:19:33 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwRGq-0004Er-1T for ipdvb-archive@ietf.org; Wed, 02 Feb 2005 15:38:40 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j12JmDe3011245 for ; Wed, 2 Feb 2005 19:48:13 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j12JmDEa011244 for ipdvb-subscribed-users; Wed, 2 Feb 2005 19:48:13 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j12JlT5t011223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 Feb 2005 19:47:30 GMT Message-ID: <42012E52.8030603@erg.abdn.ac.uk> Date: Wed, 02 Feb 2005 19:47:30 +0000 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk CC: Carsten Bormann Subject: Re: LLC support in DVB , ATSC, MPEG-2? - DO WE NEED A NEW EXTENSION? References: <41F945E4.1040403@erg.abdn.ac.uk> <41FE2FC4.6000805@erg.abdn.ac.uk> <904a5ff0bd74cd8d26b2e76016f88483@tzi.org> <41FE494D.2000607@erg.abdn.ac.uk> In-Reply-To: <41FE494D.2000607@erg.abdn.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 2.0 (++) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Content-Transfer-Encoding: 7bit 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 owner-ipdvb@erg.abdn.ac.uk Wed Feb 2 16:07:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00745 for ; Wed, 2 Feb 2005 16:07:01 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwS0j-0006T1-5g for ipdvb-archive@ietf.org; Wed, 02 Feb 2005 16:26:08 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j12Kb48A012364 for ; Wed, 2 Feb 2005 20:37:04 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j12Kb4On012363 for ipdvb-subscribed-users; Wed, 2 Feb 2005 20:37:04 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from smtpout03-03.mesa1.secureserver.net (smtpout03-03.mesa1.secureserver.net [64.202.165.73]) by erg.abdn.ac.uk (8.12.11/8.12.11) with SMTP id j12KaPmu012340 for ; Wed, 2 Feb 2005 20:36:25 GMT Received: (qmail 26928 invoked from network); 2 Feb 2005 20:36:25 -0000 Received: from unknown (HELO webmail01.mesa1.secureserver.net) (64.202.166.114) by smtpout03-03.mesa1.secureserver.net with SMTP; 2 Feb 2005 20:36:25 -0000 Received: (qmail 2295 invoked by uid 99); 2 Feb 2005 20:36:25 -0000 Message-ID: <20050202203625.2294.qmail@webmail01.mesa1.secureserver.net> Date: Wed, 2 Feb 2005 13:36:25 -0700 From: Marie-Jose Montpetit Subject: RE: LLC support in DVB , ATSC, MPEG-2? - DO WE NEED A NEW EXTENSION? To: ipdvb@erg.abdn.ac.uk cc: Carsten Bormann , ipdvb@erg.abdn.ac.uk MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 2.0 (++) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de 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@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 owner-ipdvb@erg.abdn.ac.uk Wed Feb 2 17:36:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20133 for ; Wed, 2 Feb 2005 17:36:01 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwTOu-0004qo-UL for ipdvb-archive@ietf.org; Wed, 02 Feb 2005 17:55:10 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j12M52mP014257 for ; Wed, 2 Feb 2005 22:05:02 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j12M52TS014256 for ipdvb-subscribed-users; Wed, 2 Feb 2005 22:05:02 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from informatik.uni-bremen.de (imh.informatik.uni-bremen.de [134.102.224.4]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j12M4LPu014227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 2 Feb 2005 22:04:22 GMT Received: from [IPv6:::1] (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id j12M4IUC024373; Wed, 2 Feb 2005 23:04:20 +0100 (MET) 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> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Carsten Bormann From: Carsten Bormann Subject: Re: LLC support in DVB , ATSC, MPEG-2? - DO WE NEED A NEW EXTENSION? Date: Wed, 2 Feb 2005 23:04:19 +0100 To: ipdvb@erg.abdn.ac.uk X-Mailer: Apple Mail (2.619.2) X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 2.0 (++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit 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 owner-ipdvb@erg.abdn.ac.uk Wed Feb 2 21:53:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13824 for ; Wed, 2 Feb 2005 21:53:01 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwXPY-0004BO-6r for ipdvb-archive@ietf.org; Wed, 02 Feb 2005 22:12:11 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j132PsuJ019234 for ; Thu, 3 Feb 2005 02:25:54 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j132Ps41019233 for ipdvb-subscribed-users; Thu, 3 Feb 2005 02:25:54 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from nrg.cs.usm.my (nrg.cs.usm.my [161.142.8.104]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j132PKEh019216 for ; Thu, 3 Feb 2005 02:25:21 GMT Received: from localhost (localhost.localdomain [127.0.0.1]) by nrg.cs.usm.my (Postfix) with ESMTP id B546D2200EB for ; Thu, 3 Feb 2005 10:24:51 +0800 (MYT) Received: from nrg.cs.usm.my ([127.0.0.1]) by localhost (nrg.cs.usm.my [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27641-05 for ; Thu, 3 Feb 2005 10:24:06 +0800 (MYT) Received: from MOTANGKIA (unknown [219.93.2.99]) by nrg.cs.usm.my (Postfix) with ESMTP id D481B2200EA for ; Thu, 3 Feb 2005 10:24:05 +0800 (MYT) From: "Simon Teh" To: Subject: RE: LLC support in DVB , ATSC, MPEG-2? - DO WE NEED A NEW EXTENSION? Date: Thu, 3 Feb 2005 10:23:53 +0800 Organization: NRG MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <20050202203625.2294.qmail@webmail01.mesa1.secureserver.net> Thread-Index: AcUJZ3gI6EMxypOWRnyup8M5O3ARjAALngiw Message-Id: <20050203022405.D481B2200EA@nrg.cs.usm.my> X-Virus-Scanned: amavisd-new at nrg.cs.usm.my X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 2.0 (++) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Content-Transfer-Encoding: 7bit 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@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On Behalf Of Marie-Jose Montpetit Sent: 03 February 2005 04:36 To: ipdvb@erg.abdn.ac.uk Cc: Carsten Bormann; ipdvb@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@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 owner-ipdvb@erg.abdn.ac.uk Fri Feb 4 07:41:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20768 for ; Fri, 4 Feb 2005 07:41:48 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cx35G-000880-BB for ipdvb-archive@ietf.org; Fri, 04 Feb 2005 08:01:14 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j14Bv4ue000664 for ; Fri, 4 Feb 2005 11:57:04 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j14Bv4BA000663 for ipdvb-subscribed-users; Fri, 4 Feb 2005 11:57:04 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j14BtncV000618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 4 Feb 2005 11:55:49 GMT Message-ID: <420362C5.20308@erg.abdn.ac.uk> Date: Fri, 04 Feb 2005 11:55:49 +0000 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk, Bernhard Collini-Nocker CC: AAllison@nab.org Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast Descriptors References: <41FE68DA.1020507@erg.abdn.ac.uk> In-Reply-To: <41FE68DA.1020507@erg.abdn.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit 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 owner-ipdvb@erg.abdn.ac.uk Fri Feb 4 07:58:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21876 for ; Fri, 4 Feb 2005 07:58:44 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cx3Ld-0000F6-8j for ipdvb-archive@ietf.org; Fri, 04 Feb 2005 08:18:10 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j14CbtDL001739 for ; Fri, 4 Feb 2005 12:37:55 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j14CbtNu001738 for ipdvb-subscribed-users; Fri, 4 Feb 2005 12:37:55 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from clyde.ses-astra.com (clyde.ses-astra.com [213.169.104.55]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j14CbGdo001713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 4 Feb 2005 12:37:17 GMT Received: from marge.gen.btz.aia.lu (marge.gen.btz.aia.lu [193.168.96.8]) by clyde.ses-astra.com (8.12.10/8.12.10) with ESMTP id j14CbGXZ012329 for ; Fri, 4 Feb 2005 13:37:17 +0100 (CET) Subject: Joel Grotz is out of office. From: Joel.Grotz@ses-astra.com To: ipdvb@erg.abdn.ac.uk Message-ID: Date: Fri, 4 Feb 2005 13:37:15 +0100 X-MIMETrack: Serialize by Router on marge/BTZ(Release 6.5.3FP1|December 15, 2004) at 04/02/2005 13:37:17 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 0.3 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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 owner-ipdvb@erg.abdn.ac.uk Fri Feb 4 10:00:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03169 for ; Fri, 4 Feb 2005 10:00:25 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cx5FP-0003hr-7c for ipdvb-archive@ietf.org; Fri, 04 Feb 2005 10:19:53 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j14Ecbpc004774 for ; Fri, 4 Feb 2005 14:38:37 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j14Ecb6b004773 for ipdvb-subscribed-users; Fri, 4 Feb 2005 14:38:37 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from nab.org (foxtrot.nab.org [209.116.240.194]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j14EbQik004741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 4 Feb 2005 14:37:31 GMT Received: from ([199.29.3.1]) by maildc2.nab.org with ESMTP id 4028857.3808218; Thu, 03 Feb 2005 09:35:44 -0500 Received: by mail.NAB.ORG with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Feb 2005 09:35:44 -0500 Message-ID: From: "Allison, Art" To: "'ipdvb@erg.abdn.ac.uk'" Cc: "'Carsten Bormann'" Subject: RE: LLC support in DVB , ATSC, MPEG-2? Date: Thu, 3 Feb 2005 09:35:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a 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@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On Behalf Of Gorry Fairhurst Sent: Monday, January 31, 2005 8:17 AM To: ipdvb@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 owner-ipdvb@erg.abdn.ac.uk Fri Feb 4 17:37:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14811 for ; Fri, 4 Feb 2005 17:37:52 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxCOB-0006fE-NR for ipdvb-archive@ietf.org; Fri, 04 Feb 2005 17:57:25 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j14M9Z0E014655 for ; Fri, 4 Feb 2005 22:09:35 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j14M9ZOG014654 for ipdvb-subscribed-users; Fri, 4 Feb 2005 22:09:35 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from sharplabs.com (keymaster.sharplabs.com [216.65.151.107]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j14M8dM6014623 for ; Fri, 4 Feb 2005 22:08:41 GMT Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j14M8Vvb029574; Fri, 4 Feb 2005 14:08:31 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <1B764V33>; Fri, 4 Feb 2005 14:09:22 -0800 Message-ID: <08259490B3BC3140B549DD0907A5644811D638@admsrvnt10.enet.sharplabs.com> From: "Goldberg, Adam" To: ipdvb@erg.abdn.ac.uk, Bernhard Collini-Nocker Cc: "AAllison@nab.org" , Matthew Goldman Subject: RE: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto rs Date: Fri, 4 Feb 2005 14:09:11 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc 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@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On Behalf Of Gorry Fairhurst Sent: Friday, February 04, 2005 6:56 AM To: ipdvb@erg.abdn.ac.uk; Bernhard Collini-Nocker Cc: AAllison@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 owner-ipdvb@erg.abdn.ac.uk Sun Feb 6 09:39:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26213 for ; Sun, 6 Feb 2005 09:39:18 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxnsU-0006g1-GB for ipdvb-archive@ietf.org; Sun, 06 Feb 2005 09:59:11 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j16E57sM024243 for ; Sun, 6 Feb 2005 14:05:07 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j16E5726024242 for ipdvb-subscribed-users; Sun, 6 Feb 2005 14:05:07 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from loewe.cosy.sbg.ac.at (loewe.cosy.sbg.ac.at [141.201.2.12]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j16E4ZjP024225 for ; Sun, 6 Feb 2005 14:04:35 GMT Received: from [127.0.0.1] (milbe.cosy.sbg.ac.at [141.201.2.21]) by loewe.cosy.sbg.ac.at (8.8.8/8.8.7) with ESMTP id PAA07436; Sun, 6 Feb 2005 15:04:29 +0100 (MET) Message-ID: <420623C9.50005@cosy.sbg.ac.at> Date: Sun, 06 Feb 2005 15:03:53 +0100 From: Bernhard Collini-Nocker User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Goldberg, Adam" CC: ipdvb@erg.abdn.ac.uk, "AAllison@nab.org" , Matthew Goldman Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto rs References: <08259490B3BC3140B549DD0907A5644811D638@admsrvnt10.enet.sharplabs.com> In-Reply-To: <08259490B3BC3140B549DD0907A5644811D638@admsrvnt10.enet.sharplabs.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d Content-Transfer-Encoding: 7bit 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@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On > Behalf Of Gorry Fairhurst > Sent: Friday, February 04, 2005 6:56 AM > To: ipdvb@erg.abdn.ac.uk; Bernhard Collini-Nocker > Cc: AAllison@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 owner-ipdvb@erg.abdn.ac.uk Mon Feb 7 01:12:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06761 for ; Mon, 7 Feb 2005 01:12:09 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cy2RN-0007vw-7k for ipdvb-archive@ietf.org; Mon, 07 Feb 2005 01:32:10 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j175gOlj009685 for ; Mon, 7 Feb 2005 05:42:24 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j175gOcq009684 for ipdvb-subscribed-users; Mon, 7 Feb 2005 05:42:24 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from sharplabs.com (keymaster.sharplabs.com [216.65.151.107]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j175f9VC009643 for ; Mon, 7 Feb 2005 05:41:11 GMT Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j175ex0Q013563; Sun, 6 Feb 2005 21:40:59 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <1B76VJ4B>; Sun, 6 Feb 2005 21:41:39 -0800 Message-ID: <08259490B3BC3140B549DD0907A5644811D663@admsrvnt10.enet.sharplabs.com> From: "Goldberg, Adam" To: Bernhard Collini-Nocker , "Goldberg, Adam" Cc: ipdvb@erg.abdn.ac.uk, "Allison, Art" , Matthew Goldman Subject: RE: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto rs Date: Sun, 6 Feb 2005 21:41:35 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by erg.abdn.ac.uk id j175gOlj009685 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4166dd0e0c668adc975c3d3e0f1bce3b Content-Transfer-Encoding: quoted-printable 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 =20 Bernhard Collini-Nocker wrote: >=20 > 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). >=20 > 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 usin= g > one specific packet identifier to transport subnetwork data units. Mayb= e > the term "TS (virtual) circuit" better names this? It is perhaps not well defined in 13818-1, but the term of art is "stream= s". Many people use "PID stream" which is a poor combination of words. I'd h= ave 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 som= e such). Perhaps discussing 'virtual circuits' relative to a Transport Stream is begging for confusion. Use of any such words ("TS (virtual) circuit") ne= eds careful definition, likely requiring the above SNDU Stream definition plu= s 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 D= VB > use > > of "specific TS Logical Channels". To my knowledge, this internet-dr= aft > is > > the only document anywhere which uses such terms. It is certainly tr= ue > 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. >=20 > 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 stre= am 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? >=20 > 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. >=20 > "The delivery of the bits in time through a data pipe is service privat= e > 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 no= t > detailed at all, whereas ULE tries to be. I'm not going to argue that DVB's specification is complete. I will argu= e 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 t= o > > MPEG-2, some TS Logical Channels are reserved for specific > > signalling purposes. Other standards (e.g., ATSC, DVB) also reserv= e > > 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" - whic= h > are > > the subject of a large amount of ATSC and DVB systems. >=20 > 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-=E0-vis networking has a different meanin= g than 'channel' vis-=E0-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 us= ed > > within MPEG (unless what you really mean is elementary stream, in whi= ch > case > > what do you need this extraneous term for anyhow?). >=20 > 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 mak= e > up an event, e.g. video, audio, teletext" >=20 > 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" >=20 > where: > "component_type: This 8-bit field specifies the type of the video, audi= o > or EBU-data component. The coding of this field is specified in table 2= 6." > Table 26 then lists all kinds of video, audio, and teletext formats, bu= t > unfortunately no networking formats. >=20 > 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? >=20 > > 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. >=20 > Oh yes, this is the real problem of defining something outside > television standardiszation bodies: one risks that ULE packets are bein= g > 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=20 > > 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 entertainme= nt > > (which is to say, legacy use of MPEG-2 Transport) point of view. >=20 > 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. >=20 > > [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@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] = On > > Behalf Of Gorry Fairhurst > > Sent: Friday, February 04, 2005 6:56 AM > > To: ipdvb@erg.abdn.ac.uk; Bernhard Collini-Nocker > > Cc: AAllison@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/a= nd > 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 f= or > > those > > networks that rely on PSI for remultiplexing! > > > > - Bernhard & others who understand PSI, can you work with Art to agre= e > 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 w= as > >>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 conta= ins > >>two definitions of PSI. I suggest the second should be deleted. > >> > > > > 2) > > > >>I previously made a comment about the ancillary requirements when add= ing > a > >>TS logical channel to a TS multiplex and asserted there appeared to b= e > >>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. >=20 > 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? >=20 > >>I suggest at least an informative note be added in Section 6 (after t= he > >>third line which says: "These are transmitted using a single TS Logic= al > >>Channel over a TS Multiplex.") The note should say "PSI entries to be > >>consistent with [ISO-MPEG] when constructing a conformant TS Multiple= x > and > >>means for Receivers to locate each such TS Logical Channel are outsid= e > the > >>scope of this recommendation." >=20 > Thanks, this is a very helpful suggestion for potential readers. In > addition the ipdvb-wg works on providing signalling other than PSI/SI. >=20 > >>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; a= nd > >> 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 woul= d > 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. >=20 > From an architectural point of view it is a reasonable assupmption tha= t > 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. >=20 > What is the penalty for not being strictly MPEG-2 conformant/compliant? >=20 > >>Art Allison > >>Director, Advanced Engineering > >>NAB Science & Technology > >>1771 N St NW, Washington Dc 20036 > >>202 429 5418 >=20 >=20 > Regards, > Bernhard Collini-Nocker >=20 >=20 From owner-ipdvb@erg.abdn.ac.uk Mon Feb 7 01:12:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06833 for ; Mon, 7 Feb 2005 01:12:36 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cy2Ro-0007w0-83 for ipdvb-archive@ietf.org; Mon, 07 Feb 2005 01:32:37 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j175johe009752 for ; Mon, 7 Feb 2005 05:45:50 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j175josD009751 for ipdvb-subscribed-users; Mon, 7 Feb 2005 05:45:50 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from sharplabs.com (keymaster.sharplabs.com [216.65.151.107]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j175jIZa009735 for ; Mon, 7 Feb 2005 05:45:18 GMT Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j175j9nc013745; Sun, 6 Feb 2005 21:45:09 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <1B76VJVA>; Sun, 6 Feb 2005 21:45:50 -0800 Message-ID: <08259490B3BC3140B549DD0907A5644811D664@admsrvnt10.enet.sharplabs.com> From: "Goldberg, Adam" To: "Goldberg, Adam" , Bernhard Collini-Nocker Cc: ipdvb@erg.abdn.ac.uk, "Allison, Art" , Matthew Goldman Subject: RE: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto rs Date: Sun, 6 Feb 2005 21:45:46 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by erg.abdn.ac.uk id j175johe009752 X-Spam-Score: 0.0 (/) X-Scan-Signature: e3ebaaff3b3539efaf29ef65eea2aded Content-Transfer-Encoding: quoted-printable 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 =20 > -----Original Message----- > From: Goldberg, Adam > Sent: Monday, February 07, 2005 12:42 AM > To: 'Bernhard Collini-Nocker'; Goldberg, Adam > Cc: ipdvb@erg.abdn.ac.uk; Allison, Art; Matthew Goldman > Subject: RE: Forward from Art Alison: WGLC ULE - Data Broadcast Descrip= to > rs >=20 > See below... >=20 > 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 >=20 >=20 > 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 A= rt > > 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 f= or > > 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 us= ing > > one specific packet identifier to transport subnetwork data units. Ma= ybe > > the term "TS (virtual) circuit" better names this? >=20 > 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 com= mon > PID value" (or some such). >=20 > 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 Strea= ms > to exist in a single Transport Stream. >=20 > > > 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", bu= t > it > > is > > > difficult for me to tell. > > > > I am not so sure, whether this analysis is correct. Elementary stream= s > > are those that are transported as Packetized ES, whereas "auxillary" > > data and signalling is transported as sections. Although a stream_typ= e > > in the program map section is used to reference both PESs and section= s > > the term elementary stream is used very vague and we tried to avoid > > using it in the same vague manner. >=20 > Perhaps I overstepped with "elementary stream". >=20 > 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) >=20 > Stuff carried as payload of Transport Stream packets are merely 'payloa= d'. > What the draft starts to define is a new type of payload stream (that i= s, > a new way to carry data in a transport stream). The definition is not > compete. >=20 > > 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 T= S > > 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 sha= ll > > 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 priv= ate > > and is not specified in the present document." > > It seems obvious that the use of the term "TS Data Pipe" would lead t= o > > the wrong conclusion that ULE equals Data Piping. But Data Piping is = not > > detailed at all, whereas ULE tries to be. >=20 > I'm not going to argue that DVB's specification is complete. I will ar= gue > that ULE isn't complete. >=20 > > > (from the draft) > > > TS Logical Channel: Transport Stream Logical Channel. In this > > > document, this term identifies a channel at the MPEG-2 level [IS= O- > > > 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 rese= rve > > > 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 conceivabl= e > > that > > > the reader may associate "channel" with "[television] channel" - wh= ich > > 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 an= d > > 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- o= r > > time-division multiplexing. ..." >=20 > I understand that 'channel' vis-=E0-vis networking has a different mean= ing > than 'channel' vis-=E0-vis television. This was my point actually, tha= t > those familiar with MPEG transport should not be assumed to be networki= ng- > types (even when speaking with respect to ULE). >=20 > > > Additionally, it is also wrong or ill-specified to say "According t= o > > 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 m= ake > > 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, au= dio > > 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 valu= e > > 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 be= ing > > 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. >=20 > 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. >=20 > ATSC maintains a 'codepoint registry', and would be happy to allocate a > stream_type value for ULE data upon request from IETF. Furthermore, th= e > text to specify usage of the stream_type would be reasonably easy (and > perhaps ties in to my suggested "SNDU Stream" definition (that is, defi= ne > 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 Strea= m per program, or more than one Program that carries one or more SNDU Strea= ms. > > > If there remains an opportunity to repair what I believe to be erro= rs > 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 b= e > > 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@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk= ] > On > > > Behalf Of Gorry Fairhurst > > > Sent: Friday, February 04, 2005 6:56 AM > > > To: ipdvb@erg.abdn.ac.uk; Bernhard Collini-Nocker > > > Cc: AAllison@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 a= t > the > > end > > > > > > of the Introduction (1.0) to the whole document, where people can s= ee > 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 ag= ree > > 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 li= st > > >>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 Channe= l" > 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 wh= y > > 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 Multip= lex > > and > > >>means for Receivers to locate each such TS Logical Channel are outs= ide > > 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 no= t > > >> 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 wo= uld > > be > > >>more helpful than this warning. It seems at least a warning is need= ed > > 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 t= hat > > whatever is being sent in a TS multiplex should be referenced. Howeve= r, > > 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/complian= t? > > > > >>Art Allison > > >>Director, Advanced Engineering > > >>NAB Science & Technology > > >>1771 N St NW, Washington Dc 20036 > > >>202 429 5418 > > > > > > Regards, > > Bernhard Collini-Nocker > > > > From owner-ipdvb@erg.abdn.ac.uk Mon Feb 7 08:25:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27354 for ; Mon, 7 Feb 2005 08:25:28 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cy9Cj-0000BV-QH for ipdvb-archive@ietf.org; Mon, 07 Feb 2005 08:45:32 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j17Co1AG018232 for ; Mon, 7 Feb 2005 12:50:01 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j17Co1hO018229 for ipdvb-subscribed-users; Mon, 7 Feb 2005 12:50:01 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from loewe.cosy.sbg.ac.at (loewe.cosy.sbg.ac.at [141.201.2.12]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j17CnIIJ018207 for ; Mon, 7 Feb 2005 12:49:22 GMT Received: from [127.0.0.1] (milbe.cosy.sbg.ac.at [141.201.2.21]) by loewe.cosy.sbg.ac.at (8.8.8/8.8.7) with ESMTP id NAA01314; Mon, 7 Feb 2005 13:49:17 +0100 (MET) Message-ID: <420763AB.50107@cosy.sbg.ac.at> Date: Mon, 07 Feb 2005 13:48:43 +0100 From: Bernhard Collini-Nocker User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk CC: "Goldberg, Adam" , "Allison, Art" , Matthew Goldman Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto rs References: <08259490B3BC3140B549DD0907A5644811D664@admsrvnt10.enet.sharplabs.com> In-Reply-To: <08259490B3BC3140B549DD0907A5644811D664@admsrvnt10.enet.sharplabs.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by erg.abdn.ac.uk id j17Co1AG018232 X-Spam-Score: 0.0 (/) X-Scan-Signature: ee8eaa76ea6a4fb3ccc9059a3f656ffc Content-Transfer-Encoding: quoted-printable Hello, let me try to summarize the two major points being raised and what the=20 discussion is about: 1. the name/definition of "TS Logical Channel" is not well received and=20 the name/definition of a "SNDU stream" is proposed instead 2. it is proposed to consider MPEG-2 conformance in specifying that ULE=20 requires a specific stream_type value for the PMT Personally I have no objection against 1., because it is easy to change=20 and improves wording and naming (unless somebody has an even better=20 name for it). For 2. my concern is that mentioning stream_type may require some=20 additional wording about PSI/SI in general, which is likely out of scope=20 of the ULE draft. Even worse, in introducing a "world" besides the=20 encapsulation/decapsulation of ULE, this may result in further confusion=20 about what the MPEG-2/Section layer does in addition to and/or in=20 comparison to ULE/IP. Actually some difficult question may arise from=20 this direction, for example whether it is a wishful requirement for ULE=20 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. >=20 > 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 > =20 >=20 >=20 >>-----Original Message----- >>From: Goldberg, Adam >>Sent: Monday, February 07, 2005 12:42 AM >>To: 'Bernhard Collini-Nocker'; Goldberg, Adam >>Cc: ipdvb@erg.abdn.ac.uk; Allison, Art; Matthew Goldman >>Subject: RE: Forward from Art Alison: WGLC ULE - Data Broadcast Descrip= to >>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 >=20 > Channel", >=20 >>>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 fo= r >>>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 usi= ng >>>one specific packet identifier to transport subnetwork data units. May= be >>>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 com= mon >>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 Strea= ms >>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 'payloa= d'. >>What the draft starts to define is a new type of payload stream (that i= s, >>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 shal= l >>>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 priva= te >>>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 n= ot >>>detailed at all, whereas ULE tries to be. >> >>I'm not going to argue that DVB's specification is complete. I will ar= gue >>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 t= o >>>> MPEG-2, some TS Logical Channels are reserved for specific >>>> signalling purposes. Other standards (e.g., ATSC, DVB) also reserv= e >>>> 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" - whic= h >>> >>>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-=E0-vis networking has a different mean= ing >>than 'channel' vis-=E0-vis television. This was my point actually, tha= t >>those familiar with MPEG transport should not be assumed to be networki= ng- >>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 ma= ke >>>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, aud= io >>>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, b= ut >>>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 bei= ng >>>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, th= e >>text to specify usage of the stream_type would be reasonably easy (and >>perhaps ties in to my suggested "SNDU Stream" definition (that is, defi= ne >>it as >=20 >=20 > SNDU Stream: a sequence of MPEG-2 Transport Stream packets identified b= y a > common PID value of stream_type <0xnn>. >=20 > All that then remains, I think, would be to signal when a Program carri= es > SNDU Stream(s), and what it means when there are more than one SNDU Str= eam > per program, or more than one Program that carries one or more SNDU Str= eams. >=20 >=20 >>>>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 i= n >>>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@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] >> >>On >> >>>>Behalf Of Gorry Fairhurst >>>>Sent: Friday, February 04, 2005 6:56 AM >>>>To: ipdvb@erg.abdn.ac.uk; Bernhard Collini-Nocker >>>>Cc: AAllison@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 agre= e >>> >>>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 lis= t >>>>>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 b= e >>>>>consistent with [ISO-MPEG] when constructing a conformant TS Multipl= ex >>> >>>and >>> >>>>>means for Receivers to locate each such TS Logical Channel are outsi= de >>> >>>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 wou= ld >>> >>>be >>> >>>>>more helpful than this warning. It seems at least a warning is neede= d >>> >>>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 th= at >>>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 >>> >>> >=20 >=20 From owner-ipdvb@erg.abdn.ac.uk Mon Feb 7 10:38:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09433 for ; Mon, 7 Feb 2005 10:38:30 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyBHM-00037p-0u for ipdvb-archive@ietf.org; Mon, 07 Feb 2005 10:58:25 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j17Du6K5020043 for ; Mon, 7 Feb 2005 13:56:06 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j17Du5XL020042 for ipdvb-subscribed-users; Mon, 7 Feb 2005 13:56:06 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j17Ds5dT019997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 7 Feb 2005 13:54:06 GMT Message-ID: <420772FE.7050201@erg.abdn.ac.uk> Date: Mon, 07 Feb 2005 13:54:06 +0000 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk CC: "Goldberg, Adam" , "Allison, Art" , Matthew Goldman Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto rs References: <08259490B3BC3140B549DD0907A5644811D664@admsrvnt10.enet.sharplabs.com> <420763AB.50107@cosy.sbg.ac.at> In-Reply-To: <420763AB.50107@cosy.sbg.ac.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by erg.abdn.ac.uk id j17Du6K5020043 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0807e85f6792b2e267100df15b13cd9b Content-Transfer-Encoding: quoted-printable So.... 1. The term "TS Logical Channel" was discussed a lot at the begining of t= he=20 WG. As I recall, the reason for the new term, was that at this time the W= G=20 could not find a suitably "unbiased" term for the set of TS Packets with = a=20 common PID value (raw TS, DSMCC, Private Section, PES, etc). One key obje= ctive=20 was to find a term that did not carry extra semantics, and was understand= able=20 by the networking community - this is after all intended as a part of the= =20 RFC-series, and we need to make this accessible to people familiar with u= sing=20 IP over Ethernet, MPLS, ATM, Fibre Channel, Firewire, SDH/SONET, etc. T we shoudl note that the term "TS Logical Channel term already appears (an= d is=20 discussed in some detail) in the document draft-ietf-ipvb-arch-xx.txt and= that=20 this HAS already complete WGLC. If it IS WRONG we still have a chance to= fix=20 the definition/term, if we have to. Specifically, is there already a=20 well-accepted term for the set of TS Packets with a common PID value (raw= TS,=20 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=20 that helps to describe the set of TS packets with a specific PID used for= ULE,=20 especially when talking about PSI. Bernhard, is there an opportunity of inserting a simple statement as the = final=20 paragraph of the introduction which says that to use ULE streams within a= n=20 MPEG-2 compliant multiplex may require appropriate PSI entries... I think= Art=20 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 g= reat=20 advantage in assigning a descriptor for this in ATSC. I think the WG SHOU= LD=20 should explore this at the next stage. Gorry Bernhard Collini-Nocker wrote: > Hello, >=20 > let me try to summarize the two major points being raised and what the=20 > discussion is about: > 1. the name/definition of "TS Logical Channel" is not well received and= =20 > the name/definition of a "SNDU stream" is proposed instead > 2. it is proposed to consider MPEG-2 conformance in specifying that ULE= =20 > requires a specific stream_type value for the PMT >=20 > Personally I have no objection against 1., because it is easy to change= =20 > and improves wording and naming (unless somebody has an even better=20 > name for it). > For 2. my concern is that mentioning stream_type may require some=20 > additional wording about PSI/SI in general, which is likely out of scop= e=20 > of the ULE draft. Even worse, in introducing a "world" besides the=20 > encapsulation/decapsulation of ULE, this may result in further confusio= n=20 > about what the MPEG-2/Section layer does in addition to and/or in=20 > comparison to ULE/IP. Actually some difficult question may arise from=20 > this direction, for example whether it is a wishful requirement for ULE= =20 > to support PAT/PMT/NIT/INT/... table parsing? >=20 > Any opinions, recommendations or suggestions about this? >=20 > Regards, > Bernhard >=20 > Goldberg, Adam wrote: >=20 >> 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 >> =20 >> >> >>> -----Original Message----- >>> From: Goldberg, Adam >>> Sent: Monday, February 07, 2005 12:42 AM >>> To: 'Bernhard Collini-Nocker'; Goldberg, Adam >>> Cc: ipdvb@erg.abdn.ac.uk; Allison, Art; Matthew Goldman >>> Subject: RE: Forward from Art Alison: WGLC ULE - Data Broadcast=20 >>> 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 A= rt >>>> >>>> >>>> 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=20 >>>> using >>>> one specific packet identifier to transport subnetwork data units.=20 >>>> 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 somethin= g >>> like "a sequence of MPEG-2 Transport Stream packets identified by a=20 >>> 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=20 >>> 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", bu= t >>> >>> >>> it >>> >>>> is >>>> >>>>> difficult for me to tell. >>>> >>>> >>>> I am not so sure, whether this analysis is correct. Elementary strea= ms >>>> are those that are transported as Packetized ES, whereas "auxillary" >>>> data and signalling is transported as sections. Although a stream_ty= pe >>>> in the program map section is used to reference both PESs and sectio= ns >>>> 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=20 >>> 13818-1:2000 p. >>> xiii) >>> >>> Stuff carried as payload of Transport Stream packets are merely=20 >>> 'payload'. >>> What the draft starts to define is a new type of payload stream (that= =20 >>> is, >>> a new way to carry data in a transport stream). The definition is no= t >>> 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 Strea= m >>>> packets in a service private way. The use of the adaptation_field sh= all >>>> 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=20 >>>> 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= =20 >>>> not >>>> detailed at all, whereas ULE tries to be. >>> >>> >>> I'm not going to argue that DVB's specification is complete. I will=20 >>> 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 reser= ve >>>>> 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 conceivabl= e >>>> >>>> >>>> that >>>> >>>>> the reader may associate "channel" with "[television] channel" - wh= ich >>>> >>>> >>>> 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 abou= t >>>> what a channel is. >>>> According to ATIS a channel is "1. A connection between initiating a= nd >>>> 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-=E0-vis networking has a different me= aning >>> than 'channel' vis-=E0-vis television. This was my point actually, t= hat >>> those familiar with MPEG transport should not be assumed to be=20 >>> networking- >>> types (even when speaking with respect to ULE). >>> >>> >>>>> Additionally, it is also wrong or ill-specified to say "According t= o >>>> >>>> >>>> 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=20 >>>> make >>>> up an event, e.g. video, audio, teletext" >>>> >>>> and says further: >>>> "The component descriptor identifies the type of component stream an= d >>>> 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,=20 >>>> audio >>>> or EBU-data component. The coding of this field is specified in tabl= e >>> >>> >>> 26." >>> >>>> Table 26 then lists all kinds of video, audio, and teletext formats,= =20 >>>> 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 b= y >>>> 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 valu= e >>>> >>>> >>>> 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=20 >>>> being >>>> dropped. >>>> We have discussed basically two approaches: >>>> 1. define the PSI and get an ID, or tag, or "stream_type" for ULE,=20 >>>> 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 t= o >>> 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 (an= d >>> perhaps ties in to my suggested "SNDU Stream" definition (that is,=20 >>> define >>> it as >> >> >> >> SNDU Stream: a sequence of MPEG-2 Transport Stream packets identified=20 >> by a >> common PID value of stream_type <0xnn>. >> >> All that then remains, I think, would be to signal when a Program carr= ies >> SNDU Stream(s), and what it means when there are more than one SNDU=20 >> Stream >> per program, or more than one Program that carries one or more SNDU=20 >> Streams. >> >> >>>>> If there remains an opportunity to repair what I believe to be erro= rs >>> >>> >>> 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@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk= ] >>> >>> >>> On >>> >>>>> Behalf Of Gorry Fairhurst >>>>> Sent: Friday, February 04, 2005 6:56 AM >>>>> To: ipdvb@erg.abdn.ac.uk; Bernhard Collini-Nocker >>>>> Cc: AAllison@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 a= t >>> >>> >>> the >>> >>>> end >>>> >>>>> of the Introduction (1.0) to the whole document, where people can s= ee >>> >>> >>> 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 ag= ree >>>> >>>> >>>> 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, bu= t >>> >>> >>> was >>> >>>>>> dropped because the email source address was not verified by the l= ist >>>>>> 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=20 >>>>>> 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 Chann= el" >>> >>> >>> 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 w= hy >>>> 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 (afte= r >>> >>> >>> 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=20 >>>>>> Multiplex >>>> >>>> >>>> and >>>> >>>>>> means for Receivers to locate each such TS Logical Channel are=20 >>>>>> 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/S= I. >>>> >>>> >>>>>> Reason: >>>>>> Just inserting a "TS Logical Channel" without including a >>>>>> TS_Program_map_section that lists the PID and a stream_type does n= ot >>>>>> 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 th= e >>>> >>>> >>>> means >>>> >>>>>> for binding the inserted element into a multiplex and subsequent >>>> >>>> >>>> discovery >>>> >>>>>> is to be covered in another document, a pointer to that document=20 >>>>>> would >>>> >>>> >>>> be >>>> >>>>>> more helpful than this warning. It seems at least a warning is nee= ded >>>> >>>> >>>> and >>>> >>>>>> preferably a pointer to where this next level of TS construction i= s >>>>>> defined. >>>> >>>> >>>> From an architectural point of view it is a reasonable assupmption t= hat >>>> whatever is being sent in a TS multiplex should be referenced. Howev= er, >>>> 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/complia= nt? >>>> >>>> >>>>>> Art Allison >>>>>> Director, Advanced Engineering >>>>>> NAB Science & Technology >>>>>> 1771 N St NW, Washington Dc 20036 >>>>>> 202 429 5418 >>>> >>>> >>>> >>>> Regards, >>>> Bernhard Collini-Nocker >>>> >>>> >> >> >=20 >=20 From owner-ipdvb@erg.abdn.ac.uk Mon Feb 7 11:14:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13237 for ; Mon, 7 Feb 2005 11:14:54 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyBqn-00044M-2P for ipdvb-archive@ietf.org; Mon, 07 Feb 2005 11:35:02 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j17Fdx8S022667 for ; Mon, 7 Feb 2005 15:39:59 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j17FdwaF022666 for ipdvb-subscribed-users; Mon, 7 Feb 2005 15:39:58 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j17Fbm7w022586 for ; Mon, 7 Feb 2005 15:37:49 GMT Received: from i2km99-ukbr.domain1.systemhost.net ([193.113.197.31]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.80); Mon, 7 Feb 2005 15:39:21 +0000 Received: from i2km04-ukbr.domain1.systemhost.net ([193.113.197.80]) by i2km99-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 7 Feb 2005 15:39:21 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto rs Date: Mon, 7 Feb 2005 15:39:21 -0000 Message-ID: <981038F72E40E04D8F80A194E5F7102B0E2B3D84@i2km04-ukbr.domain1.systemhost.net> Thread-Topic: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto rs Thread-Index: AcUNKozzC/gwF3eaTcWY0uigWKkRrAAAC4Rw From: To: X-OriginalArrivalTime: 07 Feb 2005 15:39:21.0541 (UTC) FILETIME=[3183E750:01C50D2B] X-ERG-MailScanner: Found to be clean, Found to be clean X-MIME-Autoconverted: from quoted-printable to 8bit by erg.abdn.ac.uk id j17FdsJP022661 Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by erg.abdn.ac.uk id j17Fdx8S022667 X-Spam-Score: 0.3 (/) X-Scan-Signature: 5a5294b34f62cf4aba63c62e30e627ff Content-Transfer-Encoding: quoted-printable Gorry, could you unsubscribe me from this list. I'm not really doing thi= s now. Dave -----Original Message----- From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk]On Behalf Of Gorry Fairhurst Sent: 07 February 2005 13:54 To: ipdvb@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 t= he=20 WG. As I recall, the reason for the new term, was that at this time the W= G=20 could not find a suitably "unbiased" term for the set of TS Packets with = a=20 common PID value (raw TS, DSMCC, Private Section, PES, etc). One key obje= ctive=20 was to find a term that did not carry extra semantics, and was understand= able=20 by the networking community - this is after all intended as a part of the= =20 RFC-series, and we need to make this accessible to people familiar with u= sing=20 IP over Ethernet, MPLS, ATM, Fibre Channel, Firewire, SDH/SONET, etc. T we shoudl note that the term "TS Logical Channel term already appears (an= d is=20 discussed in some detail) in the document draft-ietf-ipvb-arch-xx.txt and= that=20 this HAS already complete WGLC. If it IS WRONG we still have a chance to= fix=20 the definition/term, if we have to. Specifically, is there already a=20 well-accepted term for the set of TS Packets with a common PID value (raw= TS,=20 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=20 that helps to describe the set of TS packets with a specific PID used for= ULE,=20 especially when talking about PSI. Bernhard, is there an opportunity of inserting a simple statement as the = final=20 paragraph of the introduction which says that to use ULE streams within a= n=20 MPEG-2 compliant multiplex may require appropriate PSI entries... I think= Art=20 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 g= reat=20 advantage in assigning a descriptor for this in ATSC. I think the WG SHOU= LD=20 should explore this at the next stage. Gorry Bernhard Collini-Nocker wrote: > Hello, >=20 > let me try to summarize the two major points being raised and what the=20 > discussion is about: > 1. the name/definition of "TS Logical Channel" is not well received and= =20 > the name/definition of a "SNDU stream" is proposed instead > 2. it is proposed to consider MPEG-2 conformance in specifying that ULE= =20 > requires a specific stream_type value for the PMT >=20 > Personally I have no objection against 1., because it is easy to change= =20 > and improves wording and naming (unless somebody has an even better=20 > name for it). > For 2. my concern is that mentioning stream_type may require some=20 > additional wording about PSI/SI in general, which is likely out of scop= e=20 > of the ULE draft. Even worse, in introducing a "world" besides the=20 > encapsulation/decapsulation of ULE, this may result in further confusio= n=20 > about what the MPEG-2/Section layer does in addition to and/or in=20 > comparison to ULE/IP. Actually some difficult question may arise from=20 > this direction, for example whether it is a wishful requirement for ULE= =20 > to support PAT/PMT/NIT/INT/... table parsing? >=20 > Any opinions, recommendations or suggestions about this? >=20 > Regards, > Bernhard >=20 > Goldberg, Adam wrote: >=20 >> 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 >> =20 >> >> >>> -----Original Message----- >>> From: Goldberg, Adam >>> Sent: Monday, February 07, 2005 12:42 AM >>> To: 'Bernhard Collini-Nocker'; Goldberg, Adam >>> Cc: ipdvb@erg.abdn.ac.uk; Allison, Art; Matthew Goldman >>> Subject: RE: Forward from Art Alison: WGLC ULE - Data Broadcast=20 >>> 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 A= rt >>>> >>>> >>>> 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=20 >>>> using >>>> one specific packet identifier to transport subnetwork data units.=20 >>>> 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 somethin= g >>> like "a sequence of MPEG-2 Transport Stream packets identified by a=20 >>> 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=20 >>> 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", bu= t >>> >>> >>> it >>> >>>> is >>>> >>>>> difficult for me to tell. >>>> >>>> >>>> I am not so sure, whether this analysis is correct. Elementary strea= ms >>>> are those that are transported as Packetized ES, whereas "auxillary" >>>> data and signalling is transported as sections. Although a stream_ty= pe >>>> in the program map section is used to reference both PESs and sectio= ns >>>> 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=20 >>> 13818-1:2000 p. >>> xiii) >>> >>> Stuff carried as payload of Transport Stream packets are merely=20 >>> 'payload'. >>> What the draft starts to define is a new type of payload stream (that= =20 >>> is, >>> a new way to carry data in a transport stream). The definition is no= t >>> 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 Strea= m >>>> packets in a service private way. The use of the adaptation_field sh= all >>>> 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=20 >>>> 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= =20 >>>> not >>>> detailed at all, whereas ULE tries to be. >>> >>> >>> I'm not going to argue that DVB's specification is complete. I will=20 >>> 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 reser= ve >>>>> 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 conceivabl= e >>>> >>>> >>>> that >>>> >>>>> the reader may associate "channel" with "[television] channel" - wh= ich >>>> >>>> >>>> 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 abou= t >>>> what a channel is. >>>> According to ATIS a channel is "1. A connection between initiating a= nd >>>> 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-=E0-vis networking has a different me= aning >>> than 'channel' vis-=E0-vis television. This was my point actually, t= hat >>> those familiar with MPEG transport should not be assumed to be=20 >>> networking- >>> types (even when speaking with respect to ULE). >>> >>> >>>>> Additionally, it is also wrong or ill-specified to say "According t= o >>>> >>>> >>>> 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=20 >>>> make >>>> up an event, e.g. video, audio, teletext" >>>> >>>> and says further: >>>> "The component descriptor identifies the type of component stream an= d >>>> 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,=20 >>>> audio >>>> or EBU-data component. The coding of this field is specified in tabl= e >>> >>> >>> 26." >>> >>>> Table 26 then lists all kinds of video, audio, and teletext formats,= =20 >>>> 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 b= y >>>> 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 valu= e >>>> >>>> >>>> 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=20 >>>> being >>>> dropped. >>>> We have discussed basically two approaches: >>>> 1. define the PSI and get an ID, or tag, or "stream_type" for ULE,=20 >>>> 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 t= o >>> 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 (an= d >>> perhaps ties in to my suggested "SNDU Stream" definition (that is,=20 >>> define >>> it as >> >> >> >> SNDU Stream: a sequence of MPEG-2 Transport Stream packets identified=20 >> by a >> common PID value of stream_type <0xnn>. >> >> All that then remains, I think, would be to signal when a Program carr= ies >> SNDU Stream(s), and what it means when there are more than one SNDU=20 >> Stream >> per program, or more than one Program that carries one or more SNDU=20 >> Streams. >> >> >>>>> If there remains an opportunity to repair what I believe to be erro= rs >>> >>> >>> 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@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk= ] >>> >>> >>> On >>> >>>>> Behalf Of Gorry Fairhurst >>>>> Sent: Friday, February 04, 2005 6:56 AM >>>>> To: ipdvb@erg.abdn.ac.uk; Bernhard Collini-Nocker >>>>> Cc: AAllison@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 a= t >>> >>> >>> the >>> >>>> end >>>> >>>>> of the Introduction (1.0) to the whole document, where people can s= ee >>> >>> >>> 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 ag= ree >>>> >>>> >>>> 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, bu= t >>> >>> >>> was >>> >>>>>> dropped because the email source address was not verified by the l= ist >>>>>> 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=20 >>>>>> 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 Chann= el" >>> >>> >>> 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 w= hy >>>> 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 (afte= r >>> >>> >>> 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=20 >>>>>> Multiplex >>>> >>>> >>>> and >>>> >>>>>> means for Receivers to locate each such TS Logical Channel are=20 >>>>>> 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/S= I. >>>> >>>> >>>>>> Reason: >>>>>> Just inserting a "TS Logical Channel" without including a >>>>>> TS_Program_map_section that lists the PID and a stream_type does n= ot >>>>>> 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 th= e >>>> >>>> >>>> means >>>> >>>>>> for binding the inserted element into a multiplex and subsequent >>>> >>>> >>>> discovery >>>> >>>>>> is to be covered in another document, a pointer to that document=20 >>>>>> would >>>> >>>> >>>> be >>>> >>>>>> more helpful than this warning. It seems at least a warning is nee= ded >>>> >>>> >>>> and >>>> >>>>>> preferably a pointer to where this next level of TS construction i= s >>>>>> defined. >>>> >>>> >>>> From an architectural point of view it is a reasonable assupmption t= hat >>>> whatever is being sent in a TS multiplex should be referenced. Howev= er, >>>> 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/complia= nt? >>>> >>>> >>>>>> Art Allison >>>>>> Director, Advanced Engineering >>>>>> NAB Science & Technology >>>>>> 1771 N St NW, Washington Dc 20036 >>>>>> 202 429 5418 >>>> >>>> >>>> >>>> Regards, >>>> Bernhard Collini-Nocker >>>> >>>> >> >> >=20 >=20 From owner-ipdvb@erg.abdn.ac.uk Mon Feb 7 12:10:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17750 for ; Mon, 7 Feb 2005 12:10:49 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyCiu-0005RW-EQ for ipdvb-archive@ietf.org; Mon, 07 Feb 2005 12:30:57 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j17Gk08F024578 for ; Mon, 7 Feb 2005 16:46:00 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j17Gjx8H024577 for ipdvb-subscribed-users; Mon, 7 Feb 2005 16:45:59 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j17Gih1g024545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 7 Feb 2005 16:44:43 GMT Message-ID: <42079AFC.20306@erg.abdn.ac.uk> Date: Mon, 07 Feb 2005 16:44:44 +0000 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto rs References: <981038F72E40E04D8F80A194E5F7102B0E2B3D84@i2km04-ukbr.domain1.systemhost.net> In-Reply-To: <981038F72E40E04D8F80A194E5F7102B0E2B3D84@i2km04-ukbr.domain1.systemhost.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by erg.abdn.ac.uk id j17Gk08F024578 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e5958278d089090169a903f246b3f39 Content-Transfer-Encoding: quoted-printable Sure, Just send a message with "unsubscribe ipdvb" in the body of the message (not title) to "majordomo@erg.abdn.ac.uk". Gorr david.mcgovern@bt.com wrote: > Gorry, could you unsubscribe me from this list. I'm not really doing t= his now. >=20 > Dave >=20 > -----Original Message----- > From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk]On > Behalf Of Gorry Fairhurst > Sent: 07 February 2005 13:54 > To: ipdvb@erg.abdn.ac.uk > Cc: Goldberg, Adam; Allison, Art; Matthew Goldman > Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast > Descripto rs >=20 >=20 >=20 > So.... >=20 > 1. The term "TS Logical Channel" was discussed a lot at the begining of= the=20 > WG. As I recall, the reason for the new term, was that at this time the= WG=20 > could not find a suitably "unbiased" term for the set of TS Packets wit= h a=20 > common PID value (raw TS, DSMCC, Private Section, PES, etc). One key ob= jective=20 > was to find a term that did not carry extra semantics, and was understa= ndable=20 > by the networking community - this is after all intended as a part of t= he=20 > RFC-series, and we need to make this accessible to people familiar with= using=20 > IP over Ethernet, MPLS, ATM, Fibre Channel, Firewire, SDH/SONET, etc. > T >=20 > we shoudl note that the term "TS Logical Channel term already appears (= and is=20 > discussed in some detail) in the document draft-ietf-ipvb-arch-xx.txt a= nd that=20 > this HAS already complete WGLC. If it IS WRONG we still have a chance = to fix=20 > the definition/term, if we have to. Specifically, is there already a=20 > well-accepted term for the set of TS Packets with a common PID value (r= aw TS,=20 > DSMCC, Private Section, PES, etc) that we should use or refer to? >=20 >=20 > 2. I'm not against defining another term "ULE Stream", "SNDU Stream", e= tc if=20 > that helps to describe the set of TS packets with a specific PID used f= or ULE,=20 > especially when talking about PSI. >=20 > Bernhard, is there an opportunity of inserting a simple statement as th= e final=20 > paragraph of the introduction which says that to use ULE streams within= an=20 > MPEG-2 compliant multiplex may require appropriate PSI entries... I thi= nk Art=20 > already proposed some specific wording that could be used or modified? >=20 >=20 > 3) Once teh ULE spec is agreed and an RFC number issued, I can also see= great=20 > advantage in assigning a descriptor for this in ATSC. I think the WG SH= OULD=20 > should explore this at the next stage. >=20 >=20 > Gorry >=20 > Bernhard Collini-Nocker wrote: >=20 >=20 >>Hello, >> >>let me try to summarize the two major points being raised and what the=20 >>discussion is about: >>1. the name/definition of "TS Logical Channel" is not well received and= =20 >>the name/definition of a "SNDU stream" is proposed instead >>2. it is proposed to consider MPEG-2 conformance in specifying that ULE= =20 >>requires a specific stream_type value for the PMT >> >>Personally I have no objection against 1., because it is easy to change= =20 >>and improves wording and naming (unless somebody has an even better=20 >>name for it). >>For 2. my concern is that mentioning stream_type may require some=20 >>additional wording about PSI/SI in general, which is likely out of scop= e=20 >>of the ULE draft. Even worse, in introducing a "world" besides the=20 >>encapsulation/decapsulation of ULE, this may result in further confusio= n=20 >>about what the MPEG-2/Section layer does in addition to and/or in=20 >>comparison to ULE/IP. Actually some difficult question may arise from=20 >>this direction, for example whether it is a wishful requirement for ULE= =20 >>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 >>>=20 >>> >>> >>> >>>>-----Original Message----- >>>>From: Goldberg, Adam >>>>Sent: Monday, February 07, 2005 12:42 AM >>>>To: 'Bernhard Collini-Nocker'; Goldberg, Adam >>>>Cc: ipdvb@erg.abdn.ac.uk; Allison, Art; Matthew Goldman >>>>Subject: RE: Forward from Art Alison: WGLC ULE - Data Broadcast=20 >>>>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 A= rt >>>>> >>>>> >>>>>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=20 >>>>>using >>>>>one specific packet identifier to transport subnetwork data units.=20 >>>>>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 somethin= g >>>>like "a sequence of MPEG-2 Transport Stream packets identified by a=20 >>>>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=20 >>>>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", bu= t >>>> >>>> >>>>it >>>> >>>> >>>>>is >>>>> >>>>> >>>>>>difficult for me to tell. >>>>> >>>>> >>>>>I am not so sure, whether this analysis is correct. Elementary strea= ms >>>>>are those that are transported as Packetized ES, whereas "auxillary" >>>>>data and signalling is transported as sections. Although a stream_ty= pe >>>>>in the program map section is used to reference both PESs and sectio= ns >>>>>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=20 >>>>13818-1:2000 p. >>>>xiii) >>>> >>>>Stuff carried as payload of Transport Stream packets are merely=20 >>>>'payload'. >>>>What the draft starts to define is a new type of payload stream (that= =20 >>>>is, >>>>a new way to carry data in a transport stream). The definition is no= t >>>>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 Strea= m >>>>>packets in a service private way. The use of the adaptation_field sh= all >>>>>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=20 >>>>>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= =20 >>>>>not >>>>>detailed at all, whereas ULE tries to be. >>>> >>>> >>>>I'm not going to argue that DVB's specification is complete. I will=20 >>>>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 reser= ve >>>>>> 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 conceivabl= e >>>>> >>>>> >>>>>that >>>>> >>>>> >>>>>>the reader may associate "channel" with "[television] channel" - wh= ich >>>>> >>>>> >>>>>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 abou= t >>>>>what a channel is. >>>>>According to ATIS a channel is "1. A connection between initiating a= nd >>>>>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-=E0-vis networking has a different me= aning >>>>than 'channel' vis-=E0-vis television. This was my point actually, t= hat >>>>those familiar with MPEG transport should not be assumed to be=20 >>>>networking- >>>>types (even when speaking with respect to ULE). >>>> >>>> >>>> >>>>>>Additionally, it is also wrong or ill-specified to say "According t= o >>>>> >>>>> >>>>>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=20 >>>>>make >>>>>up an event, e.g. video, audio, teletext" >>>>> >>>>>and says further: >>>>>"The component descriptor identifies the type of component stream an= d >>>>>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,=20 >>>>>audio >>>>>or EBU-data component. The coding of this field is specified in tabl= e >>>> >>>> >>>>26." >>>> >>>> >>>>>Table 26 then lists all kinds of video, audio, and teletext formats,= =20 >>>>>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 b= y >>>>>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 valu= e >>>>> >>>>> >>>>>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=20 >>>>>being >>>>>dropped. >>>>>We have discussed basically two approaches: >>>>>1. define the PSI and get an ID, or tag, or "stream_type" for ULE,=20 >>>>>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 t= o >>>>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 (an= d >>>>perhaps ties in to my suggested "SNDU Stream" definition (that is,=20 >>>>define >>>>it as >>> >>> >>> >>>SNDU Stream: a sequence of MPEG-2 Transport Stream packets identified=20 >>>by a >>>common PID value of stream_type <0xnn>. >>> >>>All that then remains, I think, would be to signal when a Program carr= ies >>>SNDU Stream(s), and what it means when there are more than one SNDU=20 >>>Stream >>>per program, or more than one Program that carries one or more SNDU=20 >>>Streams. >>> >>> >>> >>>>>>If there remains an opportunity to repair what I believe to be erro= rs >>>> >>>> >>>>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@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk= ] >>>> >>>> >>>>On >>>> >>>> >>>>>>Behalf Of Gorry Fairhurst >>>>>>Sent: Friday, February 04, 2005 6:56 AM >>>>>>To: ipdvb@erg.abdn.ac.uk; Bernhard Collini-Nocker >>>>>>Cc: AAllison@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 a= t >>>> >>>> >>>>the >>>> >>>> >>>>>end >>>>> >>>>> >>>>>>of the Introduction (1.0) to the whole document, where people can s= ee >>>> >>>> >>>>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 ag= ree >>>>> >>>>> >>>>>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, bu= t >>>> >>>> >>>>was >>>> >>>> >>>>>>>dropped because the email source address was not verified by the l= ist >>>>>>>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=20 >>>>>>>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 Chann= el" >>>> >>>> >>>>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 w= hy >>>>>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 (afte= r >>>> >>>> >>>>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=20 >>>>>>>Multiplex >>>>> >>>>> >>>>>and >>>>> >>>>> >>>>>>>means for Receivers to locate each such TS Logical Channel are=20 >>>>>>>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/S= I. >>>>> >>>>> >>>>> >>>>>>>Reason: >>>>>>>Just inserting a "TS Logical Channel" without including a >>>>>>>TS_Program_map_section that lists the PID and a stream_type does n= ot >>>>>>>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 th= e >>>>> >>>>> >>>>>means >>>>> >>>>> >>>>>>>for binding the inserted element into a multiplex and subsequent >>>>> >>>>> >>>>>discovery >>>>> >>>>> >>>>>>>is to be covered in another document, a pointer to that document=20 >>>>>>>would >>>>> >>>>> >>>>>be >>>>> >>>>> >>>>>>>more helpful than this warning. It seems at least a warning is nee= ded >>>>> >>>>> >>>>>and >>>>> >>>>> >>>>>>>preferably a pointer to where this next level of TS construction i= s >>>>>>>defined. >>>>> >>>>> >>>>>From an architectural point of view it is a reasonable assupmption t= hat >>>>>whatever is being sent in a TS multiplex should be referenced. Howev= er, >>>>>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/complia= nt? >>>>> >>>>> >>>>> >>>>>>>Art Allison >>>>>>>Director, Advanced Engineering >>>>>>>NAB Science & Technology >>>>>>>1771 N St NW, Washington Dc 20036 >>>>>>>202 429 5418 >>>>> >>>>> >>>>> >>>>>Regards, >>>>>Bernhard Collini-Nocker >>>>> >>>>> >>> >>> >> >=20 >=20 >=20 From owner-ipdvb@erg.abdn.ac.uk Mon Feb 7 16:20:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20941 for ; Mon, 7 Feb 2005 16:20:17 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyGcL-0005Et-Ul for ipdvb-archive@ietf.org; Mon, 07 Feb 2005 16:40:27 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j17KumHS029956 for ; Mon, 7 Feb 2005 20:56:48 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j17Kumwo029955 for ipdvb-subscribed-users; Mon, 7 Feb 2005 20:56:48 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from out006.verizon.net (out006pub.verizon.net [206.46.170.106]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j17KuFwA029937 for ; Mon, 7 Feb 2005 20:56:15 GMT Received: from copernicus ([141.149.174.123]) by out006.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20050207205612.RESY28674.out006.verizon.net@copernicus>; Mon, 7 Feb 2005 14:56:12 -0600 Message-ID: <01d401c50d57$74092780$ad02a8c0@copernicus> From: "Marie-Jose Montpetit" To: Cc: "Goldberg, Adam" , "Allison, Art" , "Matthew Goldman" References: <08259490B3BC3140B549DD0907A5644811D664@admsrvnt10.enet.sharplabs.com> <420763AB.50107@cosy.sbg.ac.at> <420772FE.7050201@erg.abdn.ac.uk> Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto rs Date: Mon, 7 Feb 2005 15:55:57 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Authentication-Info: Submitted using SMTP AUTH at out006.verizon.net from [141.149.174.123] at Mon, 7 Feb 2005 14:56:07 -0600 X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by erg.abdn.ac.uk id j17KumHS029956 X-Spam-Score: 0.2 (/) X-Scan-Signature: cb256aa41b5300a7da304d7294799ef5 Content-Transfer-Encoding: quoted-printable 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 UL= E 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 Gorr= y) (2) PSI/SI scanning is part of the Address Resolution Draft as regard management of addressing; it will be further discussed there and focus gi= ven to the issues raised in this thread (3) Someone (Adam and/or team) proposes WG work and a draft on ATSC conce= rns 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 -----=20 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 wit= h 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 t= he > 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 a= nd 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 (r= aw 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", e= tc if > that helps to describe the set of TS packets with a specific PID used f= or ULE, > especially when talking about PSI. > > Bernhard, is there an opportunity of inserting a simple statement as th= e final > paragraph of the introduction which says that to use ULE streams within= an > MPEG-2 compliant multiplex may require appropriate PSI entries... I thi= nk 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 th= e > > discussion is about: > > 1. the name/definition of "TS Logical Channel" is not well received a= nd > > the name/definition of a "SNDU stream" is proposed instead > > 2. it is proposed to consider MPEG-2 conformance in specifying that U= LE > > requires a specific stream_type value for the PMT > > > > Personally I have no objection against 1., because it is easy to chan= ge > > 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 sc= ope > > of the ULE draft. Even worse, in introducing a "world" besides the > > encapsulation/decapsulation of ULE, this may result in further confus= ion > > 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 U= LE > > 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@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 ter= m for > >>>> the purpose of networking. The question is whether other terms, fo= r > >>>> 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 combinatio= n of > >>> words. I'd have no objection to defining a "SNDU Stream" as someth= ing > >>> 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 Strea= m is > >>> begging for confusion. Use of any such words ("TS (virtual) circui= t") > >>> 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 a= nd > >>> > >>> > >>> DVB > >>> > >>>> use > >>>> > >>>>> of "specific TS Logical Channels". To my knowledge, this interne= t- > >>> > >>> > >>> draft > >>> > >>>> is > >>>> > >>>>> the only document anywhere which uses such terms. It is certainl= y > >>> > >>> > >>> 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 "auxillar= y" > >>>> 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 avoi= d > >>>> 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 on= e > >>> 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 (th= at > >>> 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_indicat= or > >>>> field and the transport_priority field of the MPEG-2 Transport Str= eam > >>>> 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 lea= d 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 wil= l > >>> 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 [I= SO- > >>>>> 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). Accordin= g 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 conceiva= ble > >>>> > >>>> > >>>> 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 televisio= n, > >>>> however, network engineers might have a different understanding ab= out > >>>> 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-=E0-vis networking has a different meaning > >>> than 'channel' vis-=E0-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 o= r > >>> > >>> > >>> 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 togethe= r > >>>> 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 ta= ble > >>> > >>> > >>> 26." > >>> > >>>> Table 26 then lists all kinds of video, audio, and teletext format= s, > >>>> 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 defin= ed > >>>> 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 va= lue > >>>> > >>>> > >>>> 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 alloca= te 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 identifie= d > >> 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 meani= ng in > >>>> another context. However, ambiguous terms in other documents shoul= d be > >>>> avoided as well. > >>>> > >>>> > >>>>> [Apologies for being strident at all, to say nothing of at such a= n > >>>>> 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@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.= uk] > >>> > >>> > >>> On > >>> > >>>>> Behalf Of Gorry Fairhurst > >>>>> Sent: Friday, February 04, 2005 6:56 AM > >>>>> To: ipdvb@erg.abdn.ac.uk; Bernhard Collini-Nocker > >>>>> Cc: AAllison@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 need= ed > >>> > >>> > >>> 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 whe= n > >>> > >>> > >>> 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 i= s > >>>> standardized? > >>>> > >>>> > >>>>>> I suggest at least an informative note be added in Section 6 (af= ter > >>> > >>> > >>> 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. I= n > >>>> 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 strea= m; > >>> > >>> > >>> 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 owner-ipdvb@erg.abdn.ac.uk Tue Feb 8 01:03:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13995 for ; Tue, 8 Feb 2005 01:03:55 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyOn9-0003JN-9U for ipdvb-archive@ietf.org; Tue, 08 Feb 2005 01:24:08 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j185PVLV009427 for ; Tue, 8 Feb 2005 05:25:31 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j185PVBk009426 for ipdvb-subscribed-users; Tue, 8 Feb 2005 05:25:31 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from sharplabs.com (keymaster.sharplabs.com [216.65.151.107]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j185OogV009404 for ; Tue, 8 Feb 2005 05:24:52 GMT Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j185OePs018849; Mon, 7 Feb 2005 21:24:40 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <1B76VVKJ>; Mon, 7 Feb 2005 21:25:16 -0800 Message-ID: <08259490B3BC3140B549DD0907A5644811D697@admsrvnt10.enet.sharplabs.com> From: "Goldberg, Adam" To: Bernhard Collini-Nocker , ipdvb@erg.abdn.ac.uk Cc: "Goldberg, Adam" , "Allison, Art" , Matthew Goldman Subject: RE: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto rs Date: Mon, 7 Feb 2005 21:25:11 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by erg.abdn.ac.uk id j185PVLV009427 X-Spam-Score: 0.0 (/) X-Scan-Signature: b94423d57458a72e07b422b40e685d94 Content-Transfer-Encoding: quoted-printable 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 va= lue 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 anothe= r document. That seems fine, but perhaps mention should be made about it. = =20 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 =20 > -----Original Message----- > From: Bernhard Collini-Nocker [mailto:bnocker@cosy.sbg.ac.at] > Sent: Monday, February 07, 2005 7:49 AM > To: ipdvb@erg.abdn.ac.uk > Cc: Goldberg, Adam; Allison, Art; Matthew Goldman > Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast Descrip= to > rs >=20 > Hello, >=20 > 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 >=20 > 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 scop= e > of the ULE draft. Even worse, in introducing a "world" besides the > encapsulation/decapsulation of ULE, this may result in further confusio= n > 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? >=20 > Any opinions, recommendations or suggestions about this? >=20 > Regards, > Bernhard >=20 > 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@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 A= rt > >>> > >>>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 somethin= g > >>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", bu= t > >> > >>it > >> > >>>is > >>> > >>>>difficult for me to tell. > >>> > >>>I am not so sure, whether this analysis is correct. Elementary strea= ms > >>>are those that are transported as Packetized ES, whereas "auxillary" > >>>data and signalling is transported as sections. Although a stream_ty= pe > >>>in the program map section is used to reference both PESs and sectio= ns > >>>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:20= 00 > 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 no= t > >>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 Strea= m > >>>packets in a service private way. The use of the adaptation_field sh= all > >>>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 [IS= O- > >>>> 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 rese= rve > >>>> 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 conceivabl= e > >>> > >>>that > >>> > >>>>the reader may associate "channel" with "[television] channel" - wh= ich > >>> > >>>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 abou= t > >>>what a channel is. > >>>According to ATIS a channel is "1. A connection between initiating a= nd > >>>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-=E0-vis networking has a different me= aning > >>than 'channel' vis-=E0-vis television. This was my point actually, t= hat > >>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 t= o > >>> > >>>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 an= d > >>>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 tabl= e > >> > >>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 b= y > >>>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 valu= e > >>> > >>>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, o= r 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 t= o > >>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 (an= d > >>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 erro= rs > >> > >>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@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk= ] > >> > >>On > >> > >>>>Behalf Of Gorry Fairhurst > >>>>Sent: Friday, February 04, 2005 6:56 AM > >>>>To: ipdvb@erg.abdn.ac.uk; Bernhard Collini-Nocker > >>>>Cc: AAllison@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 a= t > >> > >>the > >> > >>>end > >>> > >>>>of the Introduction (1.0) to the whole document, where people can s= ee > >> > >>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 ag= ree > >>> > >>>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, bu= t > >> > >>was > >> > >>>>>dropped because the email source address was not verified by the l= ist > >>>>>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 t= o > 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 Chann= el" > >> > >>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 w= hy > >>>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 (afte= r > >> > >>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/S= I. > >>> > >>> > >>>>>Reason: > >>>>>Just inserting a "TS Logical Channel" without including a > >>>>>TS_Program_map_section that lists the PID and a stream_type does n= ot > >>>>>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 th= e > >>> > >>>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 nee= ded > >>> > >>>and > >>> > >>>>>preferably a pointer to where this next level of TS construction i= s > >>>>>defined. > >>> > >>> From an architectural point of view it is a reasonable assupmption > that > >>>whatever is being sent in a TS multiplex should be referenced. Howev= er, > >>>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/complia= nt? > >>> > >>> > >>>>>Art Allison > >>>>>Director, Advanced Engineering > >>>>>NAB Science & Technology > >>>>>1771 N St NW, Washington Dc 20036 > >>>>>202 429 5418 > >>> > >>> > >>>Regards, > >>>Bernhard Collini-Nocker > >>> > >>> > > > > From owner-ipdvb@erg.abdn.ac.uk Tue Feb 8 01:04:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14023 for ; Tue, 8 Feb 2005 01:04:15 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyOnS-0003K0-KP for ipdvb-archive@ietf.org; Tue, 08 Feb 2005 01:24:27 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j185WAi2009584 for ; Tue, 8 Feb 2005 05:32:10 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j185WAeq009583 for ipdvb-subscribed-users; Tue, 8 Feb 2005 05:32:10 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from sharplabs.com (keymaster.sharplabs.com [216.65.151.107]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j185Vbpw009558; Tue, 8 Feb 2005 05:31:38 GMT Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j185VUHS019184; Mon, 7 Feb 2005 21:31:30 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <1B76VVMH>; Mon, 7 Feb 2005 21:32:06 -0800 Message-ID: <08259490B3BC3140B549DD0907A5644811D698@admsrvnt10.enet.sharplabs.com> From: "Goldberg, Adam" To: gorry@erg.abdn.ac.uk, ipdvb@erg.abdn.ac.uk Cc: "Goldberg, Adam" , "Allison, Art" , Matthew Goldman Subject: RE: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto rs Date: Mon, 7 Feb 2005 21:32:02 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by erg.abdn.ac.uk id j185WAi2009584 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f864d073635f9dbbfb1a859082fbfac Content-Transfer-Encoding: quoted-printable 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 =20 > -----Original Message----- > From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk] > Sent: Monday, February 07, 2005 8:54 AM > To: ipdvb@erg.abdn.ac.uk > Cc: Goldberg, Adam; Allison, Art; Matthew Goldman > Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast Descrip= to > rs >=20 >=20 > So.... >=20 > 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 wit= h 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 t= he > 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 >=20 > 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 a= nd > 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 (r= aw > 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 matte= r) documents does not show a single defined term that means "sequence of transport packets each identified by a single PID value" doesn't mean tha= t 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 suppos= e) is defining is a new "type of stream" (transport packets containing ULE o= r 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", e= tc > if > that helps to describe the set of TS packets with a specific PID used f= or > ULE, > especially when talking about PSI. >=20 > Bernhard, is there an opportunity of inserting a simple statement as th= e > final > paragraph of the introduction which says that to use ULE streams within= an > MPEG-2 compliant multiplex may require appropriate PSI entries... I thi= nk > Art > already proposed some specific wording that could be used or modified? >=20 >=20 > 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 respo= nd favorably. > Gorry >=20 > Bernhard Collini-Nocker wrote: >=20 > > Hello, > > > > let me try to summarize the two major points being raised and what th= e > > discussion is about: > > 1. the name/definition of "TS Logical Channel" is not well received a= nd > > the name/definition of a "SNDU stream" is proposed instead > > 2. it is proposed to consider MPEG-2 conformance in specifying that U= LE > > requires a specific stream_type value for the PMT > > > > Personally I have no objection against 1., because it is easy to chan= ge > > 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 sc= ope > > of the ULE draft. Even worse, in introducing a "world" besides the > > encapsulation/decapsulation of ULE, this may result in further confus= ion > > 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 U= LE > > 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@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 ter= m > for > >>>> the purpose of networking. The question is whether other terms, fo= r > >>>> 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 combinatio= n > of > >>> words. I'd have no objection to defining a "SNDU Stream" as someth= ing > >>> 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 Strea= m > is > >>> begging for confusion. Use of any such words ("TS (virtual) circui= t") > >>> 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 a= nd > >>> > >>> > >>> DVB > >>> > >>>> use > >>>> > >>>>> of "specific TS Logical Channels". To my knowledge, this interne= t- > >>> > >>> > >>> draft > >>> > >>>> is > >>>> > >>>>> the only document anywhere which uses such terms. It is certainl= y > >>> > >>> > >>> 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 "auxillar= y" > >>>> 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 avoi= d > >>>> 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 on= e > >>> 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 (th= at > >>> 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_indicat= or > >>>> field and the transport_priority field of the MPEG-2 Transport Str= eam > >>>> 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 lea= d > 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 wil= l > >>> 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 [I= SO- > >>>>> 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). Accordin= g > 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 conceiva= ble > >>>> > >>>> > >>>> 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 televisio= n, > >>>> however, network engineers might have a different understanding ab= out > >>>> 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-=E0-vis networking has a different > meaning > >>> than 'channel' vis-=E0-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 o= r > >>> > >>> > >>> 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 togethe= r > >>>> 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 ta= ble > >>> > >>> > >>> 26." > >>> > >>>> Table 26 then lists all kinds of video, audio, and teletext format= s, > >>>> 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 defin= ed > >>>> 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 va= lue > >>>> > >>>> > >>>> 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 alloca= te > 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 identifie= d > >> 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 meani= ng > in > >>>> another context. However, ambiguous terms in other documents shoul= d > be > >>>> avoided as well. > >>>> > >>>> > >>>>> [Apologies for being strident at all, to say nothing of at such a= n > >>>>> 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@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.= uk] > >>> > >>> > >>> On > >>> > >>>>> Behalf Of Gorry Fairhurst > >>>>> Sent: Friday, February 04, 2005 6:56 AM > >>>>> To: ipdvb@erg.abdn.ac.uk; Bernhard Collini-Nocker > >>>>> Cc: AAllison@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 need= ed > >>> > >>> > >>> 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 whe= n > >>> > >>> > >>> 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 i= s > >>>> standardized? > >>>> > >>>> > >>>>>> I suggest at least an informative note be added in Section 6 (af= ter > >>> > >>> > >>> 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. I= n > >>>> 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 strea= m; > >>> > >>> > >>> 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 owner-ipdvb@erg.abdn.ac.uk Tue Feb 8 01:08:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14267 for ; Tue, 8 Feb 2005 01:08:08 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyOrE-0003P4-1h for ipdvb-archive@ietf.org; Tue, 08 Feb 2005 01:28:21 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j185ZAZG009640 for ; Tue, 8 Feb 2005 05:35:10 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j185Z9a0009639 for ipdvb-subscribed-users; Tue, 8 Feb 2005 05:35:09 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from sharplabs.com (keymaster.sharplabs.com [216.65.151.107]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j185Yc4J009622 for ; Tue, 8 Feb 2005 05:34:38 GMT Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j185YV5x019248; Mon, 7 Feb 2005 21:34:31 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <1B76VVNA>; Mon, 7 Feb 2005 21:35:06 -0800 Message-ID: <08259490B3BC3140B549DD0907A5644811D699@admsrvnt10.enet.sharplabs.com> From: "Goldberg, Adam" To: Marie-Jose Montpetit , ipdvb@erg.abdn.ac.uk Cc: "Goldberg, Adam" , "Allison, Art" , Matthew Goldman Subject: RE: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto rs Date: Mon, 7 Feb 2005 21:35:02 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by erg.abdn.ac.uk id j185ZAZG009640 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0dcdaa57c570c86b2e4beb0ed476393e Content-Transfer-Encoding: quoted-printable 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 =20 > -----Original Message----- > From: Marie-Jose Montpetit [mailto:mariejose.montpetit@verizon.net] > Sent: Monday, February 07, 2005 3:56 PM > To: ipdvb@erg.abdn.ac.uk > Cc: Goldberg, Adam; Allison, Art; Matthew Goldman > Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast Descrip= to > rs >=20 > I think we need to close on some of those issues and move forward. >=20 > Here is what I propose which would be inline with the conclusions of th= e > 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 "ATS= C concerns" so much as concerns from one overly familiar with MPEG-2 Transp= ort Streams and their widespread use. >=20 > Thanks >=20 > Marie-Jose >=20 > ----- 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 Descrip= to > rs >=20 >=20 > > > > 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 t= he > WG > > could not find a suitably "unbiased" term for the set of TS Packets w= ith > 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 wi= th > 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 chanc= e > 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 with= in > 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 s= ee > 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 bette= r > > > 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 fr= om > > > 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 bel= ow. > > >> > > >> 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@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 tho= se > Art > > >>>> > > >>>> > > >>>> points > > >>>> > > >>>>> out), as well as confusion heaped upon someone familiar with MP= EG- > 2 > > >>>>> Transport (as typically used in entertainment delivery). > > >>>> > > >>>> > > >>>> Unfortunately the MPEG-2 standards do not provide a reasonable t= erm > for > > >>>> the purpose of networking. The question is whether other terms, = for > > >>>> example "PID network" or "PID stream" would be better received a= nd > > >>>> understood? > > >>>> The term "TS logical channel" tries to verbally visualize that t= he > > >>>> encapsulation uses a continouos stream of transport stream packe= ts > > >>>> using > > >>>> one specific packet identifier to transport subnetwork data unit= s. > > >>>> 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 combinat= ion > 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 Str= eam > 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 certai= nly > > >>> > > >>> > > >>> 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 av= oid > > >>>> 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 i= s > not > > >>> compete. > > >>> > > >>> > > >>>> According to, for example EN301192 v1.3.1, defines Data Piping a= s: > > >>>> " The data broadcast service shall insert the data to be broadca= st > > >>>> directly in the payload of MPEG-2 TS packets." > > >>>> That raises the question, how to call a continouos stream of MPE= G-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_fiel= d > 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 l= ead > to > > >>>> the wrong conclusion that ULE equals Data Piping. But Data Pipin= g > is > > >>>> not > > >>>> detailed at all, whereas ULE tries to be. > > >>> > > >>> > > >>> I'm not going to argue that DVB's specification is complete. I w= ill > > >>> 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. A= ll > > >>>>> packets sent over a TS Logical Channel carry the same PID val= ue > > >>>>> (this value is unique within a specific TS Multiplex). Accord= ing > 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 th= at > > >>>> > > >>>> > > >>>> "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 initiati= ng > 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 frequen= cy- > or > > >>>> time-division multiplexing. ..." > > >>> > > >>> > > >>> I understand that 'channel' vis-=E0-vis networking has a differen= t > meaning > > >>> than 'channel' vis-=E0-vis television. This was my point actuall= y, > 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 "Accordi= ng > 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 toget= her > > >>>> make > > >>>> up an event, e.g. video, audio, teletext" > > >>>> > > >>>> and says further: > > >>>> "The component descriptor identifies the type of component strea= m > and > > >>>> may be used to provide a text description of the elementary stre= am" > > >>>> > > >>>> where: > > >>>> "component_type: This 8-bit field specifies the type of the vide= o, > > >>>> 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 namin= g: > > >>>> "event: grouping of elementary broadcast data streams with a > defined > > >>>> start and end time belonging to a common service, e.g. first hal= f > of > a > > >>>> football match, News Flash, first part of an entertainment show" > > >>>> What is a "elementary broadcast data streams"? Not by guessing b= ut > 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 an= d > > >>>>> 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 a= re > > >>>> being > > >>>> dropped. > > >>>> We have discussed basically two approaches: > > >>>> 1. define the PSI and get an ID, or tag, or "stream_type" for UL= E, > > >>>> 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 do= ne. > > >>> Without defining a stream_type for ULE data, it is neither possib= le > 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. Furthermo= re, > 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 identif= ied > > >> 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 SND= U > > >> Stream > > >> per program, or more than one Program that carries one or more SND= U > > >> 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 sho= uld > 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@erg.abdn.ac.uk [mailto:owner- > ipdvb@erg.abdn.ac.uk] > > >>> > > >>> > > >>> On > > >>> > > >>>>> Behalf Of Gorry Fairhurst > > >>>>> Sent: Friday, February 04, 2005 6:56 AM > > >>>>> To: ipdvb@erg.abdn.ac.uk; Bernhard Collini-Nocker > > >>>>> Cc: AAllison@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 c= an > 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 t= o > 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 t= he > 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 i= t > > >>> > > >>> > > >>> contains > > >>> > > >>>>>> two definitions of PSI. I suggest the second should be deleted. > > >>>>>> > > >>>>> > > >>>>> 2) > > >>>>> > > >>>>> > > >>>>>> I previously made a comment about the ancillary requirements w= hen > > >>> > > >>> > > >>> adding > > >>> > > >>>> a > > >>>> > > >>>>>> TS logical channel to a TS multiplex and asserted there appear= ed > > >>>>>> to be > > >>>>>> under > > >>>>>> specification. Perhaps it was viewed as out of scope, or perha= ps > 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 contra= ry > 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 T= S > > >>> > > >>> > > >>> Logical > > >>> > > >>>>>> Channel over a TS Multiplex.") The note should say "PSI entrie= s > 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 do= es > 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. I= f > the > > >>>> > > >>>> > > >>>> means > > >>>> > > >>>>>> for binding the inserted element into a multiplex and subseque= nt > > >>>> > > >>>> > > >>>> discovery > > >>>> > > >>>>>> is to be covered in another document, a pointer to that docume= nt > > >>>>>> 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 constructi= on > is > > >>>>>> defined. > > >>>> > > >>>> > > >>>> From an architectural point of view it is a reasonable assupmpti= on > that > > >>>> whatever is being sent in a TS multiplex should be referenced. > However, > > >>>> the reality is that "ghost" PIDs do occur in many services eithe= r > > >>>> 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 owner-ipdvb@erg.abdn.ac.uk Tue Feb 8 03:01:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12949 for ; Tue, 8 Feb 2005 03:01:17 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyQci-0005iW-Dr for ipdvb-archive@ietf.org; Tue, 08 Feb 2005 03:21:31 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j187HkV1011706 for ; Tue, 8 Feb 2005 07:17:46 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j187HkBp011705 for ipdvb-subscribed-users; Tue, 8 Feb 2005 07:17:46 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from loewe.cosy.sbg.ac.at (loewe.cosy.sbg.ac.at [141.201.2.12]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j187HC5L011689 for ; Tue, 8 Feb 2005 07:17:12 GMT Received: from [127.0.0.1] (milbe.cosy.sbg.ac.at [141.201.2.21]) by loewe.cosy.sbg.ac.at (8.8.8/8.8.7) with ESMTP id IAA13042; Tue, 8 Feb 2005 08:17:06 +0100 (MET) Message-ID: <42086752.107@cosy.sbg.ac.at> Date: Tue, 08 Feb 2005 08:16:34 +0100 From: Bernhard Collini-Nocker User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk CC: "Goldberg, Adam" , "Allison, Art" , Matthew Goldman Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto rs References: <08259490B3BC3140B549DD0907A5644811D697@admsrvnt10.enet.sharplabs.com> In-Reply-To: <08259490B3BC3140B549DD0907A5644811D697@admsrvnt10.enet.sharplabs.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by erg.abdn.ac.uk id j187HkV1011706 X-Spam-Score: 0.0 (/) X-Scan-Signature: 959bc20619a369a796f66bb9e13b5f74 Content-Transfer-Encoding: quoted-printable Please read below. Goldberg, Adam wrote: > Re #2 below, without discussion of PSI it will be both (1) difficult fo= r > 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=20 Stream Table (UST) for that purpose? Even on a dedicated PID, say 0x16,=20 and registered/reserved for that purpose? It could well serve also=20 INT/IMT/... purposes, without having to parse other sections. Consequently, the responsibility would be there, where it should be.=20 Although, it wold make sense if someone would take responsibility for=20 registration and someone else for semantics? But that seems quite=20 innovative. Would ATSC/DVB let IETF/... come up with a draft/standard=20 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=20 primarily is?) with network equipment. Whether a unreferenced (ghost)=20 PID is being dropped by a multiplexer or not is probably just a=20 configuration issue. But, in what way can an IP router can tell (MPEG-2)=20 receivers, where (on what PID) a specific ULE Stream is available? In a=20 carneval like statement one could argue, that MPEG-2 is like a room with=20 8K Ethernet plugs, guess which is the right one to connect to your local=20 network. Of course we know, that it is physically more the opposite: one=20 plug, where 8K networks are on it, so more the nightmare for security=20 admins. > I note from another response that the carriage may be specified in anot= her > document. That seems fine, but perhaps mention should be made about it= . =20 Yes, information about the 8K PID Networks is essential for=20 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=20 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=20 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 >=20 >>-----Original Message----- >>From: Bernhard Collini-Nocker [mailto:bnocker@cosy.sbg.ac.at] >>Sent: Monday, February 07, 2005 7:49 AM >>To: ipdvb@erg.abdn.ac.uk >>Cc: Goldberg, Adam; Allison, Art; Matthew Goldman >>Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast Descrip= to >>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 scop= e >>of the ULE draft. Even worse, in introducing a "world" besides the >>encapsulation/decapsulation of ULE, this may result in further confusio= n >>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@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 A= rt >>>>> >>>>>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 somethin= g >>>>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", bu= t >>>> >>>>it >>>> >>>> >>>>>is >>>>> >>>>> >>>>>>difficult for me to tell. >>>>> >>>>>I am not so sure, whether this analysis is correct. Elementary strea= ms >>>>>are those that are transported as Packetized ES, whereas "auxillary" >>>>>data and signalling is transported as sections. Although a stream_ty= pe >>>>>in the program map section is used to reference both PESs and sectio= ns >>>>>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:20= 00 >> >>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 >=20 > is, >=20 >>>>a new way to carry data in a transport stream). The definition is no= t >>>>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 Strea= m >>>>>packets in a service private way. The use of the adaptation_field sh= all >>>>>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 reser= ve >>>>>> 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 conceivabl= e >>>>> >>>>>that >>>>> >>>>> >>>>>>the reader may associate "channel" with "[television] channel" - wh= ich >>>>> >>>>>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 abou= t >>>>>what a channel is. >>>>>According to ATIS a channel is "1. A connection between initiating a= nd >>>>>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-=E0-vis networking has a different me= aning >>>>than 'channel' vis-=E0-vis television. This was my point actually, t= hat >>>>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 t= o >>>>> >>>>>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 an= d >>>>>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 tabl= e >>>> >>>>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 b= y >>>>>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 valu= e >>>>> >>>>>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, o= r >=20 > 2. >=20 >>>>>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 t= o >>>>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 (an= d >>>>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 erro= rs >>>> >>>>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@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk= ] >>>> >>>>On >>>> >>>> >>>>>>Behalf Of Gorry Fairhurst >>>>>>Sent: Friday, February 04, 2005 6:56 AM >>>>>>To: ipdvb@erg.abdn.ac.uk; Bernhard Collini-Nocker >>>>>>Cc: AAllison@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 a= t >>>> >>>>the >>>> >>>> >>>>>end >>>>> >>>>> >>>>>>of the Introduction (1.0) to the whole document, where people can s= ee >>>> >>>>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 ag= ree >>>>> >>>>>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, bu= t >>>> >>>>was >>>> >>>> >>>>>>>dropped because the email source address was not verified by the l= ist >>>>>>>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 t= o >> >>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 Chann= el" >>>> >>>>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 w= hy >>>>>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 (afte= r >>>> >>>>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/S= I. >>>>> >>>>> >>>>> >>>>>>>Reason: >>>>>>>Just inserting a "TS Logical Channel" without including a >>>>>>>TS_Program_map_section that lists the PID and a stream_type does n= ot >>>>>>>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 th= e >>>>> >>>>>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 nee= ded >>>>> >>>>>and >>>>> >>>>> >>>>>>>preferably a pointer to where this next level of TS construction i= s >>>>>>>defined. >>>>> >>>>>From an architectural point of view it is a reasonable assupmption >> >>that >> >>>>>whatever is being sent in a TS multiplex should be referenced. Howev= er, >>>>>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/complia= nt? >>>>> >>>>> >>>>> >>>>>>>Art Allison >>>>>>>Director, Advanced Engineering >>>>>>>NAB Science & Technology >>>>>>>1771 N St NW, Washington Dc 20036 >>>>>>>202 429 5418 >>>>> >>>>> >>>>>Regards, >>>>>Bernhard Collini-Nocker >>>>> >>>>> >>> >>> >=20 From owner-ipdvb@erg.abdn.ac.uk Tue Feb 8 03:09:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13523 for ; Tue, 8 Feb 2005 03:09:44 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyQkw-0005rM-3O for ipdvb-archive@ietf.org; Tue, 08 Feb 2005 03:29:59 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j187dFw2012076 for ; Tue, 8 Feb 2005 07:39:15 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j187dF0r012075 for ipdvb-subscribed-users; Tue, 8 Feb 2005 07:39:15 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from loewe.cosy.sbg.ac.at (loewe.cosy.sbg.ac.at [141.201.2.12]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j187cidu012054 for ; Tue, 8 Feb 2005 07:38:44 GMT Received: from [127.0.0.1] (milbe.cosy.sbg.ac.at [141.201.2.21]) by loewe.cosy.sbg.ac.at (8.8.8/8.8.7) with ESMTP id IAA14772 for ; Tue, 8 Feb 2005 08:38:44 +0100 (MET) Message-ID: <42086C64.4080900@cosy.sbg.ac.at> Date: Tue, 08 Feb 2005 08:38:12 +0100 From: Bernhard Collini-Nocker User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto rs References: <08259490B3BC3140B549DD0907A5644811D699@admsrvnt10.enet.sharplabs.com> In-Reply-To: <08259490B3BC3140B549DD0907A5644811D699@admsrvnt10.enet.sharplabs.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by erg.abdn.ac.uk id j187dFw2012076 X-Spam-Score: 0.0 (/) X-Scan-Signature: e0ce87e8a8080dd27b518f94257398f8 Content-Transfer-Encoding: quoted-printable Nothin more to say than: http://www.ietf.org/internet-drafts/draft-fair-ipdvb-ar-02.txt Regards, Bernhard Goldberg, Adam wrote: > Below >=20 > 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 > =20 >=20 >=20 >>-----Original Message----- >>From: Marie-Jose Montpetit [mailto:mariejose.montpetit@verizon.net] >>Sent: Monday, February 07, 2005 3:56 PM >>To: ipdvb@erg.abdn.ac.uk >>Cc: Goldberg, Adam; Allison, Art; Matthew Goldman >>Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast Descrip= to >>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 th= e >>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) >=20 >=20 > 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. >=20 >=20 >>(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 >=20 >=20 > Can someone provide a pointer to the "Address Resolution Draft"? >=20 >=20 >>(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 >=20 >=20 > Don't misunderstand my concerns (or Art's, I suppose) - they are not "A= TSC > concerns" so much as concerns from one overly familiar with MPEG-2 Tran= sport > Streams and their widespread use. >=20 >=20 >=20 >>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 Descrip= to >>rs >> >> >> >>>So.... >>> >>>1. The term "TS Logical Channel" was discussed a lot at the begining o= f >> >>the >> >>>WG. As I recall, the reason for the new term, was that at this time th= e >> >>WG >> >>>could not find a suitably "unbiased" term for the set of TS Packets wi= th >> >>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 wit= h >> >>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 t= he >> >>final >> >>>paragraph of the introduction which says that to use ULE streams withi= n >> >>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 se= e >> >>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 th= e >>>>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@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 ter= m >> >>for >> >>>>>>>the purpose of networking. The question is whether other terms, fo= r >>>>>>>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 combinatio= n >> >>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 Strea= m >> >>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 certainl= y >>>>>> >>>>>> >>>>>>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 avoi= d >>>>>>>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 on= e >>>>>>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 lea= d >> >>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 wil= l >>>>>>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). Accordin= g >> >>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 >=20 > television, >=20 >>>>>>>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-=E0-vis networking has a different >> >>meaning >> >>>>>>than 'channel' vis-=E0-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 o= r >>>>>> >>>>>> >>>>>>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 togethe= r >>>>>>>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 >=20 > formats, >=20 >>>>>>>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 identifie= d >>>>>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 shoul= d >> >>be >> >>>>>>>avoided as well. >>>>>>> >>>>>>> >>>>>>> >>>>>>>>[Apologies for being strident at all, to say nothing of at such a= n >>>>>>>>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@erg.abdn.ac.uk [mailto:owner- >> >>ipdvb@erg.abdn.ac.uk] >> >>>>>> >>>>>>On >>>>>> >>>>>> >>>>>>>>Behalf Of Gorry Fairhurst >>>>>>>>Sent: Friday, February 04, 2005 6:56 AM >>>>>>>>To: ipdvb@erg.abdn.ac.uk; Bernhard Collini-Nocker >>>>>>>>Cc: AAllison@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 whe= n >>>>>> >>>>>> >>>>>>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 i= s >>>>>>>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. I= n >>>>>>>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 >>>>>>> >>>>>>> >>>>> >>>>> >>>> >=20 From owner-ipdvb@erg.abdn.ac.uk Tue Feb 8 03:58:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17018 for ; Tue, 8 Feb 2005 03:58:04 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyRVi-0006wo-6z for ipdvb-archive@ietf.org; Tue, 08 Feb 2005 04:18:19 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j188O3q7013136 for ; Tue, 8 Feb 2005 08:24:03 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j188O2QD013135 for ipdvb-subscribed-users; Tue, 8 Feb 2005 08:24:02 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from sharplabs.com (keymaster.sharplabs.com [216.65.151.107]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j188NXtC013113 for ; Tue, 8 Feb 2005 08:23:33 GMT Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j188NKQZ026380; Tue, 8 Feb 2005 00:23:20 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <1B76VWPK>; Tue, 8 Feb 2005 00:23:54 -0800 Message-ID: <08259490B3BC3140B549DD0907A5644811D69B@admsrvnt10.enet.sharplabs.com> From: "Goldberg, Adam" To: Bernhard Collini-Nocker , ipdvb@erg.abdn.ac.uk Cc: "Goldberg, Adam" , "Allison, Art" , Matthew Goldman Subject: RE: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto rs Date: Tue, 8 Feb 2005 00:23:47 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by erg.abdn.ac.uk id j188O3q7013136 X-Spam-Score: 0.0 (/) X-Scan-Signature: d465bee15753def7c258f355435bdf03 Content-Transfer-Encoding: quoted-printable > 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 UL= E packets as defined in the draft. (2) Define (in some document, this one or another) that a Program which h= as 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 on= ly 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 =20 > -----Original Message----- > From: Bernhard Collini-Nocker [mailto:bnocker@cosy.sbg.ac.at] > Sent: Tuesday, February 08, 2005 2:17 AM > To: ipdvb@erg.abdn.ac.uk > Cc: Goldberg, Adam; Allison, Art; Matthew Goldman > Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast Descrip= to > rs >=20 > Please read below. >=20 > 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 PI= D > value >=20 > 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= ? >=20 > > 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). >=20 > 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 wit= h > 8K Ethernet plugs, guess which is the right one to connect to your loca= l > network. Of course we know, that it is physically more the opposite: on= e > plug, where 8K networks are on it, so more the nightmare for security > admins. >=20 > > 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. >=20 > Yes, information about the 8K PID Networks is essential for > routing/addressing/... purposes. >=20 > > In any case, 'TS Logical Channel' remains irksome to me. I'll respon= d > > separately to other responses. >=20 > Well, meanwhile my favourite is ULE Stream instead (thanks Gorry). It > simply says what it is. >=20 > > 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 >=20 > Thanks for the interesting discussion, which is unfortunately a liitle > bit late, yet fundamental. >=20 > Kind regards, > Bernhard >=20 > 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 >=20 > > > >>-----Original Message----- > >>From: Bernhard Collini-Nocker [mailto:bnocker@cosy.sbg.ac.at] > >>Sent: Monday, February 07, 2005 7:49 AM > >>To: ipdvb@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 th= e > >>discussion is about: > >>1. the name/definition of "TS Logical Channel" is not well received a= nd > >>the name/definition of a "SNDU stream" is proposed instead > >>2. it is proposed to consider MPEG-2 conformance in specifying that U= LE > >>requires a specific stream_type value for the PMT > >> > >>Personally I have no objection against 1., because it is easy to chan= ge > >>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 sc= ope > >>of the ULE draft. Even worse, in introducing a "world" besides the > >>encapsulation/decapsulation of ULE, this may result in further confus= ion > >>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 U= LE > >>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@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 ter= m > for > >>>>>the purpose of networking. The question is whether other terms, fo= r > >>>>>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 combinatio= n > of > >>>>words. I'd have no objection to defining a "SNDU Stream" as someth= ing > >>>>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 Strea= m > is > >>>>begging for confusion. Use of any such words ("TS (virtual) circui= t") > >>>>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 a= nd > >>>> > >>>>DVB > >>>> > >>>> > >>>>>use > >>>>> > >>>>> > >>>>>>of "specific TS Logical Channels". To my knowledge, this interne= t- > >>>> > >>>>draft > >>>> > >>>> > >>>>>is > >>>>> > >>>>> > >>>>>>the only document anywhere which uses such terms. It is certainl= y > >>>> > >>>>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 "auxillar= y" > >>>>>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 avoi= d > >>>>>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 on= e > >>>>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 (th= at > > > > 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_indicat= or > >>>>>field and the transport_priority field of the MPEG-2 Transport Str= eam > >>>>>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 lea= d > 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 wil= l > >> > >>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 [I= SO- > >>>>>> 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). Accordin= g > 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 conceiva= ble > >>>>> > >>>>>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 televisio= n, > >>>>>however, network engineers might have a different understanding ab= out > >>>>>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-=E0-vis networking has a different > meaning > >>>>than 'channel' vis-=E0-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 o= r > >>>> > >>>>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 togethe= r > >> > >>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 ta= ble > >>>> > >>>>26." > >>>> > >>>> > >>>>>Table 26 then lists all kinds of video, audio, and teletext format= s, > >> > >>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 defin= ed > >>>>>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 va= lue > >>>>> > >>>>>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 alloca= te > 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 identifie= d > 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 meani= ng > in > >>>>>another context. However, ambiguous terms in other documents shoul= d > be > >>>>>avoided as well. > >>>>> > >>>>> > >>>>> > >>>>>>[Apologies for being strident at all, to say nothing of at such a= n > >>>>>>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@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.= uk] > >>>> > >>>>On > >>>> > >>>> > >>>>>>Behalf Of Gorry Fairhurst > >>>>>>Sent: Friday, February 04, 2005 6:56 AM > >>>>>>To: ipdvb@erg.abdn.ac.uk; Bernhard Collini-Nocker > >>>>>>Cc: AAllison@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 need= ed > >>>> > >>>>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 whe= n > >>>> > >>>>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 i= s > >>>>>standardized? > >>>>> > >>>>> > >>>>> > >>>>>>>I suggest at least an informative note be added in Section 6 (af= ter > >>>> > >>>>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. I= n > >>>>>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 strea= m; > >>>> > >>>>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 owner-ipdvb@erg.abdn.ac.uk Tue Feb 8 05:13:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22162 for ; Tue, 8 Feb 2005 05:13:30 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CySgj-000075-2Y for ipdvb-archive@ietf.org; Tue, 08 Feb 2005 05:33:46 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j189XPAN014919 for ; Tue, 8 Feb 2005 09:33:25 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j189XOw0014918 for ipdvb-subscribed-users; Tue, 8 Feb 2005 09:33:25 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j189WdR0014884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 8 Feb 2005 09:32:40 GMT Message-ID: <42088737.3020707@erg.abdn.ac.uk> Date: Tue, 08 Feb 2005 09:32:39 +0000 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: Re: ATSC Data Broadcast Descriptors References: <08259490B3BC3140B549DD0907A5644811D698@admsrvnt10.enet.sharplabs.com> In-Reply-To: <08259490B3BC3140B549DD0907A5644811D698@admsrvnt10.enet.sharplabs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit 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@erg.abdn.ac.uk] >>Sent: Monday, February 07, 2005 8:54 AM >>To: ipdvb@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 owner-ipdvb@erg.abdn.ac.uk Tue Feb 8 05:14:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22240 for ; Tue, 8 Feb 2005 05:14:43 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyShu-00008Y-SO for ipdvb-archive@ietf.org; Tue, 08 Feb 2005 05:35:00 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j189ksOg015293 for ; Tue, 8 Feb 2005 09:46:54 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j189ksQR015291 for ipdvb-subscribed-users; Tue, 8 Feb 2005 09:46:54 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j189joBt015255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 8 Feb 2005 09:45:51 GMT Message-ID: <42088A4F.2090109@erg.abdn.ac.uk> Date: Tue, 08 Feb 2005 09:45:51 +0000 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast Descriptors References: <08259490B3BC3140B549DD0907A5644811D699@admsrvnt10.enet.sharplabs.com> In-Reply-To: <08259490B3BC3140B549DD0907A5644811D699@admsrvnt10.enet.sharplabs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by erg.abdn.ac.uk id j189ksOg015293 X-Spam-Score: 0.0 (/) X-Scan-Signature: f08e78ca11d3665672faaf95e9d79578 Content-Transfer-Encoding: quoted-printable The -ar- draft covers addressing and address resolution (at both IP and M= PEG-2=20 layers). This draft is a proposal for a new work (and not yet adopted by = the=20 IETF). It will need inputs on all the topics, at the moment it is incompl= ete.=20 The draft is currently being revised, and a new revision is expected prio= r to=20 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, a= nd=20 inputs. This thread is useful. I don't want to stop this discussion, but concerni= ng=20 the ULE Spec, we do seem near to an agreement.... let's now move to compl= ete=20 this and get the document submitted! I can work from this thread to make a proposal to the WG for the final te= xt to=20 be inserted in ULE. Gorry Goldberg, Adam wrote: > Below >=20 > 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 > =20 >=20 >=20 >>-----Original Message----- >>From: Marie-Jose Montpetit [mailto:mariejose.montpetit@verizon.net] >>Sent: Monday, February 07, 2005 3:56 PM >>To: ipdvb@erg.abdn.ac.uk >>Cc: Goldberg, Adam; Allison, Art; Matthew Goldman >>Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast Descrip= to >>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 th= e >>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) >=20 >=20 > 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. >=20 >=20 >>(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 >=20 >=20 > Can someone provide a pointer to the "Address Resolution Draft"? >=20 >=20 >>(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 >=20 >=20 > Don't misunderstand my concerns (or Art's, I suppose) - they are not "A= TSC > concerns" so much as concerns from one overly familiar with MPEG-2 Tran= sport > Streams and their widespread use. >=20 >=20 >=20 >>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 Descrip= to >>rs >> >> >> >>>So.... >>> >>>1. The term "TS Logical Channel" was discussed a lot at the begining o= f >> >>the >> >>>WG. As I recall, the reason for the new term, was that at this time th= e >> >>WG >> >>>could not find a suitably "unbiased" term for the set of TS Packets wi= th >> >>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 wit= h >> >>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 t= he >> >>final >> >>>paragraph of the introduction which says that to use ULE streams withi= n >> >>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 se= e >> >>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 th= e >>>>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@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 ter= m >> >>for >> >>>>>>>the purpose of networking. The question is whether other terms, fo= r >>>>>>>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 combinatio= n >> >>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 Strea= m >> >>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 certainl= y >>>>>> >>>>>> >>>>>>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 avoi= d >>>>>>>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 on= e >>>>>>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 lea= d >> >>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 wil= l >>>>>>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). Accordin= g >> >>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 >=20 > television, >=20 >>>>>>>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-=E0-vis networking has a different >> >>meaning >> >>>>>>than 'channel' vis-=E0-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 o= r >>>>>> >>>>>> >>>>>>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 togethe= r >>>>>>>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 >=20 > formats, >=20 >>>>>>>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 identifie= d >>>>>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 shoul= d >> >>be >> >>>>>>>avoided as well. >>>>>>> >>>>>>> >>>>>>> >>>>>>>>[Apologies for being strident at all, to say nothing of at such a= n >>>>>>>>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@erg.abdn.ac.uk [mailto:owner- >> >>ipdvb@erg.abdn.ac.uk] >> >>>>>> >>>>>>On >>>>>> >>>>>> >>>>>>>>Behalf Of Gorry Fairhurst >>>>>>>>Sent: Friday, February 04, 2005 6:56 AM >>>>>>>>To: ipdvb@erg.abdn.ac.uk; Bernhard Collini-Nocker >>>>>>>>Cc: AAllison@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 whe= n >>>>>> >>>>>> >>>>>>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 i= s >>>>>>>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. I= n >>>>>>>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 >>>>>>> >>>>>>> >>>>> >>>>> >>>> >=20 >=20 From owner-ipdvb@erg.abdn.ac.uk Tue Feb 8 07:27:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03584 for ; Tue, 8 Feb 2005 07:27:16 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyUmB-00033q-Oh for ipdvb-archive@ietf.org; Tue, 08 Feb 2005 07:47:32 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j18Bm0xm018171 for ; Tue, 8 Feb 2005 11:48:00 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j18Bm0YC018169 for ipdvb-subscribed-users; Tue, 8 Feb 2005 11:48:00 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j18Bkksx018129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 8 Feb 2005 11:46:47 GMT Message-ID: <4208A6A7.5070304@erg.abdn.ac.uk> Date: Tue, 08 Feb 2005 11:46:47 +0000 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-ERG-MailScanner: Found to be clean, Found to be clean Subject: Repost: WGLC ULE - Data Broadcast Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by erg.abdn.ac.uk id j18Bm0xm018171 X-Spam-Score: 0.0 (/) X-Scan-Signature: c8e71861e926d70c1bd2436e580ecf31 Content-Transfer-Encoding: quoted-printable 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@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@erg.abdn.ac.uk Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast=20 Descripto rs Send reply to: rupert@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@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@erg.abdn.ac.uk > Hello, >=20 > let me try to summarize the two major points being raised and what the=20 > discussion is about: > 1. the name/definition of "TS Logical Channel" is not well received and= =20 > the name/definition of a "SNDU stream" is proposed instead > 2. it is proposed to consider MPEG-2 conformance in specifying that ULE= =20 > requires a specific stream_type value for the PMT >=20 > Personally I have no objection against 1., because it is easy to change= =20 > and improves wording and naming (unless somebody has an even better=20 > name for it). > For 2. my concern is that mentioning stream_type may require some=20 > additional wording about PSI/SI in general, which is likely out of scop= e=20 > of the ULE draft. Even worse, in introducing a "world" besides the=20 > encapsulation/decapsulation of ULE, this may result in further confusio= n=20 > about what the MPEG-2/Section layer does in addition to and/or in=20 > comparison to ULE/IP. Actually some difficult question may arise from=20 > this direction, for example whether it is a wishful requirement for ULE= =20 > to support PAT/PMT/NIT/INT/... table parsing? >=20 > Any opinions, recommendations or suggestions about this? >=20 > Regards, > Bernhard >=20 > Goldberg, Adam wrote: > > ARGH. I fat-fingered 'send' before completing the email. See below. > >=20 > > 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 > > =20 > >=20 > >=20 > >>-----Original Message----- > >>From: Goldberg, Adam > >>Sent: Monday, February 07, 2005 12:42 AM > >>To: 'Bernhard Collini-Nocker'; Goldberg, Adam > >>Cc: ipdvb@erg.abdn.ac.uk; Allison, Art; Matthew Goldman > >>Subject: RE: Forward from Art Alison: WGLC ULE - Data Broadcast Descr= ipto > >>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 > >=20 > > Channel", > >=20 > >>>and > >>> > >>>>indeed doing so creates risks of ill-specification (such as those A= rt > >>> > >>>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 u= sing > >>>one specific packet identifier to transport subnetwork data units. M= aybe > >>>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 somethin= g > >>like "a sequence of MPEG-2 Transport Stream packets identified by a c= ommon > >>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 Str= eams > >>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", bu= t > >> > >>it > >> > >>>is > >>> > >>>>difficult for me to tell. > >>> > >>>I am not so sure, whether this analysis is correct. Elementary strea= ms > >>>are those that are transported as Packetized ES, whereas "auxillary" > >>>data and signalling is transported as sections. Although a stream_ty= pe > >>>in the program map section is used to reference both PESs and sectio= ns > >>>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:20= 00 p. > >>xiii) > >> > >>Stuff carried as payload of Transport Stream packets are merely 'payl= oad'. > >>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 no= t > >>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 Strea= m > >>>packets in a service private way. The use of the adaptation_field sh= all > >>>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 pri= vate > >>>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 [IS= O- > >>>> 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 rese= rve > >>>> 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 conceivabl= e > >>> > >>>that > >>> > >>>>the reader may associate "channel" with "[television] channel" - wh= ich > >>> > >>>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 abou= t > >>>what a channel is. > >>>According to ATIS a channel is "1. A connection between initiating a= nd > >>>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-=E0-vis networking has a different me= aning > >>than 'channel' vis-=E0-vis television. This was my point actually, t= hat > >>those familiar with MPEG transport should not be assumed to be networ= king- > >>types (even when speaking with respect to ULE). > >> > >> > >>>>Additionally, it is also wrong or ill-specified to say "According t= o > >>> > >>>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 an= d > >>>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, a= udio > >>>or EBU-data component. The coding of this field is specified in tabl= e > >> > >>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 b= y > >>>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 valu= e > >>> > >>>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 b= eing > >>>dropped. > >>>We have discussed basically two approaches: > >>>1. define the PSI and get an ID, or tag, or "stream_type" for ULE, o= r 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 t= o > >>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 (an= d > >>perhaps ties in to my suggested "SNDU Stream" definition (that is, de= fine > >>it as > >=20 > >=20 > > SNDU Stream: a sequence of MPEG-2 Transport Stream packets identified= by a > > common PID value of stream_type <0xnn>. > >=20 > > All that then remains, I think, would be to signal when a Program car= ries > > SNDU Stream(s), and what it means when there are more than one SNDU S= tream > > per program, or more than one Program that carries one or more SNDU S= treams. > >=20 > >=20 > >>>>If there remains an opportunity to repair what I believe to be erro= rs > >> > >>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@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk= ] > >> > >>On > >> > >>>>Behalf Of Gorry Fairhurst > >>>>Sent: Friday, February 04, 2005 6:56 AM > >>>>To: ipdvb@erg.abdn.ac.uk; Bernhard Collini-Nocker > >>>>Cc: AAllison@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 a= t > >> > >>the > >> > >>>end > >>> > >>>>of the Introduction (1.0) to the whole document, where people can s= ee > >> > >>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 ag= ree > >>> > >>>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, bu= t > >> > >>was > >> > >>>>>dropped because the email source address was not verified by the l= ist > >>>>>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 t= o 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 Chann= el" > >> > >>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 w= hy > >>>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 (afte= r > >> > >>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 Multi= plex > >>> > >>>and > >>> > >>>>>means for Receivers to locate each such TS Logical Channel are out= side > >>> > >>>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/S= I. > >>> > >>> > >>>>>Reason: > >>>>>Just inserting a "TS Logical Channel" without including a > >>>>>TS_Program_map_section that lists the PID and a stream_type does n= ot > >>>>>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 th= e > >>> > >>>means > >>> > >>>>>for binding the inserted element into a multiplex and subsequent > >>> > >>>discovery > >>> > >>>>>is to be covered in another document, a pointer to that document w= ould > >>> > >>>be > >>> > >>>>>more helpful than this warning. It seems at least a warning is nee= ded > >>> > >>>and > >>> > >>>>>preferably a pointer to where this next level of TS construction i= s > >>>>>defined. > >>> > >>> From an architectural point of view it is a reasonable assupmption = that > >>>whatever is being sent in a TS multiplex should be referenced. Howev= er, > >>>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/complia= nt? > >>> > >>> > >>>>>Art Allison > >>>>>Director, Advanced Engineering > >>>>>NAB Science & Technology > >>>>>1771 N St NW, Washington Dc 20036 > >>>>>202 429 5418 > >>> > >>> > >>>Regards, > >>>Bernhard Collini-Nocker > >>> > >>> > >=20 > >=20 >=20 ------- End of forwarded message ------- From owner-ipdvb@erg.abdn.ac.uk Tue Feb 8 17:14:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06281 for ; Tue, 8 Feb 2005 17:14:26 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CydwV-0004Rn-QZ for ipdvb-archive@ietf.org; Tue, 08 Feb 2005 17:34:49 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j18Las5x000355 for ; Tue, 8 Feb 2005 21:36:54 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j18LasI0000354 for ipdvb-subscribed-users; Tue, 8 Feb 2005 21:36:54 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j18La4N1000326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 Feb 2005 21:36:05 GMT Message-ID: <420930C5.4080705@erg.abdn.ac.uk> Date: Tue, 08 Feb 2005 21:36:05 +0000 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk CC: "Goldberg, Adam" , "Allison, Art" , Matthew Goldman Subject: WGLC: ULE --- Questions to this WG. References: <08259490B3BC3140B549DD0907A5644811D664@admsrvnt10.enet.sharplabs.com> <420763AB.50107@cosy.sbg.ac.at> In-Reply-To: <420763AB.50107@cosy.sbg.ac.at> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit 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 owner-ipdvb@erg.abdn.ac.uk Thu Feb 10 06:05:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18265 for ; Thu, 10 Feb 2005 06:05:31 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzCSb-0000R7-Oi for ipdvb-archive@ietf.org; Thu, 10 Feb 2005 06:26:14 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j1AATePg009074 for ; Thu, 10 Feb 2005 10:29:40 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j1AATeJ5009073 for ipdvb-subscribed-users; Thu, 10 Feb 2005 10:29:40 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from [10.0.1.92] (maxp18.abdn.ac.uk [139.133.7.177]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j1AAT2Rc009057 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 10 Feb 2005 10:29:07 GMT User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 10 Feb 2005 10:29:41 +0000 Subject: I-D ACTION:draft-fair-ipdvb-ar-03.txt From: Gorry Fairhurst To: "ipdvb@erg.abdn.ac.uk" Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit 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 owner-ipdvb@erg.abdn.ac.uk Thu Feb 10 06:54:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18266 for ; Thu, 10 Feb 2005 06:05:31 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzCSb-0000Qe-RW for ipdvb-archive@ietf.org; Thu, 10 Feb 2005 06:26:14 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j1AAdso1009265 for ; Thu, 10 Feb 2005 10:39:54 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j1AAdsB9009264 for ipdvb-subscribed-users; Thu, 10 Feb 2005 10:39:54 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from [10.0.1.92] (maxp18.abdn.ac.uk [139.133.7.177]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j1AAccBj009229 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 10 Feb 2005 10:38:43 GMT User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 10 Feb 2005 10:39:17 +0000 Subject: I-D ACTION:draft-aoki-arib-uri-00.txt From: Gorry Fairhurst To: "ipdvb@erg.abdn.ac.uk" Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit 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 owner-ipdvb@erg.abdn.ac.uk Fri Feb 11 07:33:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22937 for ; Fri, 11 Feb 2005 07:33:03 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzaJ4-0005Sv-3M for ipdvb-archive@ietf.org; Fri, 11 Feb 2005 07:53:58 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j1BC0QxH010337 for ; Fri, 11 Feb 2005 12:00:26 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j1BC0PbJ010336 for ipdvb-subscribed-users; Fri, 11 Feb 2005 12:00:26 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j1BBwSd2010276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 11 Feb 2005 11:58:29 GMT Message-ID: <420C9DE5.4070600@erg.abdn.ac.uk> Date: Fri, 11 Feb 2005 11:58:29 +0000 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk CC: "Goldberg, Adam" , "Allison, Art" , Matthew Goldman Subject: PLEASE REPLY by 15th Feb 2005 - Final Sign-off of ULE References: <08259490B3BC3140B549DD0907A5644811D664@admsrvnt10.enet.sharplabs.com> <420763AB.50107@cosy.sbg.ac.at> <420930C5.4080705@erg.abdn.ac.uk> In-Reply-To: <420930C5.4080705@erg.abdn.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit 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 owner-ipdvb@erg.abdn.ac.uk Fri Feb 11 11:15:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11715 for ; Fri, 11 Feb 2005 11:15:58 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Czdmp-0002Ov-41 for ipdvb-archive@ietf.org; Fri, 11 Feb 2005 11:36:56 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j1BFK8bl014776 for ; Fri, 11 Feb 2005 15:20:08 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j1BFK8Ta014773 for ipdvb-subscribed-users; Fri, 11 Feb 2005 15:20:08 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from nab.org (foxtrot.nab.org [209.116.240.194]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j1BFIj27014704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 11 Feb 2005 15:18:46 GMT Received: from ([199.29.3.1]) by maildc2.nab.org with ESMTP id 4028857.3908584; Fri, 11 Feb 2005 10:18:21 -0500 Received: by mail.NAB.ORG with Internet Mail Service (5.5.2653.19) id ; Fri, 11 Feb 2005 10:18:21 -0500 Message-ID: From: "Allison, Art" To: "'ipdvb@erg.abdn.ac.uk'" , "'Gorry Fairhurst'" Cc: "'Matthew Goldman'" Subject: RE: PLEASE REPLY by 15th Feb 2005 - Final Sign-off of ULE Date: Fri, 11 Feb 2005 10:18:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e 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@erg.abdn.ac.uk] Sent: Friday, February 11, 2005 6:58 AM To: ipdvb@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 owner-ipdvb@erg.abdn.ac.uk Fri Feb 11 13:18:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22352 for ; Fri, 11 Feb 2005 13:18:13 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzfhA-0005gm-Tg for ipdvb-archive@ietf.org; Fri, 11 Feb 2005 13:39:13 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j1BHaXuB017663 for ; Fri, 11 Feb 2005 17:36:34 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j1BHaXZ8017662 for ipdvb-subscribed-users; Fri, 11 Feb 2005 17:36:33 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j1BHZRv0017619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 11 Feb 2005 17:35:27 GMT Message-ID: <420CECDF.7010908@erg.abdn.ac.uk> Date: Fri, 11 Feb 2005 17:35:27 +0000 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Allison, Art" CC: "'ipdvb@erg.abdn.ac.uk'" , "'Matthew Goldman'" Subject: Re: PLEASE REPLY by 15th Feb 2005 - Final Sign-off of ULE References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Content-Transfer-Encoding: 7bit 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@erg.abdn.ac.uk] > Sent: Friday, February 11, 2005 6:58 AM > To: ipdvb@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 owner-ipdvb@erg.abdn.ac.uk Mon Feb 14 12:34:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25140 for ; Mon, 14 Feb 2005 12:34:30 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0kS6-0007ld-O2 for ipdvb-archive@ietf.org; Mon, 14 Feb 2005 12:56:08 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j1EH825t001649 for ; Mon, 14 Feb 2005 17:08:03 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j1EH82Kq001648 for ipdvb-subscribed-users; Mon, 14 Feb 2005 17:08:02 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from loewe.cosy.sbg.ac.at (loewe.cosy.sbg.ac.at [141.201.2.12]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j1EH7JhY001612 for ; Mon, 14 Feb 2005 17:07:19 GMT Received: from [127.0.0.1] (milbe.cosy.sbg.ac.at [141.201.2.21]) by loewe.cosy.sbg.ac.at (8.8.8/8.8.7) with ESMTP id SAA03813 for ; Mon, 14 Feb 2005 18:07:20 +0100 (MET) Message-ID: <4210DAA8.4060809@cosy.sbg.ac.at> Date: Mon, 14 Feb 2005 18:06:48 +0100 From: Bernhard Collini-Nocker User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: Re: PLEASE REPLY by 15th Feb 2005 - Final Sign-off of ULE X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit 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 owner-ipdvb@erg.abdn.ac.uk Thu Feb 17 16:27:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06961 for ; Thu, 17 Feb 2005 16:27:00 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1tWO-0008LU-Go for ipdvb-archive@ietf.org; Thu, 17 Feb 2005 16:49:17 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j1HKefLq007146 for ; Thu, 17 Feb 2005 20:40:41 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j1HKefP4007145 for ipdvb-subscribed-users; Thu, 17 Feb 2005 20:40:41 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from kyoto.netlab.nec.de (kyoto.netlab.nec.de [195.37.70.21]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j1HKe83u007129 for ; Thu, 17 Feb 2005 20:40:08 GMT Received: from [10.0.1.2] (p50841AD1.dip0.t-ipconnect.de [80.132.26.209]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 801D41BAC9E for ; Thu, 17 Feb 2005 21:40:00 +0100 (CET) Date: Thu, 17 Feb 2005 21:39:57 +0100 From: Martin Stiemerling To: ipdvb@erg.abdn.ac.uk Subject: I-D ACTION:draft-stiemerling-ipdvb-config-00.txt (fwd) Message-ID: <3FE10A5C09BEE173EDC46BFA@[10.0.1.2]> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========B18EB3FF2673D41C9EE4==========" X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 0.3 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 --==========B18EB3FF2673D41C9EE4========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 7bit 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@ietf.org To: i-d-announce@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@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@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 ---------- --==========B18EB3FF2673D41C9EE4========== Content-Type: message/rfc822; name="I-D ACTION:draft-stiemerling-ipdvb-config-00.txt" Received: from smtp2.netlab.nec.de ([10.1.1.15]) by europa.office with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Feb 2005 18:41:29 +0100 Received: by smtp2.netlab.nec.de (Postfix) id B9BAADC3F; Wed, 16 Feb 2005 18:47:28 +0100 (CET) Delivered-To: stiemerling@netlab.nec.de Received: by smtp2.netlab.nec.de (Postfix, from userid 502) id AD1EFDC59; Wed, 16 Feb 2005 18:47:28 +0100 (CET) Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by smtp2.netlab.nec.de (Postfix) with ESMTP id D9FD2DC3F for ; Wed, 16 Feb 2005 18:47:26 +0100 (CET) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1RPI-0006Sh-5m; Wed, 16 Feb 2005 10:48:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1QuF-0001XP-PW for i-d-announce@megatron.ietf.org; Wed, 16 Feb 2005 10:15:59 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20856 for ; Wed, 16 Feb 2005 10:15:57 -0500 (EST) Message-Id: <200502161515.KAA20856@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 16 Feb 2005 10:15:56 -0500 Subject: I-D ACTION:draft-stiemerling-ipdvb-config-00.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org X-Spam-Level: X-Spam-Status: No, score=-101.4 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME,USER_IN_WHITELIST autolearn=no version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on atlas.office X-Sanitizer: This message has been sanitized! Return-Path: i-d-announce-bounces@ietf.org X-OriginalArrivalTime: 16 Feb 2005 17:41:29.0386 (UTC) FILETIME=[BEF810A0:01C5144E] --NextPart 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@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@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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-16102347.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-stiemerling-ipdvb-config-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-stiemerling-ipdvb-config-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-16102347.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- --==========B18EB3FF2673D41C9EE4==========-- From owner-ipdvb@erg.abdn.ac.uk Fri Feb 18 08:40:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01928 for ; Fri, 18 Feb 2005 08:40:14 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D28iM-00009C-CW for ipdvb-archive@ietf.org; Fri, 18 Feb 2005 09:02:39 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j1ICsaf1026999 for ; Fri, 18 Feb 2005 12:54:36 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j1ICsa05026991 for ipdvb-subscribed-users; Fri, 18 Feb 2005 12:54:36 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from [217.167.116.160] ([217.167.116.160]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j1ICrEA1026952 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 18 Feb 2005 12:53:19 GMT User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 18 Feb 2005 13:53:55 +0100 Subject: I-D ACTION:draft-ietf-ipdvb-ule-05.txt From: Gorry Fairhurst To: "ipdvb@erg.abdn.ac.uk" Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit 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 owner-ipdvb@erg.abdn.ac.uk Mon Feb 21 05:58:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10721 for ; Mon, 21 Feb 2005 05:58:59 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3Bda-0005HQ-8H for ipdvb-archive@ietf.org; Mon, 21 Feb 2005 06:22:02 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j1LAENaJ018057 for ; Mon, 21 Feb 2005 10:14:23 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j1LAEM5j018056 for ipdvb-subscribed-users; Mon, 21 Feb 2005 10:14:22 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j1LADh7g018029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 21 Feb 2005 10:13:43 GMT Message-ID: <4219B457.6090409@erg.abdn.ac.uk> Date: Mon, 21 Feb 2005 10:13:43 +0000 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: Re: I-D ACTION:draft-stiemerling-ipdvb-config-00.txt (fwd) References: <3FE10A5C09BEE173EDC46BFA@[10.0.1.2]> In-Reply-To: <3FE10A5C09BEE173EDC46BFA@[10.0.1.2]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit 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@ietf.org > To: i-d-announce@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@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@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 owner-ipdvb@erg.abdn.ac.uk Mon Feb 21 06:05:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11426 for ; Mon, 21 Feb 2005 06:05:27 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3Bjq-0005TX-A4 for ipdvb-archive@ietf.org; Mon, 21 Feb 2005 06:28:30 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j1LAShBn018581 for ; Mon, 21 Feb 2005 10:28:43 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j1LASgbP018580 for ipdvb-subscribed-users; Mon, 21 Feb 2005 10:28:42 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j1LAOYmn018424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 21 Feb 2005 10:24:36 GMT Message-ID: <4219B6E3.6050409@erg.abdn.ac.uk> Date: Mon, 21 Feb 2005 10:24:35 +0000 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk CC: gorry Fairhurst Subject: Request to Publish as an RFC: draft-ietf-ipdvb-ule-05.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Content-Transfer-Encoding: 7bit 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 owner-ipdvb@erg.abdn.ac.uk Mon Feb 21 06:45:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15520 for ; Mon, 21 Feb 2005 06:45:27 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3CMV-0006Y1-CM for ipdvb-archive@ietf.org; Mon, 21 Feb 2005 07:08:30 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j1LAmhUV019244 for ; Mon, 21 Feb 2005 10:48:43 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j1LAmgUm019243 for ipdvb-subscribed-users; Mon, 21 Feb 2005 10:48:43 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j1LAkUPn019155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 21 Feb 2005 10:46:33 GMT Message-ID: <4219BC06.4040801@erg.abdn.ac.uk> Date: Mon, 21 Feb 2005 10:46:30 +0000 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk CC: Gorry Fairhurst Subject: FIRST DRAFT of AGENDA for ipdvb meeting, at IETF-62, Monday 7th March 1930-2200 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit 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@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 owner-ipdvb@erg.abdn.ac.uk Mon Feb 21 09:48:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02743 for ; Mon, 21 Feb 2005 09:48:17 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3FDU-0003Lh-Hw for ipdvb-archive@ietf.org; Mon, 21 Feb 2005 10:11:22 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j1LE8XRa024387 for ; Mon, 21 Feb 2005 14:08:34 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j1LE8XPR024386 for ipdvb-subscribed-users; Mon, 21 Feb 2005 14:08:33 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from smtp01.sciatl.com (smtp01.sciatl.com [192.133.193.52]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j1LE7T3d024360 for ; Mon, 21 Feb 2005 14:07:30 GMT Received: from mail pickup service by smtp01.sciatl.com with Microsoft SMTPSVC; Mon, 21 Feb 2005 09:08:08 -0500 X-Envelope-From: owner-ipdvb@erg.abdn.ac.uk X-Received-From-Address: 139.133.204.77 thread-index: AcUX/vEl9yZTgFibTIqI4WStlEqEAA== X-Envelope-To: Alex.Luccisano@sciatl.com Content-Class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.132 Received: from erg.abdn.ac.uk ([139.133.204.77]) by mailman.sciatl.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Feb 2005 05:20:17 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j1LAENaJ018057 for ; Mon, 21 Feb 2005 10:14:23 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j1LAEM5j018056 for ipdvb-subscribed-users; Mon, 21 Feb 2005 10:14:22 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j1LADh7g018029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 21 Feb 2005 10:13:43 GMT Message-ID: <4219B457.6090409@erg.abdn.ac.uk> Date: Mon, 21 Feb 2005 10:13:43 +0000 From: "Gorry Fairhurst" Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Subject: Re: I-D ACTION:draft-stiemerling-ipdvb-config-00.txt (fwd) References: <3FE10A5C09BEE173EDC46BFA@[10.0.1.2]> In-Reply-To: <3FE10A5C09BEE173EDC46BFA@[10.0.1.2]> Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean, Found to be clean, Found to be clean X-OriginalArrivalTime: 21 Feb 2005 10:20:17.0921 (UTC) FILETIME=[F0CFCF10:01C517FE] Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit 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@ietf.org > To: i-d-announce@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@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@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 owner-ipdvb@erg.abdn.ac.uk Wed Feb 23 12:52:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19088 for ; Wed, 23 Feb 2005 12:52:53 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D413i-0002if-9G for ipdvb-archive@ietf.org; Wed, 23 Feb 2005 13:16:26 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j1NHISwP005047 for ; Wed, 23 Feb 2005 17:18:28 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j1NHISI1005046 for ipdvb-subscribed-users; Wed, 23 Feb 2005 17:18:28 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from mailg.surrey.ac.uk (mailg.surrey.ac.uk [131.227.102.21]) by erg.abdn.ac.uk (8.12.11/8.12.11) with SMTP id j1NHHa95005013 for ; Wed, 23 Feb 2005 17:17:36 GMT Received: from ads33.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Wed, 23 Feb 2005 17:16:07 +0000 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads33.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Feb 2005 17:16:02 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Call for inputs for IETF-62 (Minneapolis) 6-11 March 2005 Date: Wed, 23 Feb 2005 17:16:01 -0000 Message-ID: Thread-Topic: Call for inputs for IETF-62 (Minneapolis) 6-11 March 2005 Thread-Index: AcT9N11/JHy/miWoTZCKpM/jApjgkwcjpvAA From: "H.Cruickshank" To: ipdvb Cc: "Laurence.Duquerroy" , "Stephane.Combes" , "S.Iyengar" X-OriginalArrivalTime: 23 Feb 2005 17:16:02.0211 (UTC) FILETIME=[5997E730:01C519CB] X-ERG-MailScanner: Found to be clean, Found to be clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by erg.abdn.ac.uk id j1NHIQjE005043 Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 8bit 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@surrey.ac.uk http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ -----Original Message----- From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On Behalf Of Gorry Fairhurst Sent: 17 January 2005 17:59 To: ipdvb@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 owner-ipdvb@erg.abdn.ac.uk Thu Feb 24 03:28:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16018 for ; Thu, 24 Feb 2005 03:28:30 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Ej9-0006QR-Fb for ipdvb-archive@ietf.org; Thu, 24 Feb 2005 03:52:10 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j1O7reiZ025204 for ; Thu, 24 Feb 2005 07:53:41 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j1O7redc025202 for ipdvb-subscribed-users; Thu, 24 Feb 2005 07:53:40 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from [10.0.1.110] (maxp12.abdn.ac.uk [139.133.7.171]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j1O7q76l025148 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 24 Feb 2005 07:52:10 GMT User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 24 Feb 2005 07:53:00 +0000 Subject: Re: Call for inputs for IETF-62 (Minneapolis) 6-11 March 2005 From: Gorry Fairhurst To: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: 7bit 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@surrey.ac.uk > http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ > > > > -----Original Message----- > From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On > Behalf Of Gorry Fairhurst > Sent: 17 January 2005 17:59 > To: ipdvb@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 owner-ipdvb@erg.abdn.ac.uk Thu Feb 24 16:45:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25158 for ; Thu, 24 Feb 2005 16:45:51 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Qnx-0005Fc-Bj for ipdvb-archive@ietf.org; Thu, 24 Feb 2005 16:45:53 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j1OLMZLF015593 for ; Thu, 24 Feb 2005 21:22:35 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j1OLMZ8r015592 for ipdvb-subscribed-users; Thu, 24 Feb 2005 21:22:35 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j1OLLcK0015546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 24 Feb 2005 21:21:39 GMT Message-ID: <421E4562.9060101@erg.abdn.ac.uk> Date: Thu, 24 Feb 2005 21:21:38 +0000 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: AGENDA for ipdvb meeting, at IETF-62, Monday 7th March 19:30-22:00 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Please find below the Agenda for the ipdvb WG to be held at IETF-62. Best wishes, Gorry (ipdvb WG Chair) gorry@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 owner-ipdvb@erg.abdn.ac.uk Thu Feb 24 17:33:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25160 for ; Thu, 24 Feb 2005 16:45:51 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Qnx-0005Fb-E3 for ipdvb-archive@ietf.org; Thu, 24 Feb 2005 16:45:53 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j1OL7HAq015265 for ; Thu, 24 Feb 2005 21:07:17 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j1OL7HwH015264 for ipdvb-subscribed-users; Thu, 24 Feb 2005 21:07:17 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j1OL6gLV015237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 24 Feb 2005 21:06:43 GMT Message-ID: <421E41E3.3070104@erg.abdn.ac.uk> Date: Thu, 24 Feb 2005 21:06:43 +0000 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: I-D ACTION:draft-bormann-rohc-over-802-01.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit 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 owner-ipdvb@erg.abdn.ac.uk Fri Feb 25 10:14:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25709 for ; Fri, 25 Feb 2005 10:14:57 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4hBH-0003Bl-6k for ipdvb-archive@ietf.org; Fri, 25 Feb 2005 10:15:09 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j1PEiS9x008580 for ; Fri, 25 Feb 2005 14:44:28 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j1PEiRjv008579 for ipdvb-subscribed-users; Fri, 25 Feb 2005 14:44:28 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from web25702.mail.ukl.yahoo.com (web25702.mail.ukl.yahoo.com [217.12.10.174]) by erg.abdn.ac.uk (8.12.11/8.12.11) with SMTP id j1PEhm43008551 for ; Fri, 25 Feb 2005 14:43:48 GMT Received: (qmail 47408 invoked by uid 60001); 25 Feb 2005 14:43:43 -0000 Message-ID: <20050225144343.47406.qmail@web25702.mail.ukl.yahoo.com> Received: from [192.102.214.6] by web25702.mail.ukl.yahoo.com via HTTP; Fri, 25 Feb 2005 14:43:43 GMT Date: Fri, 25 Feb 2005 14:43:43 +0000 (GMT) From: Stephen Bullers Subject: ULE Downlink required for decoding test To: ip-dvb@erg.abdn.ac.uk MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 8bit 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