From owner-ipdvb@erg.abdn.ac.uk Mon Apr 4 05:20:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09716 for ; Mon, 4 Apr 2005 05:20:24 -0400 (EDT) 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 1DINsp-0002PR-GR for ipdvb-archive@ietf.org; Mon, 04 Apr 2005 05:28:37 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j348kKas004419 for ; Mon, 4 Apr 2005 09:46:20 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j348kJ4f004418 for ipdvb-subscribed-users; Mon, 4 Apr 2005 09:46:20 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from bestia.e-milio.com ([217.15.36.230]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j348itq5004356 for ; Mon, 4 Apr 2005 09:44:55 +0100 (BST) Received: from hermes (opetus23.edu.stadia.fi [195.148.99.23]) by bestia.e-milio.com (8.12.11/8.12.9) with ESMTP id j348iq2B008450 for ; Mon, 4 Apr 2005 10:44:52 +0200 From: "Eduardo Alonso de la Fuente" To: "IP/DVB mailing list" Date: Mon, 4 Apr 2005 11:44:29 +0300 Message-ID: <000a01c538f2$87556990$fc13130a@hermes> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C5390B.ACA2A190" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-AntiVirus: checked by AntiVir Milter 1.0.6; AVE 6.30.0.7; VDF 6.30.0.61 X-ERG-MailScanner: Found to be clean, Found to be clean Subject: Mapping of OSI-3 datagrams in the application data table of the MPE-FEC frame Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.1 (/) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C5390B.ACA2A190 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, In the ETSI 301 192 final draft (point 9.3) it is written that IP datagrams that form the application data table of the MPE-FEC frame are carried in MPE sections. It says that the address of each datagram within the table is signalled in the header of the section that carries it. It also states that there is a table_boundary flag that indicates the end of layer 3 datagrams within the application data table. The same document (point 7) describes the syntax and semantics of the MPE section but of course there is no bits assigned to carry the address of the datagram in the application data table and no table_boundary flag. I am a student doing a bachelor thesis on the matter, modelling an MPE encapsulator with Matlab, and maybe I am a little bit lost in this matter, but I guess this information is introduced in any of the optional fields (i.e. stuffing byte) though I do not really know if it is done like that or if there is any 'standard' way of doing it. Any help you can provide will be very useful. Thank you in advance, Eduardo Alonso de la Fuente edu_gallofo@hotmail.com +358417759640 ------=_NextPart_000_000B_01C5390B.ACA2A190 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

In the ETSI 301 192 final draft (point 9.3) it is written that IP datagrams that form the application data table of the MPE-FEC frame are carried in MPE sections. It says that t= he address of each datagram within the table is signalled in the header of the section that carries it. It also states that there is a table_boundary flag that indicates the end of layer 3 datagrams within the application data table.

 <= /font>

The same document (point = 7) describes the syntax and semantics of the MPE section but of course there i= s no bits assigned to carry the address of the datagram in the application data table and no table_boundary flag. I am a student doing a bachelor thesis on the matter, modelling an MPE encapsulator with Matlab, and maybe I am a little bit lost i= n this matter, but I guess this information is introduced in any of the optional fields (i.e. stuffing byte) though I do not really know if it is done like = that or if there is any ‘standard’ way of doing it.

 <= /font>

Any help you can provide = will be very useful.

 <= /font>

Thank you in advance,

 <= /font>

 <= /font>

 <= /font>

Eduar= do Alonso de la Fuente

edu_gallofo@hotmail.com

+358417759640

------=_NextPart_000_000B_01C5390B.ACA2A190-- From owner-ipdvb@erg.abdn.ac.uk Mon Apr 4 06:02:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13031 for ; Mon, 4 Apr 2005 06:02:52 -0400 (EDT) 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 1DIOXu-0003tP-Ua for ipdvb-archive@ietf.org; Mon, 04 Apr 2005 06:11:05 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j349bO90005773 for ; Mon, 4 Apr 2005 10:37:24 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j349bNG0005771 for ipdvb-subscribed-users; Mon, 4 Apr 2005 10:37:24 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from natnoddy.rzone.de (natnoddy.rzone.de [81.169.145.166]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j349afUL005743 for ; Mon, 4 Apr 2005 10:36:41 +0100 (BST) Received: from server (hmln-d9b8ef42.pool.mediaWays.net [217.184.239.66]) (authenticated bits=0) by post.webmailer.de (8.13.1/8.13.1) with ESMTP id j349acxI024982 for ; Mon, 4 Apr 2005 11:36:39 +0200 (MEST) Message-ID: <003a01c538fb$4568ccd0$42efb8d9@server> From: "Karsten Siebert @ dpi AG" To: References: <000a01c538f2$87556990$fc13130a@hermes> Subject: Re: Mapping of OSI-3 datagrams in the application data table of the MPE-FEC frame Date: Mon, 4 Apr 2005 11:47:05 +0200 Organization: data planet international AG MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0037_01C5390C.06097100" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.2 (/) X-Scan-Signature: 025f8c5000216988bfe31585db759250 This is a multi-part message in MIME format. ------=_NextPart_000_0037_01C5390C.06097100 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Have a look in the section (9) describing real time parameters (address, bo= undaries and real time values), which are the same for MPE and FEC sections= . Four MAC address bytes (1-4) are replaced by these parameters. Karsten ----- Original Message -----=20 From: Eduardo Alonso de la Fuente=20 To: IP/DVB mailing list=20 Sent: Monday, April 04, 2005 10:44 AM Subject: Mapping of OSI-3 datagrams in the application data table of the = MPE-FEC frame Hi, =20=20=20 In the ETSI 301 192 final draft (point 9.3) it is written that IP datagra= ms that form the application data table of the MPE-FEC frame are carried in= MPE sections. It says that the address of each datagram within the table i= s signalled in the header of the section that carries it. It also states th= at there is a table_boundary flag that indicates the end of layer 3 datagra= ms within the application data table. =20=20=20 The same document (point 7) describes the syntax and semantics of the MPE= section but of course there is no bits assigned to carry the address of th= e datagram in the application data table and no table_boundary flag. I am a= student doing a bachelor thesis on the matter, modelling an MPE encapsulat= or with Matlab, and maybe I am a little bit lost in this matter, but I gues= s this information is introduced in any of the optional fields (i.e. stuffi= ng byte) though I do not really know if it is done like that or if there is= any 'standard' way of doing it. =20=20=20 Any help you can provide will be very useful. =20=20=20 Thank you in advance, =20=20=20 =20=20=20 =20=20=20 Eduardo Alonso de la Fuente edu_gallofo@hotmail.com +358417759640 ------=_NextPart_000_0037_01C5390C.06097100 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Have a look in the section (9)=20 describing real time parameters (address, boundaries and real time val= ues),=20 which are the same for MPE and FEC sections. Four MAC address bytes (1-4) a= re=20 replaced by these parameters.
 
Karsten
 
----- Original Message -----
Fro= m:=20 Eduardo=20 Alonso de la Fuente
Sent: Monday, April 04, 2005 10:44= =20 AM
Subject: Mapping of OSI-3 datagram= s in=20 the application data table of the MPE-FEC frame

Hi,<= /P>

 

I= n the=20 ETSI 301 192 final draft (point 9.3) it is written that IP datagrams that= form=20 the application data table of the MPE-FEC frame are carried in MPE sectio= ns.=20 It says that the address of each datagram within the table is signalled i= n the=20 header of the section that carries it. It also states that there is a table_boundary flag that indicates the end of layer= 3=20 datagrams within the application data table.

<= o:p> 

T= he same=20 document (point 7) describes the syntax and semantics of the MPE section = but=20 of course there is no bits assigned to carry the address of the datagram = in=20 the application data table and no table_boundary=20 flag. I am a student doing a bachelor thesis on the matter, modelling an = MPE=20 encapsulator with Matlab= ,=20 and maybe I am a little bit lost in this matter, but I guess this informa= tion=20 is introduced in any of the optional fields (i.e. stuffing byte) though I= do=20 not really know if it is done like that or if there is any =91standard=92= way of=20 doing it.

<= o:p> 

A= ny help=20 you can provide will be very useful.

<= o:p> 

T= hank=20 you in advance,

<= o:p> 

<= o:p> 

<= o:p> 

Eduardo=20 Alonso de la Fuente

<= A=20 href=3D"mailto:edu_gallofo@hotmail.com">edu_gallofo@hotmail.com=

+358417759640

------=_NextPart_000_0037_01C5390C.06097100-- From owner-ipdvb@erg.abdn.ac.uk Mon Apr 4 06:58:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17181 for ; Mon, 4 Apr 2005 06:58:04 -0400 (EDT) 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 1DIPPO-0005o6-2Q for ipdvb-archive@ietf.org; Mon, 04 Apr 2005 07:06:18 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j34AQIAr006966 for ; Mon, 4 Apr 2005 11:26:18 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j34AQIVf006965 for ipdvb-subscribed-users; Mon, 4 Apr 2005 11:26:18 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from bestia.e-milio.com ([217.15.36.230]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j34APTd3006936 for ; Mon, 4 Apr 2005 11:25:29 +0100 (BST) Received: from hermes (opetus142.edu.stadia.fi [195.148.99.142]) by bestia.e-milio.com (8.12.11/8.12.9) with ESMTP id j34APSAH030149 for ; Mon, 4 Apr 2005 12:25:28 +0200 From: "Eduardo Alonso de la Fuente" To: Subject: RE: Mapping of OSI-3 datagrams in the application data table of the MPE-FEC frame Date: Mon, 4 Apr 2005 13:25:01 +0300 Message-ID: <001401c53900$92e8a2f0$fc13130a@hermes> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01C53919.B835DAF0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: <003a01c538fb$4568ccd0$42efb8d9@server> X-AntiVirus: checked by AntiVir Milter 1.0.6; AVE 6.30.0.7; VDF 6.30.0.61 X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.2 (/) X-Scan-Signature: 9aa22b77adc37e7d33e29644e4dc0b33 This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C53919.B835DAF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Ok, I had not realised that the real time parameters described were for both MPE and MPE-FEC sections. Thank you very much!!! -----Mensaje original----- De: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] En nombre de Karsten Siebert @ dpi AG Enviado el: lunes, 04 de abril de 2005 12:47 Para: ipdvb@erg.abdn.ac.uk Asunto: Re: Mapping of OSI-3 datagrams in the application data table of the MPE-FEC frame Have a look in the section (9) describing real time parameters (address, boundaries and real time values), which are the same for MPE and FEC sections. Four MAC address bytes (1-4) are replaced by these parameters. Karsten ----- Original Message ----- From: Eduardo Alonso de la Fuente To: IP/DVB mailing list Sent: Monday, April 04, 2005 10:44 AM Subject: Mapping of OSI-3 datagrams in the application data table of the MPE-FEC frame Hi, In the ETSI 301 192 final draft (point 9.3) it is written that IP datagrams that form the application data table of the MPE-FEC frame are carried in MPE sections. It says that the address of each datagram within the table is signalled in the header of the section that carries it. It also states that there is a table_boundary flag that indicates the end of layer 3 datagrams within the application data table. The same document (point 7) describes the syntax and semantics of the MPE section but of course there is no bits assigned to carry the address of the datagram in the application data table and no table_boundary flag. I am a student doing a bachelor thesis on the matter, modelling an MPE encapsulator with Matlab, and maybe I am a little bit lost in this matter, but I guess this information is introduced in any of the optional fields (i.e. stuffing byte) though I do not really know if it is done like that or if there is any 'standard' way of doing it. Any help you can provide will be very useful. Thank you in advance, Eduardo Alonso de la Fuente edu_gallofo@hotmail.com +358417759640 ------=_NextPart_000_0015_01C53919.B835DAF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ok, I had not realised that the real time parameters described were for both MPE and MPE-FEC sections.

 

Thank you very much!!!

 

-----Mensaje original-----
De: owner-ipdvb@erg.abdn.ac.= uk [mailto:owner-ipdvb@erg.abdn.ac.uk] En = nombre de Karsten Siebert @ dpi AG
Enviado el: lunes, 04 de abr= il de 2005 12:47
Para: ipdvb@erg.abdn.ac.uk Asunto: Re: Mapping of OSI-3 datagrams in the application data table of the MPE-FEC frame<= /p>

 =

Have a look in the section&nbs= p;(9) describing real time parameters (address, boundaries and real time values), which are the same for MPE and FEC sections. Four MAC address bytes (1-4) are replaced by these parameters.

 =

Karsten

 =

----- Original Message ----- <= o:p>

Sent:<= /font> M= onday, April 04, 2005 10:44 AM

Subject: M= apping of OSI-3 datagrams in the application data table of the MPE-FEC frame

 =

Hi,

 

In the ETSI 301 192 final draft (point 9.3) it is written that IP datagrams th= at form the application data table of the MPE-FEC frame are carried in MPE sections. It says that the address of each datagram within the table is signalled in the header of the section that carries it. It also states that there is a table_boundary flag that indicates the end of layer 3 datagrams within the application data table.

 

The same document (point 7) describes the syntax and semantics of the MPE secti= on but of course there is no bits assigned to carry the address of the datagra= m in the application data table and no table_boundary flag. I am a student doing= a bachelor thesis on the matter, modelling an MPE encapsulator with Matlab, a= nd maybe I am a little bit lost in this matter, but I guess this information is introduced in any of the optional fields (i.e. stuffing byte) though I do n= ot really know if it is done like that or if there is any ‘standard̵= 7; way of doing it.

 

Any help you can provide will be very useful.

 

Thank you in advance,

 

 

 

Edu= ar= do Alonso de la Fuente

edu_gallofo@hotmail.com

+358417759640

------=_NextPart_000_0015_01C53919.B835DAF0-- From owner-ipdvb@erg.abdn.ac.uk Tue Apr 12 15:44:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29849 for ; Tue, 12 Apr 2005 15:44:13 -0400 (EDT) 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 1DLRSe-0003Rk-KM for ipdvb-archive@ietf.org; Tue, 12 Apr 2005 15:54:14 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3CJ7dxu009241 for ; Tue, 12 Apr 2005 20:07:39 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j3CJ7cRp009240 for ipdvb-subscribed-users; Tue, 12 Apr 2005 20:07:39 +0100 (BST) 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 j3CJ6oqx009208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 12 Apr 2005 20:06:51 +0100 (BST) Message-ID: <425C1C4B.80800@erg.abdn.ac.uk> Date: Tue, 12 Apr 2005 20:06:51 +0100 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: Minutes/Slides from ipdvb at IETF-62 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit I would like to say, a big thank you to Joerg for taking the notes at the Minneapolis IETF62 meeting. The final copy of the minutes for the ipdvb WG (with minor corrections) are now available on the IETF proceedings site. https://datatracker.ietf.org/public/proceeding_interim.cgi?meeting_num=62 If you notice any factual errors, please do let me know - the cut-off for any corrections is 25th April 2005. Best wishes, Gorry Fairhurst (ipdvb WG Chair) From owner-ipdvb@erg.abdn.ac.uk Tue Apr 12 16:49:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09607 for ; Tue, 12 Apr 2005 16:49:09 -0400 (EDT) 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 1DLSTV-00073B-2V for ipdvb-archive@ietf.org; Tue, 12 Apr 2005 16:59:10 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3CKEE8M010638 for ; Tue, 12 Apr 2005 21:14:14 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j3CKEDia010637 for ipdvb-subscribed-users; Tue, 12 Apr 2005 21:14:13 +0100 (BST) 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 j3CKCcFP010584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 12 Apr 2005 21:12:39 +0100 (BST) Message-ID: <425C2BB7.1010501@erg.abdn.ac.uk> Date: Tue, 12 Apr 2005 21:12:39 +0100 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: I-D ACTION:draft-fair-ipdvb-ar-04.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Address Resolution for IP datagrams over MPEG-2 networks Author(s) : G. Fairhurst, et al. Filename : draft-fair-ipdvb-ar-04.txt Pages : 17 Date : 2005-4-12 This document describes the process of binding/associating IPv4/IPv6 addresses with MPEG-2 Transport Streams (TS). This procedure is known as Address Resolution (AR), or Neighbour Discovery (ND). Such address resolution complements the higher layer resource discovery tools that are used to advertise IP sessions. In MPEG-2 networks, an IP address must be associated with a Packet ID (PID) and a specific Transmission Multiplex The document reviews current methods. It also describes the interaction with well-known protocols for address management including DHCP, ARP, and NDP, and provides guidance on usage. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-fair-ipdvb-ar-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-fair-ipdvb-ar-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-fair-ipdvb-ar-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From owner-ipdvb@erg.abdn.ac.uk Fri Apr 15 06:45:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15785 for ; Fri, 15 Apr 2005 06:45:25 -0400 (EDT) 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 1DMOUQ-0008H7-BV for ipdvb-archive@ietf.org; Fri, 15 Apr 2005 06:55:58 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3F9tNrS020936 for ; Fri, 15 Apr 2005 10:55:23 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j3F9tNNM020935 for ipdvb-subscribed-users; Fri, 15 Apr 2005 10:55:23 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from bestia.e-milio.com ([217.15.36.230]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3F9scfa020910 for ; Fri, 15 Apr 2005 10:54:39 +0100 (BST) Received: from hermes (opetus203.edu.stadia.fi [195.148.99.203]) by bestia.e-milio.com (8.12.11/8.12.9) with ESMTP id j3F9sa62024864 for ; Fri, 15 Apr 2005 11:54:36 +0200 Message-Id: <200504150954.j3F9sa62024864@bestia.e-milio.com> From: "Eduardo Alonso de la Fuente" To: "IP/DVB mailing list" Subject: DVB-H, MPE and Delta-T Date: Fri, 15 Apr 2005 12:54:23 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C541BA.42F80480" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcVBoRn3ekWjgl+aTB2OopTPFmyGXw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-AntiVirus: checked by AntiVir Milter 1.0.6; AVE 6.30.0.7; VDF 6.30.0.97 X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.1 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C541BA.42F80480 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi everyone, I am working in a bachelor thesis modelling with matlab and/or simulink an MPE/MPE-FEC encapsulator for a time sliced DVB-H bigger model. I still did not start with the programming as I am finding certain difficulties that I need to solve before. My doubt is how the encapsulator calculates the delta-t value within consecutive bursts? I understand how the delta_t value is coded but not how to obtain it. If anyone could refer me to any document or could give me some information on the matter I would be very thankful. Kind regards!!! Eduardo Alonso de la Fuente ------=_NextPart_000_0004_01C541BA.42F80480 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi everyone,

 

 

I am working in a bachelor thesis modelling = with matlab and/or simulink an MPE/MPE-FEC encapsulator for a time sliced = DVB-H bigger model. I still did not start with the programming as I am finding = certain difficulties that I need to solve before. My doubt is how the = encapsulator calculates the delta-t value within consecutive bursts? I understand how = the delta_t value is coded but not how to obtain it. If anyone could refer = me to any document or could give me some information on the matter I would be very thankful.

 

 

Kind regards!!!

 

 

 

Eduardo Alonso de la = Fuente

------=_NextPart_000_0004_01C541BA.42F80480-- From owner-ipdvb@erg.abdn.ac.uk Mon Apr 25 12:24:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29664 for ; Mon, 25 Apr 2005 12:24:15 -0400 (EDT) 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 1DQ6Zs-0007Eg-KN for ipdvb-archive@ietf.org; Mon, 25 Apr 2005 12:37:00 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3PFYDA0029632 for ; Mon, 25 Apr 2005 16:34:13 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j3PFYDvn029631 for ipdvb-subscribed-users; Mon, 25 Apr 2005 16:34:13 +0100 (BST) 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 j3PFXTwJ029603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 25 Apr 2005 16:33:29 +0100 (BST) Message-ID: <426D0DC9.4010702@erg.abdn.ac.uk> Date: Mon, 25 Apr 2005 16:33:29 +0100 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: Please all respond: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ar-04.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit As WG chair, I request the ipdvb list to consider whether the WG is ready to support adoption of the following individual Internet Draft (ID) as a WG ID. By adopting an individual ID as a working group ID, this WG indicates that it intends to be develop this into an RFC, according to the WG charter. WG documents should no longer be regarded as the property of the individuals who originally authored them - the working group as a whole must decide how they are shaped, and to see the document to a successful conclusion. If adopted, the Internet Draft will be renamed to start with the filename draft-ietf-ipdvb..., and will be listed on the IETF web page for this WG. --- Title : Address Resolution for IP datagrams over MPEG-2 networks Author(s) : G. Fairhurst, et al. Filename : draft-fair-ipdvb-ar-04.txt Pages : 17 Date : 2005-4-12 This document describes the process of binding/associating IPv4/IPv6 addresses with MPEG-2 Transport Streams (TS). This procedure is known as Address Resolution (AR), or Neighbour Discovery (ND). Such address resolution complements the higher layer resource discovery tools that are used to advertise IP sessions. In MPEG-2 networks, an IP address must be associated with a Packet ID (PID) and a specific Transmission Multiplex The document reviews current methods. It also describes the interaction with well-known protocols for address management including DHCP, ARP, and NDP, and provides guidance on usage. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-fair-ipdvb-ar-04.txt --- You are encouraged to send email to this WG, to help make the decision for adoption. Possible recommendations are: 1) Support for adoption as a working group draft under our Charter - i.e. Recommend this Internet Draft SHOULD be used as the basis for developing an RFC by the ipdvb WG. 2) Request for non-adoption i.e. That there is (or could be) alternative approaches to the problem, and that the current draft is not sufficiently developed / or correctly designed ipdvb WG 3) Out of scope i.e. you believe the document to be beyond the scope of the approved ipdvb WG charter. Emails on this topic should be sent to the ipdvb mailing list before 6th May 2005. Note that an ID does not need to be complete to be adopted. It would also be most useful to collect as many comments/criticisms as possible from those reading this ID. Looking through the archived mailing list, a first list of issues to be addressed is included at the end of this email. Please do help to identify any more known (or potential) issues that should be addressed/discussed. Best wishes, Gorry Fairhurst (ipdvb WG Chair) From owner-ipdvb@erg.abdn.ac.uk Mon Apr 25 13:10:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02531 for ; Mon, 25 Apr 2005 13:10:13 -0400 (EDT) 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 1DQ7IP-0000HJ-Aw for ipdvb-archive@ietf.org; Mon, 25 Apr 2005 13:22:59 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3PGX3VI001064 for ; Mon, 25 Apr 2005 17:33:03 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j3PGX3ZE001063 for ipdvb-subscribed-users; Mon, 25 Apr 2005 17:33:03 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from smtpout03-03.mesa1.secureserver.net (smtpout03-03.mesa1.secureserver.net [64.202.165.73]) by erg.abdn.ac.uk (8.12.11/8.12.11) with SMTP id j3PGWY7N001047 for ; Mon, 25 Apr 2005 17:32:34 +0100 (BST) Received: (qmail 26196 invoked from network); 25 Apr 2005 16:32:34 -0000 Received: from unknown (HELO gem-wbe03.mesa1.secureserver.net) (64.202.189.35) by smtpout03-03.mesa1.secureserver.net with SMTP; 25 Apr 2005 16:32:34 -0000 Received: (qmail 363 invoked by uid 99); 25 Apr 2005 16:32:34 -0000 Message-ID: <20050425163234.362.qmail@gem-wbe03.mesa1.secureserver.net> Date: Mon, 25 Apr 2005 09:32:34 -0700 From: Marie-Jose Montpetit Subject: RE: Please all respond: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ar-04.txt To: ipdvb@erg.abdn.ac.uk MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be This draft has gone for 3 re-drafts already and is due I believe for adoption as it reflects one of the goals of the WG. It still needs inputs from the wider MPEG2 communivty (DVB, ATSC, cable) in terms of how different technologies deal with L2/L3 addressing issues. Marie-Jose > -------- Original Message -------- > Subject: Please all respond: Call for the ipdvb WG to adopt: > draft-fair-ipdvb-ar-04.txt > From: Gorry Fairhurst > Date: Mon, April 25, 2005 11:33 am > To: ipdvb@erg.abdn.ac.uk > > As WG chair, I request the ipdvb list to consider whether the WG is > ready to support adoption of the following individual Internet Draft > (ID) as a WG ID. By adopting an individual ID as a working group ID, > this WG indicates that it intends to be develop this into an RFC, > according to the WG charter. > > WG documents should no longer be regarded as the property of the > individuals who originally authored them - the working group as a > whole must decide how they are shaped, and to see the document to a > successful conclusion. If adopted, the Internet Draft will be renamed > to start with the filename draft-ietf-ipdvb..., and will be listed on > the IETF web page for this WG. > > > --- > > Title : Address Resolution for IP datagrams over > MPEG-2 networks > Author(s) : G. Fairhurst, et al. > Filename : draft-fair-ipdvb-ar-04.txt > Pages : 17 > Date : 2005-4-12 > > This document describes the process of binding/associating IPv4/IPv6 > addresses with MPEG-2 Transport Streams (TS). This procedure is > known as Address Resolution (AR), or Neighbour Discovery (ND). Such > address resolution complements the higher layer resource discovery > tools that are used to advertise IP sessions. In MPEG-2 networks, an > IP address must be associated with a Packet ID (PID) and a specific > Transmission Multiplex The document reviews current methods. It also > describes the interaction with well-known protocols for address > management including DHCP, ARP, and NDP, and provides guidance on > usage. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-fair-ipdvb-ar-04.txt > > --- > > You are encouraged to send email to this WG, to help make the decision > for adoption. Possible recommendations are: > > 1) Support for adoption as a working group draft under our Charter - > i.e. Recommend this Internet Draft SHOULD be used as the basis for > developing an RFC by the ipdvb WG. > > 2) Request for non-adoption > i.e. That there is (or could be) alternative approaches to > the problem, and that the current draft is not sufficiently > developed / or correctly designed ipdvb WG > > 3) Out of scope > i.e. you believe the document to be beyond the scope of the > approved ipdvb WG charter. > > Emails on this topic should be sent to the ipdvb mailing list before > 6th May 2005. > > Note that an ID does not need to be complete to be adopted. It would > also be most useful to collect as many comments/criticisms as possible > from those reading this ID. Looking through the archived mailing > list, a first list of issues to be addressed is included at the end of > this email. > > Please do help to identify any more known (or potential) issues that > should be addressed/discussed. > > Best wishes, > > Gorry Fairhurst > (ipdvb WG Chair) From owner-ipdvb@erg.abdn.ac.uk Tue Apr 26 03:03:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07552 for ; Tue, 26 Apr 2005 03:03:26 -0400 (EDT) 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 1DQKIp-0003Ua-U0 for ipdvb-archive@ietf.org; Tue, 26 Apr 2005 03:16:16 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3Q649bA015811 for ; Tue, 26 Apr 2005 07:04:09 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j3Q648x9015810 for ipdvb-subscribed-users; Tue, 26 Apr 2005 07:04:08 +0100 (BST) 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 j3Q62lGk015765 for ; Tue, 26 Apr 2005 07:02:48 +0100 (BST) Received: from [127.0.0.1] (milbe.cosy.sbg.ac.at [141.201.2.21]) by loewe.cosy.sbg.ac.at (8.8.8/8.8.7) with ESMTP id IAA12165 for ; Tue, 26 Apr 2005 08:02:47 +0200 (MET DST) Message-ID: <426DD966.7030808@cosy.sbg.ac.at> Date: Tue, 26 Apr 2005 08:02:14 +0200 From: Bernhard Collini-Nocker User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: Re: Please all respond: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ar-04.txt References: <426D0DC9.4010702@erg.abdn.ac.uk> In-Reply-To: <426D0DC9.4010702@erg.abdn.ac.uk> 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-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit Dear Gorry, I vote for recommendation 1). Kind regards, Bernhard Gorry Fairhurst wrote: > As WG chair, I request the ipdvb list to consider whether the WG is > ready to support adoption of the following individual Internet Draft > (ID) as a WG ID. By adopting an individual ID as a working group ID, > this WG indicates that it intends to be develop this into an RFC, > according to the WG charter. > > WG documents should no longer be regarded as the property of the > individuals who originally authored them - the working group as a > whole must decide how they are shaped, and to see the document to a > successful conclusion. If adopted, the Internet Draft will be renamed > to start with the filename draft-ietf-ipdvb..., and will be listed on > the IETF web page for this WG. > > > --- > > Title : Address Resolution for IP datagrams over > MPEG-2 networks > Author(s) : G. Fairhurst, et al. > Filename : draft-fair-ipdvb-ar-04.txt > Pages : 17 > Date : 2005-4-12 > > This document describes the process of binding/associating IPv4/IPv6 > addresses with MPEG-2 Transport Streams (TS). This procedure is > known as Address Resolution (AR), or Neighbour Discovery (ND). Such > address resolution complements the higher layer resource discovery > tools that are used to advertise IP sessions. In MPEG-2 networks, an > IP address must be associated with a Packet ID (PID) and a specific > Transmission Multiplex The document reviews current methods. It also > describes the interaction with well-known protocols for address > management including DHCP, ARP, and NDP, and provides guidance on > usage. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-fair-ipdvb-ar-04.txt > > --- > > You are encouraged to send email to this WG, to help make the decision > for adoption. Possible recommendations are: > > 1) Support for adoption as a working group draft under our Charter - > i.e. Recommend this Internet Draft SHOULD be used as the basis for > developing an RFC by the ipdvb WG. > > 2) Request for non-adoption > i.e. That there is (or could be) alternative approaches to > the problem, and that the current draft is not sufficiently > developed / or correctly designed ipdvb WG > > 3) Out of scope > i.e. you believe the document to be beyond the scope of the > approved ipdvb WG charter. > > Emails on this topic should be sent to the ipdvb mailing list before > 6th May 2005. > > Note that an ID does not need to be complete to be adopted. It would > also be most useful to collect as many comments/criticisms as possible > from those reading this ID. Looking through the archived mailing > list, a first list of issues to be addressed is included at the end of > this email. > > Please do help to identify any more known (or potential) issues that > should be addressed/discussed. > > Best wishes, > > Gorry Fairhurst > (ipdvb WG Chair) > From owner-ipdvb@erg.abdn.ac.uk Tue Apr 26 08:34:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03862 for ; Tue, 26 Apr 2005 08:34:49 -0400 (EDT) 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 1DQPTa-0002vT-Hn for ipdvb-archive@ietf.org; Tue, 26 Apr 2005 08:47:43 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3QBWNF3021933 for ; Tue, 26 Apr 2005 12:32:23 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j3QBWMeE021932 for ipdvb-subscribed-users; Tue, 26 Apr 2005 12:32:22 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3QBVb0E021902 for ; Tue, 26 Apr 2005 12:31:37 +0100 (BST) Received: from europa.office (europa.office [10.1.1.2]) by smtp0.netlab.nec.de (Postfix) with ESMTP id DE85CDC96 for ; Tue, 26 Apr 2005 13:34:42 +0200 (CEST) Received: from [10.1.1.109] ([10.1.1.109]) by europa.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Tue, 26 Apr 2005 13:31:32 +0200 Date: Tue, 26 Apr 2005 13:31:31 +0200 From: Martin Stiemerling To: ipdvb@erg.abdn.ac.uk Subject: Re: Please all respond: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ar-04.txt Message-ID: <1FE098C0BBDC403DBF3C015C@[10.1.1.109]> In-Reply-To: <426D0DC9.4010702@erg.abdn.ac.uk> References: <426D0DC9.4010702@erg.abdn.ac.uk> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 26 Apr 2005 11:31:32.0614 (UTC) FILETIME=[7F2A3260:01C54A53] X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit Hi all, I vote for WG ID. Martin --On Montag, 25. April 2005 16:33 Uhr +0100 Gorry Fairhurst wrote: | As WG chair, I request the ipdvb list to consider whether the WG is | ready to support adoption of the following individual Internet Draft | (ID) as a WG ID. By adopting an individual ID as a working group ID, | this WG indicates that it intends to be develop this into an RFC, | according to the WG charter. | | WG documents should no longer be regarded as the property of the | individuals who originally authored them - the working group as a | whole must decide how they are shaped, and to see the document to a | successful conclusion. If adopted, the Internet Draft will be renamed | to start with the filename draft-ietf-ipdvb..., and will be listed on | the IETF web page for this WG. | | | --- | | Title : Address Resolution for IP datagrams over | MPEG-2 networks | Author(s) : G. Fairhurst, et al. | Filename : draft-fair-ipdvb-ar-04.txt | Pages : 17 | Date : 2005-4-12 | | This document describes the process of binding/associating IPv4/IPv6 | addresses with MPEG-2 Transport Streams (TS). This procedure is | known as Address Resolution (AR), or Neighbour Discovery (ND). Such | address resolution complements the higher layer resource discovery | tools that are used to advertise IP sessions. In MPEG-2 networks, an | IP address must be associated with a Packet ID (PID) and a specific | Transmission Multiplex The document reviews current methods. It also | describes the interaction with well-known protocols for address | management including DHCP, ARP, and NDP, and provides guidance on | usage. | | A URL for this Internet-Draft is: | http://www.ietf.org/internet-drafts/draft-fair-ipdvb-ar-04.txt | | --- | | You are encouraged to send email to this WG, to help make the decision | for adoption. Possible recommendations are: | | 1) Support for adoption as a working group draft under our Charter | - | i.e. Recommend this Internet Draft SHOULD be used as the basis for | developing an RFC by the ipdvb WG. | | 2) Request for non-adoption | i.e. That there is (or could be) alternative approaches to | the problem, and that the current draft is not sufficiently | developed / or correctly designed ipdvb WG | | 3) Out of scope | i.e. you believe the document to be beyond the scope of the | approved ipdvb WG charter. | | Emails on this topic should be sent to the ipdvb mailing list before | 6th May 2005. | | Note that an ID does not need to be complete to be adopted. It would | also be most useful to collect as many comments/criticisms as possible | from those reading this ID. Looking through the archived mailing | list, a first list of issues to be addressed is included at the end of | this email. | | Please do help to identify any more known (or potential) issues that | should be addressed/discussed. | | Best wishes, | | Gorry Fairhurst | (ipdvb WG Chair) | From owner-ipdvb@erg.abdn.ac.uk Tue Apr 26 09:14:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06619 for ; Tue, 26 Apr 2005 09:14:40 -0400 (EDT) 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 1DQQ67-0003nF-9N for ipdvb-archive@ietf.org; Tue, 26 Apr 2005 09:27:34 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3QCTsak023154 for ; Tue, 26 Apr 2005 13:29:54 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j3QCTsNS023153 for ipdvb-subscribed-users; Tue, 26 Apr 2005 13:29:54 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from iit.demokritos.gr (aiolos.iit.demokritos.gr [143.233.6.1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3QCT3Ba023119 for ; Tue, 26 Apr 2005 13:29:03 +0100 (BST) Received: from CPQ19007325591 (credo-143-233-227-003.iit.demokritos.gr [143.233.227.3]) by iit.demokritos.gr (8.11.6+Sun/8.11.6) with ESMTP id j3QCSrD10585 for ; Tue, 26 Apr 2005 15:28:53 +0300 (EEST) From: "Charalabos Skianis" To: Subject: Please all respond: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ar-04.txt Date: Tue, 26 Apr 2005 15:29:00 +0300 Message-ID: <000301c54a5b$8694b860$03e3e98f@CPQ19007325591> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <1FE098C0BBDC403DBF3C015C@[10.1.1.109]> Importance: Normal X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 7bit Hi, I vote for WG ID. Harry --On Montag, 25. April 2005 16:33 Uhr +0100 Gorry Fairhurst wrote: | As WG chair, I request the ipdvb list to consider whether the WG is | ready to support adoption of the following individual Internet Draft | (ID) as a WG ID. By adopting an individual ID as a working group ID, | this WG indicates that it intends to be develop this into an RFC, | according to the WG charter. | | WG documents should no longer be regarded as the property of the | individuals who originally authored them - the working group as a | whole must decide how they are shaped, and to see the document to a | successful conclusion. If adopted, the Internet Draft will be renamed | to start with the filename draft-ietf-ipdvb..., and will be listed on | the IETF web page for this WG. | | | --- | | Title : Address Resolution for IP datagrams over | MPEG-2 networks | Author(s) : G. Fairhurst, et al. | Filename : draft-fair-ipdvb-ar-04.txt | Pages : 17 | Date : 2005-4-12 | | This document describes the process of binding/associating IPv4/IPv6 | addresses with MPEG-2 Transport Streams (TS). This procedure is | known as Address Resolution (AR), or Neighbour Discovery (ND). Such | address resolution complements the higher layer resource discovery | tools that are used to advertise IP sessions. In MPEG-2 networks, an | IP address must be associated with a Packet ID (PID) and a specific | Transmission Multiplex The document reviews current methods. It also | describes the interaction with well-known protocols for address | management including DHCP, ARP, and NDP, and provides guidance on | usage. | | A URL for this Internet-Draft is: | http://www.ietf.org/internet-drafts/draft-fair-ipdvb-ar-04.txt | | --- | | You are encouraged to send email to this WG, to help make the decision | for adoption. Possible recommendations are: | | 1) Support for adoption as a working group draft under our Charter | - | i.e. Recommend this Internet Draft SHOULD be used as the basis for | developing an RFC by the ipdvb WG. | | 2) Request for non-adoption | i.e. That there is (or could be) alternative approaches to | the problem, and that the current draft is not sufficiently | developed / or correctly designed ipdvb WG | | 3) Out of scope | i.e. you believe the document to be beyond the scope of the | approved ipdvb WG charter. | | Emails on this topic should be sent to the ipdvb mailing list before | 6th May 2005. | | Note that an ID does not need to be complete to be adopted. It would | also be most useful to collect as many comments/criticisms as possible | from those reading this ID. Looking through the archived mailing | list, a first list of issues to be addressed is included at the end of | this email. | | Please do help to identify any more known (or potential) issues that | should be addressed/discussed. | | Best wishes, | | Gorry Fairhurst | (ipdvb WG Chair) | From owner-ipdvb@erg.abdn.ac.uk Tue Apr 26 11:09:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16265 for ; Tue, 26 Apr 2005 11:09:40 -0400 (EDT) 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 1DQRtS-0006qQ-Hm for ipdvb-archive@ietf.org; Tue, 26 Apr 2005 11:22:36 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3QEI58X025532 for ; Tue, 26 Apr 2005 15:18:05 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j3QEI5Xp025531 for ipdvb-subscribed-users; Tue, 26 Apr 2005 15:18:05 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from venezia.uab.es (venezia.uab.es [158.109.120.15]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3QEGtwd025489 for ; Tue, 26 Apr 2005 15:16:55 +0100 (BST) Received: from venezia.uab.es (localhost [127.0.0.1]) by venezia.uab.es (Sun Java System Messaging Server 6.1 HotFix 0.10 (built Jan 6 2005)) with ESMTP id <0IFK002LZ51EV640@venezia.uab.es> for ipdvb@erg.abdn.ac.uk; Tue, 26 Apr 2005 16:17:38 +0200 (CEST) Received: from [127.0.0.1] ([158.109.69.162]) by venezia.uab.es (Sun Java System Messaging Server 6.1 HotFix 0.10 (built Jan 6 2005)) with ESMTP id <0IFK009W751DMF60@venezia.uab.es> for ipdvb@erg.abdn.ac.uk; Tue, 26 Apr 2005 16:17:37 +0200 (CEST) Date: Tue, 26 Apr 2005 16:18:02 +0200 From: Fausto Vieira Subject: Re: Please all respond: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ar-04.txt In-reply-to: <426D0DC9.4010702@erg.abdn.ac.uk> To: ipdvb@erg.abdn.ac.uk Message-id: <426E4D9A.50107@sunaut.uab.es> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <426D0DC9.4010702@erg.abdn.ac.uk> User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Content-Transfer-Encoding: 7BIT Dear all, This is the first time I see this document. I also vote for WG ID. Nonetheless, here are my remarks on the current version of the document: The following sentence is duplicated in the draft (page 5): "The all 1s PID value indicates a Null TS Packet introduced to maintain a constant bit rate of a TS Multiplex. There is no required relationship between the PID values used for TS Logical Channels transmitted using different TS Multiplexes." This sentence is also duplicated (page 5): "PSI: Program Specific Information [ISO-MPEG2]. PSI is used to convey information about services carried in a TS Multiplex. It is carried in one of four specifically identified table section constructs [ISO-MPEG2], see also SI Table. Spelling error: "Multicast address resolution occurs at one level in associating a specific L2 address with _am_ IP Group Destination Address" Change the underlined to "an" Spelling error: "The principle drawbacks are that _while_ the INT, there is a need for a Gateway to introduce associated PSI/SI MPEG-2 control information." Change the underlined to "with" Spelling error: "(...) or parts of the network where gateway devices isolate the MPEG devices from the larger Internet creating virtual MPEG2 private networks.)" Move the last parentheses to before the period mark. Spelling error: "The ND protocol of IPv6 [RFC2461] may be used.NDP does not require (...)" Insert a after the period mark. Spelling error: "The ND protocol of IPv6 [RFC2461] may be used with The LLC/SNAP format of MPE. NDP does not require(...)" Remove the 2nd after the period mark. Cheers Fausto Vieira Gorry Fairhurst wrote: > As WG chair, I request the ipdvb list to consider whether the WG is > ready to support adoption of the following individual Internet Draft > (ID) as a WG ID. By adopting an individual ID as a working group ID, > this WG indicates that it intends to be develop this into an RFC, > according to the WG charter. > > WG documents should no longer be regarded as the property of the > individuals who originally authored them - the working group as a > whole must decide how they are shaped, and to see the document to a > successful conclusion. If adopted, the Internet Draft will be renamed > to start with the filename draft-ietf-ipdvb..., and will be listed on > the IETF web page for this WG. > > > --- > > Title : Address Resolution for IP datagrams over > MPEG-2 networks > Author(s) : G. Fairhurst, et al. > Filename : draft-fair-ipdvb-ar-04.txt > Pages : 17 > Date : 2005-4-12 > > This document describes the process of binding/associating IPv4/IPv6 > addresses with MPEG-2 Transport Streams (TS). This procedure is > known as Address Resolution (AR), or Neighbour Discovery (ND). Such > address resolution complements the higher layer resource discovery > tools that are used to advertise IP sessions. In MPEG-2 networks, an > IP address must be associated with a Packet ID (PID) and a specific > Transmission Multiplex The document reviews current methods. It also > describes the interaction with well-known protocols for address > management including DHCP, ARP, and NDP, and provides guidance on > usage. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-fair-ipdvb-ar-04.txt > > --- > > You are encouraged to send email to this WG, to help make the decision > for adoption. Possible recommendations are: > > 1) Support for adoption as a working group draft under our > Charter - > i.e. Recommend this Internet Draft SHOULD be used as the basis for > developing an RFC by the ipdvb WG. > > 2) Request for non-adoption > i.e. That there is (or could be) alternative approaches to > the problem, and that the current draft is not sufficiently > developed / or correctly designed ipdvb WG > > 3) Out of scope > i.e. you believe the document to be beyond the scope of the > approved ipdvb WG charter. > > Emails on this topic should be sent to the ipdvb mailing list before > 6th May 2005. > > Note that an ID does not need to be complete to be adopted. It would > also be most useful to collect as many comments/criticisms as possible > from those reading this ID. Looking through the archived mailing > list, a first list of issues to be addressed is included at the end of > this email. > > Please do help to identify any more known (or potential) issues that > should be addressed/discussed. > > Best wishes, > > Gorry Fairhurst > (ipdvb WG Chair) > From owner-ipdvb@erg.abdn.ac.uk Tue Apr 26 11:43:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19999 for ; Tue, 26 Apr 2005 11:43:07 -0400 (EDT) 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 1DQSPl-00084s-2v for ipdvb-archive@ietf.org; Tue, 26 Apr 2005 11:56:03 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3QFEi4D026812 for ; Tue, 26 Apr 2005 16:14:44 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j3QFEirP026811 for ipdvb-subscribed-users; Tue, 26 Apr 2005 16:14:44 +0100 (BST) 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 (network2.cs.usm.my [161.142.8.104]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3QFE4Mp026778 for ; Tue, 26 Apr 2005 16:14:05 +0100 (BST) Received: from localhost (localhost.localdomain [127.0.0.1]) by nrg.cs.usm.my (Postfix) with ESMTP id 2CBBE220108 for ; Tue, 26 Apr 2005 23:13:48 +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 20784-03 for ; Tue, 26 Apr 2005 23:13:38 +0800 (MYT) Received: from abc (unknown [219.93.2.101]) by nrg.cs.usm.my (Postfix) with ESMTP id 215D4220107 for ; Tue, 26 Apr 2005 23:13:38 +0800 (MYT) From: "Simon Teh" To: Subject: RE: Please all respond: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ar-04.txt Date: Tue, 26 Apr 2005 23:13:27 +0800 Organization: NRG MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <426D0DC9.4010702@erg.abdn.ac.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVJrPq/AiAvYSQCTUCvr/CgdSiPVgAxRUgw Message-Id: <20050426151338.215D4220107@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-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit Dear members, I vote the recommendation no.1 Best Regards, Simon Teh Universiti Sains Malaysia -----Original Message----- From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On Behalf Of Gorry Fairhurst Sent: 25 April 2005 23:33 To: ipdvb@erg.abdn.ac.uk Subject: Please all respond: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ar-04.txt As WG chair, I request the ipdvb list to consider whether the WG is ready to support adoption of the following individual Internet Draft (ID) as a WG ID. By adopting an individual ID as a working group ID, this WG indicates that it intends to be develop this into an RFC, according to the WG charter. WG documents should no longer be regarded as the property of the individuals who originally authored them - the working group as a whole must decide how they are shaped, and to see the document to a successful conclusion. If adopted, the Internet Draft will be renamed to start with the filename draft-ietf-ipdvb..., and will be listed on the IETF web page for this WG. --- Title : Address Resolution for IP datagrams over MPEG-2 networks Author(s) : G. Fairhurst, et al. Filename : draft-fair-ipdvb-ar-04.txt Pages : 17 Date : 2005-4-12 This document describes the process of binding/associating IPv4/IPv6 addresses with MPEG-2 Transport Streams (TS). This procedure is known as Address Resolution (AR), or Neighbour Discovery (ND). Such address resolution complements the higher layer resource discovery tools that are used to advertise IP sessions. In MPEG-2 networks, an IP address must be associated with a Packet ID (PID) and a specific Transmission Multiplex The document reviews current methods. It also describes the interaction with well-known protocols for address management including DHCP, ARP, and NDP, and provides guidance on usage. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-fair-ipdvb-ar-04.txt --- You are encouraged to send email to this WG, to help make the decision for adoption. Possible recommendations are: 1) Support for adoption as a working group draft under our Charter - i.e. Recommend this Internet Draft SHOULD be used as the basis for developing an RFC by the ipdvb WG. 2) Request for non-adoption i.e. That there is (or could be) alternative approaches to the problem, and that the current draft is not sufficiently developed / or correctly designed ipdvb WG 3) Out of scope i.e. you believe the document to be beyond the scope of the approved ipdvb WG charter. Emails on this topic should be sent to the ipdvb mailing list before 6th May 2005. Note that an ID does not need to be complete to be adopted. It would also be most useful to collect as many comments/criticisms as possible from those reading this ID. Looking through the archived mailing list, a first list of issues to be addressed is included at the end of this email. Please do help to identify any more known (or potential) issues that should be addressed/discussed. Best wishes, Gorry Fairhurst (ipdvb WG Chair) From owner-ipdvb@erg.abdn.ac.uk Tue Apr 26 12:32:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23792 for ; Tue, 26 Apr 2005 12:32:04 -0400 (EDT) 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 1DQTB4-0000u3-3h for ipdvb-archive@ietf.org; Tue, 26 Apr 2005 12:45:01 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3QFksIH027464 for ; Tue, 26 Apr 2005 16:46:54 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j3QFkrrO027463 for ipdvb-subscribed-users; Tue, 26 Apr 2005 16:46:53 +0100 (BST) 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 j3QFkLBf027445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 26 Apr 2005 16:46:22 +0100 (BST) Message-ID: <426E624E.5010001@erg.abdn.ac.uk> Date: Tue, 26 Apr 2005 16:46:22 +0100 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: Please all respond: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ar-04.txt References: <426D0DC9.4010702@erg.abdn.ac.uk> <426E4D9A.50107@sunaut.uab.es> In-Reply-To: <426E4D9A.50107@sunaut.uab.es> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Content-Transfer-Encoding: 7bit Thanks for noting the typos, it's always good to know people have read the documents - these typos will be fixed in the next revision of the draft. Gorry Fausto Vieira wrote: > Dear all, > > This is the first time I see this document. > > I also vote for WG ID. > > Nonetheless, here are my remarks on the current version of the document: > > The following sentence is duplicated in the draft (page 5): > "The all 1s PID value indicates a Null TS Packet introduced to maintain > a constant bit rate of a TS Multiplex. There is no required relationship > between the PID values used for TS Logical Channels transmitted using > different TS Multiplexes." > > This sentence is also duplicated (page 5): > "PSI: Program Specific Information [ISO-MPEG2]. PSI is used to convey > information about services carried in a TS Multiplex. It is carried in > one of four specifically identified table section constructs > [ISO-MPEG2], see also SI Table. > > Spelling error: > "Multicast address resolution occurs at one level in associating a > specific L2 address with _am_ IP Group Destination Address" > Change the underlined to "an" > > Spelling error: > "The principle drawbacks are that _while_ the INT, there is a need for a > Gateway to introduce associated PSI/SI MPEG-2 control information." > Change the underlined to "with" > > Spelling error: > "(...) or parts of the network where gateway devices isolate the MPEG > devices from the larger Internet creating virtual MPEG2 private networks.)" > Move the last parentheses to before the period mark. > > Spelling error: > "The ND protocol of IPv6 [RFC2461] may be used.NDP does not require (...)" > Insert a after the period mark. > > Spelling error: > "The ND protocol of IPv6 [RFC2461] may be used with The LLC/SNAP format > of MPE. NDP does not require(...)" > Remove the 2nd after the period mark. > > > Cheers > > Fausto Vieira > > > > > Gorry Fairhurst wrote: > >> As WG chair, I request the ipdvb list to consider whether the WG is >> ready to support adoption of the following individual Internet Draft >> (ID) as a WG ID. By adopting an individual ID as a working group ID, >> this WG indicates that it intends to be develop this into an RFC, >> according to the WG charter. >> >> WG documents should no longer be regarded as the property of the >> individuals who originally authored them - the working group as a >> whole must decide how they are shaped, and to see the document to a >> successful conclusion. If adopted, the Internet Draft will be renamed >> to start with the filename draft-ietf-ipdvb..., and will be listed on >> the IETF web page for this WG. >> >> >> --- >> >> Title : Address Resolution for IP datagrams over >> MPEG-2 networks >> Author(s) : G. Fairhurst, et al. >> Filename : draft-fair-ipdvb-ar-04.txt >> Pages : 17 >> Date : 2005-4-12 >> >> This document describes the process of binding/associating IPv4/IPv6 >> addresses with MPEG-2 Transport Streams (TS). This procedure is >> known as Address Resolution (AR), or Neighbour Discovery (ND). Such >> address resolution complements the higher layer resource discovery >> tools that are used to advertise IP sessions. In MPEG-2 networks, an >> IP address must be associated with a Packet ID (PID) and a specific >> Transmission Multiplex The document reviews current methods. It also >> describes the interaction with well-known protocols for address >> management including DHCP, ARP, and NDP, and provides guidance on >> usage. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-fair-ipdvb-ar-04.txt >> >> --- >> >> You are encouraged to send email to this WG, to help make the decision >> for adoption. Possible recommendations are: >> >> 1) Support for adoption as a working group draft under our >> Charter - >> i.e. Recommend this Internet Draft SHOULD be used as the basis for >> developing an RFC by the ipdvb WG. >> >> 2) Request for non-adoption >> i.e. That there is (or could be) alternative approaches to >> the problem, and that the current draft is not sufficiently >> developed / or correctly designed ipdvb WG >> >> 3) Out of scope >> i.e. you believe the document to be beyond the scope of the >> approved ipdvb WG charter. >> >> Emails on this topic should be sent to the ipdvb mailing list before >> 6th May 2005. >> >> Note that an ID does not need to be complete to be adopted. It would >> also be most useful to collect as many comments/criticisms as possible >> from those reading this ID. Looking through the archived mailing >> list, a first list of issues to be addressed is included at the end of >> this email. >> >> Please do help to identify any more known (or potential) issues that >> should be addressed/discussed. >> >> Best wishes, >> >> Gorry Fairhurst >> (ipdvb WG Chair) >> > > From owner-ipdvb@erg.abdn.ac.uk Tue Apr 26 23:53:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21444 for ; Tue, 26 Apr 2005 23:53:05 -0400 (EDT) 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 1DQdoL-00005k-BX for ipdvb-archive@ietf.org; Wed, 27 Apr 2005 00:06:08 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3R3AtT1010565 for ; Wed, 27 Apr 2005 04:10:55 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j3R3AtCA010564 for ipdvb-subscribed-users; Wed, 27 Apr 2005 04:10:55 +0100 (BST) 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 j3R3ANAO010548 for ; Wed, 27 Apr 2005 04:10:25 +0100 (BST) Received: from localhost (localhost.localdomain [127.0.0.1]) by nrg.cs.usm.my (Postfix) with ESMTP id 8ECCF220110 for ; Wed, 27 Apr 2005 11:10:17 +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 28629-09 for ; Wed, 27 Apr 2005 11:10:15 +0800 (MYT) Received: from [10.207.140.97] (unknown [10.207.140.97]) by nrg.cs.usm.my (Postfix) with ESMTP id 262EF22010D for ; Wed, 27 Apr 2005 11:10:15 +0800 (MYT) Subject: Re: Please all respond: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ar-04.txt From: nurul To: "ipdvb@erg.abdn.ac.uk" In-Reply-To: <426D0DC9.4010702@erg.abdn.ac.uk> References: <426D0DC9.4010702@erg.abdn.ac.uk> Content-Type: text/plain Message-Id: <1114571589.3757.28.camel@nurul> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 27 Apr 2005 11:13:09 +0800 Content-Transfer-Encoding: 7bit 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-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit voting for no. 1 On Mon, 2005-04-25 at 23:33, Gorry Fairhurst wrote: > As WG chair, I request the ipdvb list to consider whether the WG is > ready to support adoption of the following individual Internet Draft > (ID) as a WG ID. By adopting an individual ID as a working group ID, > this WG indicates that it intends to be develop this into an RFC, > according to the WG charter. > > WG documents should no longer be regarded as the property of the > individuals who originally authored them - the working group as a > whole must decide how they are shaped, and to see the document to a > successful conclusion. If adopted, the Internet Draft will be renamed > to start with the filename draft-ietf-ipdvb..., and will be listed on > the IETF web page for this WG. > > > --- > > Title : Address Resolution for IP datagrams over > MPEG-2 networks > Author(s) : G. Fairhurst, et al. > Filename : draft-fair-ipdvb-ar-04.txt > Pages : 17 > Date : 2005-4-12 > > This document describes the process of binding/associating IPv4/IPv6 > addresses with MPEG-2 Transport Streams (TS). This procedure is > known as Address Resolution (AR), or Neighbour Discovery (ND). Such > address resolution complements the higher layer resource discovery > tools that are used to advertise IP sessions. In MPEG-2 networks, an > IP address must be associated with a Packet ID (PID) and a specific > Transmission Multiplex The document reviews current methods. It also > describes the interaction with well-known protocols for address > management including DHCP, ARP, and NDP, and provides guidance on > usage. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-fair-ipdvb-ar-04.txt > > --- > > You are encouraged to send email to this WG, to help make the decision > for adoption. Possible recommendations are: > > 1) Support for adoption as a working group draft under our Charter - > i.e. Recommend this Internet Draft SHOULD be used as the basis for > developing an RFC by the ipdvb WG. > > 2) Request for non-adoption > i.e. That there is (or could be) alternative approaches to > the problem, and that the current draft is not sufficiently > developed / or correctly designed ipdvb WG > > 3) Out of scope > i.e. you believe the document to be beyond the scope of the > approved ipdvb WG charter. > > Emails on this topic should be sent to the ipdvb mailing list before > 6th May 2005. > > Note that an ID does not need to be complete to be adopted. It would > also be most useful to collect as many comments/criticisms as possible > from those reading this ID. Looking through the archived mailing > list, a first list of issues to be addressed is included at the end of > this email. > > Please do help to identify any more known (or potential) issues that > should be addressed/discussed. > > Best wishes, > > Gorry Fairhurst > (ipdvb WG Chair) > From owner-ipdvb@erg.abdn.ac.uk Wed Apr 27 00:10:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22581 for ; Wed, 27 Apr 2005 00:10:15 -0400 (EDT) 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 1DQe4y-0000NM-Ha for ipdvb-archive@ietf.org; Wed, 27 Apr 2005 00:23:18 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3R3VJtw010956 for ; Wed, 27 Apr 2005 04:31:19 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j3R3VI1R010955 for ipdvb-subscribed-users; Wed, 27 Apr 2005 04:31:18 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from smtp2.mei.co.jp (smtp2.mei.co.jp [133.183.129.27]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3R3Tf7q010897 for ; Wed, 27 Apr 2005 04:29:42 +0100 (BST) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp2.mei.co.jp (8.12.10/3.7W/jazz) with ESMTP id j3R3TWjp013099 for ; Wed, 27 Apr 2005 12:29:32 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id j3R3TYG27438 for ; Wed, 27 Apr 2005 12:29:34 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/whitesox) with ESMTP id j3R3TXN20802 for ; Wed, 27 Apr 2005 12:29:33 +0900 (JST) Received: from psl.com.sg ([10.81.114.28]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.211); Wed, 27 Apr 2005 11:27:06 +0800 Message-ID: <426F0686.7050003@psl.com.sg> Date: Wed, 27 Apr 2005 11:27:02 +0800 From: Chen Zhigao User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: Re: Please all respond: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ar-04.txt References: <426D0DC9.4010702@erg.abdn.ac.uk> <1FE098C0BBDC403DBF3C015C@[10.1.1.109]> In-Reply-To: <1FE098C0BBDC403DBF3C015C@[10.1.1.109]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Apr 2005 03:27:06.0564 (UTC) FILETIME=[FCDCB040:01C54AD8] X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 7bit I am happy to see the AR I-D to be put forward and become a WG draft. --Zhigao > > > --On Montag, 25. April 2005 16:33 Uhr +0100 Gorry Fairhurst > wrote: > > | As WG chair, I request the ipdvb list to consider whether the WG is > | ready to support adoption of the following individual Internet Draft > | (ID) as a WG ID. By adopting an individual ID as a working group ID, > | this WG indicates that it intends to be develop this into an RFC, > | according to the WG charter. > | > | WG documents should no longer be regarded as the property of the > | individuals who originally authored them - the working group as a > | whole must decide how they are shaped, and to see the document to a > | successful conclusion. If adopted, the Internet Draft will be renamed > | to start with the filename draft-ietf-ipdvb..., and will be listed on > | the IETF web page for this WG. > | > | > | --- > | > | Title : Address Resolution for IP datagrams over > | MPEG-2 networks > | Author(s) : G. Fairhurst, et al. > | Filename : draft-fair-ipdvb-ar-04.txt > | Pages : 17 > | Date : 2005-4-12 > | > | This document describes the process of binding/associating > IPv4/IPv6 > | addresses with MPEG-2 Transport Streams (TS). This procedure is > | known as Address Resolution (AR), or Neighbour Discovery (ND). Such > | address resolution complements the higher layer resource discovery > | tools that are used to advertise IP sessions. In MPEG-2 > networks, an > | IP address must be associated with a Packet ID (PID) and a specific > | Transmission Multiplex The document reviews current methods. It > also > | describes the interaction with well-known protocols for address > | management including DHCP, ARP, and NDP, and provides guidance on > | usage. > | > | A URL for this Internet-Draft is: > | http://www.ietf.org/internet-drafts/draft-fair-ipdvb-ar-04.txt > | > | --- > | > | You are encouraged to send email to this WG, to help make the decision > | for adoption. Possible recommendations are: > | > | 1) Support for adoption as a working group draft under our > Charter > | - > | i.e. Recommend this Internet Draft SHOULD be used as the > basis for > | developing an RFC by the ipdvb WG. > | > | 2) Request for non-adoption > | i.e. That there is (or could be) alternative approaches to > | the problem, and that the current draft is not sufficiently > | developed / or correctly designed ipdvb WG > | > | 3) Out of scope > | i.e. you believe the document to be beyond the scope of the > | approved ipdvb WG charter. > | > | Emails on this topic should be sent to the ipdvb mailing list before > | 6th May 2005. > | > | Note that an ID does not need to be complete to be adopted. It would > | also be most useful to collect as many comments/criticisms as possible > | from those reading this ID. Looking through the archived mailing > | list, a first list of issues to be addressed is included at the end of > | this email. > | > | Please do help to identify any more known (or potential) issues that > | should be addressed/discussed. > | > | Best wishes, > | > | Gorry Fairhurst > | (ipdvb WG Chair) > | > > > From owner-ipdvb@erg.abdn.ac.uk Wed Apr 27 08:01:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29127 for ; Wed, 27 Apr 2005 08:01:59 -0400 (EDT) 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 1DQlRV-0000wZ-Un for ipdvb-archive@ietf.org; Wed, 27 Apr 2005 08:15:05 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3RB6JGn020784 for ; Wed, 27 Apr 2005 12:06:19 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j3RB6Jbx020783 for ipdvb-subscribed-users; Wed, 27 Apr 2005 12:06:19 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from mailg.surrey.ac.uk (mailg.surrey.ac.uk [131.227.102.21]) by erg.abdn.ac.uk (8.12.11/8.12.11) with SMTP id j3RB5hRu020757 for ; Wed, 27 Apr 2005 12:05:43 +0100 (BST) Received: from ads33.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Wed, 27 Apr 2005 11:52:07 +0100 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads33.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.211); Wed, 27 Apr 2005 11:52:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Please all respond: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ar-04.txt Date: Wed, 27 Apr 2005 11:52:06 +0100 Message-ID: Thread-Topic: Please all respond: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ar-04.txt Thread-Index: AcVJsctVUMxxyeLoT3mUp9ATN1vEmABZSgFw From: "H.Cruickshank" To: ipdvb X-OriginalArrivalTime: 27 Apr 2005 10:52:06.0272 (UTC) FILETIME=[2720D000:01C54B17] X-ERG-MailScanner: Found to be clean, Found to be clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by erg.abdn.ac.uk id j3RB6G0F020780 Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 8bit Hi All, Voting for no. 1 I suppose security consideration sectionwill come in future versions. Haitham -----Original Message----- From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On Behalf Of Gorry Fairhurst Sent: 25 April 2005 16:33 To: ipdvb@erg.abdn.ac.uk Subject: Please all respond: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ar-04.txt As WG chair, I request the ipdvb list to consider whether the WG is ready to support adoption of the following individual Internet Draft (ID) as a WG ID. By adopting an individual ID as a working group ID, this WG indicates that it intends to be develop this into an RFC, according to the WG charter. WG documents should no longer be regarded as the property of the individuals who originally authored them - the working group as a whole must decide how they are shaped, and to see the document to a successful conclusion. If adopted, the Internet Draft will be renamed to start with the filename draft-ietf-ipdvb..., and will be listed on the IETF web page for this WG. --- Title : Address Resolution for IP datagrams over MPEG-2 networks Author(s) : G. Fairhurst, et al. Filename : draft-fair-ipdvb-ar-04.txt Pages : 17 Date : 2005-4-12 This document describes the process of binding/associating IPv4/IPv6 addresses with MPEG-2 Transport Streams (TS). This procedure is known as Address Resolution (AR), or Neighbour Discovery (ND). Such address resolution complements the higher layer resource discovery tools that are used to advertise IP sessions. In MPEG-2 networks, an IP address must be associated with a Packet ID (PID) and a specific Transmission Multiplex The document reviews current methods. It also describes the interaction with well-known protocols for address management including DHCP, ARP, and NDP, and provides guidance on usage. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-fair-ipdvb-ar-04.txt --- You are encouraged to send email to this WG, to help make the decision for adoption. Possible recommendations are: 1) Support for adoption as a working group draft under our Charter - i.e. Recommend this Internet Draft SHOULD be used as the basis for developing an RFC by the ipdvb WG. 2) Request for non-adoption i.e. That there is (or could be) alternative approaches to the problem, and that the current draft is not sufficiently developed / or correctly designed ipdvb WG 3) Out of scope i.e. you believe the document to be beyond the scope of the approved ipdvb WG charter. Emails on this topic should be sent to the ipdvb mailing list before 6th May 2005. Note that an ID does not need to be complete to be adopted. It would also be most useful to collect as many comments/criticisms as possible from those reading this ID. Looking through the archived mailing list, a first list of issues to be addressed is included at the end of this email. Please do help to identify any more known (or potential) issues that should be addressed/discussed. Best wishes, Gorry Fairhurst (ipdvb WG Chair) From owner-ipdvb@erg.abdn.ac.uk Wed Apr 27 21:17:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27510 for ; Wed, 27 Apr 2005 21:17:01 -0400 (EDT) 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 1DQxr3-0000fw-JG for ipdvb-archive@ietf.org; Wed, 27 Apr 2005 21:30:15 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3S0aPCO007867 for ; Thu, 28 Apr 2005 01:36:25 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j3S0aOc7007866 for ipdvb-subscribed-users; Thu, 28 Apr 2005 01:36:25 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from web42204.mail.yahoo.com (web42204.mail.yahoo.com [66.218.93.205]) by erg.abdn.ac.uk (8.12.11/8.12.11) with SMTP id j3S0ZdOX007835 for ; Thu, 28 Apr 2005 01:35:40 +0100 (BST) Received: (qmail 38132 invoked by uid 60001); 28 Apr 2005 00:35:35 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=G8mbatOD6IFR6D8Pb7u5y5AcVu9QsTm2QPjRqvaKBMsmI/mDqUgg9yPOnkqK7qL0DzNi1kj5/0P3Uyv1oSir5lRfnSFQFLaujTgDQMOU5vsMB65ZzGA4QJs2+LFTT0dHhUzCRYpzmXf3f1zWKulgRcCx2Z3+tJ4boZxk3gN5mrY= ; Message-ID: <20050428003535.38130.qmail@web42204.mail.yahoo.com> Received: from [129.46.216.198] by web42204.mail.yahoo.com via HTTP; Wed, 27 Apr 2005 17:35:35 PDT Date: Wed, 27 Apr 2005 17:35:35 -0700 (PDT) From: Siva Veerepalli Subject: MPE Question To: ipdvb@erg.abdn.ac.uk Cc: sivaveer@yahoo.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 A couple of questions about MPE-FEC framing. 1. The interim IP datacast standard A079 (meant to facilitate DVB-H trials) specifies that only one datagram should be used per MPE section i.e., no fragmentation of IP datagram over multiple MPE sections. However, the DVB Databroadcast specification allows fragmentation of the IP datagram over multiple sections. Does anyone know what the usual practice is? Do the final DVB/IP datacast standards specify this for DVB-H? 2. The MPE section has optional stuffing bytes at the end of the section. Are these used? If yes, for what? thanks, Siva __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-ipdvb@erg.abdn.ac.uk Thu Apr 28 02:43:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12631 for ; Thu, 28 Apr 2005 02:43:55 -0400 (EDT) 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 1DR2xP-0002mJ-R0 for ipdvb-archive@ietf.org; Thu, 28 Apr 2005 02:57:11 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3S5NouF013380 for ; Thu, 28 Apr 2005 06:23:50 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j3S5NoGR013379 for ipdvb-subscribed-users; Thu, 28 Apr 2005 06:23:50 +0100 (BST) 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 j3S5NHRA013351 for ; Thu, 28 Apr 2005 06:23:17 +0100 (BST) Received: from [127.0.0.1] (milbe.cosy.sbg.ac.at [141.201.2.21]) by loewe.cosy.sbg.ac.at (8.8.8/8.8.7) with ESMTP id HAA18132 for ; Thu, 28 Apr 2005 07:23:17 +0200 (MET DST) Message-ID: <42707323.6070201@cosy.sbg.ac.at> Date: Thu, 28 Apr 2005 07:22:43 +0200 From: Bernhard Collini-Nocker User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: Re: MPE Question References: <20050428003535.38130.qmail@web42204.mail.yahoo.com> In-Reply-To: <20050428003535.38130.qmail@web42204.mail.yahoo.com> 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-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Siva Veerepalli wrote: > A couple of questions about MPE-FEC framing. > > 1. The interim IP datacast standard A079 (meant to > facilitate DVB-H trials) specifies that only one > datagram should be used per MPE section i.e., no > fragmentation of IP datagram over multiple MPE > sections. However, the DVB Databroadcast specification > allows fragmentation of the IP datagram over multiple > sections. Does anyone know what the usual practice is? In order to reduce encapsulation overhead, section packing is used, i.e. if the (remainder of an) IP packet does not fit exactly in a TS packet a subsequent IP packet may start in that TS packet as well. In order to reduce jitter and latency, section packing is not used. You can find both on existing services. > Do the final DVB/IP datacast standards specify this > for DVB-H? The difficulty with section peckaing on the transmit side is that the encapsulator needs to wait for subsequent IP packets to fill an partially filled TS packet and therefor has typically a time-out associated to that waiting, ie before flushing the buffer and transmitting the final TS packet. > 2. The MPE section has optional stuffing bytes at the > end of the section. Are these used? If yes, for what? Whenver an IP packets leaves "enough" space in the last TS packet another IP packet could be inserted. If not wanted or needed, stuffing takes care that the empty space is filled up with pattern 0xFF. > thanks, > Siva > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > From owner-ipdvb@erg.abdn.ac.uk Thu Apr 28 02:43:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12651 for ; Thu, 28 Apr 2005 02:43:57 -0400 (EDT) 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 1DR2xS-0002mQ-D6 for ipdvb-archive@ietf.org; Thu, 28 Apr 2005 02:57:13 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3S5eG9K013759 for ; Thu, 28 Apr 2005 06:40:16 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j3S5eGXX013758 for ipdvb-subscribed-users; Thu, 28 Apr 2005 06:40:16 +0100 (BST) 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 j3S5diGI013731 for ; Thu, 28 Apr 2005 06:39:45 +0100 (BST) Received: from localhost (localhost.localdomain [127.0.0.1]) by nrg.cs.usm.my (Postfix) with ESMTP id C968D22011A for ; Thu, 28 Apr 2005 13:39:37 +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 17427-04 for ; Thu, 28 Apr 2005 13:39:36 +0800 (MYT) Received: from [10.207.140.97] (unknown [10.207.140.97]) by nrg.cs.usm.my (Postfix) with ESMTP id 35B71220116 for ; Thu, 28 Apr 2005 13:39:36 +0800 (MYT) Subject: Re: MPE Question From: nurul To: "ipdvb@erg.abdn.ac.uk" In-Reply-To: <42707323.6070201@cosy.sbg.ac.at> References: <20050428003535.38130.qmail@web42204.mail.yahoo.com> <42707323.6070201@cosy.sbg.ac.at> Content-Type: text/plain Message-Id: <1114666952.4102.7.camel@nurul> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 28 Apr 2005 13:42:33 +0800 Content-Transfer-Encoding: 7bit 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-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Hi, Do MPE allows packing? cause as far as i concern it's only allow padding while ULE allows both. Correct me if i'm wrong. regards, nurul On Thu, 2005-04-28 at 13:22, Bernhard Collini-Nocker wrote: > Siva Veerepalli wrote: > > A couple of questions about MPE-FEC framing. > > > > 1. The interim IP datacast standard A079 (meant to > > facilitate DVB-H trials) specifies that only one > > datagram should be used per MPE section i.e., no > > fragmentation of IP datagram over multiple MPE > > sections. However, the DVB Databroadcast specification > > allows fragmentation of the IP datagram over multiple > > sections. Does anyone know what the usual practice is? > > In order to reduce encapsulation overhead, section packing is used, i.e. > if the (remainder of an) IP packet does not fit exactly in a TS packet a > subsequent IP packet may start in that TS packet as well. > In order to reduce jitter and latency, section packing is not used. > > You can find both on existing services. > > > Do the final DVB/IP datacast standards specify this > > for DVB-H? > > The difficulty with section peckaing on the transmit side is that the > encapsulator needs to wait for subsequent IP packets to fill an > partially filled TS packet and therefor has typically a time-out > associated to that waiting, ie before flushing the buffer and > transmitting the final TS packet. > > > 2. The MPE section has optional stuffing bytes at the > > end of the section. Are these used? If yes, for what? > > Whenver an IP packets leaves "enough" space in the last TS packet > another IP packet could be inserted. If not wanted or needed, stuffing > takes care that the empty space is filled up with pattern 0xFF. > > > thanks, > > Siva > > > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam protection around > > http://mail.yahoo.com > > > From owner-ipdvb@erg.abdn.ac.uk Thu Apr 28 03:26:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16153 for ; Thu, 28 Apr 2005 03:26:42 -0400 (EDT) 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 1DR3cq-0004VW-Vd for ipdvb-archive@ietf.org; Thu, 28 Apr 2005 03:39:59 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3S6KacD014645 for ; Thu, 28 Apr 2005 07:20:36 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j3S6KZFD014644 for ipdvb-subscribed-users; Thu, 28 Apr 2005 07:20:35 +0100 (BST) 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 (netmon.cs.usm.my [161.142.8.104]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3S6JkWl014600 for ; Thu, 28 Apr 2005 07:19:47 +0100 (BST) Received: from localhost (localhost.localdomain [127.0.0.1]) by nrg.cs.usm.my (Postfix) with ESMTP id 2CC14220122 for ; Thu, 28 Apr 2005 14:19:41 +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 18067-08 for ; Thu, 28 Apr 2005 14:19:39 +0800 (MYT) Received: from abc (unknown [219.93.2.101]) by nrg.cs.usm.my (Postfix) with ESMTP id 734C4220129 for ; Thu, 28 Apr 2005 14:19:39 +0800 (MYT) From: "Simon Teh" To: Subject: RE: MPE Question Date: Thu, 28 Apr 2005 14:19:30 +0800 Organization: NRG MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <1114666952.4102.7.camel@nurul> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVLtSdGYqNnpCvNQf2ifWoP7g2E7gAA0cZQ Message-Id: <20050428061939.734C4220129@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-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Dear members, For packing and padding, it depends on the TS packet. If a payload unit finishes before the end of a TS packet payload, and where there is sufficient space, the TS packet will carry one more new payload unit. So, TS packet padding and packing can be used for MPE and ULE. I hope it will help. Best Regards, Simon Teh Universiti Sains Malaysia -----Original Message----- From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On Behalf Of nurul Sent: 28 April 2005 13:43 To: ipdvb@erg.abdn.ac.uk Subject: Re: MPE Question Hi, Do MPE allows packing? cause as far as i concern it's only allow padding while ULE allows both. Correct me if i'm wrong. regards, nurul On Thu, 2005-04-28 at 13:22, Bernhard Collini-Nocker wrote: > Siva Veerepalli wrote: > > A couple of questions about MPE-FEC framing. > > > > 1. The interim IP datacast standard A079 (meant to > > facilitate DVB-H trials) specifies that only one > > datagram should be used per MPE section i.e., no > > fragmentation of IP datagram over multiple MPE > > sections. However, the DVB Databroadcast specification > > allows fragmentation of the IP datagram over multiple > > sections. Does anyone know what the usual practice is? > > In order to reduce encapsulation overhead, section packing is used, i.e. > if the (remainder of an) IP packet does not fit exactly in a TS packet a > subsequent IP packet may start in that TS packet as well. > In order to reduce jitter and latency, section packing is not used. > > You can find both on existing services. > > > Do the final DVB/IP datacast standards specify this > > for DVB-H? > > The difficulty with section peckaing on the transmit side is that the > encapsulator needs to wait for subsequent IP packets to fill an > partially filled TS packet and therefor has typically a time-out > associated to that waiting, ie before flushing the buffer and > transmitting the final TS packet. > > > 2. The MPE section has optional stuffing bytes at the > > end of the section. Are these used? If yes, for what? > > Whenver an IP packets leaves "enough" space in the last TS packet > another IP packet could be inserted. If not wanted or needed, stuffing > takes care that the empty space is filled up with pattern 0xFF. > > > thanks, > > Siva > > > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam protection around > > http://mail.yahoo.com > > > From owner-ipdvb@erg.abdn.ac.uk Thu Apr 28 04:51:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24640 for ; Thu, 28 Apr 2005 04:51:12 -0400 (EDT) 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 1DR4we-00088L-Ik for ipdvb-archive@ietf.org; Thu, 28 Apr 2005 05:04:30 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3S87P4d016359 for ; Thu, 28 Apr 2005 09:07:25 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j3S87PcG016358 for ipdvb-subscribed-users; Thu, 28 Apr 2005 09:07:25 +0100 (BST) 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 j3S86FjA016312 for ; Thu, 28 Apr 2005 09:06:16 +0100 (BST) Received: from localhost (localhost.localdomain [127.0.0.1]) by nrg.cs.usm.my (Postfix) with ESMTP id 6AEC3220119 for ; Thu, 28 Apr 2005 16:06:10 +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 21639-05 for ; Thu, 28 Apr 2005 16:06:08 +0800 (MYT) Received: from [10.207.140.97] (unknown [10.207.140.97]) by nrg.cs.usm.my (Postfix) with ESMTP id CD853220116 for ; Thu, 28 Apr 2005 16:06:08 +0800 (MYT) Subject: Re: MPE Question From: nurul To: "ipdvb@erg.abdn.ac.uk" In-Reply-To: References: Content-Type: text/plain Message-Id: <1114675745.4102.16.camel@nurul> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 28 Apr 2005 16:09:05 +0800 Content-Transfer-Encoding: 7bit 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-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit i see. thank you Sir. regards, nurul On Thu, 2005-04-28 at 15:49, Gorry Fairhurst wrote: > Indeed the MPE specification *DOES* allow section packing as an option. Not > all drivers/implementations permit this. > > Conversely, in ULE *ALL* compliant drivers MUST support it. > > Gorry Fairhurst > > On 28/4/05 6:42 am, "nurul" wrote: > > > Hi, > > > > Do MPE allows packing? cause as far as i concern it's only allow padding > > while ULE allows both. Correct me if i'm wrong. > > > > regards, > > nurul > > > > On Thu, 2005-04-28 at 13:22, Bernhard Collini-Nocker wrote: > >> Siva Veerepalli wrote: > >>> A couple of questions about MPE-FEC framing. > >>> > >>> 1. The interim IP datacast standard A079 (meant to > >>> facilitate DVB-H trials) specifies that only one > >>> datagram should be used per MPE section i.e., no > >>> fragmentation of IP datagram over multiple MPE > >>> sections. However, the DVB Databroadcast specification > >>> allows fragmentation of the IP datagram over multiple > >>> sections. Does anyone know what the usual practice is? > >> > >> In order to reduce encapsulation overhead, section packing is used, i.e. > >> if the (remainder of an) IP packet does not fit exactly in a TS packet a > >> subsequent IP packet may start in that TS packet as well. > >> In order to reduce jitter and latency, section packing is not used. > >> > >> You can find both on existing services. > >> > >>> Do the final DVB/IP datacast standards specify this > >>> for DVB-H? > >> > >> The difficulty with section peckaing on the transmit side is that the > >> encapsulator needs to wait for subsequent IP packets to fill an > >> partially filled TS packet and therefor has typically a time-out > >> associated to that waiting, ie before flushing the buffer and > >> transmitting the final TS packet. > >> > >>> 2. The MPE section has optional stuffing bytes at the > >>> end of the section. Are these used? If yes, for what? > >> > >> Whenver an IP packets leaves "enough" space in the last TS packet > >> another IP packet could be inserted. If not wanted or needed, stuffing > >> takes care that the empty space is filled up with pattern 0xFF. > >> > >>> thanks, > >>> Siva > >>> > >>> > >>> __________________________________________________ > >>> Do You Yahoo!? > >>> Tired of spam? Yahoo! Mail has the best spam protection around > >>> http://mail.yahoo.com > >>> > >> > > > > From owner-ipdvb@erg.abdn.ac.uk Thu Apr 28 04:54:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24765 for ; Thu, 28 Apr 2005 04:54:04 -0400 (EDT) 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 1DR4zP-0008Ek-DF for ipdvb-archive@ietf.org; Thu, 28 Apr 2005 05:07:22 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3S7p69J015976 for ; Thu, 28 Apr 2005 08:51:06 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j3S7p5Ea015975 for ipdvb-subscribed-users; Thu, 28 Apr 2005 08:51:05 +0100 (BST) 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.7] (maxp17.dialup.abdn.ac.uk [139.133.201.176]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3S7noBb015919 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 28 Apr 2005 08:49:55 +0100 (BST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 28 Apr 2005 08:49:40 +0100 Subject: Re: MPE Question From: Gorry Fairhurst To: Message-ID: In-Reply-To: <1114666952.4102.7.camel@nurul> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Indeed the MPE specification *DOES* allow section packing as an option. Not all drivers/implementations permit this. Conversely, in ULE *ALL* compliant drivers MUST support it. Gorry Fairhurst On 28/4/05 6:42 am, "nurul" wrote: > Hi, > > Do MPE allows packing? cause as far as i concern it's only allow padding > while ULE allows both. Correct me if i'm wrong. > > regards, > nurul > > On Thu, 2005-04-28 at 13:22, Bernhard Collini-Nocker wrote: >> Siva Veerepalli wrote: >>> A couple of questions about MPE-FEC framing. >>> >>> 1. The interim IP datacast standard A079 (meant to >>> facilitate DVB-H trials) specifies that only one >>> datagram should be used per MPE section i.e., no >>> fragmentation of IP datagram over multiple MPE >>> sections. However, the DVB Databroadcast specification >>> allows fragmentation of the IP datagram over multiple >>> sections. Does anyone know what the usual practice is? >> >> In order to reduce encapsulation overhead, section packing is used, i.e. >> if the (remainder of an) IP packet does not fit exactly in a TS packet a >> subsequent IP packet may start in that TS packet as well. >> In order to reduce jitter and latency, section packing is not used. >> >> You can find both on existing services. >> >>> Do the final DVB/IP datacast standards specify this >>> for DVB-H? >> >> The difficulty with section peckaing on the transmit side is that the >> encapsulator needs to wait for subsequent IP packets to fill an >> partially filled TS packet and therefor has typically a time-out >> associated to that waiting, ie before flushing the buffer and >> transmitting the final TS packet. >> >>> 2. The MPE section has optional stuffing bytes at the >>> end of the section. Are these used? If yes, for what? >> >> Whenver an IP packets leaves "enough" space in the last TS packet >> another IP packet could be inserted. If not wanted or needed, stuffing >> takes care that the empty space is filled up with pattern 0xFF. >> >>> thanks, >>> Siva >>> >>> >>> __________________________________________________ >>> Do You Yahoo!? >>> Tired of spam? Yahoo! Mail has the best spam protection around >>> http://mail.yahoo.com >>> >> > From owner-ipdvb@erg.abdn.ac.uk Thu Apr 28 04:55:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24823 for ; Thu, 28 Apr 2005 04:55:16 -0400 (EDT) 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 1DR50a-0008Fg-M9 for ipdvb-archive@ietf.org; Thu, 28 Apr 2005 05:08:34 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3S86VTk016328 for ; Thu, 28 Apr 2005 09:06:31 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j3S86UXT016326 for ipdvb-subscribed-users; Thu, 28 Apr 2005 09:06:30 +0100 (BST) 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 j3S856nx016282 for ; Thu, 28 Apr 2005 09:05:07 +0100 (BST) Received: from [127.0.0.1] (milbe.cosy.sbg.ac.at [141.201.2.21]) by loewe.cosy.sbg.ac.at (8.8.8/8.8.7) with ESMTP id KAA11732 for ; Thu, 28 Apr 2005 10:05:06 +0200 (MET DST) Message-ID: <42709910.5040300@cosy.sbg.ac.at> Date: Thu, 28 Apr 2005 10:04:32 +0200 From: Bernhard Collini-Nocker User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: Re: MPE Question References: <20050428003535.38130.qmail@web42204.mail.yahoo.com> <42707323.6070201@cosy.sbg.ac.at> <1114666952.4102.7.camel@nurul> In-Reply-To: <1114666952.4102.7.camel@nurul> 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-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Well, section packing is allowed, and MPE uses sections, so it can "ride that horse". And, of course, MPE with section packing meanwhile is supported by nearly all IRD cards and drivers. However, it is badly described compared to ULE. Regards, Bernhard nurul wrote: > Hi, > > Do MPE allows packing? cause as far as i concern it's only allow padding > while ULE allows both. Correct me if i'm wrong. > > regards, > nurul > > On Thu, 2005-04-28 at 13:22, Bernhard Collini-Nocker wrote: > >>Siva Veerepalli wrote: >> >>>A couple of questions about MPE-FEC framing. >>> >>>1. The interim IP datacast standard A079 (meant to >>>facilitate DVB-H trials) specifies that only one >>>datagram should be used per MPE section i.e., no >>>fragmentation of IP datagram over multiple MPE >>>sections. However, the DVB Databroadcast specification >>>allows fragmentation of the IP datagram over multiple >>>sections. Does anyone know what the usual practice is? >> >>In order to reduce encapsulation overhead, section packing is used, i.e. >>if the (remainder of an) IP packet does not fit exactly in a TS packet a >>subsequent IP packet may start in that TS packet as well. >>In order to reduce jitter and latency, section packing is not used. >> >>You can find both on existing services. >> >> >>>Do the final DVB/IP datacast standards specify this >>>for DVB-H? >> >>The difficulty with section peckaing on the transmit side is that the >>encapsulator needs to wait for subsequent IP packets to fill an >>partially filled TS packet and therefor has typically a time-out >>associated to that waiting, ie before flushing the buffer and >>transmitting the final TS packet. >> >> >>>2. The MPE section has optional stuffing bytes at the >>>end of the section. Are these used? If yes, for what? >> >>Whenver an IP packets leaves "enough" space in the last TS packet >>another IP packet could be inserted. If not wanted or needed, stuffing >>takes care that the empty space is filled up with pattern 0xFF. >> >> >>>thanks, >>>Siva >>> >>> >>>__________________________________________________ >>>Do You Yahoo!? >>>Tired of spam? Yahoo! Mail has the best spam protection around >>>http://mail.yahoo.com >>> >> > From owner-ipdvb@erg.abdn.ac.uk Thu Apr 28 04:55:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24841 for ; Thu, 28 Apr 2005 04:55:26 -0400 (EDT) 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 1DR50l-0008GA-Qo for ipdvb-archive@ietf.org; Thu, 28 Apr 2005 05:08:44 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3S8EqVB016541 for ; Thu, 28 Apr 2005 09:14:52 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j3S8EpXk016540 for ipdvb-subscribed-users; Thu, 28 Apr 2005 09:14:51 +0100 (BST) 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 (netmon.cs.usm.my [161.142.8.104]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3S8DofC016495 for ; Thu, 28 Apr 2005 09:13:51 +0100 (BST) Received: from localhost (localhost.localdomain [127.0.0.1]) by nrg.cs.usm.my (Postfix) with ESMTP id 5224B22011A for ; Thu, 28 Apr 2005 16:13:45 +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 21864-02 for ; Thu, 28 Apr 2005 16:13:43 +0800 (MYT) Received: from [10.207.140.97] (unknown [10.207.140.97]) by nrg.cs.usm.my (Postfix) with ESMTP id C83C6220119 for ; Thu, 28 Apr 2005 16:13:43 +0800 (MYT) Subject: Re: MPE Question From: nurul To: "ipdvb@erg.abdn.ac.uk" In-Reply-To: <42709910.5040300@cosy.sbg.ac.at> References: <20050428003535.38130.qmail@web42204.mail.yahoo.com> <42707323.6070201@cosy.sbg.ac.at> <1114666952.4102.7.camel@nurul> <42709910.5040300@cosy.sbg.ac.at> Content-Type: text/plain Message-Id: <1114676200.4102.18.camel@nurul> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 28 Apr 2005 16:16:40 +0800 Content-Transfer-Encoding: 7bit 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-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit ahhh.. i see... thank you to you too, sir. regards, nurul On Thu, 2005-04-28 at 16:04, Bernhard Collini-Nocker wrote: > Well, section packing is allowed, and MPE uses sections, so it can "ride > that horse". And, of course, MPE with section packing meanwhile is > supported by nearly all IRD cards and drivers. However, it is badly > described compared to ULE. > > Regards, > Bernhard > > nurul wrote: > > Hi, > > > > Do MPE allows packing? cause as far as i concern it's only allow padding > > while ULE allows both. Correct me if i'm wrong. > > > > regards, > > nurul > > > > On Thu, 2005-04-28 at 13:22, Bernhard Collini-Nocker wrote: > > > >>Siva Veerepalli wrote: > >> > >>>A couple of questions about MPE-FEC framing. > >>> > >>>1. The interim IP datacast standard A079 (meant to > >>>facilitate DVB-H trials) specifies that only one > >>>datagram should be used per MPE section i.e., no > >>>fragmentation of IP datagram over multiple MPE > >>>sections. However, the DVB Databroadcast specification > >>>allows fragmentation of the IP datagram over multiple > >>>sections. Does anyone know what the usual practice is? > >> > >>In order to reduce encapsulation overhead, section packing is used, i.e. > >>if the (remainder of an) IP packet does not fit exactly in a TS packet a > >>subsequent IP packet may start in that TS packet as well. > >>In order to reduce jitter and latency, section packing is not used. > >> > >>You can find both on existing services. > >> > >> > >>>Do the final DVB/IP datacast standards specify this > >>>for DVB-H? > >> > >>The difficulty with section peckaing on the transmit side is that the > >>encapsulator needs to wait for subsequent IP packets to fill an > >>partially filled TS packet and therefor has typically a time-out > >>associated to that waiting, ie before flushing the buffer and > >>transmitting the final TS packet. > >> > >> > >>>2. The MPE section has optional stuffing bytes at the > >>>end of the section. Are these used? If yes, for what? > >> > >>Whenver an IP packets leaves "enough" space in the last TS packet > >>another IP packet could be inserted. If not wanted or needed, stuffing > >>takes care that the empty space is filled up with pattern 0xFF. > >> > >> > >>>thanks, > >>>Siva > >>> > >>> > >>>__________________________________________________ > >>>Do You Yahoo!? > >>>Tired of spam? Yahoo! Mail has the best spam protection around > >>>http://mail.yahoo.com > >>> > >> > > > From owner-ipdvb@erg.abdn.ac.uk Thu Apr 28 10:51:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23180 for ; Thu, 28 Apr 2005 10:51:26 -0400 (EDT) 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 1DRAZJ-0005sr-St for ipdvb-archive@ietf.org; Thu, 28 Apr 2005 11:04:47 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3SDgkbY023887 for ; Thu, 28 Apr 2005 14:42:46 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j3SDgkgY023886 for ipdvb-subscribed-users; Thu, 28 Apr 2005 14:42:46 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from mclean-vscan1.bah.com (mclean-vscan1.bah.com [156.80.3.61]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3SDgKD3023870 for ; Thu, 28 Apr 2005 14:42:21 +0100 (BST) Received: from mclean-vscan1.bah.com (mclean-vscan1.bah.com [156.80.3.61]) by mclean-vscan1.bah.com (8.11.0/8.11.0) with SMTP id j3SDgE029397 for ; Thu, 28 Apr 2005 09:42:14 -0400 (EDT) Received: from mclnexbh01.resource.ds.bah.com ([156.80.7.151]) by mclean-vscan1.bah.com (SAVSMTP 3.1.6.45) with SMTP id M2005042809421427121 for ; Thu, 28 Apr 2005 09:42:14 -0400 Received: from MCLNEXVS08.resource.ds.bah.com ([156.80.7.142]) by mclnexbh01.resource.ds.bah.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 28 Apr 2005 09:42:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: MPE Question Date: Thu, 28 Apr 2005 09:42:13 -0400 Message-ID: <9AE7477D59B99A44871665DBFD97FF894FD135@MCLNEXVS08.resource.ds.bah.com> Thread-Topic: MPE Question Thread-Index: AcVLzk5yi1wuIV3bTMqQ4TfoQUKQfgAJPD6w From: "Summers Edwin" To: X-OriginalArrivalTime: 28 Apr 2005 13:42:15.0567 (UTC) FILETIME=[16C159F0:01C54BF8] X-ERG-MailScanner: Found to be clean, Found to be clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by erg.abdn.ac.uk id j3SDgj3G023883 Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 8bit Greetings, While researching MPE and the proposed ULE spec, I ran across some information that I cannot equate. If I read table 3 of EN 301 193 v1.4.1 (DVB spec for data broadcasting) correctly, the overhead of an MPE section is 16 bytes (assuming LLC/SNAP not used). But while researching MPE I found a brief by Vladimir Ksinant, Alain Ritoux, and "fritsche" entitled "Using ULE for IPv4/v6 in MPEG-2 encapsulation" (12/11/2003) that states there is 17 bytes of header/trailer for IPv4 packets encapsulated by MPE, and 25 bytes for IPv6, assuming use of LLC/SNAP. 1) For a section encapsulating an IPv4 packet and not using LLC/SNAP, is the overhead 16 or 17 bytes? (same for ULE...I count 8 bytes in draft-ietf-ipdvb-ule-05 section 4 where the above document states 9 bytes, when not using the destination address) 2) (for MPE) If my original calculation of 16 bytes is correct, then would the overhead for a section using LLC/SNAP be 24 bytes (16 + 8 byte LLC/SNAP)? 3) Do current MPE implementations in IPv6 networks require the use of LLC/SNAP in the section? I know this was discussed on the list some time ago, and I believe the reason for it was because MPE does not include a type field, where ULE does. Are there any current MPE implementations that do not require LLC/SNAP for IPv6 packets? Thanks in advance! Ed -------------------- Ed Summers Booz Allen Hamilton (o) 703.377.1407 (f) 703.902.3409 From owner-ipdvb@erg.abdn.ac.uk Thu Apr 28 12:24:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01887 for ; Thu, 28 Apr 2005 12:24:12 -0400 (EDT) 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 1DRC18-0001iv-C3 for ipdvb-archive@ietf.org; Thu, 28 Apr 2005 12:37:34 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3SFr9gb026862 for ; Thu, 28 Apr 2005 16:53:09 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j3SFr95q026861 for ipdvb-subscribed-users; Thu, 28 Apr 2005 16:53:09 +0100 (BST) 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.8] (maxp17.dialup.abdn.ac.uk [139.133.201.176]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3SFqDIh026820 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 28 Apr 2005 16:52:15 +0100 (BST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 28 Apr 2005 16:52:04 +0100 Subject: Re: MPE Question From: Gorry Fairhurst To: Message-ID: In-Reply-To: <9AE7477D59B99A44871665DBFD97FF894FD135@MCLNEXVS08.resource.ds.bah.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit See a few in-line comments. On 28/4/05 2:42 pm, "Summers Edwin" wrote: > Greetings, > > While researching MPE and the proposed ULE spec, I ran across some > information that I cannot equate. > > If I read table 3 of EN 301 193 v1.4.1 (DVB spec for data broadcasting) > correctly, the overhead of an MPE section is 16 bytes (assuming LLC/SNAP > not used). OK. > But while researching MPE I found a brief by Vladimir > Ksinant, Alain Ritoux, and "fritsche" entitled "Using ULE for IPv4/v6 in > MPEG-2 encapsulation" (12/11/2003) that states there is 17 bytes of Including the Payload Pointer (PP), perhaps? - See the examples of using the PP in TS Packets at the end of the ULE Spec. > header/trailer for IPv4 packets encapsulated by MPE, and 25 bytes for > IPv6, assuming use of LLC/SNAP. > > 1) For a section encapsulating an IPv4 packet and not using LLC/SNAP, is > the overhead 16 or 17 bytes? (same for ULE...I count 8 bytes in > draft-ietf-ipdvb-ule-05 section 4 where the above document states 9 > bytes, when not using the destination address) > I guess also considering the overhead of the PP byte? > 2) (for MPE) If my original calculation of 16 bytes is correct, then > would the overhead for a section using LLC/SNAP be 24 bytes (16 + 8 byte > LLC/SNAP)? > > 3) Do current MPE implementations in IPv6 networks require the use of > LLC/SNAP in the section? I know this was discussed on the list some > time ago, and I believe the reason for it was because MPE does not > include a type field, where ULE does. Are there any current MPE > implementations that do not require LLC/SNAP for IPv6 packets? > > Thanks in advance! > Ed > > -------------------- > Ed Summers > Booz Allen Hamilton > (o) 703.377.1407 > (f) 703.902.3409 > > From owner-ipdvb@erg.abdn.ac.uk Thu Apr 28 13:16:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05658 for ; Thu, 28 Apr 2005 13:16:06 -0400 (EDT) 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 1DRCpL-0003sO-8k for ipdvb-archive@ietf.org; Thu, 28 Apr 2005 13:29:29 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3SGWtUr027898 for ; Thu, 28 Apr 2005 17:32:55 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j3SGWtOq027897 for ipdvb-subscribed-users; Thu, 28 Apr 2005 17:32:55 +0100 (BST) 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 j3SGW60A027862 for ; Thu, 28 Apr 2005 17:32:07 +0100 (BST) Received: from localhost (localhost.localdomain [127.0.0.1]) by nrg.cs.usm.my (Postfix) with ESMTP id 99BF9220119 for ; Fri, 29 Apr 2005 00:32:01 +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 27012-09 for ; Fri, 29 Apr 2005 00:31:54 +0800 (MYT) Received: from abc (unknown [219.93.2.101]) by nrg.cs.usm.my (Postfix) with ESMTP id 8F363220116 for ; Fri, 29 Apr 2005 00:31:54 +0800 (MYT) From: "Simon Teh" To: Subject: RE: MPE Question Date: Fri, 29 Apr 2005 00:31:44 +0800 Organization: NRG MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcVLzk5yi1wuIV3bTMqQ4TfoQUKQfgAJPD6wAAat4oA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <9AE7477D59B99A44871665DBFD97FF894FD135@MCLNEXVS08.resource.ds.bah.com> Message-Id: <20050428163154.8F363220116@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-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Dear members, I have gone through the document that mention by Ed Summers, for my opinion the authors had included the Payload Pointer in the overhead bytes calculation for MPE and ULE. Normally when we calculate the encapsulated bytes MPEG-2 TS for MPE and ULE: If the payload unit is a new payload, usually we calculated in this way = Encapsulated bytes =188bytes - 4bytes - 1 bytes (TS pkt size) (TS header) (PP) Encapsulated bytes = 183 So I think maybe the authors had considered the overhead of PP (like what Gorry said) Best Regards, Simon Teh Universiti Sains Malaysia -----Original Message----- From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On Behalf Of Summers Edwin Sent: 28 April 2005 21:42 To: ipdvb@erg.abdn.ac.uk Subject: RE: MPE Question Greetings, While researching MPE and the proposed ULE spec, I ran across some information that I cannot equate. If I read table 3 of EN 301 193 v1.4.1 (DVB spec for data broadcasting) correctly, the overhead of an MPE section is 16 bytes (assuming LLC/SNAP not used). But while researching MPE I found a brief by Vladimir Ksinant, Alain Ritoux, and "fritsche" entitled "Using ULE for IPv4/v6 in MPEG-2 encapsulation" (12/11/2003) that states there is 17 bytes of header/trailer for IPv4 packets encapsulated by MPE, and 25 bytes for IPv6, assuming use of LLC/SNAP. 1) For a section encapsulating an IPv4 packet and not using LLC/SNAP, is the overhead 16 or 17 bytes? (same for ULE...I count 8 bytes in draft-ietf-ipdvb-ule-05 section 4 where the above document states 9 bytes, when not using the destination address) 2) (for MPE) If my original calculation of 16 bytes is correct, then would the overhead for a section using LLC/SNAP be 24 bytes (16 + 8 byte LLC/SNAP)? 3) Do current MPE implementations in IPv6 networks require the use of LLC/SNAP in the section? I know this was discussed on the list some time ago, and I believe the reason for it was because MPE does not include a type field, where ULE does. Are there any current MPE implementations that do not require LLC/SNAP for IPv6 packets? Thanks in advance! Ed -------------------- Ed Summers Booz Allen Hamilton (o) 703.377.1407 (f) 703.902.3409 From owner-ipdvb@erg.abdn.ac.uk Thu Apr 28 13:16:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05683 for ; Thu, 28 Apr 2005 13:16:18 -0400 (EDT) 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 1DRCpZ-0003sb-3y for ipdvb-archive@ietf.org; Thu, 28 Apr 2005 13:29:41 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3SGk1tG028220 for ; Thu, 28 Apr 2005 17:46:01 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j3SGk1FK028219 for ipdvb-subscribed-users; Thu, 28 Apr 2005 17:46:01 +0100 (BST) 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 (netmon.cs.usm.my [161.142.8.104]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3SGjUZ3028191 for ; Thu, 28 Apr 2005 17:45:31 +0100 (BST) Received: from localhost (localhost.localdomain [127.0.0.1]) by nrg.cs.usm.my (Postfix) with ESMTP id C0832220119 for ; Fri, 29 Apr 2005 00:45:25 +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 27024-10 for ; Fri, 29 Apr 2005 00:45:22 +0800 (MYT) Received: from abc (unknown [219.93.2.101]) by nrg.cs.usm.my (Postfix) with ESMTP id 5CC6A220116 for ; Fri, 29 Apr 2005 00:45:22 +0800 (MYT) From: "Simon Teh" To: "Ip-DVB" Date: Fri, 29 Apr 2005 00:45:12 +0800 Organization: NRG MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C54C54.B3EA5590" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcVMEaVIiYhm4qa9S3uIwzmQUGR0Aw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: <20050428164522.5CC6A220116@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 Subject: Question on ANNEX A: Informative Appendix - SNDU Packing Examples Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.2 (/) X-Scan-Signature: fbe0995f04cc21309ef8614a2838e306 This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C54C54.B3EA5590 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear members, I'm quite confusing with the example shown in Annex A on the examples of SNDU packing. Example A.1: Two 186B PDUs. SNDU A is 200 bytes (including the ULE destination NPA address) SNDU B is 200 bytes (including the ULE destination NPA address) The sequence comprises 3 TS Packets: SNDU PP=0 Length +-----+------+------+------+- -+------+ | HDR | 0x00 | 0x00 | 0xC4 | ... | A182 | +-----+----*-+-*----+------+- -+------+ PUSI=1 * * ***** For the SNDU Length shown in the figure above, why it is 0xC4? The size for a MPEG-2 TS packet is 188, if minus TS header and PP, is 183 bytes. So the maximum size that the IP packet (SNDU A) can be encapsulated should be 183 = 0xb7, But why it is 0xC4 instead of 0xb7? Or Do I miss something? Hope somebody could help me on this matter. Thanks in advance! Best Regards, Simon Teh Universiti Sains Malaysia ------=_NextPart_000_0008_01C54C54.B3EA5590 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear members,

 

I’m quite confusing with the example = shown in Annex A on the examples of SNDU packing.

 

Example A.1: Two 186B PDUs. =

    
    &nbs=
p;SNDU A is 200 bytes (including the ULE destination NPA address) =

    &nbs=
p;SNDU B is 200 bytes (including the ULE destination NPA address) =

    
   The =
sequence comprises 3 TS Packets: =

    
       &nbs=
p;            =
;  SNDU         &n=
bsp;      =

       &nbs=
p;   PP=3D0      =
Length          =

   +-----+------+------+------+=
-   -+------+ 
   | HDR | 0x00 | 0x00 | 0xC4 =
| ... | A182 | 
   +-----+----*-+-*----+------+=
-   -+------+ 
   PUSI=3D1   &n=
bsp; *   * 
       &nbs=
p;      ***** =

       &nbs=
p;            =
;            =
         <=
/font>
    

For the SNDU Length shown in the figure above, = why it is 0xC4?

The size for a MPEG-2 TS packet is 188, if = minus TS header and PP, is 183 bytes.

So the maximum size that the IP packet (SNDU A) = can be encapsulated should be 183 =3D 0xb7,

But why it is 0xC4 instead of 0xb7? Or Do I = miss something?

 

Hope somebody could help me on this matter. = Thanks in advance!

 

 

 

 

Best = Regards,

Simon = Teh

Universiti Sains = Malaysia

 

------=_NextPart_000_0008_01C54C54.B3EA5590-- From owner-ipdvb@erg.abdn.ac.uk Thu Apr 28 15:10:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15148 for ; Thu, 28 Apr 2005 15:10:50 -0400 (EDT) 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 1DREcO-0000Hx-Fa for ipdvb-archive@ietf.org; Thu, 28 Apr 2005 15:24:13 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3SIQwxJ000263 for ; Thu, 28 Apr 2005 19:26:58 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j3SIQwHT000262 for ipdvb-subscribed-users; Thu, 28 Apr 2005 19:26:58 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from wills (wills.erg.abdn.ac.uk [139.133.204.225]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3SIQXMP000245 for ; Thu, 28 Apr 2005 19:26:33 +0100 (BST) Message-Id: <200504281826.j3SIQXMP000245@erg.abdn.ac.uk> From: "William StanisLaus" To: "'Ip-DVB'" Subject: RE: Question on ANNEX A: Informative Appendix - SNDU Packing Examples Date: Thu, 28 Apr 2005 19:26:25 +0100 Organization: University of Aberdeen MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0033_01C54C28.2E013100" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <20050428164522.5CC6A220116@nrg.cs.usm.my> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVMEaVIiYhm4qa9S3uIwzmQUGR0AwADJpZA X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.2 (/) X-Scan-Signature: 9668dd9718e12afaf579fddf1143437a This is a multi-part message in MIME format. ------=_NextPart_000_0033_01C54C28.2E013100 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Simon, The Length specified in the example is SNDU length and NOT MPEG2-TS header length, as the ULE draft specifies one SNDU can prolong/extend more than one MPEG2-TS packet (that's what this example trying to explain). In this example complete MPEG2-TS header information are not discussed, only PUSI and if PUSI is ONE payload pointer are discussed. -William. _____ From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On Behalf Of Simon Teh Sent: Thursday, April 28, 2005 5:45 PM To: Ip-DVB Subject: Question on ANNEX A: Informative Appendix - SNDU Packing Examples Dear members, I'm quite confusing with the example shown in Annex A on the examples of SNDU packing. Example A.1: Two 186B PDUs. SNDU A is 200 bytes (including the ULE destination NPA address) SNDU B is 200 bytes (including the ULE destination NPA address) The sequence comprises 3 TS Packets: SNDU PP=0 Length +-----+------+------+------+- -+------+ | HDR | 0x00 | 0x00 | 0xC4 | ... | A182 | +-----+----*-+-*----+------+- -+------+ PUSI=1 * * ***** For the SNDU Length shown in the figure above, why it is 0xC4? The size for a MPEG-2 TS packet is 188, if minus TS header and PP, is 183 bytes. So the maximum size that the IP packet (SNDU A) can be encapsulated should be 183 = 0xb7, But why it is 0xC4 instead of 0xb7? Or Do I miss something? Hope somebody could help me on this matter. Thanks in advance! Best Regards, Simon Teh Universiti Sains Malaysia ------=_NextPart_000_0033_01C54C28.2E013100 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Simon,

 

The Length specified in the example = is SNDU length and NOT MPEG2-TS header length,  as the ULE draft = specifies one SNDU can prolong/extend more than one MPEG2-TS packet (that’s = what this example trying to explain). In this example complete MPEG2-TS = header information are not discussed, only PUSI and if PUSI is ONE payload = pointer are discussed.

 

-William.

 

 

 

From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On Behalf Of Simon Teh
Sent: Thursday, April 28, = 2005 5:45 PM
To: Ip-DVB
Subject: Question on = ANNEX A: Informative Appendix - SNDU Packing = Examples

 

Dear members,

 

I’m quite confusing with the example = shown in Annex A on the examples of SNDU packing.

 

Example A.1: Two 186B PDUs. =

    
    &nbs=
p;SNDU A is 200 bytes (including the ULE destination NPA address) =

    &nbs=
p;SNDU B is 200 bytes (including the ULE destination NPA address) =

    
   The =
sequence comprises 3 TS Packets: =

    
       &nbs=
p;            =
;  SNDU         &n=
bsp;      =

       &nbs=
p;   PP=3D0      =
Length          =

   +-----+------+------+------+=
-   -+------+ 
   | HDR | 0x00 | 0x00 | 0xC4 =
| ... | A182 | 
   +-----+----*-+-*----+------+=
-   -+------+ 
   PUSI=3D1   &n=
bsp; *   * 
       &nbs=
p;      ***** =

       &nbs=
p;            =
;            =
         <=
/font>
    

For the SNDU Length shown in the figure above, = why it is 0xC4?

The size for a MPEG-2 TS packet is 188, if = minus TS header and PP, is 183 bytes.

So the maximum size that the IP packet (SNDU A) = can be encapsulated should be 183 =3D 0xb7,

But why it is 0xC4 instead of 0xb7? Or Do I = miss something?

 

Hope somebody could help me on this matter. = Thanks in advance!

 

 

 

 

Best = Regards,

Simon = Teh

Universiti Sains Malaysia

 

------=_NextPart_000_0033_01C54C28.2E013100-- From owner-ipdvb@erg.abdn.ac.uk Thu Apr 28 18:15:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00820 for ; Thu, 28 Apr 2005 18:15:13 -0400 (EDT) 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 1DRHUr-0007vp-E0 for ipdvb-archive@ietf.org; Thu, 28 Apr 2005 18:28:39 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3SLmZkg004085 for ; Thu, 28 Apr 2005 22:48:35 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j3SLmZd8004084 for ipdvb-subscribed-users; Thu, 28 Apr 2005 22:48:35 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from web42203.mail.yahoo.com (web42203.mail.yahoo.com [66.218.93.204]) by erg.abdn.ac.uk (8.12.11/8.12.11) with SMTP id j3SLmAOk004068 for ; Thu, 28 Apr 2005 22:48:11 +0100 (BST) Received: (qmail 17554 invoked by uid 60001); 28 Apr 2005 21:48:06 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=Mf6CGsU/zIwNoAVZCF/eMUB+PKXcCygwYQVizdch6FayTDFsQ5vVHgNsW0jp4VnUkLaWkXCYranLgSKLiky4DvpmW4X7taESvYpQo1LetRHnDWlugGOq62WAjsufjYmWf5WeBja6QinngIgYmYTlcYHrXlJU63GZsaNIwLWZv9c= ; Message-ID: <20050428214806.17552.qmail@web42203.mail.yahoo.com> Received: from [129.46.216.198] by web42203.mail.yahoo.com via HTTP; Thu, 28 Apr 2005 14:48:06 PDT Date: Thu, 28 Apr 2005 14:48:06 -0700 (PDT) From: Siva Veerepalli Subject: Re: MPE Question To: ipdvb@erg.abdn.ac.uk Cc: Siva Veerepalli In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Thanks for the response Bernhard, but I am a bit confused about the answer. Please see my question below: --- Bernhard Collini-Nocker wrote: > Siva Veerepalli wrote: > > A couple of questions about MPE-FEC framing. > > > > 1. The interim IP datacast standard A079 (meant to > > facilitate DVB-H trials) specifies that only one > > datagram should be used per MPE section i.e., no > > fragmentation of IP datagram over multiple MPE > > sections. However, the DVB Databroadcast > specification > > allows fragmentation of the IP datagram over > multiple > > sections. Does anyone know what the usual practice > is? > > In order to reduce encapsulation overhead, section > packing is used, i.e. > if the (remainder of an) IP packet does not fit > exactly in a TS packet a > subsequent IP packet may start in that TS packet as > well. > In order to reduce jitter and latency, section > packing is not used. I understand that two MPE sections could probably start in the same TS packet (I guess that is what you mean by section packing). My original questions was, what is the usual practice with regards to fragmenting an IP datagram over multiple MPE sections (irrespective of how these sections are transported in TS packets)? The DVB-H (data broadcast standard) allows for this, however, the IPDC interim specification requires that one datagram be encapsulated entirely in one mpe section i.e., no datagram fragmentation over multiple MPE sections. thanks, Siva > > You can find both on existing services. > > > Do the final DVB/IP datacast standards specify > this > > for DVB-H? > > The difficulty with section peckaing on the transmit > side is that the > encapsulator needs to wait for subsequent IP packets > to fill an > partially filled TS packet and therefor has > typically a time-out > associated to that waiting, ie before flushing the > buffer and > transmitting the final TS packet. > > > 2. The MPE section has optional stuffing bytes at > the > > end of the section. Are these used? If yes, for > what? > > Whenver an IP packets leaves "enough" space in the > last TS packet > another IP packet could be inserted. If not wanted > or needed, stuffing > takes care that the empty space is filled up with > pattern 0xFF. > > > thanks, > > Siva > > > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam > protection around > > http://mail.yahoo.com > > > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-ipdvb@erg.abdn.ac.uk Thu Apr 28 18:18:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01298 for ; Thu, 28 Apr 2005 18:18:08 -0400 (EDT) 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 1DRHXf-00084y-VJ for ipdvb-archive@ietf.org; Thu, 28 Apr 2005 18:31:33 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3SLrAwK004207 for ; Thu, 28 Apr 2005 22:53:10 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j3SLrAWu004206 for ipdvb-subscribed-users; Thu, 28 Apr 2005 22:53:10 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from web42205.mail.yahoo.com (web42205.mail.yahoo.com [66.218.93.206]) by erg.abdn.ac.uk (8.12.11/8.12.11) with SMTP id j3SLqfor004185 for ; Thu, 28 Apr 2005 22:52:42 +0100 (BST) Received: (qmail 96713 invoked by uid 60001); 28 Apr 2005 21:52:37 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=aytefoEnVA1itud2/uHo93pll4b9AoeY2HmuKfVdQljKEuNdBEMTCeQstWTTMLkOL4DVlw1tvXV3MhC2FLD7XQtvUDE4mBLnRLC+YgIz92UuUhqULsed6cMcZf5Im4UST9+fQ/falIan+d44q1TSEfL7+NM74tr2sWeNeXgvOQM= ; Message-ID: <20050428215237.96711.qmail@web42205.mail.yahoo.com> Received: from [129.46.216.198] by web42205.mail.yahoo.com via HTTP; Thu, 28 Apr 2005 14:52:37 PDT Date: Thu, 28 Apr 2005 14:52:37 -0700 (PDT) From: Siva Veerepalli Subject: Re: MPE Question To: ipdvb@erg.abdn.ac.uk In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 --- Bernhard Collini-Nocker wrote: > Siva Veerepalli wrote: > > A couple of questions about MPE-FEC framing. > > > > 2. The MPE section has optional stuffing bytes at > the > > end of the section. Are these used? If yes, for > what? > > Whenver an IP packets leaves "enough" space in the > last TS packet > another IP packet could be inserted. If not wanted > or needed, stuffing > takes care that the empty space is filled up with > pattern 0xFF. I was actually referring to the stuffing bytes in the MPE section, not the TS packet. I understand the use of stuffing bytes in TS packets, but am not clear why stuffing bytes are used in MPE sections. thanks, Siva > > > thanks, > > Siva > > > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam > protection around > > http://mail.yahoo.com > > > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-ipdvb@erg.abdn.ac.uk Fri Apr 29 00:04:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26104 for ; Fri, 29 Apr 2005 00:04:07 -0400 (EDT) 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 1DRMwW-0005Vy-Kd for ipdvb-archive@ietf.org; Fri, 29 Apr 2005 00:17:35 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3T3KnDH009833 for ; Fri, 29 Apr 2005 04:20:49 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j3T3Knqg009832 for ipdvb-subscribed-users; Fri, 29 Apr 2005 04:20:49 +0100 (BST) 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 (network2.cs.usm.my [161.142.8.104]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3T3KD1u009811 for ; Fri, 29 Apr 2005 04:20:14 +0100 (BST) Received: from localhost (localhost.localdomain [127.0.0.1]) by nrg.cs.usm.my (Postfix) with ESMTP id 956E322011A for ; Fri, 29 Apr 2005 11:19:49 +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 02833-09 for ; Fri, 29 Apr 2005 11:19:37 +0800 (MYT) Received: from abc (unknown [219.93.2.101]) by nrg.cs.usm.my (Postfix) with ESMTP id 68FFB220119 for ; Fri, 29 Apr 2005 11:19:37 +0800 (MYT) From: "Simon Teh" To: Subject: RE: Question on ANNEX A: Informative Appendix - SNDU Packing Examples Date: Fri, 29 Apr 2005 11:19:25 +0800 Organization: NRG MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C54CAD.4D7036A0" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <200504281826.j3SIQXMP000245@erg.abdn.ac.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVMEaVIiYhm4qa9S3uIwzmQUGR0AwADJpZAABLZjlA= Message-Id: <20050429031937.68FFB220119@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-Spam-Score: 0.4 (/) X-Scan-Signature: a83e8b750067501be8b56bf02fb6582d This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C54CAD.4D7036A0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Thanks for the answer Mr. William StanisLaus. Best Regards, Simon Teh Universiti Sains Malaysia _____ From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On Behalf Of William StanisLaus Sent: 29 April 2005 02:26 To: 'Ip-DVB' Subject: RE: Question on ANNEX A: Informative Appendix - SNDU Packing Examples Hi Simon, The Length specified in the example is SNDU length and NOT MPEG2-TS header length, as the ULE draft specifies one SNDU can prolong/extend more than one MPEG2-TS packet (that's what this example trying to explain). In this example complete MPEG2-TS header information are not discussed, only PUSI and if PUSI is ONE payload pointer are discussed. -William. _____ From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On Behalf Of Simon Teh Sent: Thursday, April 28, 2005 5:45 PM To: Ip-DVB Subject: Question on ANNEX A: Informative Appendix - SNDU Packing Examples Dear members, I'm quite confusing with the example shown in Annex A on the examples of SNDU packing. Example A.1: Two 186B PDUs. SNDU A is 200 bytes (including the ULE destination NPA address) SNDU B is 200 bytes (including the ULE destination NPA address) The sequence comprises 3 TS Packets: SNDU PP=0 Length +-----+------+------+------+- -+------+ | HDR | 0x00 | 0x00 | 0xC4 | ... | A182 | +-----+----*-+-*----+------+- -+------+ PUSI=1 * * ***** For the SNDU Length shown in the figure above, why it is 0xC4? The size for a MPEG-2 TS packet is 188, if minus TS header and PP, is 183 bytes. So the maximum size that the IP packet (SNDU A) can be encapsulated should be 183 = 0xb7, But why it is 0xC4 instead of 0xb7? Or Do I miss something? Hope somebody could help me on this matter. Thanks in advance! Best Regards, Simon Teh Universiti Sains Malaysia ------=_NextPart_000_0003_01C54CAD.4D7036A0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Thanks for the = answer Mr. William StanisLaus.

 <= /span>

Best = Regards,

Simon = Teh

Universiti Sains Malaysia

From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On Behalf Of William = StanisLaus
Sent: 29 April 2005 = 02:26
To: 'Ip-DVB'
Subject: RE: Question on = ANNEX A: Informative Appendix - SNDU Packing Examples

 

Hi = Simon,

 =

The Length = specified in the example is SNDU length and NOT MPEG2-TS header length,  as the = ULE draft specifies one SNDU can prolong/extend more than one MPEG2-TS = packet (that’s what this example trying to explain). In this example = complete MPEG2-TS header information are not discussed, only PUSI and if PUSI is = ONE payload pointer are discussed.

 =

-William.

 =

 =

 =

From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On Behalf Of Simon Teh
Sent: Thursday, April 28, = 2005 5:45 PM
To: Ip-DVB
Subject: Question on = ANNEX A: Informative Appendix - SNDU Packing Examples

 

Dear members,

 

I’m quite confusing with the example = shown in Annex A on the examples of SNDU packing.

 

Example A.1: Two 186B PDUs. =

    
    &nbs=
p;SNDU A is 200 bytes (including the ULE destination NPA address) =

    &nbs=
p;SNDU B is 200 bytes (including the ULE destination NPA address) =

    
   The =
sequence comprises 3 TS Packets: =

    
       &nbs=
p;            =
;  SNDU         &n=
bsp;      =

       &nbs=
p;   PP=3D0      =
Length          =

   +-----+------+------+------+=
-   -+------+ 
   | HDR | 0x00 | 0x00 | 0xC4 =
| ... | A182 | 
   +-----+----*-+-*----+------+=
-   -+------+ 
   PUSI=3D1   &n=
bsp; *   * 
       &nbs=
p;      ***** =

       &nbs=
p;            =
;            =
         <=
/font>
    

For the SNDU Length shown in the figure above, = why it is 0xC4?

The size for a MPEG-2 TS packet is 188, if = minus TS header and PP, is 183 bytes.

So the maximum size that the IP packet (SNDU A) = can be encapsulated should be 183 =3D 0xb7,

But why it is 0xC4 instead of 0xb7? Or Do I = miss something?

 

Hope somebody could help me on this matter. = Thanks in advance!

 

 

 

 

Best = Regards,

Simon = Teh

Universiti Sains Malaysia

 

------=_NextPart_000_0003_01C54CAD.4D7036A0-- From owner-ipdvb@erg.abdn.ac.uk Fri Apr 29 02:38:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25938 for ; Fri, 29 Apr 2005 02:38:53 -0400 (EDT) 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 1DRPMK-00033k-OH for ipdvb-archive@ietf.org; Fri, 29 Apr 2005 02:52:22 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3T5tqPt012322 for ; Fri, 29 Apr 2005 06:55:52 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j3T5tqLT012321 for ipdvb-subscribed-users; Fri, 29 Apr 2005 06:55:52 +0100 (BST) 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 j3T5tRSs012304 for ; Fri, 29 Apr 2005 06:55:27 +0100 (BST) Received: from [127.0.0.1] (milbe.cosy.sbg.ac.at [141.201.2.21]) by loewe.cosy.sbg.ac.at (8.8.8/8.8.7) with ESMTP id HAA25810 for ; Fri, 29 Apr 2005 07:55:27 +0200 (MET DST) Message-ID: <4271CC29.5080409@cosy.sbg.ac.at> Date: Fri, 29 Apr 2005 07:54:49 +0200 From: Bernhard Collini-Nocker User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: Re: MPE Question References: <20050428214806.17552.qmail@web42203.mail.yahoo.com> In-Reply-To: <20050428214806.17552.qmail@web42203.mail.yahoo.com> 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-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Dear Siva, you are right in that I had understood your question different. Generally Sections do allow for numbering that is, one can put a payload (for example a DSM-CC object) into a number of Sections and with section_number and last_section_number the reassebler knows what to do. MPE uses this Section mechanism, so multiple Section operations should be possible. Actually I have never tested whether MPE decapsulators do support this in real, in principle they should (again the DVB databroadacst standard does not say too much, if anything, about it) but in DSM-CC Obejct carousels is a very usual mode of operation. Siva Veerepalli wrote: > Thanks for the response Bernhard, but I am a bit > confused about the answer. Please see my question > below: > > --- Bernhard Collini-Nocker > wrote: > >>Siva Veerepalli wrote: [...] > I understand that two MPE sections could probably > start in the same TS packet (I guess that is what you > mean by section packing). Yes. > My original questions was, what is the usual practice > with regards to fragmenting an IP datagram over > multiple MPE sections (irrespective of how these > sections are transported in TS packets)? The DVB-H > (data broadcast standard) allows for this, however, > the IPDC interim specification requires that one > datagram be encapsulated entirely in one mpe section > i.e., no datagram fragmentation over multiple MPE > sections. Now the confusion starts when one introduces the wording of "over multiple MPE sections", because there is no such thing as a MPE section fragmentation. I will have to read the DVB-H standard again in order to find out what it really says. I guess the only real issues the DVB-H wrt to IP is addressing is the necessity of a IP datagram encapsulated in MPE is to support time slicing (ie a burst transmission of the resulting TS packets to allow for power saving) and MPE-FEC (adding redundant code to allow for reconstruction). In that case I woould assume that it is very reasonable (especially with legacy equipment) to avoid all potential interpretations of MPE wrt multiple section operation and section packing. > thanks, > Siva [...] Yor are very welcome, and I hope I got THE expected answer closer, Bernhard From owner-ipdvb@erg.abdn.ac.uk Fri Apr 29 02:49:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26617 for ; Fri, 29 Apr 2005 02:49:03 -0400 (EDT) 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 1DRPWB-0003Rm-0m for ipdvb-archive@ietf.org; Fri, 29 Apr 2005 03:02:32 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3T67PW7012443 for ; Fri, 29 Apr 2005 07:07:25 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j3T67PTp012442 for ipdvb-subscribed-users; Fri, 29 Apr 2005 07:07:25 +0100 (BST) 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 j3T672mc012427 for ; Fri, 29 Apr 2005 07:07:02 +0100 (BST) Received: from [127.0.0.1] (milbe.cosy.sbg.ac.at [141.201.2.21]) by loewe.cosy.sbg.ac.at (8.8.8/8.8.7) with ESMTP id IAA26567 for ; Fri, 29 Apr 2005 08:07:02 +0200 (MET DST) Message-ID: <4271CEE3.1070907@cosy.sbg.ac.at> Date: Fri, 29 Apr 2005 08:06:27 +0200 From: Bernhard Collini-Nocker User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: Re: MPE Question References: <20050428215237.96711.qmail@web42205.mail.yahoo.com> In-Reply-To: <20050428215237.96711.qmail@web42205.mail.yahoo.com> 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-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Hello again, the famous words stuffing and padding are Siva Veerepalli wrote: > --- Bernhard Collini-Nocker > wrote: > >>Siva Veerepalli wrote: >> >>>A couple of questions about MPE-FEC framing. >>> > > > >>>2. The MPE section has optional stuffing bytes at >> >>the >> >>>end of the section. Are these used? If yes, for >> >>what? >> >>Whenver an IP packets leaves "enough" space in the >>last TS packet >>another IP packet could be inserted. If not wanted >>or needed, stuffing >>takes care that the empty space is filled up with >>pattern 0xFF. > > > I was actually referring to the stuffing bytes in the > MPE section, not the TS packet. I understand the use > of stuffing bytes in TS packets, but am not clear why > stuffing bytes are used in MPE sections. According to EN301192 "stuffing_byte: this is an optional 8-bit field whose value is not specified. If the payload of the section is scrambled (see payload_scrambling_mode), these bytes are scrambled. They are to assist with block encryption and data processing in wide bus environments. The number of stuffing_bytes used should meet the data alignment requirements defined in the data_broadcast_descriptor." So, for block encryption one typically has some arbitariy number of bits to encrypt and needs to ensure that the MPE payload is on auch a multiple bit boundary for what MPE internal stuffing might be needed... > thanks, > Siva > >>>thanks, >>>Siva >>> >>> >>>__________________________________________________ >>>Do You Yahoo!? >>>Tired of spam? Yahoo! Mail has the best spam >> >>protection around >> >>>http://mail.yahoo.com >>> >> >> > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > From owner-ipdvb@erg.abdn.ac.uk Fri Apr 29 03:59:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01981 for ; Fri, 29 Apr 2005 03:59:12 -0400 (EDT) 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 1DRQc6-0006Zn-3y for ipdvb-archive@ietf.org; Fri, 29 Apr 2005 04:12:42 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3T77Qr5013710 for ; Fri, 29 Apr 2005 08:07:26 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j3T77QRo013709 for ipdvb-subscribed-users; Fri, 29 Apr 2005 08:07:26 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from thingmagic.com (tm-gw2.cictr.com [204.9.221.21] (may be forged)) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3T76ldE013684 for ; Fri, 29 Apr 2005 08:06:47 +0100 (BST) Received: from [212.147.29.57] (account margaret HELO [192.168.116.133]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 356535 for ipdvb@erg.abdn.ac.uk; Fri, 29 Apr 2005 03:03:01 -0400 Mime-Version: 1.0 Message-Id: Date: Fri, 29 Apr 2005 00:49:36 -0400 To: ipdvb From: Margaret Wasserman Subject: AD review of draft-ietf-ipdvb-ule-05.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Hi All, I have finished my AD review of draft-ietf-ipdvb-ule-05.txt. This document appears to be in very good shape. I just have a couple of comments/questions on the document (see below) that I would like to resolve before sending the document to the IESG for final review. Since any changes related to these comments are likely to be very small, I will send the document to IETF LC in parallel with resolving these issues. Gorry, if you like, you can wait until the IETF LC completes and make any changes resulting from these comments at the same time as you make any changes to address the IETF LC comments. Margaret --- 4. SNDU Format PDUs are encapsulated using ULE to form an SNDU. (Each SNDU is an MPEG-2 Payload Unit.) The encapsulation format to be used for PDUs is illustrated below: < ----------------------------- SNDU ----------------------------- > +-+-------------------------------------------------------+--------+ |D| Length | Type | PDU | CRC-32 | +-+-------------------------------------------------------+--------+ Figure 1: SNDU Encapsulation All multi-byte values in ULE (including Length, Type, and Destination fields) are transmitted in network byte order (most significant byte first). The most significant bit of each byte is placed in the left-most position of the 8-bit field. Appendix A provides informative examples of usage. >> A destination field is mentioned in the text, but not shown in >> the diagram? It might make sense to how/where the destination >> may be included before mentioning it. 5.1 Test SNDU A Test SNDU (figure 10) is of a Mandatory Extension Header of Type 1. This header must be the final (or only) extension header specified in the header chain of a SNDU. [...] 5.2 Bridge Frame SNDU Encapsulation A bridged SNDU is a Mandatory Extension Header of Type 1. It must be the final (or only) extension header specified in the header chain of a SNDU. >> Is it intentional that the Test SNDU and the Bridge Frame SNDU >> headers cannot be used in the same SNDU? 3. Description of the Method [...] The ULE encapsulation is limited to TS private streams only. The header of each TS Packet carries a one bit Payload Unit Start Indicator (PUSI) field. A PUSI field with a value of 1 indicates the presence of at least one Payload Unit (SNDU) within the TS Packet payload. >> s/the presence of at least one/the start of at least one/ ?? >> >> If I understand this correctly, the PUSI field will be 0 if >> the TS does not include the start of an SNDU. From owner-ipdvb@erg.abdn.ac.uk Fri Apr 29 06:41:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11304 for ; Fri, 29 Apr 2005 06:41:25 -0400 (EDT) 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 1DRT94-0004d9-45 for ipdvb-archive@ietf.org; Fri, 29 Apr 2005 06:54:57 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3TA5FOw018660 for ; Fri, 29 Apr 2005 11:05:15 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j3TA5FIe018659 for ipdvb-subscribed-users; Fri, 29 Apr 2005 11:05:15 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3TA4dl2018634 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 29 Apr 2005 11:04:40 +0100 (BST) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j3TA4dM18204 for ; Fri, 29 Apr 2005 13:04:39 +0300 (EET DST) X-Scanned: Fri, 29 Apr 2005 13:23:57 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j3TANvtC026047 for ; Fri, 29 Apr 2005 13:23:57 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00lIiICG; Fri, 29 Apr 2005 13:19:40 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j3T9abd13131 for ; Fri, 29 Apr 2005 12:36:37 +0300 (EET DST) Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 29 Apr 2005 12:36:04 +0300 Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Apr 2005 12:36:02 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: MPE Question Date: Fri, 29 Apr 2005 12:36:02 +0300 Message-ID: <7222D14EF47E0840AD88EC7BCBAD85130E4DBC@trebe101.NOE.Nokia.com> Thread-Topic: MPE Question Thread-Index: AcVLixW7xVX9RMIaT46S/2LEYXRz+wBEXsXA From: To: X-OriginalArrivalTime: 29 Apr 2005 09:36:02.0813 (UTC) FILETIME=[DBEBBAD0:01C54C9E] X-ERG-MailScanner: Found to be clean, Found to be clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by erg.abdn.ac.uk id j3TA5D3o018656 Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.3 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 8bit Hi An important feature of DVB-H is time slicing and to ensure that data of a single packet is not spread into mutliple slices/bursts (hence avoiding keeping additional data and context for prolonged time), thus a single (DVB-H) MPE section must not have only part of an IP packet. I haven't been following the lower layers so closely recently, but I would be very suprised to find this changed for DVB-H. In a sense DVB-H IP encapsulation is a profile of DVB data broadcast encapsulation, so it shouldn't be supprising that the latter offers a superset of features from the former. All the MPE clients I've had the fortune to play with have supported packing (but that's only a few), but personally I've have problems with encapsulators forcably waiting to "fill up" sections. My experience from DVB-H onwards was less troublesome (because we became much more choosy about encapsulators). (Nowadays I'm not in touch with broadcast MAC so much). So far, a complelling case to allow fragmentation over MPE sections for DVB-H has not been presented, whereas the opposite (the cost of doing so over bursts, and the consideration that it adds insignificant value anyway) has been accepted. (Noting that no DVB-H use case requires anything close to exceeding the 4KB MPE MTU in IP packet length). Hope that's useful. Cheers, Rod. > -----Original Message----- > From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk]On > Behalf Of ext Siva Veerepalli > Sent: Thursday, April 28, 2005 3:36 AM > To: ipdvb@erg.abdn.ac.uk > Cc: sivaveer@yahoo.com > Subject: MPE Question > > > A couple of questions about MPE-FEC framing. > > 1. The interim IP datacast standard A079 (meant to > facilitate DVB-H trials) specifies that only one > datagram should be used per MPE section i.e., no > fragmentation of IP datagram over multiple MPE > sections. However, the DVB Databroadcast specification > allows fragmentation of the IP datagram over multiple > sections. Does anyone know what the usual practice is? > Do the final DVB/IP datacast standards specify this > for DVB-H? > > 2. The MPE section has optional stuffing bytes at the > end of the section. Are these used? If yes, for what? > > > thanks, > Siva > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > From owner-ipdvb@erg.abdn.ac.uk Fri Apr 29 12:45:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13493 for ; Fri, 29 Apr 2005 12:45:27 -0400 (EDT) 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 1DRYpS-0004WB-SS for ipdvb-archive@ietf.org; Fri, 29 Apr 2005 12:59:03 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3TFv7Pm026519 for ; Fri, 29 Apr 2005 16:57:07 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j3TFv6Wg026518 for ipdvb-subscribed-users; Fri, 29 Apr 2005 16:57:07 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from wills (wills.erg.abdn.ac.uk [139.133.204.225]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j3TFuC1V026477 for ; Fri, 29 Apr 2005 16:56:12 +0100 (BST) Message-Id: <200504291556.j3TFuC1V026477@erg.abdn.ac.uk> From: "William StanisLaus" To: Subject: RE: MPE Question Date: Fri, 29 Apr 2005 16:56:03 +0100 Organization: University of Aberdeen MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <4271CC29.5080409@cosy.sbg.ac.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVMgBmpothDNqCnS0yPnlqtLzxfPwAIyDcg X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Hi Siva and Bernhard, DSM-CC which is a potential MPE of our present day DOES NOT support section packing for normal IP data transmissions. In DSM-CC we have section length of 12 bits, which can hold maximum of 4096 Bytes of payload data (IP in our discussion). In Normal scenario we don't even use this big, since section packing is not supported practically (theoretically YES), we use DVB router one interface as Ethernet and other as DVB, on Ethernet wire we get only 1500 bytes the max, though there is a room for section packing(theoretically) real time packet routing don't wait for another IP packet, just push each and every ip packet received with MPE (DSM-CC) and to MPEG2-TS (supports section packing, based on the timer - reason MPEG2-TS MUST be 188 bytes, instead of wasting bytes with stuffing we have section packing). When we are talking about stuffing bytes, that was perfect by Bernhard, we use for packet alignment, to be more specific, real time operating system like PSOS, requires it be WORD aligned ( Multiples of Four) before encryption algorithm to be applied for scrambling. -William. > -----Original Message----- > From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On > Behalf Of Bernhard Collini-Nocker > Sent: Friday, April 29, 2005 6:55 AM > To: ipdvb@erg.abdn.ac.uk > Subject: Re: MPE Question > > Dear Siva, > > you are right in that I had understood your question different. > > Generally Sections do allow for numbering that is, one can put a payload > (for example a DSM-CC object) into a number of Sections and with > section_number and last_section_number the reassebler knows what to do. > MPE uses this Section mechanism, so multiple Section operations should > be possible. Actually I have never tested whether MPE decapsulators do > support this in real, in principle they should (again the DVB > databroadacst standard does not say too much, if anything, about it) but > in DSM-CC Obejct carousels is a very usual mode of operation. > > Siva Veerepalli wrote: > > Thanks for the response Bernhard, but I am a bit > > confused about the answer. Please see my question > > below: > > > > --- Bernhard Collini-Nocker > > wrote: > > > >>Siva Veerepalli wrote: > [...] > > I understand that two MPE sections could probably > > start in the same TS packet (I guess that is what you > > mean by section packing). > > Yes. > > > My original questions was, what is the usual practice > > with regards to fragmenting an IP datagram over > > multiple MPE sections (irrespective of how these > > sections are transported in TS packets)? The DVB-H > > (data broadcast standard) allows for this, however, > > the IPDC interim specification requires that one > > datagram be encapsulated entirely in one mpe section > > i.e., no datagram fragmentation over multiple MPE > > sections. > > Now the confusion starts when one introduces the wording of "over > multiple MPE sections", because there is no such thing as a MPE section > fragmentation. > I will have to read the DVB-H standard again in order to find out what > it really says. I guess the only real issues the DVB-H wrt to IP is > addressing is the necessity of a IP datagram encapsulated in MPE is to > support time slicing (ie a burst transmission of the resulting TS > packets to allow for power saving) and MPE-FEC (adding redundant code to > allow for reconstruction). In that case I woould assume that it is very > reasonable (especially with legacy equipment) to avoid all potential > interpretations of MPE wrt multiple section operation and section packing. > > > thanks, > > Siva > [...] > > Yor are very welcome, > and I hope I got THE expected answer closer, > Bernhard