From owner-ipdvb@erg.abdn.ac.uk Fri Dec 3 01:05:13 2004 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 BAA14901 for ; Fri, 3 Dec 2004 01:05: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 1Ca6en-0002gv-Vo for ipdvb-archive@ietf.org; Fri, 03 Dec 2004 01:11:06 -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 iB35hEWa021327 for ; Fri, 3 Dec 2004 05:43:14 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iB35hELY021326 for ipdvb-subscribed-users; Fri, 3 Dec 2004 05:43:14 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.ttml.co.in (smtp1.ttml.co.in [202.149.208.98]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iB35gSTT021304 for ; Fri, 3 Dec 2004 05:42:29 GMT Received: from [202.149.201.66] (Krishna.Vora@dg2l.com) by smtp1.ttml.co.in (Terrace MailWatcher) with ESMTP id 2004120311:06:12:727354.5631.259 for ; Fri, 03 Dec 2004 11:06:12 +0630 (IST) Subject: Multicast Query From: Krishna Vora To: ip-dvb@erg.abdn.ac.uk Content-Type: text/plain Organization: DG2L Technologies Message-Id: <1102052663.2121.8.camel@dg2l-dpc29> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 03 Dec 2004 11:14:23 +0530 Content-Transfer-Encoding: 7bit X-TERRACE-SPAMRATE: g=0.56 l=0.00 NOT YET spam-rated. 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: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Hi, I would like to have some information regarding use of Multicast IP for a DVB-S Set Top Box scenario. Is the STB user required to first contact some network centre to be a part of a multicast group. Similarly how is the multicast MAC addressing done? -- Regards, Krishna Vora From owner-ipdvb@erg.abdn.ac.uk Fri Dec 3 04:50:37 2004 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 EAA16901 for ; Fri, 3 Dec 2004 04:50: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 1CaAAy-0007FX-Kj for ipdvb-archive@ietf.org; Fri, 03 Dec 2004 04:56:33 -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 iB39NJxc024910 for ; Fri, 3 Dec 2004 09:23:19 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iB39NIKV024909 for ipdvb-subscribed-users; Fri, 3 Dec 2004 09:23:18 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 iB39M23F024875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 3 Dec 2004 09:22:03 GMT Message-ID: <41B0303A.2010208@erg.abdn.ac.uk> Date: Fri, 03 Dec 2004 09:22:02 +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: Multicast Query References: <1102052663.2121.8.camel@dg2l-dpc29> In-Reply-To: <1102052663.2121.8.camel@dg2l-dpc29> 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: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Krishna Vora wrote: > Hi, > > I would like to have some information regarding use of Multicast IP for > a DVB-S Set Top Box scenario. Is the STB user required to first contact > some network centre to be a part of a multicast group. > Similarly how is the multicast MAC addressing done? > > In ULE the rules for multicast MAC addressing are described in section 4.5, " 4.5 SNDU Destination Address Field The SNDU Destination Address Field is optional (see section 4.1). This field MUST be carried (i.e. D=0) for IP unicast packets destined to routers that are sent using shared links (i.e., where the same link connects multiple Receivers). A sender MAY omit this field (D=1) for an IP unicast packet and/or multicast packets delivered to Receivers that are able to utilise a discriminator field (e.g. the IPv4/IPv6 destination address), which in combination with the PID value, could be interpreted as a Link-Level address. When the SNDU header indicates the presence of a SNDU Destination Address field (i.e. D=0), a Network Point of Attachment, NPA, field directly follows the SNDU Type Field. NPA destination addresses are 6 Byte numbers, normally expressed in hexadecimal, used to identify the Receiver(s) in a MPEG-2 transmission network that should process a received SNDU. The value 0x00:00:00:00:00:00, MUST NOT be used as a destination address in a SNDU. The least significant bit of the first byte of the address is set to 1 for multicast frames, and the remaining bytes specify the link layer multicast address. The specific value 0xFF:FF:FF:FF:FF:FF is the link broadcast address, indicating this SNDU is to be delivered to all Receivers. " The draft is available from: http://www.ietf.org/internet-drafts/draft-ietf-ipdvb-ule-03.txt Gorry From owner-ipdvb@erg.abdn.ac.uk Fri Dec 3 10:30:45 2004 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 KAA16272 for ; Fri, 3 Dec 2004 10:30:45 -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 1CaFU9-00064R-LN for ipdvb-archive@ietf.org; Fri, 03 Dec 2004 10:36:44 -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 iB3F6BJv002921 for ; Fri, 3 Dec 2004 15:06:11 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iB3F6Aca002920 for ipdvb-subscribed-users; Fri, 3 Dec 2004 15:06: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 multicasttech.com (IDENT:root@lennon.multicasttech.com [63.105.122.7]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iB3F4BiT002857; Fri, 3 Dec 2004 15:04:12 GMT Received: from [70.179.108.186] (account ) by multicasttech.com (CommuniGate Pro WebUser 3.4.8) with HTTP id 2585433; Fri, 03 Dec 2004 10:03:16 -0500 From: "Marshall Eubanks" Subject: Re: Multicast Query To: ipdvb@erg.abdn.ac.uk, ipdvb@erg.abdn.ac.uk X-Mailer: CommuniGate Pro Web Mailer v.3.4.8 Date: Fri, 03 Dec 2004 10:03:16 -0500 Message-ID: In-Reply-To: <41B0303A.2010208@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-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 8bit On Fri, 03 Dec 2004 09:22:02 +0000 Gorry Fairhurst wrote: > Krishna Vora wrote: > > Hi, > > > > I would like to have some information regarding use of Multicast IP for > > a DVB-S Set Top Box scenario. Is the STB user required to first contact > > some network centre to be a part of a multicast group. > > Similarly how is the multicast MAC addressing done? > > Multicast group address allocations are described by rfc3171 (and its references) http://www.ietf.org/rfc/rfc3171.txt The 239/8 address range is analgous to 10/8 for unicast (i.e., these are internal addresses that can be used freely as long as they don't leak out). > > > > In ULE the rules for multicast MAC addressing are described in section 4.5, > > " 4.5 SNDU Destination Address Field > > The SNDU Destination Address Field is optional (see section 4.1). > This field MUST be carried (i.e. D=0) for IP unicast packets > destined to routers that are sent using shared links (i.e., where > the same link connects multiple Receivers). A sender MAY omit this > field (D=1) for an IP unicast packet and/or multicast packets > delivered to Receivers that are able to utilise a discriminator > field (e.g. the IPv4/IPv6 destination address), which in combination > with the PID value, could be interpreted as a Link-Level address. > > When the SNDU header indicates the presence of a SNDU Destination > Address field (i.e. D=0), a Network Point of Attachment, NPA, field > directly follows the SNDU Type Field. NPA destination addresses are > 6 Byte numbers, normally expressed in hexadecimal, used to identify > the Receiver(s) in a MPEG-2 transmission network that should process > a received SNDU. The value 0x00:00:00:00:00:00, MUST NOT be used as > a destination address in a SNDU. The least significant bit of the > first byte of the address is set to 1 for multicast frames, and th In IP multicast, there is a mapping between the IP Group address of the multicast, and the MAC address. For example, in IPv4, multicast MAC addresses start with 01:00:5E, followed by a zero bit, followed by the low order 23 bits of the multicast group address. Was there a specific reason why not to follow this ? Regards Marshall Eubanks > remaining bytes specify the link layer multicast address. The > specific value 0xFF:FF:FF:FF:FF:FF is the link broadcast address, > indicating this SNDU is to be delivered to all Receivers. " > > The draft is available from: > > http://www.ietf.org/internet-drafts/draft-ietf-ipdvb-ule-03.txt > > Gorry > From owner-ipdvb@erg.abdn.ac.uk Fri Dec 3 10:58:41 2004 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 KAA19246 for ; Fri, 3 Dec 2004 10:58:41 -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 1CaFvE-0006rs-5R for ipdvb-archive@ietf.org; Fri, 03 Dec 2004 11:04: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 iB3FfAtr003868 for ; Fri, 3 Dec 2004 15:41:10 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iB3Ff97X003865 for ipdvb-subscribed-users; Fri, 3 Dec 2004 15:41: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 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 iB3FeLuW003827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 3 Dec 2004 15:40:22 GMT Message-ID: <41B088E6.3060102@erg.abdn.ac.uk> Date: Fri, 03 Dec 2004 15:40:22 +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: Multicast Query 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: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit Marshall Eubanks wrote: > On Fri, 03 Dec 2004 09:22:02 +0000 > Gorry Fairhurst wrote: > >>Krishna Vora wrote: >> >>>Hi, >>> >>>I would like to have some information regarding use of Multicast IP for >>>a DVB-S Set Top Box scenario. Is the STB user required to first contact >>>some network centre to be a part of a multicast group. >>>Similarly how is the multicast MAC addressing done? >>> > > > Multicast group address allocations are described by rfc3171 (and its references) > > http://www.ietf.org/rfc/rfc3171.txt > > The 239/8 address range is analgous to 10/8 for unicast (i.e., these are internal addresses that can > be used freely as long as they don't leak out). > > > >>In ULE the rules for multicast MAC addressing are described in section 4.5, >> >>" 4.5 SNDU Destination Address Field >> >> The SNDU Destination Address Field is optional (see section 4.1). >> This field MUST be carried (i.e. D=0) for IP unicast packets >> destined to routers that are sent using shared links (i.e., where >> the same link connects multiple Receivers). A sender MAY omit this >> field (D=1) for an IP unicast packet and/or multicast packets >> delivered to Receivers that are able to utilise a discriminator >> field (e.g. the IPv4/IPv6 destination address), which in combination >> with the PID value, could be interpreted as a Link-Level address. >> >> When the SNDU header indicates the presence of a SNDU Destination >> Address field (i.e. D=0), a Network Point of Attachment, NPA, field >> directly follows the SNDU Type Field. NPA destination addresses are >> 6 Byte numbers, normally expressed in hexadecimal, used to identify >> the Receiver(s) in a MPEG-2 transmission network that should process >> a received SNDU. The value 0x00:00:00:00:00:00, MUST NOT be used as >> a destination address in a SNDU. The least significant bit of the >> first byte of the address is set to 1 for multicast frames, and th > > > > In IP multicast, there is a mapping between the IP Group address > of the multicast, and the MAC address. For example, in IPv4, > multicast MAC addresses start with 01:00:5E, followed by a zero bit, followed > by the low order 23 bits of the multicast group address. Was there a > specific reason why not to follow this ? > > Regards > Marshall Eubanks > The MAC address format in the spec above is consistent with what you say, (and also with the similar mapping used in IPv6). That is "01" in 01:00:5E sets bit zero of the first byte. > > >> remaining bytes specify the link layer multicast address. The >> specific value 0xFF:FF:FF:FF:FF:FF is the link broadcast address, >> indicating this SNDU is to be delivered to all Receivers. " >> >>The draft is available from: >> >>http://www.ietf.org/internet-drafts/draft-ietf-ipdvb-ule-03.txt >> >>Gorry >> > Gorry Fairhurst. From owner-ipdvb@erg.abdn.ac.uk Mon Dec 6 09:47:39 2004 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 JAA18071 for ; Mon, 6 Dec 2004 09:47:39 -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 1CbKFj-0006cu-J8 for ipdvb-archive@ietf.org; Mon, 06 Dec 2004 09:54: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 iB6E76Un017681 for ; Mon, 6 Dec 2004 14:07:07 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iB6E76fL017680 for ipdvb-subscribed-users; Mon, 6 Dec 2004 14:07: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 Outgoing-SMTP.gilat.com ([199.203.106.52]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iB6E6axi017662 for ; Mon, 6 Dec 2004 14:06:37 GMT Received: from mail.gilat.com (unverified) by Outgoing-SMTP.gilat.com (Content Technologies SMTPRS 4.2.10) with ESMTP id for ; Mon, 6 Dec 2004 16:08:08 +0200 Received: by gilat-ex.gilat.com with Internet Mail Service (5.5.2650.21) id ; Mon, 6 Dec 2004 16:07:23 +0200 Message-ID: <4937F3760ADC614BA4C8F1642FF911CE02D8F8BA@gexd.gilat.com> From: Dor Snapir - Israel To: "'ipdvb@erg.abdn.ac.uk'" Subject: RE: SkyStream SMR-24 info Date: Mon, 6 Dec 2004 16:08:07 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-8" 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: d6b246023072368de71562c0ab503126 What would you like to know? Dor S. -----Original Message----- From: Stefan Baryakov [mailto:stefan@telecom-bg.com] Sent: Tuesday, November 23, 2004 6:22 PM To: ip-dvb@erg.abdn.ac.uk Subject: SkyStream SMR-24 info Hi all, Does someone here have a user manuals for SkyStream SMR-24 ? Any help will be highly appreciated. I apologize if this is off topic. Thanks ! Stefan B. From owner-ipdvb@erg.abdn.ac.uk Tue Dec 7 04:43:24 2004 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 EAA06362 for ; Tue, 7 Dec 2004 04:43:24 -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 1Cbbz1-0006Si-Ci for ipdvb-archive@ietf.org; Tue, 07 Dec 2004 04:50:12 -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 iB79IYNC010981 for ; Tue, 7 Dec 2004 09:18:34 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iB79IYDl010980 for ipdvb-subscribed-users; Tue, 7 Dec 2004 09:18:34 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 iB79HwSi010956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 7 Dec 2004 09:17:59 GMT Message-ID: <41B57547.4090602@erg.abdn.ac.uk> Date: Tue, 07 Dec 2004 09:17:59 +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: IETF-61 DRAFT NOTES. 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 iB79IYNC010981 X-Spam-Score: 2.6 (++) X-Scan-Signature: ba0d4c5f57f7c289496fce758bbf4798 Content-Transfer-Encoding: quoted-printable The following text provides the draft notes. Thanks are due to our two=20 note-takers: Carsten Bormann and J=F6rg Ott. These are formatted for the=20 proceedings of IETF-61. Please could people in the Working Group check th= em,=20 and send any corrections/additions a.s.a.p.. Best wishes, Gorry Fairhurst ---------- Minutes of the IPDVB WG (IETF-61) --------------------------------- Chair: Gorry Fairhurst (gorry@erg.abdn.ac.uk) Notes by Carsten Bormann and J=F6rg Ott 1. Agenda Bashing (Gorry Fairhurst) The IPDVB WG met once at the 61st IETF for a two-hour slot. The meeting was attended by approximately 30 participants. The proposed agenda was accepted (with one addition made later during the meeting). G= orry=20 noted that the IETF-hosted ftp archive of the mailing list for the IPDVB WG is now operational, as a backup to the existing WG archive. 2. Working Group Status and Plans (Gorry Fairhurst) Gorry provided an overview of the current status of the documents and the working group as a whole. The two current WG drafts are nearing completion; the generic parts of the XULE draft were integrated into the ULE draft, but specific XULE features were left out (these are a possible item of future work within this group). The working group has successfully completed two milestones and is slightly lagging behind on four others. The main focus of the meeting is on new work items: address resolution and XML receiver configuration. 3. Requirements/Framework (Marie-Jose Montpetit) draft-ietf-arch-01.txt Marie-Jos=E9 presented the status of the architecture document. Its main purpose is to establish terminology, define implementation scenarios (richer than just use cases), discuss the relationship to existing work (ATSC, DVB, ISO, etc.), and to establish requirements for the WG. She noted that the scope of the work has expanded from a focus on encapsulation to a rather complete system solution, and from satellite links to a broader coverage including terrestrial networks. After briefly reviewing the scenarios, Marie-Jos=E9 discussed the changes since the last revision and the comments raised during WGLC. Besides a few nits, only one technical open issue remains: Shall link security be mandatory or optional? Once this issue is resolved, the updated document will be posted and shall be considered for publication as Informational RFC. Comments from the group clearly indicated that security should not be mandated: Layer 3 security is available, so that specific link layer mechanisms are not needed in many cases. Also, security is highly application-dependent. Link-layer security would require key management to be defined. Gorry noted that those comments are in favor of the current text. The draft will be updated to incorporate all comments received on the list and during the meeting, and passed to the AD for review. 4. Ultra Lightweight Encapsulation (Gorry Fairhurst) draft-ietf-ule-02.txt Gorry presented an update to the ULE specification ID and reviewed the -- largely minor -- changes to the document. The major technical modification is the inclusion of the ULE extension mechanisms in section 5. Gorry noted an issue in the processing rules: What to do when the CRC fails in a previous packed SNDU? Two options were available: a) discard corrupted SNDU and enter idle state (conservative - required in previous revisions of the ULE draft); b) discard corrupted SNDU and continue unpacking next (liberal). Commenters pointed out that this is a local implementation decision and that both can be allowed. The authors plan to look at the current text, to examine the implications on interoperability from relaxing the wording. There was also a request that the draft should be updated to to say why this issue needs consideration. This issue was taken to the list for further discussion. Known ULE implementations are listed at: http://www.erg.abdn.ac.uk/ipdvb/ipdvb-impl.html; information about other implementations is solicited so that the list can be updated. The IANA consideration section has been updated. The group needs to decide on the policy for registrations of new ULE extension headers: should an RFC suffice or should standards track be required? Comments were made that a strong specification level (i.e., standards track) should be required (only a few extensions are envisioned anyway, this should not be issue). It is planned to have a new revision of the draft available by the end of November. It should then be ready for WGLC. 5. ULE Extension Headers (Gorry Fairhurst) draft-collini-xule-00.txt Gorry briefly outlined the evolution of the ULE extension headers draft since the last IETF. Its main features were defining the extension header format that is now included in the base ULE spec. Hence, there is little reason to the draft around. Gorry proposed to simply let it expire -- which was accepted. 6. Address Resolution (Marie-Jose Montpetit) draft-fair-ipdvb-ar-02.txt Marie-Jos=E9 presents the draft on address resolution for IP/DVB. It is based on the requirements for address resolution described in the architecture draft. Table-based mechanisms for IP-to-MPEG-2 address and IP-to-MAC address mapping will be reviewed (including known/solved issues). The changes since the last revision include: splitting the document into two parts to strictly separate the review of existing stuff from a newly proposed protocol; adding another co-author (Hidetaka Izumiyama); adding the Wishnet experiments with IPv6; and various editorial changes. Marie-Jos=E9 solicits input from the working group on more specific implementations: INT usage for IP/PID; IP/MAC resolution; DHCP and NAT; DVB-RCS use cases (e.g. MMT); MHP/OpenCable use cases (AIT, etc.). A new revision of the document will be made available by the end of December 2004. A document in this area should become a WG item in the mid-term. IETF protocol dependencies and issues are important: DHCP, NAT, UDLR, ARP, and ND. In the discussion, one question asked why NATs were considered relevant to address resolution; the implications on other=20 mechanisms needed to be considereted, but the address translation itself is a different issue. Marie-Jos=E9 said that, at this time, the authors were collecting information that may be relevant (and this may have an impact on how mapping tables are ultimately built). The potential relevance of the IETF BEHAVE WG was also mentioned, but the work in BEHAVE may be too specific. 7. XML for Receiver AR Config (Martin Stiemerling) Martin presented an overview of the design space for configuring IPDVB receivers and particularly discussed the pros and cons of XML-based approaches. The problem space to be solved includes IP address and stack configuration, service-related configuration, among others. He identified three issues to discuss: the configuration scenarios, what exactly to configure, and which mechanisms to apply for a configuration. As related areas, Martin mentioned IPCDN, DOCSIS, and DVB (with SI tables) layer 2 and DHC, NETCONF, and basic IP mechanisms (such as neighbor discovery) at layer 3(+). Some discussion arose concerning why XML should be used and why tables are suggested instead of the existing IP mechanisms. Those issues are addressed later. Martin described two configuration scenarios: 1) in the IP configuration scenario, underlying (DVB) mechanisms are already up and running and configuration essentially comprises IP-layer parameters. 2) In the complete bootstrap case, the configuration must start from scratch and requires to configure the DVB layer as well. Martin also identified a set of issues to be discussed, including: Who is in control of the receiver? - several scenarios exist, some controlled by an operator, some configured by a user. Scale: The difference in scale (10^5 receivers) compared to a few for NETCONF and 10^3 for IPCDN. Martin concluded in stating that is too early to define parameters. Rather, usage scenarios need to be defined, then related techniques should be explored to learn from these. Commenters recommended that the WG first looked at how to use existing protocols (that may also be used in a uni-directional way), and see how much can be done using existing mechanisms (this may also depend on whether there is also Internet connectivity via other links, or only via a single link). Some changes may be needed to the existing protocols. It was noted that the information required can vary between scenarios. Comments were made that it is important to keep things simple. Some further debate arose around the merits of and issues with using XML (at this layer). Marie-Jos=E9 also pointed to a draft on address resolution and configuration based upon XML (which she presented later). A separation was suggested between "Address Resolution (identification of sender/receiver)" and "Address Mapping (to lower layers)". 8. Receiver AR Config/Protocol (Gorry Fairhurst, Marie-Jos=E9 Montpetit, Joerg Ott) draft-mjm-ipdvb-config-00.txt (see mailing list) Later published as: draft-montpetit-ipdvb-config-00.txt draft-ietf-mmusic-img-req-07.txt draft-ietf-mmusic-img-framework-08.txt Marie-Jos=E9 introduced an XML-based AR configuration protocol. This approach built upon existing table-based mechanisms, but used XML syntax. It defines a simple autoconf protocol for extended AR records and builds on existing protocols where possible. She discussed a number of requirements, including: extensible syntax (e.g., to represent future fields), optimizations for large-scale multicast, and support for source/destination scoping. The presentation suggested an XML syntax. Delivery mechanisms may comprise SOAP, UDP, and SIP. Marie-Jos=E9 said there w3as running code for the proposed solution and there is interest and participation from the different industries that make up the MPEG-2 community. Joerg Ott pointed to work on Internet Media Guides (IMG) that is on-going in MMUSIC (in the IETF Transport Area) that may be suitable for higher layer service announcement aspects. This was briefly presented in a -- dynamically added -- presentation after the one given by Marie-Jos=E9. Joerg Ott presented an overview of the work on Internet Media Guides (IMGs) as presently undertaken in the MMUSIC WG (where it was started some 1.5 years ago). The work is motivated by the need to provide powerful generic mechanisms for disseminating content and service information in various networks (including DVB, UMTS, and plain IP networks, among others). The concept of IMGs defines mechanisms to communicate metadata (about content, services, and also configurations) from one or more IMG sender via zero, one, or more intermediaries (IMG transceivers) to any number of IMG receivers. IMG metadata -- formats for which are not defined in MMUSIC -- are encapsulated in IMG envelopes and transported using different IMG operations: ANNOUNCE for multicast/broadcast dissemination, QUERY/RESOLVE for receiver-side inquiries (polling) to a server, and SUBSCRIBE/NOTIFY for asynchronous notifications. These operations are realized using FLUTE, HTTP, and SIP, respectively. As IMGs are agnostic to the content format, (XML or otherwise encoded) high-level configuration information could be distributed via IMG mechanisms. The reliable multicast support appears particularly applicable for a DVB environment. Authentication of source is also impor= tant. Comments from the audience suggest that this may be very applicable, not necessarily at the IP layer (as Gorry pointed out). Joerg made the point that this is clearly not meant for IP stack configuration, but for higher layer information. Hence there is a "vertical" split between IMG and DVB/IP layer config -- which is well-recognized. Argument= s=20 were made that the address resolution mechanism should not reach too far = up=20 into higher layer aspects, but be very restrictive. Some intermediate MP= EG-2=20 devices currently have no IP-stack, and simple clients would be needed.=20 Higher layer aspects could be dealt with by work such as IMGs working wit= h=20 other IETF WGs. 9. Review of Milestones (Gorry Fairhurst) Gorry reviewed the WG milestones. The two initial milestones have been met (for the architecture and the ULE document), but their completion is lagging behind. While the address resolution is progressing, the=20 respective future milestones will likely need adjustment. These Charter=20 changes will be agreed with our responsible Area Director (Margaret). From owner-ipdvb@erg.abdn.ac.uk Thu Dec 9 06:57:12 2004 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 GAA15746 for ; Thu, 9 Dec 2004 06:57:12 -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 1CcN23-0003LM-3t for ipdvb-archive@ietf.org; Thu, 09 Dec 2004 07:04: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 iB9BP75o016219 for ; Thu, 9 Dec 2004 11:25:07 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iB9BP6KC016218 for ipdvb-subscribed-users; Thu, 9 Dec 2004 11:25: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 [10.0.1.108] (maxp4.abdn.ac.uk [139.133.7.163]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iB9BOBfm016194 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 9 Dec 2004 11:24:16 GMT User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 09 Dec 2004 11:24:42 +0000 Subject: I-D ACTION:draft-ietf-ipdvb-arch-02.txt From: Gorry Fairhurst To: 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: d8ae4fd88fcaf47c1a71c804d04f413d 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 : A Framework for transmission of IP datagrams over MPEG-2 Networks Author(s) : M. Montpetit, et al. Filename : draft-ietf-ipdvb-arch-02.txt Pages : 39 Date : 2004-12-7 This document describes an architecture for the transport of IP Datagrams over ISO MPEG-2 Transport Streams (TS). The MPEG-2 TS has been widely accepted not only for providing digital TV services, but also as a subnetwork technology for building IP networks. Examples of systems using MPEG-2 include the Digital Video Broadcast (DVB) and Advanced Television Systems Committee (ATSC) Standards for Digital Television. The document identifies the need for a set of Internet standards defining the interface between the MPEG-2 Transport Stream and an IP subnetwork. It suggests a new encapsulation method for IP datagrams and proposes protocols to perform IPv6/IPv4 address resolution, to associate IP packets with the properties of the Logical Channels provided by an MPEG-2 TS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipdvb-arch-02.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-arch-02.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-arch-02.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 Fri Dec 10 11:01:46 2004 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 LAA25775 for ; Fri, 10 Dec 2004 11:01:46 -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 1CcnKV-0007sI-Jz for ipdvb-archive@ietf.org; Fri, 10 Dec 2004 11:09:16 -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 iBAFT1u9022223 for ; Fri, 10 Dec 2004 15:29:01 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iBAFT0B1022222 for ipdvb-subscribed-users; Fri, 10 Dec 2004 15:29: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 iBAFRuI1022161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 10 Dec 2004 15:27:58 GMT Message-ID: <41B9C07C.1080209@erg.abdn.ac.uk> Date: Fri, 10 Dec 2004 15:27:56 +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: WGLC Reminder: draft-ietf-ipdvb-arch-01.txt for 15th December 2004 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: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit As WG Chair: http://www.ietf.org/internet-drafts/draft-ietf-ipdvb-ule-03.txt or The WGLC for the above ID is due to end at midnight 15/12/2004. Please ensure that you send an email to the ipdvb list if there are ANY issues which you think may require further discussion or any comments/corrections. It would also be most useful to email, if you have read the document and have no comments (or just minor corrections). If you would like to see a comparision with the last rev (which was mostly stable), then please do see the "differences" file at: http://www.erg.abdn.ac.uk/ip-dvb/ids/rfcdiff-ule-02-03.html Gorry Fairhurst (IPDVB WG CHAIR) From owner-ipdvb@erg.abdn.ac.uk Tue Dec 14 09:22:15 2004 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 JAA00361 for ; Tue, 14 Dec 2004 09:22: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 1CeDhB-0001vM-F8 for ipdvb-archive@ietf.org; Tue, 14 Dec 2004 09:30:34 -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 iBEDxPCC009928 for ; Tue, 14 Dec 2004 13:59:25 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iBEDxPi9009927 for ipdvb-subscribed-users; Tue, 14 Dec 2004 13:59: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 nab.org (foxtrot.nab.org [209.116.240.194]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iBEDvTrx009857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 14 Dec 2004 13:57:31 GMT Received: from ([199.29.3.1]) by maildc2.nab.org with ESMTP id 4028857.3228507; Tue, 14 Dec 2004 08:57:05 -0500 Received: by mail.NAB.ORG with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Dec 2004 08:57:05 -0500 Message-ID: <5A659834E1607E4EBD72FCE2FE5C9CF10ADB4729@mail.NAB.ORG> From: "Allison, Art" To: ipdvb@erg.abdn.ac.uk Subject: FW: Delivery Notification Date: Tue, 14 Dec 2004 08:57:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C4E1E4.CB51B820" 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: cdb443e3957ca9b4c5b55e78cfcf4b26 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C4E1E4.CB51B820 Content-Type: text/plain Retrying -----Original Message----- From: "Postmaster" [mailto:"Postmaster"] Sent: Saturday, December 11, 2004 10:58 AM To: "Undisclosed Recipient" Subject: Delivery Notification This is a delivery status notification, automatically generated by MTA maildc2.nab.org on Sat, 11 Dec 2004 10:58:20 -0500 Regarding recipient(s) : ipdvb@erg.abdn.ac.uk Delivery status : Failed. None of the mail servers for the destination domain has so far responded. (erg.abdn.ac.uk). We have been attempting delivery for 5 times. Maximum delivery tries attempted. Please contact your administrator to contact the destination domain or resend your message. Delivery failed. Message Information: Sender : aallison@nab.org Recipient : ipdvb@erg.abdn.ac.uk MTA Response :4.4.1 The original message is included as attachment. ------_=_NextPart_000_01C4E1E4.CB51B820 Content-Type: application/octet-stream; name="ATT100174.TXT" Content-Disposition: attachment; filename="ATT100174.TXT" Reporting-MTA: dns; maildc2.nab.org Final-Recipient: rfc822;ipdvb@erg.abdn.ac.uk Diagnostic-Code: smtp; 4.4.1 None of the mail servers for the destination domain has so far responded. Action: failed Status: 4.0.0 ------_=_NextPart_000_01C4E1E4.CB51B820 Content-Type: message/rfc822 Message-ID: <5A659834E1607E4EBD72FCE2FE5C9CF10ADB46F2@mail.NAB.ORG> From: "Allison, Art" To: ipdvb@erg.abdn.ac.uk Subject: RE: WG Last-Call (WGLC) for comments: draft-ietf-ipdvb-ule-03.txt Date: Fri, 10 Dec 2004 10:55:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C4E1E4.CB51B820" ------_=_NextPart_002_01C4E1E4.CB51B820 Content-Type: text/plain Please find comments below. There is a chance that I will be able to return to the document and complete my review, but that may not happen. Broad issue - if the term being defined is in all caps, should not it be in all caps when that defined term is used? Or a rule that only initial caps are used after the all caps format should be pointed out. It is very bad to attempt, and I believe this draft must not, normatively redefine any ISO/IEC defined term. It may informatively list what another standard defines. Quick scan - Need work on MPEG term usage; Section 7 scoping; Refs should be updated from source web sited just b4 publications (A/53 is now A/53C, for example) MPEG term usage: @PRIVATE SECTION. While the use listed is one use, use of private sections is NOT constrained to only service information. It may be used for any Program data. It is not accurate to assert that all table sections must be carried over a single TS Logical Channel. Further attempting to assert the rules for such sections is in appropriate as 13818-1 rules. The draft should say, informatively, something like "ISO-MPEG requires that all table sections of a particular table _id must be carried in packets identified with a single PID. A packets with a given PID may contain data for more than one set of table sections. @p10 TABLE SECTION. Table sections are used for many purposes beside MPEG-2 SI. Users of MPEG-2 have added their own PSI[sic] table sections and employer them for other purposed. Also there may be private table sections that have any desired purpose. The point is they are related to any particular MPEG Program, not the System Information. @p10 seem to be missing PDU definition. @ p. 10, TS LOGICAL CHANNEL: Add 'unique' to: "...All packets sent over a TS Logical Channel carry the same unique PID value." PID values are required to be unique within each TS MULTIPLEX by MPEG-2 systems. @ p10-11 TS MULTIPLEX: Defining a TS MULTIPLEX in terms of the set of TS logical channels is an interesting way to view it, but as there is an internationally approved standard it would seem best to reference ISO/IEC 13818-1. It is NOT limited to a common physical link. Common physical links e.g., Ethernet, IEEE 1394, Satellite transponders can have more than one MPEG-2 transport stream. So the implication that the TS Logical Channel ID is unique to a physical link is incorrect. The last sentence in the definition is not wrong, but is not complete either. The same PID value can identify MPEG-2 packets with totally unrelated content in different TS MULTIPLEXes. @p11 Section 3. Asserting that ULE is limited to TS private streams seems underspecified. What is the means of identifying that this private use of a particular private stream_type is different from another's use of the same stream_type? It is a choice for the draft to be silent on how the PID value with these datagrams is found, but is seems that use of the MRD should be required in the PMT loop that has the private stream_type used by ULE. All programs must be listed per 13818-1, but that standard is silent on conflict resolution among private users. @p12 Section 3, 4th para. It is interesting that this receiver behavior is believed to be known. Particularly since the value 0xFF for table_id is expressly forbidden by ISO-MPEG. The meaning asserted is simply wrong. Padding (bytes of 0xFF) may occur in TS packets when a table section's content ends before the end of the TS packet. When they occur the following statements are correct. @p12 last para. The use and meaning of adaptation field is completely defined by ISO-MPEG. The assertion of its primary purpose does not appear relevant or needed and I would not agree with the word 'primary' . The assertion that values of 00 are discarded is interesting, and I would agree with the speculation that they should be ignored and discard the packets. The value '00' is not available for use, and discussion of anything but the requirement that the value 01 is required here seems unneeded. @p12 section 4. The sentence "Each SNDU is sent as a MPEG-2 Payload Unit." can be expanded to read '"Each Subnetwork Date Unit is sent as a MPEG-2 Payload Unit." But Payload Unit is a defined term here, meaning a sequence of bytes sent using a TS. So all this sentence says is each sequence of bytes is sent as a sequence of bytes. Was something more intended? It would seem that the order of the bits in each byte should be specified as well. MSBit first? @p 12-13 Section 4.1 and 4.2. The D field is shown as a separate field in figure 1 and then described as part of the Length field in the text. One can deduce that the length field bits are sent divided over two bytes and that the first byte has one bit that is unrelated to the length, but the field is not explicitly defined. The MSbyte is the one that has a bit that means Destination Address present, and it is the first bit sent? The MSB of the length field follows the D bit? Clarify. @section 4.4: bit order of the bytes in the field? @Section 4.5 :I don't see the location of this filed. Does the destination address field arrive just before the CRC? Section 4.1 says the D must be set to 0, unless an End indicator, yet this section says is 1 may be used for a non End Indicator situation. These sections need to be made consistent. What is the non-default situation and when can that be used? Why say "by default" in section 4.1? The situations for not using the default should be stated, if any exist. @Section 4.6 "...represented 0x104C11DB7..." is opaque in meaning. What is the ref for translating this and what does it mean? @Section 4.7 is this a receiver behavior spec section rather than a description of format section ( as it seems to be)? The format meanings were already specified..using slightly different words. ---far as I got--- 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: Tuesday, November 30, 2004 4:47 PM To: ipdvb@erg.abdn.ac.uk Subject: WG Last-Call (WGLC) for comments: draft-ietf-ipdvb-ule-03.txt This note starts the WG two week Last-Call for comments for the WG document named below: draft-ietf-ipdvb-ule-03.txt The Last-Call will end on 15/12/2004. Members of the IETF ipdvb WG are asked to read the above draft and send any issues, comments, or corrections to this mailing list. The WGLC procedure is the last chance for this working group to modify/correct this document. Please do forward any comments to the list. Best wishes, Gorry Fairhurst (ipdvb WG Chair) ------_=_NextPart_002_01C4E1E4.CB51B820-- ------_=_NextPart_000_01C4E1E4.CB51B820-- From owner-ipdvb@erg.abdn.ac.uk Tue Dec 14 23:01:16 2004 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 XAA24023 for ; Tue, 14 Dec 2004 23:01: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 1CeQTv-0000Ca-Pw for ipdvb-archive@ietf.org; Tue, 14 Dec 2004 23:09:44 -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 iBF3YJJf000253 for ; Wed, 15 Dec 2004 03:34:19 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iBF3YJTd000251 for ipdvb-subscribed-users; Wed, 15 Dec 2004 03:34:19 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 iBF3XMPn000212 for ; Wed, 15 Dec 2004 03:33:25 GMT Received: from localhost (localhost.localdomain [127.0.0.1]) by nrg.cs.usm.my (Postfix) with ESMTP id BEC112200DD for ; Wed, 15 Dec 2004 11:33:13 +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 09393-01 for ; Wed, 15 Dec 2004 11:33:13 +0800 (MYT) Received: from MOTANGKIA (unknown [10.207.140.69]) by nrg.cs.usm.my (Postfix) with ESMTP id 0E0B92200DC for ; Wed, 15 Dec 2004 11:33:13 +0800 (MYT) From: "Simon Teh" To: "Ip-DVB" Subject: MPE and ULE padding Date: Wed, 15 Dec 2004 11:33:01 +0800 Organization: NRG MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C4E299.D5B37C80" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcTiVsb6ZHln7u/+R4KjSlphLujFGA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: <20041215033313.0E0B92200DC@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: 0.0 (/) X-Scan-Signature: e654cfa5e44bd623be3eb2c720858b05 This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C4E299.D5B37C80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear all IP-DVB members, Good morning, I have several questions about ULE and MPE padding. As we know that the size of ULE and MPE are variable size (MTU 1500 bytes), so if the actual data is really small (maybe 2 bytes): My Questions: 1. Will it be padded until the PDU reach an expected length by MPE and ULE? 2. Do the MPE and ULE have a minimum size? If yes what is the minimum size for MPE and ULE? Thank you! Best Regards, Simon Teh Universiti Sains Malaysia ------=_NextPart_000_0000_01C4E299.D5B37C80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all IP-DVB members,<= /p>

 

Good morning, I h= ave several questions about ULE and MPE padding. As we know that the size of ULE and MPE are variable size (MTU 1500 bytes), so if the actual data is really= small (maybe 2 bytes):

 =

My Questions:

1.       Will it be padded= until the PDU reach an expected length by MPE and ULE?

2.       Do the MPE and UL= E have a minimum size? If yes what is the minimum size for MPE and ULE?

 

Thank you!

 

 

Best Regards,

Simon Teh

Universiti Sains Malaysia

 

------=_NextPart_000_0000_01C4E299.D5B37C80-- From owner-ipdvb@erg.abdn.ac.uk Wed Dec 15 09:35:14 2004 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 JAA03923 for ; Wed, 15 Dec 2004 09:35: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 1CeaNW-00076k-VC for ipdvb-archive@ietf.org; Wed, 15 Dec 2004 09:43:47 -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 iBFEC6FA013254 for ; Wed, 15 Dec 2004 14:12:06 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iBFEC6is013253 for ipdvb-subscribed-users; Wed, 15 Dec 2004 14:12: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 dobermann.cosy.sbg.ac.at (dobermann.cosy.sbg.ac.at [141.201.2.56]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iBFEB9CH013221 for ; Wed, 15 Dec 2004 14:11:10 GMT Received: by dobermann.cosy.sbg.ac.at (Postfix, from userid 102) id 8DDFAF9A32; Wed, 15 Dec 2004 15:11:10 +0100 (CET) Received: from [141.201.2.194] (wal.cosy.sbg.ac.at [141.201.2.194]) by dobermann.cosy.sbg.ac.at (Postfix) with ESMTP id DA53EF9A2B for ; Wed, 15 Dec 2004 15:11:08 +0100 (CET) Message-ID: <41C045DA.9060904@cosy.sbg.ac.at> Date: Wed, 15 Dec 2004 15:10:34 +0100 From: Wolfram Stering Organization: Dept. of Scientific Computing, Salzburg University User-Agent: Mozilla Thunderbird 0.9 (X11/20041127) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: Re: WG Last-Call (WGLC) for comments: draft-ietf-ipdvb-ule-03.txt References: <41ACEA54.6020507@erg.abdn.ac.uk> In-Reply-To: <41ACEA54.6020507@erg.abdn.ac.uk> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on dobermann.cosy.sbg.ac.at X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 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 Gorry Fairhurst wrote: > > This note starts the WG two week Last-Call for comments for the WG document > named below: > > draft-ietf-ipdvb-ule-03.txt > > The Last-Call will end on 15/12/2004. Following Gorry's call, please find below some comments: As implementors of draft-ietf-ipdvb-ule-03.txt, we discovered some issues that will be elaborated in the following paragraphs: 1. Section 5, related to fig. 10: The text says: "a 5-bit zero prefix and a 3-bit H-Len field", but the figure shows 4 bits zero and thus suggests 4 bit for H-Len. 2. Section 4.4.1, "Next Header Type Fields": When considering extension headers, type field values of 0x0000 (TEST SNDU), 0x0001 (BRIDGED SNDU), and 0x0100 (PADDING) are to be interpreted as mandatory extension headers. We propose to describe these in section 5 and state in 4.4.1 that type field values less than 1536 denote extension headers. 3. PADDING type: 0x0100 would decode as a 2 bytes long optional extension header, which is obviously not as intended. 4. Section 4.5, "SNDU Destination Address Field": If extension headers are used in combination with SNDU destination address (i.e. D-Bit is zero), it is not clear, where exactly the NPA address has to be placed, i.e. after which type field: after the last extension header or after the SNDU header (thus occupying bytes 5 to 10 of the SNDU). For ease of processing and filtering, we propose to have the NPA address' position fixed, directly following the 4-bytes SNDU header. An STB would have to decode all extension headers to find the NPA address, just to discover that it has to be dropped, if it doesn't match its own MAC address. 5. Bridged SNDUs: There is an inconsistency with respect to bridged SNDUs. As a bridged SNDU is declared as a mandatory extension header (H-Len = 0, H-Type = 1, see above), it could principally be chained with other extension headers. However, in the current version this is not possible as no other type field (next level header) can follow a bridged header (the bridged frame follows). 6. Bridging VLAN frames: There is a note in section 4.7.5, after figure 9, stating that a bridged SNDU could convey an 802.3 Ethernet frame (as opposed to the examples (fig. 8, fig. 9) containing an LLC/SNAP encapsulation. This note should be extended to also cover 802.1q frames (VLAN), which contain a 4-byte VLAN tag after the 2 Ethernet MAC addresses. We hope to contribute to a bullet-proof standard. best regards, Hilmar Linder Wolfram Stering -- Wolfram Stering, Department of Scientific Computing, Salzburg University Tel: +43 (0)662 8044 6334 Fax: +43 (0)662 8044 172 "If we knew what it was we were doing it would not be called research, would it?" From owner-ipdvb@erg.abdn.ac.uk Wed Dec 15 11:28:18 2004 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 LAA13557 for ; Wed, 15 Dec 2004 11:28: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 1Cec8y-0001en-8n for ipdvb-archive@ietf.org; Wed, 15 Dec 2004 11:36: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 iBFG2R4A015838 for ; Wed, 15 Dec 2004 16:02:27 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iBFG2Rus015837 for ipdvb-subscribed-users; Wed, 15 Dec 2004 16:02:27 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 iBFG0esF015790 for ; Wed, 15 Dec 2004 16:00:40 GMT Received: from [141.201.123.6] (embrace1.cosy.sbg.ac.at [141.201.123.6]) by loewe.cosy.sbg.ac.at (8.8.8/8.8.7) with ESMTP id RAA14659 for ; Wed, 15 Dec 2004 17:00:40 +0100 (MET) Message-ID: <41C05F8A.90609@cosy.sbg.ac.at> Date: Wed, 15 Dec 2004 17:00:10 +0100 From: Lutz Findeisen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: MPEG2 TS and ULE extension for Ethereal 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: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit hi, The Ethereal extension for parsing MPEG2 MPE and ULE is ready and can be downloaded form: http://www.network-research.org/mp2tsdis.html Regards, Lutz Findeisen From owner-ipdvb@erg.abdn.ac.uk Wed Dec 15 14:38:03 2004 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 OAA01779 for ; Wed, 15 Dec 2004 14:38:02 -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 1Cef6c-0007hI-BB for ipdvb-archive@ietf.org; Wed, 15 Dec 2004 14:46:38 -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 iBFJKfMJ021258 for ; Wed, 15 Dec 2004 19:20:41 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iBFJKelD021256 for ipdvb-subscribed-users; Wed, 15 Dec 2004 19:20: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 rproxy.gmail.com (rproxy.gmail.com [64.233.170.196]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iBFJJh6J021219 for ; Wed, 15 Dec 2004 19:19:44 GMT Received: by rproxy.gmail.com with SMTP id r35so1512834rna for ; Wed, 15 Dec 2004 11:19:43 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=A9G06U9hH8Lu04UvusXfbt0q3wKG6sa9E3a96XsYNe11cZc8zuCw7UH94Tg4FdXuKHLYn/DJkepA9Z9tlh1K/0FjM4Njd4ctk3NxX6xs+En2Ex4HSDfFrWFfZrtSRpCjtRrLbfgb6riqcnsucmuuCpNtyI/7dDWi87ATrcg31Pg= Received: by 10.38.12.73 with SMTP id 73mr2787242rnl; Wed, 15 Dec 2004 11:19:42 -0800 (PST) Received: by 10.38.81.77 with HTTP; Wed, 15 Dec 2004 11:19:42 -0800 (PST) Message-ID: Date: Wed, 15 Dec 2004 19:19:42 +0000 From: James Courtier-Dutton To: ipdvb@erg.abdn.ac.uk Subject: MPLS over satellite. 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: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit The use of MPLS to the CPE device on Cable Internet networks seems to be getting popular now. Are there any special considerations one should take into account, if one wished to use MPLS over Satellite networks. Maybe some bytes could be saved if one included a consideration for MPLS in the draft-ietf-ipdvb-ule-03.txt document. Kind Regards James From owner-ipdvb@erg.abdn.ac.uk Thu Dec 16 09:13:15 2004 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 JAA25041 for ; Thu, 16 Dec 2004 09:13: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 1CewW0-0001wk-04 for ipdvb-archive@ietf.org; Thu, 16 Dec 2004 09:22:01 -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 iBGDNm2X014110 for ; Thu, 16 Dec 2004 13:23:48 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iBGDNlGZ014109 for ipdvb-subscribed-users; Thu, 16 Dec 2004 13:23:47 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from web15703.mail.cnb.yahoo.com (web15703.mail.cnb.yahoo.com [202.165.102.70]) by erg.abdn.ac.uk (8.12.11/8.12.11) with SMTP id iBGDN9ws014088 for ; Thu, 16 Dec 2004 13:23:10 GMT Message-ID: <20041216132303.41276.qmail@web15703.mail.cnb.yahoo.com> Received: from [210.77.19.218] by web15703.mail.cnb.yahoo.com via HTTP; Thu, 16 Dec 2004 21:23:03 CST Date: Thu, 16 Dec 2004 21:23:03 +0800 (CST) From: =?gb2312?q?=BD=DC=20=D0=EC?= Subject: the relationship of ip-dvb and atm over satellite To: ipdvb@erg.abdn.ac.uk MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 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: base64 X-MIME-Autoconverted: from 8bit to base64 by erg.abdn.ac.uk id iBGDNm2X014110 X-Spam-Score: 1.1 (+) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: base64 DQogIGhpLCANCg0KDQogICAgIGlzIHRoZXJlIHNvbWUgcmVsYXRpb25zaGlwIG9mIGlwLWR2 YiBhbmQgYXRtIG92ZXINCnNhdGVsbGl0ZT8NCiAgICAgQW5kIHdoYXQgaXMgdGhlIGFyY2hp dGVjdHVyZSBvZg0KbmV4dC1nZW5lcmF0aW9uLXNhdGVsbGl0ZSBuZXR3b3Jrcz8gDQoNCiAg ICAgdGhhbmtzIQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCkRvIFlvdSBZYWhvbyE/DQoxNTDN8sf6TVAzt+i/8cvRo6y0 +MT6tLPI69L0wNa17szDDQpodHRwOi8vbXVzaWMueWlzb3UuY29tLw0Kw8DFrsP30MfTptPQ vqHT0KOsy9Gx6cPAzbyhotHezby6zb/hzbwNCmh0dHA6Ly9pbWFnZS55aXNvdS5jb20NCjFH vs3KxzEwMDDV16Os0cW7orXn08rX1Nb6wKnI3aOhDQpodHRwOi8vY24ucmQueWFob28uY29t L21haWxfY24vdGFnLzFnLypodHRwOi8vY24ubWFpbC55YWhvby5jb20vZXZlbnQvbWFpbF8x Zy8NCg== From owner-ipdvb@erg.abdn.ac.uk Fri Dec 17 05:38:37 2004 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 FAA03338 for ; Fri, 17 Dec 2004 05:38:37 -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 1CfFe1-0007za-KX for ipdvb-archive@ietf.org; Fri, 17 Dec 2004 05:47:34 -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 iBH9xMXP012319 for ; Fri, 17 Dec 2004 09:59:22 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iBH9xMqK012318 for ipdvb-subscribed-users; Fri, 17 Dec 2004 09:59: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 iBH9wqUj012302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 17 Dec 2004 09:58:52 GMT Message-ID: <41C2ADDC.3040309@erg.abdn.ac.uk> Date: Fri, 17 Dec 2004 09:58:52 +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: MPE and ULE padding References: <20041215033313.0E0B92200DC@nrg.cs.usm.my> In-Reply-To: <20041215033313.0E0B92200DC@nrg.cs.usm.my> 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: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit See in-line. Simon Teh wrote: > Dear all IP-DVB members, > > > > Good morning, I have several questions about ULE and MPE padding. As we > know that the size of ULE and MPE are variable size (MTU 1500 bytes), The Maximum MTU of MPE is defined as a little less than 4KB. The Maximum MTU of ULE is defined as a little less than 32KB. Although, as you say 1500 is a common MTU for *classical* Ethernet. > so > if the actual data is really small (maybe 2 bytes): > I don't know of any packet which is this small in the IP world, but sure we can and do expect packets much less than the MTU. > > > My Questions: > > 1. Will it be padded until the PDU reach an expected length by MPE > and ULE? > It **CAN** be padded to fit exactly into an under-lying Transport Stream Packet (183B payload). **OR** if Packing is supported - i.e. the MPE driver supports (many do, and *ALL* ULE ones do), then you do not need normally to add any padding. The ULE spec explains this process. > 2. Do the MPE and ULE have a minimum size? If yes what is the > minimum size for MPE and ULE? > No (unless you refer to the TS Packet size). > > > Thank you! > > Best Regards, > > Simon Teh > > Universiti Sains Malaysia > > > Gory Fairhurst. From owner-ipdvb@erg.abdn.ac.uk Fri Dec 17 05:46:18 2004 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 FAA03973 for ; Fri, 17 Dec 2004 05:46: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 1CfFl4-0008Dx-KU for ipdvb-archive@ietf.org; Fri, 17 Dec 2004 05:55:15 -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 iBHAFQXK012620 for ; Fri, 17 Dec 2004 10:15:27 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iBHAFQuv012619 for ipdvb-subscribed-users; Fri, 17 Dec 2004 10:15: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 iBHAEgqc012590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 17 Dec 2004 10:14:42 GMT Message-ID: <41C2B192.6040007@erg.abdn.ac.uk> Date: Fri, 17 Dec 2004 10:14:42 +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: MPLS/PPP over satellite. 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: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit In answer to both the question about PPP and MPLS. The intenetion is to support Internet (IP) protocols over this media, including the various tunnel, and other protocol components. the ULE Encapsulation supports all IANA EtherTypes: http://www.iana.org/assignments/ethernet-numbers This includes code-points for MPLS and PPP. However, there has been no specific discussions on either of these topics on this list. If there is a need to specify the precise mapping, or to provide recommendations on addressing and/or usage, then this WG list is a good place to start this discussion. Please do send comments and/or Internet Drafts on these topics for the group to consider. Gorry Fairhurst (ipdvb WG Chair) James Courtier-Dutton wrote: > The use of MPLS to the CPE device on Cable Internet networks seems to > be getting popular now. Are there any special considerations one > should take into account, if one wished to use MPLS over Satellite > networks. > Maybe some bytes could be saved if one included a consideration for > MPLS in the draft-ietf-ipdvb-ule-03.txt document. > > Kind Regards > > James > > From owner-ipdvb@erg.abdn.ac.uk Fri Dec 17 05:53:53 2004 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 FAA04519 for ; Fri, 17 Dec 2004 05:53: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 1CfFsn-0008Ro-SR for ipdvb-archive@ietf.org; Fri, 17 Dec 2004 06:02:50 -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 iBHAWmho013202 for ; Fri, 17 Dec 2004 10:32:48 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iBHAWmni013201 for ipdvb-subscribed-users; Fri, 17 Dec 2004 10:32: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 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 iBHAWEFW013179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 17 Dec 2004 10:32:15 GMT Message-ID: <41C2B5AF.2080902@erg.abdn.ac.uk> Date: Fri, 17 Dec 2004 10:32:15 +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: Repost: RE: WG Last-Call (WGLC) for comments: draft-ietf-ipdvb-ule-03.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-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Content-Transfer-Encoding: 7bit Gorry Forwarding to you due to the bounce. Art Allison Director, Advanced Engineering NAB Science & Technology 1771 N St NW, Washington Dc 20036 202 429 5418 --- Please find comments below. There is a chance that I will be able to return to the document and complete my review, but that may not happen. Broad issue - if the term being defined is in all caps, should not it be in all caps when that defined term is used? Or a rule that only initial caps are used after the all caps format should be pointed out. It is very bad to attempt, and I believe this draft must not, normatively redefine any ISO/IEC defined term. It may informatively list what another standard defines. Quick scan - Need work on MPEG term usage; Section 7 scoping; Refs should be updated from source web sited just b4 publications (A/53 is now A/53C, for example) MPEG term usage: @PRIVATE SECTION. While the use listed is one use, use of private sections is NOT constrained to only service information. It may be used for any Program data. It is not accurate to assert that all table sections must be carried over a single TS Logical Channel. Further attempting to assert the rules for such sections is in appropriate as 13818-1 rules. The draft should say, informatively, something like "ISO-MPEG requires that all table sections of a particular table _id must be carried in packets identified with a single PID. A packets with a given PID may contain data for more than one set of table sections. @p10 TABLE SECTION. Table sections are used for many purposes beside MPEG-2 SI. Users of MPEG-2 have added their own PSI[sic] table sections and employer them for other purposed. Also there may be private table sections that have any desired purpose. The point is they are related to any particular MPEG Program, not the System Information. @p10 seem to be missing PDU definition. @ p. 10, TS LOGICAL CHANNEL: Add 'unique' to: "...All packets sent over a TS Logical Channel carry the same unique PID value." PID values are required to be unique within each TS MULTIPLEX by MPEG-2 systems. @ p10-11 TS MULTIPLEX: Defining a TS MULTIPLEX in terms of the set of TS logical channels is an interesting way to view it, but as there is an internationally approved standard it would seem best to reference ISO/IEC 13818-1. It is NOT limited to a common physical link. Common physical links e.g., Ethernet, IEEE 1394, Satellite transponders can have more than one MPEG-2 transport stream. So the implication that the TS Logical Channel ID is unique to a physical link is incorrect. The last sentence in the definition is not wrong, but is not complete either. The same PID value can identify MPEG-2 packets with totally unrelated content in different TS MULTIPLEXes. @p11 Section 3. Asserting that ULE is limited to TS private streams seems underspecified. What is the means of identifying that this private use of a particular private stream_type is different from another's use of the same stream_type? It is a choice for the draft to be silent on how the PID value with these datagrams is found, but is seems that use of the MRD should be required in the PMT loop that has the private stream_type used by ULE. All programs must be listed per 13818-1, but that standard is silent on conflict resolution among private users. @p12 Section 3, 4th para. It is interesting that this receiver behavior is believed to be known. Particularly since the value 0xFF for table_id is expressly forbidden by ISO-MPEG. The meaning asserted is simply wrong. Padding (bytes of 0xFF) may occur in TS packets when a table section's content ends before the end of the TS packet. When they occur the following statements are correct. @p12 last para. The use and meaning of adaptation field is completely defined by ISO-MPEG. The assertion of its primary purpose does not appear relevant or needed and I would not agree with the word 'primary' . The assertion that values of 00 are discarded is interesting, and I would agree with the speculation that they should be ignored and discard the packets. The value '00' is not available for use, and discussion of anything but the requirement that the value 01 is required here seems unneeded. @p12 section 4. The sentence "Each SNDU is sent as a MPEG-2 Payload Unit." can be expanded to read '"Each Subnetwork Date Unit is sent as a MPEG-2 Payload Unit." But Payload Unit is a defined term here, meaning a sequence of bytes sent using a TS. So all this sentence says is each sequence of bytes is sent as a sequence of bytes. Was something more intended? It would seem that the order of the bits in each byte should be specified as well. MSBit first? @p 12-13 Section 4.1 and 4.2. The D field is shown as a separate field in figure 1 and then described as part of the Length field in the text. One can deduce that the length field bits are sent divided over two bytes and that the first byte has one bit that is unrelated to the length, but the field is not explicitly defined. The MSbyte is the one that has a bit that means Destination Address present, and it is the first bit sent? The MSB of the length field follows the D bit? Clarify. @section 4.4: bit order of the bytes in the field? @Section 4.5 :I don't see the location of this filed. Does the destination address field arrive just before the CRC? Section 4.1 says the D must be set to 0, unless an End indicator, yet this section says is 1 may be used for a non End Indicator situation. These sections need to be made consistent. What is the non-default situation and when can that be used? Why say "by default" in section 4.1? The situations for not using the default should be stated, if any exist. @Section 4.6 "...represented 0x104C11DB7..." is opaque in meaning. What is the ref for translating this and what does it mean? @Section 4.7 is this a receiver behavior spec section rather than a description of format section ( as it seems to be)? The format meanings were already specified..using slightly different words. ---far as I got--- 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: Tuesday, November 30, 2004 4:47 PM To: ipdvb@erg.abdn.ac.uk Subject: WG Last-Call (WGLC) for comments: draft-ietf-ipdvb-ule-03.txt This note starts the WG two week Last-Call for comments for the WG document named below: draft-ietf-ipdvb-ule-03.txt The Last-Call will end on 15/12/2004. Members of the IETF ipdvb WG are asked to read the above draft and send any issues, comments, or corrections to this mailing list. The WGLC procedure is the last chance for this working group to modify/correct this document. Please do forward any comments to the list. Best wishes, Gorry Fairhurst (ipdvb WG Chair) From owner-ipdvb@erg.abdn.ac.uk Fri Dec 17 06:38:58 2004 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 GAA07572 for ; Fri, 17 Dec 2004 06:38: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 1CfGaR-00017a-Ms for ipdvb-archive@ietf.org; Fri, 17 Dec 2004 06:47: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 iBHBKGwg014696 for ; Fri, 17 Dec 2004 11:20:16 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iBHBKGW3014695 for ipdvb-subscribed-users; Fri, 17 Dec 2004 11:20:16 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 iBHBIgXH014625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 17 Dec 2004 11:18:44 GMT Message-ID: <41C2C093.3020207@erg.abdn.ac.uk> Date: Fri, 17 Dec 2004 11:18: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: repost: Re: WGLC ule-03 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: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit I'm forwarding the comments below (extracted, from a longer email from "Bernhard Collini-Nocker" ), since they relate to suggested changes to ULE, resulting from reading during the WGLC. Gorry Fairhurst (ipdvb WG Chair) ---- 1. Figure 12 does not provide clear guidance on the placement of the NPA field when extension headers are present. The placement within the base-header needs to be clarified. >>So, section 5. provides the following (more complex) example: >> < -------------------------- SNDU ------------------------- > >> +---+---------------------------------------------------+--------+ >> |D=1| Length | T1 | H1 | T2 | H2 | T3 | PDU | CRC-32 | >> +---+---------------------------------------------------+--------+ >> < ULE base header >< ext 1 >< ext 2 > >> >> Figure 12: SNDU Encapsulation with two Extension Headers >> > Gorry: > I'd kind of assumed the NPA ALAWAYS was a part of the BASE HEADER, and that > it always is inserted after the first type field, with any extension headers > FOLLOWING the NPA when it is present. So, I guess I had imagined: > > < -------------------------- SNDU ------------------------- > > +---+---------------------------------------------------+--------+ > |D=0| Length | T1 | NPA | H1 | T2 | H2 | T3 | PDU | CRC-32 | > +---+---------------------------------------------------+--------+ > <*1> < ext 1 >< ext 2 > > > *1 NPA, if present, is always counted as a part of the base header. > > Thoughts? ---- 2. In Section 4.7.5 Fig 8 The Bridge Frame SNDU Encapsulation - "Receiver Destination Address" should be marked as "NPA Address" ---- From owner-ipdvb@erg.abdn.ac.uk Fri Dec 17 12:14:24 2004 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 MAA11230 for ; Fri, 17 Dec 2004 12:14:24 -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 1CfLp5-0004B5-F8 for ipdvb-archive@ietf.org; Fri, 17 Dec 2004 12:23: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 iBHGr1in022289 for ; Fri, 17 Dec 2004 16:53:01 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iBHGr1xc022288 for ipdvb-subscribed-users; Fri, 17 Dec 2004 16:53: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 hatl0ms23.corp.cox.com (gw2.cox.com [24.248.72.254]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iBHGqBNq022265 for ; Fri, 17 Dec 2004 16:52:11 GMT Received: from mail pickup service by hatl0ms23.corp.cox.com with Microsoft SMTPSVC; Fri, 17 Dec 2004 11:52:05 -0500 Received: from cox.com ([10.64.198.37]) by HATL0MS22.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 17 Dec 2004 05:24:14 -0500 Received: from ([139.133.204.77]) by post4.cox.com with SMTP id KP-VXH63.85936212; Fri, 17 Dec 2004 05:23:43 -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 iBH9xMXP012319 for ; Fri, 17 Dec 2004 09:59:22 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iBH9xMqK012318 for ipdvb-subscribed-users; Fri, 17 Dec 2004 09:59: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 iBH9wqUj012302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 17 Dec 2004 09:58:52 GMT Message-ID: <41C2ADDC.3040309@erg.abdn.ac.uk> Date: Fri, 17 Dec 2004 09:58:52 +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: MPE and ULE padding References: <20041215033313.0E0B92200DC@nrg.cs.usm.my> In-Reply-To: <20041215033313.0E0B92200DC@nrg.cs.usm.my> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean, Found to be clean, Found to be clean X-esp: ESP<1>=RBL:<0> RDNS:<0> SHA:<1> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> HTML Dictionary (TRU6):<0> NigeriaScam Dictionary (TRU6):<0> URL Dictionary (TRU6):<0> Spam Dictionary (TRU6):<0> CAN-SPAM Compliance Dictionary (TRU6):<0> Obscenities Dictionary (TRU6):<0> Embed HTML Dictionary (TRU6):<0> Porn Dictionary (TRU6):<0> X-OriginalArrivalTime: 17 Dec 2004 10:24:14.0335 (UTC) FILETIME=[8E7638F0:01C4E422] 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: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit See in-line. Simon Teh wrote: > Dear all IP-DVB members, > > > > Good morning, I have several questions about ULE and MPE padding. As we > know that the size of ULE and MPE are variable size (MTU 1500 bytes), The Maximum MTU of MPE is defined as a little less than 4KB. The Maximum MTU of ULE is defined as a little less than 32KB. Although, as you say 1500 is a common MTU for *classical* Ethernet. > so > if the actual data is really small (maybe 2 bytes): > I don't know of any packet which is this small in the IP world, but sure we can and do expect packets much less than the MTU. > > > My Questions: > > 1. Will it be padded until the PDU reach an expected length by MPE > and ULE? > It **CAN** be padded to fit exactly into an under-lying Transport Stream Packet (183B payload). **OR** if Packing is supported - i.e. the MPE driver supports (many do, and *ALL* ULE ones do), then you do not need normally to add any padding. The ULE spec explains this process. > 2. Do the MPE and ULE have a minimum size? If yes what is the > minimum size for MPE and ULE? > No (unless you refer to the TS Packet size). > > > Thank you! > > Best Regards, > > Simon Teh > > Universiti Sains Malaysia > > > Gory Fairhurst. From owner-ipdvb@erg.abdn.ac.uk Fri Dec 17 14:01:24 2004 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 OAA21598 for ; Fri, 17 Dec 2004 14:01:24 -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 1CfNUe-0007pn-Cf for ipdvb-archive@ietf.org; Fri, 17 Dec 2004 14:10: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 iBHIFVlr024361 for ; Fri, 17 Dec 2004 18:15:31 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iBHIFV76024355 for ipdvb-subscribed-users; Fri, 17 Dec 2004 18:15: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 hatl0ms23.corp.cox.com (gw2.cox.com [24.248.72.254]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iBHIE6Fe024316 for ; Fri, 17 Dec 2004 18:14:07 GMT Received: from mail pickup service by hatl0ms23.corp.cox.com with Microsoft SMTPSVC; Fri, 17 Dec 2004 13:14:01 -0500 Received: from cox.com ([10.64.198.37]) by HATL0MS22.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 17 Dec 2004 05:41:29 -0500 Received: from ([139.133.204.77]) by post4.cox.com with SMTP id KP-VXH63.85938573; Fri, 17 Dec 2004 05:41: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 iBHAFQXK012620 for ; Fri, 17 Dec 2004 10:15:27 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iBHAFQuv012619 for ipdvb-subscribed-users; Fri, 17 Dec 2004 10:15: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 iBHAEgqc012590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 17 Dec 2004 10:14:42 GMT Message-ID: <41C2B192.6040007@erg.abdn.ac.uk> Date: Fri, 17 Dec 2004 10:14:42 +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: MPLS/PPP over satellite. 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, Found to be clean, Found to be clean X-esp: ESP<1>=RBL:<0> RDNS:<0> SHA:<1> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> HTML Dictionary (TRU6):<0> NigeriaScam Dictionary (TRU6):<0> URL Dictionary (TRU6):<0> Spam Dictionary (TRU6):<0> CAN-SPAM Compliance Dictionary (TRU6):<0> Obscenities Dictionary (TRU6):<0> Embed HTML Dictionary (TRU6):<0> Porn Dictionary (TRU6):<0> X-OriginalArrivalTime: 17 Dec 2004 10:41:29.0585 (UTC) FILETIME=[F784D610:01C4E424] 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: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit In answer to both the question about PPP and MPLS. The intenetion is to support Internet (IP) protocols over this media, including the various tunnel, and other protocol components. the ULE Encapsulation supports all IANA EtherTypes: http://www.iana.org/assignments/ethernet-numbers This includes code-points for MPLS and PPP. However, there has been no specific discussions on either of these topics on this list. If there is a need to specify the precise mapping, or to provide recommendations on addressing and/or usage, then this WG list is a good place to start this discussion. Please do send comments and/or Internet Drafts on these topics for the group to consider. Gorry Fairhurst (ipdvb WG Chair) James Courtier-Dutton wrote: > The use of MPLS to the CPE device on Cable Internet networks seems to > be getting popular now. Are there any special considerations one > should take into account, if one wished to use MPLS over Satellite > networks. > Maybe some bytes could be saved if one included a consideration for > MPLS in the draft-ietf-ipdvb-ule-03.txt document. > > Kind Regards > > James > > From owner-ipdvb@erg.abdn.ac.uk Fri Dec 17 14:57:25 2004 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 OAA26593 for ; Fri, 17 Dec 2004 14:57: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 1CfOMs-00017O-0X for ipdvb-archive@ietf.org; Fri, 17 Dec 2004 15:06: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 iBHJFmdT025841 for ; Fri, 17 Dec 2004 19:15:48 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iBHJFmVZ025840 for ipdvb-subscribed-users; Fri, 17 Dec 2004 19:15: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 mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iBHJEHVg025782 for ; Fri, 17 Dec 2004 19:14:18 GMT Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 17 Dec 2004 11:14:09 -0800 Received: from RED-MSG-42.redmond.corp.microsoft.com ([157.54.12.202]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1264); Fri, 17 Dec 2004 11:14:14 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4E46C.9A832F68" Subject: RE: How to compute the checksum and crc-32 for MPE and ULE Date: Fri, 17 Dec 2004 11:14:10 -0800 Message-ID: <19A328037921AA42847A717566D1D6A103B6DF27@RED-MSG-42.redmond.corp.microsoft.com> Thread-Topic: How to compute the checksum and crc-32 for MPE and ULE Thread-Index: AcSFCXslKUn7PFN8RV+txWIPWGxRPBfYqt2A From: "Regis Crinon" To: X-OriginalArrivalTime: 17 Dec 2004 19:14:14.0240 (UTC) FILETIME=[98AEA600:01C4E46C] 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: e3901bdd61b234d82da85cc76f05a7e8 This is a multi-part message in MIME format. ------_=_NextPart_001_01C4E46C.9A832F68 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A good reference for CRC calculations is the section "Error-Detection Mecha= nisms (CRCs and Checksums)" in chapter 1 of the following book: "Data Broadcasting", by R. Chernock, R. Crinon, M. Dolan and J. Mick Jr., = McGraw Hill Publisher, Video/Audio Professional Series. ISBN is 0-07-137590-2 =20 Regis J. Crinon =20 =20 =20 ________________________________ From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On Beh= alf Of Bernhard Collini-Nocker Sent: Wednesday, August 18, 2004 2:27 AM To: ipdvb@erg.abdn.ac.uk Subject: AW: How to compute the checksum and crc-32 for MPE and ULE =20 Dear Simon, =20 probably the easiest way to find out how to correctly implement ULE, althou= gh not yet the final version :-(, and particularly the CRC32 is looking int= o the linuxtv.org source code where we have contributed and what is meanwhi= le even part of the latest linux 2.6 kernel. =20 Regards, Bernhard =20 Dr. Bernhard Collini-Nocker Paris Lodron University Salzburg Department of Scientific Computing Multimedia Communication Group Jakob Haringer Str. 2 A-5020 Salzburg AUSTRIA Tel: +43-662-8044 6316 Fax: +43-662-8044 172 www.scicomp.sbg.ac.at www.network-research.org=20 -----Urspr=FCngliche Nachricht----- Von: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] Im Auft= rag von Simon Teh Gesendet: Wednesday, August 18, 2004 08:51 An: Ip-DVB Betreff: How to compute the checksum and crc-32 for MPE and ULE Dear all experts, =09=20 Currently I'm studying the encapsulation method on MPE and ULE. Bu= t I'm confusing on how the crc32 and the checksum been calculate. Are they = compute from the datagram section or the hold packet? I hope somebody can h= elp me or send me some paper or website related with these topics.. Thanks = in advance!! =09=20 Best Regards, Simon Teh Universiti Sains Malaysia =09=20 ------_=_NextPart_001_01C4E46C.9A832F68 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Nachricht

A good reference for CRC calculations = is the section “Error-Detection Mechanisms (CRCs and Checksums)” in chapter 1 of the following book:

“Data Broadcasting”, by R.= Chernock, R. Crinon, M. Dolan and J. Mick Jr., =A0McGraw Hill Publisher, Video/Audio Professional Series.

ISBN is 0-07-137590-2

 

Regis J. Crinon

 

=A0

 

From: owner-ip= dvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On Behalf Of Bernhard Collini-Nocker
Sent: Wednesday, August 18, = 2004 2:27 AM
To: ipdvb@erg.abdn.ac.uk
Subject: AW: How to compute = the checksum and crc-32 for MPE and ULE

 

Dear Simon,

 

probably the easiest way to find out h= ow to correctly implement ULE, although not yet the final version :-(, and particularly the CRC32 is looking into the linuxtv.org source code where we have contributed and what is meanwhile even part of the latest lin= ux 2.6 kernel.

 

Regards,

Bernhard

 

Dr. Bernhard Collini-Nocker
Paris Lodron University Salzburg
Department of Scientific Computing
Multimedia Communication Group
Jakob Haringer Str. 2
A-5020 Salzburg
AUSTRIA
Tel: +43-662-8044 6316
Fax: +43-662-8044 172
www.scicomp.sbg.ac.at
www.network-research.org

-----Urspr=FCngliche Nachricht-----
Von: owner-ipdvb@erg.abdn.ac= .uk [mailto:owner-ipdvb@erg.abdn.ac.uk] Im Auftrag von Simon Teh
Gesendet: Wednesday, August = 18, 2004 08:51
An: Ip-DVB
Betreff: How to compute the checksum and crc-32 for MPE and ULE

Dear all experts,

 

        Current= ly I’m studying the encapsulation method on MPE and ULE. But I’m confusing on how the crc32 and the checksum been calculate. Are they compute from the datagram section or the hold packet? I hope somebody can help me or send me some paper or website related with these topics.. Thanks in advance= !!

 

Best Regards,

Simon Teh

Universiti Sains Malaysia

 

------_=_NextPart_001_01C4E46C.9A832F68-- From owner-ipdvb@erg.abdn.ac.uk Mon Dec 20 12:08:54 2004 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 MAA16332 for ; Mon, 20 Dec 2004 12:08: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 1CgRB2-00066S-Ni for ipdvb-archive@ietf.org; Mon, 20 Dec 2004 12:18:33 -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 iBKGWllc005398 for ; Mon, 20 Dec 2004 16:32:47 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iBKGWlb9005397 for ipdvb-subscribed-users; Mon, 20 Dec 2004 16:32:47 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 iBKGWHh7005379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 20 Dec 2004 16:32:17 GMT Message-ID: <41C6FE91.3040507@erg.abdn.ac.uk> Date: Mon, 20 Dec 2004 16:32:17 +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: Request to publish the WG document : draft-ietf-ipdvb-arch-02.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-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit The Arch ID now rests with our AD. Please find below a copy of the "request to publish note" for the ARCH draft. Best wishes, Gorry Faihurst (ipdvb WG Chair) ----- The following draft defines an architecture for the transport of IP Datagrams over ISO MPEG-2 Transport Streams (TS) and is a product of the IETF ipdvb WG: draft-ietf-ipdvb-arch-02.txt This document successfully passed WGLC at midnight on 29th October 2004. The WGLC process was performed on the following list: http://www.erg.abdn.ac.uk/ip-dvb/archive/ Feedback was received during the WGLC. Following completion of WGLC, the document editor updated the draft to correct NiTs and typos found, and to correct the phrasing of some sections. During WGLC, a specific question was raised concerning whether the architecture should mandate a minimal encryption method that would be mandatory to be supported. Comments from the list, and feedback provided at IETF-61 showed a consensus that while such security is desirable in some scenarios, there are also cases where physical layer or network layer methods may also be appropriate. The consensus was that the WG should allow, but not mandate, the implementation of link encryption as a part of its architecture. While updating the ID, the following minor changes were also applied: - one figure was updated (based on a comment by Rod Walsh, in the update the ULE protocol was added to the protocol stack; this is intended to also be a WG protocol spec). - the references were updated to add some more informative citations. - one paragraph was removed from the Appendix. The complete list of changes is available at: http://www.erg.abdn.ac.uk/ip-dvb/ids/rfcdiff-arch-01-02.html On behalf of the ipdvb WG, I am now forwarding this for for AD review. with a request that is published as an Informational RFC. Best wishes, Gorry Fairhurst ipdvb WG Chair P.S. I intend to send a copy of this note also to the ipdvb list. From owner-ipdvb@erg.abdn.ac.uk Mon Dec 20 12:45:00 2004 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 MAA18743 for ; Mon, 20 Dec 2004 12:45: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 1CgRjz-0006yh-AB for ipdvb-archive@ietf.org; Mon, 20 Dec 2004 12:54: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 iBKHHNAh006641 for ; Mon, 20 Dec 2004 17:17:23 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iBKHHNYi006640 for ipdvb-subscribed-users; Mon, 20 Dec 2004 17:17:23 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 iBKHFvwS006595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 20 Dec 2004 17:15:58 GMT Message-ID: <41C708CE.8070605@erg.abdn.ac.uk> Date: Mon, 20 Dec 2004 17:15:58 +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=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Subject: Completion of ULE WGLC -03 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: 96e0f8497f38c15fbfc8f6f315bcdecb Content-Transfer-Encoding: 7bit Revision 3 of the ULE Spec recently completed the last call period within this WG. There is still one report to be submitted, but in the mean-time I have collated the issues that have been raised in the following spread-sheet. Gorry Fairhurst (ipdvb WG Chair) +----+---------------------------+---------------------------+----------+ | | ULE-Spec 03 | WGLC Issues, | | | | |updated 17th Deecember 2004| | +----+---------------------------+---------------------------+----------+ |Iss |Section Status | Description | Notes | | | | | | +----+---------------------------+---------------------------+----------+ | 1 | 5 Raised during WGLC | The text says: "a 5-bit |W.Stering | | |fig. 10 - diagram Changed | zero prefix and a 3-bit |archive/ms| | | | H-Len field", but the |g00861.htm| | | | figure | l | | | |shows 4 bits zero and thus | | | | | suggests 4 bit for H-Len. | | +----+---------------------------+---------------------------+----------+ | 2 | 4.7 Raised during WGLC |"Next Header Type Fields": |W.Stering | | | - Moved to Sect 5 |When considering extension |archive/ms| | | - NOTE: Padding is |headers, type field values |g00861.htm| | | an OPTIONAL | of 0x0000 (TEST SNDU), | l | | | extension header. |0x0001 (BRIDGED SNDU), and | | | | |0x0100 (PADDING) are to be | | | | | interpreted as | | | | | mandatory extension | | | | | headers. We propose to | | | | |describe these in section 5| | | | | and state in 4.4.1 that | | | | |type field values less than| | | | | 1536 denote extension | | | | | headers. | | +----+---------------------------+---------------------------+----------+ | 3 | Raised during WGLC |PADDING type: 0x0100 would |W.Stering | | | - clarification of | decode as a 2 bytes long |archive/ms| | | question required. | optional extension |g00861.htm| | | |header, which is obviously | l | | | | not as intended. | | +----+---------------------------+---------------------------+----------+ | 4 | 4.5 Raised during WGLC | "SNDU Destination Address |W.Stering | | | - | Field": |archive/ms| | | | If extension headers are |g00861.htm| | | Figure 8 changed to | used in combination with | l | | | show case where D=0 | SNDU destination address | | | | and therefore the |(i.e. D-Bit is zero), it is| | | | NPA directly follows| not clear, where exactly | | | | the Type field of | the NPA address has to | | | | the base header. |be placed, i.e. after which| | | | |type field: after the last | | | | | extension header or | | | | |after the SNDU header (thus| | | | |occupying bytes 5 to 10 of | | | | | the SNDU). For | | | | | ease of processing and | | | | | filtering, we propose to | | | | | have the NPA address' | | | | | position fixed, directly | | | | |following the 4-bytes SNDU | | | | | header. An STB would | | | | | have to decode all | | | | | extension headers to find | | | | | the NPA address, just to | | | | |discover that it has to be | | | | | dropped, if it doesn't | | | | |match its own MAC address. | | +----+---------------------------+---------------------------+----------+ | 5 | Raised during WGLC | Bridging VLAN frames: |W.Stering | | | - query, this is a |There is a note in section |archive/ms| | | standard ethertype. | 4.7.5, after figure 9, |g00861.htm| | | | stating that a | l | | | | bridged SNDU could convey | | | | |an 802.3 Ethernet frame (as| | | | | opposed to | | | | |the examples (fig. 8, fig. | | | | | 9) containing an LLC/SNAP | | | | | encapsulation. | | | | | This note should be | | | | | extended to also cover | | | | | 802.1q frames (VLAN), | | | | |which contain a 4-byte VLAN| | | | | tag after the 2 Ethernet | | | | | MAC addresses. | | | | | | | +----+---------------------------+---------------------------+----------+ | 6 | 5 Proposed resolution:|Figure 12 does not provide |Raised by | | |Fig 12 This diagram could | clear guidance on the | BCN | | | be fixed by |placement of the NPA field | | | | replacing it with |when extension headers are | | | | one quoting ther | present. The placement | | | | case where D=0 | within the base-header | | | | | needs to be clarified. | | | | | | | +----+---------------------------+---------------------------+----------+ | 7 | 4.7.5 Raised during WGLC | Bridge Frame SNDU |Raised by | | | Fig 8 | Encapsulation | GF | | | | - "Receiver Destination | | | | | Address" should be marked | | | | | as "NPA Address" | | +----+---------------------------+---------------------------+----------+ | 8 |Definit Raised during WGLC |Broad issue - if the term |Raised by | | | ions |being defined is in all | AA | | | |caps, should not it be in | msg00867 | | | |all caps when that defined | | | | |term is used? Or a rule | | | | |that only initial caps | | | | |are used after the all caps| | | | |format should be pointed | | | | |out. It is very bad to | | | | |attempt, and I believe this| | | | |draft must not, normatively| | | | |redefine any ISO/IEC | | | | |defined term. It may | | | | |informatively list what | | | | |another standard defines. | | +----+---------------------------+---------------------------+----------+ | 9 | Refs Raised during WGLC |Quick scan - Need work on |Raised by | | | |MPEG term usage; Section 7 | AA | | | |scoping; Refs should be | msg00867 | | | |updated from source web | | | | |sited just b4 publications | | | | |(A/53 is now A/53C, for | | | | |example) | | +----+---------------------------+---------------------------+----------+ | 10 |Definti Raised during WGLC |@PRIVATE SECTION. While |Raised by | | | ons |the use listed is one use, | AA | | | p10 |use of private sections | msg00867 | | | |is NOT constrained to only | | | | |service information. It may| | | | |be used for any | | | | |Program data. It is not | | | | |accurate to assert that all| | | | |table sections must be | | | | |carried over a single TS | | | | |Logical Channel. Further | | | | |attempting to assert the | | | | |rules for such sections is | | | | |in appropriate as | | | | |13818-1 rules. The draft | | | | |should say, informatively, | | | | |something like "ISO-MPEG | | | | |requires that all table | | | | |sections of a particular | | | | |table _id must be carried | | | | |in packets identified with | | | | |a single PID. A packets | | | | |with a given PID may | | | | |contain data for more than | | | | |one set of table sections. | | +----+---------------------------+---------------------------+----------+ | 11 |Definti Raised during WGLC |TABLE SECTION. Table|Raised by | | | ons |sections are used for many| AA | | | p10 |purposes beside MPEG-2 | msg00867 | | | |SI. Users of MPEG-2 have| | | | |added their own PSI[sic]| | | | |table sections and | | | | |employer them for other| | | | |purposed. Also there may be| | | | |private table sections | | | | |that have any desired| | | | |purpose. The point is they| | | | |are related to any | | | | |particular MPEG Program,| | | | |not the System Information.| | +----+---------------------------+---------------------------+----------+ | 12 |Definti Raised during WGLC | missing PDU definition. |Raised by | | | ons | | AA | | | p10 | | msg00867 | +----+---------------------------+---------------------------+----------+ | 13 | Raised during WGLC | TS LOGICAL CHANNEL: Add |Raised by | | | | 'unique' to: "...All | AA | | | | packets sent over a | msg00867 | | | | TS Logical Channel carry | | | | |the same unique PID value."| | | | | PID values are | | | | | required to be unique | | | | |within each TS MULTIPLEX by| | | | | MPEG-2 systems. | | +----+---------------------------+---------------------------+----------+ | 14 | Raised during WGLC |TS MULTIPLEX: Defining |Raised by | | | |a TS MULTIPLEX in terms of | AA | | | | the set of TS | msg00867 | | | | logical channels is an | | | | |interesting way to view it,| | | | | but as there is an | | | | | internationally approved | | | | |standard it would seem best| | | | | to reference ISO/IEC | | | | |13818-1. It is NOT limited| | | | |to a common physical link. | | | | | Common physical links | | | | |e.g., Ethernet, IEEE 1394, | | | | |Satellite transponders can | | | | | have more than one | | | | | MPEG-2 transport stream. | | | | |So the implication that the| | | | | TS Logical Channel ID | | | | | is unique to a physical | | | | |link is incorrect. The last| | | | | sentence in the | | | | | definition is not wrong, | | | | |but is not complete either.| | | | | The same PID value can | | | | | identify MPEG-2 packets | | | | | with totally unrelated | | | | | content in different TS | | | | | MULTIPLEXes. | | +----+---------------------------+---------------------------+----------+ | 15 | P11 Raised during WGLC | Asserting that ULE is |Raised by | | |Sect 3 | limited to TS private | AA | | | | streams seems | msg00867 | | | |underspecified. What is the| | | | | means of identifying that | | | | | this private use of a | | | | | particular private | | | | | stream_type is different | | | | | from another's use of the | | | | | same | | | | | stream_type? It is a | | | | |choice for the draft to be | | | | |silent on how the PID value| | | | | with these datagrams is | | | | | found, but is seems that | | | | | use of the MRD should be | | | | | required in the PMT loop | | | | | that has the private | | | | | stream_type used by ULE. | | | | | All | | | | |programs must be listed per| | | | |13818-1, but that standard | | | | | is silent on conflict | | | | | resolution among private | | | | | users. | | +----+---------------------------+---------------------------+----------+ | 16 | p12 Raised during WGLC |4th para. It is interesting|Raised by | | |Sect 3 |that this receiver behavior| AA | | | | is believed to be known. | msg00867 | | | | Particularly since the | | | | |value 0xFF for table_id is | | | | | expressly forbidden by | | | | | ISO-MPEG. The meaning | | | | | asserted is simply wrong. | | | | |Padding (bytes of 0xFF) may| | | | |occur in TS packets when a | | | | | table section's | | | | |content ends before the end| | | | |of the TS packet. When they| | | | | occur the following | | | | | statements are correct. | | +----+---------------------------+---------------------------+----------+ | 17 | p12 Raised during WGLC | last para. The use and |Raised by | | |Sect 4 |meaning of adaptation field| AA | | | | is completely | msg00867 | | | | defined by ISO-MPEG. The | | | | | assertion of its primary | | | | | purpose does not appear | | | | | relevant or needed and I | | | | | would not agree with the | | | | | word 'primary' . The | | | | |assertion that values of 00| | | | | are discarded is | | | | | interesting, and I would | | | | |agree with the speculation | | | | |that they should be ignored| | | | | and discard the packets. | | | | | The value '00' is not | | | | | available for use, and | | | | |discussion of anything but | | | | | the requirement that the | | | | | value 01 is required here | | | | | seems unneeded. | | +----+---------------------------+---------------------------+----------+ | 18 | p12 Raised during WGLC |The sentence "Each SNDU is |Raised by | | |Sect 4 | sent as a MPEG-2 Payload | AA | | | | Unit." can be expanded to | msg00867 | | | |read '"Each Subnetwork Date| | | | | Unit is sent as a MPEG-2 | | | | |Payload Unit." But Payload | | | | | Unit is a defined term | | | | | here, meaning a sequence | | | | | of bytes sent using a TS. | | | | | So all this sentence says | | | | | is each sequence of | | | | |bytes is sent as a sequence| | | | | of bytes. Was something | | | | | more intended? It | | | | | would seem that the order | | | | | of the bits in each byte | | | | | should be specified as | | | | | well. MSBit first? | | +----+---------------------------+---------------------------+----------+ | 19 | 12-13 Raised during WGLC | The D field is shown as a |Raised by | | | Sect | separate field in | AA | | | 4.1 & |figure 1 and then described| msg00867 | | | 4.2 |as part of the Length field| | | | | in the text. One can | | | | | deduce that the length | | | | |field bits are sent divided| | | | | over two bytes and that | | | | |the first byte has one bit | | | | | that is unrelated to the | | | | | length, but the field | | | | |is not explicitly defined. | | | | |The MSbyte is the one that | | | | | has a bit that means | | | | | Destination Address | | | | | present, and it is the | | | | |first bit sent? The MSB of | | | | | the length field follows | | | | | the D bit? Clarify. | | +----+---------------------------+---------------------------+----------+ | 20 | 4.4 Raised during WGLC | Define bit order of the |Raised by | | | | bytes in the field | AA | | | | | msg00867 | +----+---------------------------+---------------------------+----------+ | 21 | 4.5 Raised during WGLC |I don't see the location of|Raised by | | | | this filed. Does the | AA | | | | destination address field | msg00867 | | | |arrive just before the CRC?| | | | |Section 4.1 says the D must| | | | |be set to 0, unless an End | | | | |indicator, yet this section| | | | |says is 1 may be used for a| | | | | non End Indicator | | | | | situation. These sections | | | | |need to be made consistent.| | | | | What is the non-default | | | | |situation and when can that| | | | | be used? Why say "by | | | | | default" in section 4.1? | | | | | The situations for not | | | | |using the default should be| | | | | stated, if any exist. | | +----+---------------------------+---------------------------+----------+ | 22 | 4.6 Raised during WGLC | "...represented |Raised by | | | | 0x104C11DB7..." is opaque | AA | | | | in meaning. What is | msg00867 | | | | the ref for translating | | | | |this and what does it mean?| | +----+---------------------------+---------------------------+----------+ | 23 | 4.7 Raised during WGLC |is this a receiver behavior|Raised by | | | |spec section rather than a | AA | | | | description of format | msg00867 | | | | section ( as it seems to | | | | | be)? The format meanings | | | | | were already specified | | | | | using slightly different | | | | | words. | | +----+---------------------------+---------------------------+----------+