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--