From majordomo-owner@erg.abdn.ac.uk Fri Mar 1 15:27:28 2002 Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.12.2/8.12.2) with ESMTP id g21FR0kP026401 for ; Fri, 1 Mar 2002 15:27:01 GMT Message-ID: <3C7F9DC7.F1158B4A@erg.abdn.ac.uk> Date: Fri, 01 Mar 2002 15:27:02 +0000 From: Gorry Fairhurst Organization: ERG X-Mailer: Mozilla 4.75 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: IP-over-DVB/MPEG-2 : Status Update Mar 2002 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-ERG-MailScanner: Found to be clean February was a quite month for this list. There were various reasons why in these months Andrew and I were not able to play as big a role as we had hoped. I was unfortunately committed to other things because of a temporary local staff shortage (sorry). Andrew has been subject to a company reorganisation, and will now be leaving his former company, and his role of co-ordination with DVB (but will still be on the list). Requirements ID --------------- Some significant things have happened - the first revision of the first Internet Draft was issued. The authors have received some comments - and will start to reply to these - but this is probably a good time to encourage all on the list to look through the draft and see what needs to be added, changed, or corrected. I’d particularly like to see input from the terrestrial TV people, and those involved in manufacturing receiver cards or IP gateways.... You can down-load this id from: http://search.ietf.org/internet-drafts/draft-fair-ipdvb-req-00.txt Internet drafts usually go through a great many revisions before they reach their final form. Please send your comments to this list! Efficient Encapsulation ----------------------- To capture thoughts, several people have been working on a submission of an ID on this topic. I have lots of text, and will be putting this into an ID when the Internet Drafts archive re-opens after this IETF. Hopefully this subject will also result in one or more drafts to look at options in this design space. Signalling / Addressing ----------------------- This word seems to cover most of the other things which it is currently proposed to look at. This is an important area and one were we have to be careful to get a broad consensus. There has been some discussion on the list, but, there is not yet an Internet Draft. IETF March 2002 --------------- Due to an unfortunate combination of events (see top), we were unable to progress to hold a BoF at this coming IETF. ----- I would like to encourage all to think about what they would like the group to achieve, and to share their ideas and capture the good ones into Internet Drafts. Many successful IETF working groups start off with a good portfolio of IDs. An ID doesn’t need to describe a complete solution, or a part of a protocol - if you’d like help in submitting an ID for this group to use for discussion, do contact one of our <> - I guess for the moment that’s me! Best wishes, Gorry P.S. For those who joined recently, note that this list’s email archive is at: http://www.erg.abdn.ac.uk/users/gorry/ip-dvb/archive/ From majordomo-owner@erg.abdn.ac.uk Tue Mar 5 15:06:23 2002 Received: from sophia.inria.fr (sophia.inria.fr [138.96.32.20]) by erg.abdn.ac.uk (8.12.2/8.12.2) with SMTP id g25F5tkP001427 for ; Tue, 5 Mar 2002 15:05:55 GMT Received: from sophia.inria.fr by sophia.inria.fr (8.11.6/8.10.0) with ESMTP id g25F5tH15821 for ; Tue, 5 Mar 2002 16:05:55 +0100 (MET) X-Authentication-Warning: sophia.inria.fr: Host tac.inria.fr [138.96.24.102] claimed to be sophia.inria.fr Sender: Ghassane.Aniba@sophia.inria.fr Message-ID: <3C84DED2.92DF0471@sophia.inria.fr> Date: Tue, 05 Mar 2002 16:05:54 +0100 From: Ghassane Aniba Organization: INRIA Sophia Antipolis X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: fr-FR, en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: mapping IP -> DVB ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean Hello, i don't know, what few people are sending in this forum. my question is about routing or mapping IP packet in DVB ? I've already read about using LLC SNAP, but i don't know if it's for routing or not. Could someone tell me more about, or if someone has a idea about.... Thank you for your help. seeu. -- Ghassane ANIBA INRIA (projet PLANETE) 2004, route des Lucioles BP 93 FR-06902 Sophia Antipolis Tel : +33(0)492387563 Fax : +33(0)492387978 From majordomo-owner@erg.abdn.ac.uk Fri Mar 15 19:49:40 2002 Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.12.2/8.12.2) with ESMTP id g2FHfKdE008684 for ; Fri, 15 Mar 2002 17:41:21 GMT Message-ID: <3C923242.AE2987E2@erg.abdn.ac.uk> Date: Fri, 15 Mar 2002 17:41:21 +0000 From: Gorry Fairhurst Organization: ERG X-Mailer: Mozilla 4.73C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Re: mapping IP -> DVB ? References: <3C84DED2.92DF0471@sophia.inria.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean I'm not sure exactly what your question is asking... Ghassane Aniba wrote: > > Hello, > i don't know, what few people are sending in this forum. > my question is about routing or mapping IP packet in DVB ? > I've already read about using LLC SNAP, but i don't know if it's for > routing or not. Sure it can be used for IP routing - or for bridging. > Could someone tell me more about, or if someone has a idea about.... > Thank you for your help. You may want also to look at UDLR - RFC3077 http://www.ietf.org/rfc/rfc3077.txt > > seeu. > > -- > Ghassane ANIBA > INRIA (projet PLANETE) > 2004, route des Lucioles > BP 93 > FR-06902 Sophia Antipolis > Tel : +33(0)492387563 > Fax : +33(0)492387978 Best wishes, Gorry From majordomo-owner@erg.abdn.ac.uk Mon Mar 18 15:35:55 2002 Received: from sophia.inria.fr (sophia.inria.fr [138.96.32.20]) by erg.abdn.ac.uk (8.12.2/8.12.2) with SMTP id g2IFZI32000856 for ; Mon, 18 Mar 2002 15:35:20 GMT Received: from sophia.inria.fr by sophia.inria.fr (8.11.6/8.11.6) with ESMTP id g2IFZIO12905 for ; Mon, 18 Mar 2002 16:35:18 +0100 (MET) X-Authentication-Warning: sophia.inria.fr: Host tac.inria.fr [138.96.24.102] claimed to be sophia.inria.fr Sender: Ghassane.Aniba@sophia.inria.fr Message-ID: <3C960936.818A125E@sophia.inria.fr> Date: Mon, 18 Mar 2002 16:35:18 +0100 From: Ghassane Aniba Organization: INRIA Sophia Antipolis X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: fr-FR, en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: How can we use PID in switching? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean Hi everybody, thanks for your answer. But, in general, we use PID to separete between sound and video streams, so how can we use it to switch the IP Packets? If we have many IP adress(more than 2pow(24)), how can we map between PID and @IP? -- Ghassane ANIBA INRIA (Projet PLANETE) | Email : ghassane.aniba@sophia.inria.fr 2004, Route des Lucioles BP 93 | Phone : +33 4 92 38 75 63 06902 Sophia Antipolis CEDEX France| Fax : +33 4 92 38 79 78 From majordomo-owner@erg.abdn.ac.uk Mon Mar 18 15:53:02 2002 Received: from esacom56-int.estec.esa.int (firewall-user@esacom56-ext.estec.esa.int [131.176.107.3]) by erg.abdn.ac.uk (8.12.2/8.12.2) with SMTP id g2IFqU32001116 for ; Mon, 18 Mar 2002 15:52:30 GMT Received: from esacom52.estec.esa.nl (esacom52.estec.esa.nl [131.176.7.7]) by esacom56-int.estec.esa.int (8.10.2/8.10.2/ESA-External-v2.0) with ESMTP id g2IFqU913639 for ; Mon, 18 Mar 2002 16:52:30 +0100 (MET) Received: from estecmail4.estec.esa.int (estecmail4.estec.esa.nl [131.176.7.65]) by esacom52.estec.esa.nl (8.9.2/8.9.2/ESA-ESTEC-mail-gw-v1.6) with SMTP id PAA22460 for ; Mon, 18 Mar 2002 15:52:30 GMT Received: by estecmail4.estec.esa.int(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 41256B80.0057B904 ; Mon, 18 Mar 2002 16:58:09 +0100 X-Lotus-FromDomain: ESA From: Frank.Zeppenfeldt@esa.int To: ip-dvb@erg.abdn.ac.uk Message-ID: <41256B80.0057B82A.00@estecmail4.estec.esa.int> Date: Mon, 18 Mar 2002 16:51:55 +0100 Subject: Re: How can we use PID in switching? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-ERG-MailScanner: Found to be clean Frank Zeppenfeldt@ESA 03/18/2002 04:51 PM Dear Ghassane, In the report on regenerative satellite systems (starting page 24) there is good description of possible switching and routing architectures and their implications. See the report on http://telecom.estec.esa.nl/artes/artes1/fileincludes/documentation/ahg-rsat.cfm . Regards, Frank |--------+--------------------------------> | | Ghassane Aniba | | | | | | | | | 2002/03/18 16:35 | | | Please respond to | | | ip-dvb | | | | |--------+--------------------------------> >-------------------------------------------------------------------------| | | | To: ip-dvb@erg.abdn.ac.uk | | cc: (bcc: Frank Zeppenfeldt/estec/ESA) | | Subject: How can we use PID in switching? | >-------------------------------------------------------------------------| Hi everybody, thanks for your answer. But, in general, we use PID to separete between sound and video streams, so how can we use it to switch the IP Packets? If we have many IP adress(more than 2pow(24)), how can we map between PID and @IP? -- Ghassane ANIBA INRIA (Projet PLANETE) | Email : ghassane.aniba@sophia.inria.fr 2004, Route des Lucioles BP 93 | Phone : +33 4 92 38 75 63 06902 Sophia Antipolis CEDEX France| Fax : +33 4 92 38 79 78 From majordomo-owner@erg.abdn.ac.uk Tue Mar 19 07:00:33 2002 Received: from rusfw.rohde-schwarz.com (rusfw.rohde-schwarz.com [80.246.32.32]) by erg.abdn.ac.uk (8.12.2/8.12.2) with SMTP id g2J70332008426 for ; Tue, 19 Mar 2002 07:00:03 GMT Received: from rus11.rsd.de by rusfw.rohde-schwarz.com via smtpd (for mavis.erg.abdn.ac.uk [139.133.204.77]) with SMTP; 19 Mar 2002 07:00:03 UT Received: by mail.rohde-schwarz.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id C1256B81.00267690 ; Tue, 19 Mar 2002 08:00:07 +0100 X-Lotus-FromDomain: FTK@RUS From: Torsten.Jaekel@FTK.rohde-schwarz.com Sender: Torsten.Jaekel@FTK.rohde-schwarz.com To: ip-dvb@erg.abdn.ac.uk Message-ID: Date: Tue, 19 Mar 2002 08:00:47 +0100 Subject: Antwort: How can we use PID in switching? Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-ERG-MailScanner: Found to be clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by erg.abdn.ac.uk id g2J70Xep008447 Hi, you can decide to transmitt all IP in one PID or to assign particular IP addresses to separate PIDs (e.g. subnet grouping). But you should be in mind, that: - the PIDs are coded in 13 bits, 0x1fff (dec. 8191) is the maximum PID number. Means. no chance to map all IP in different PID   (therefore subnetworks and a few particular IP connection). - some receivers and recption devices are not able to support so many parallel PIDs. Therefore the IP connections to one   device should travel in one or in not so many different PIDs. But nevertheless, the idea to map IP to PIDs is a good idea especially in case there are PID routers in a video network (I do not know if it exists, perhaps also remultiplexer) and you want be sure that the logical IP overlay fits to the physical transport stream network ... Best regards Torsten Jaekel Product Marketing Datacasting Rohde & Schwarz FTK GmbH Wendenschlossstr. 168, Haus 28 12557 Berlin Germany Phone: +49 30 65 89 1 - 103 FAX:     +49 30 65 55 02 21 email: Torsten.Jaekel@FTK.rohde-schwarz.com |+-------------------------------+---------------------------------------------| || Ghassane Aniba | | || |         Kopie:        (Blindkopie: Torsten| || | Jaekel/FTK) | || 18.03.2002 16:35 |         Thema:        How can we use PID | || Bitte antworten an ip-dvb | in switching? | || | | |+-------------------------------+---------------------------------------------| Hi everybody, thanks for your answer. But, in general, we use PID to separete between sound and video streams, so how can we use it to switch the IP Packets? If we have many IP adress(more than 2pow(24)), how can we map between PID and @IP? -- Ghassane ANIBA INRIA (Projet PLANETE)             | Email : ghassane.aniba@sophia.inria.fr 2004, Route des Lucioles BP 93     | Phone : +33 4 92 38 75 63 06902 Sophia Antipolis CEDEX France| Fax   : +33 4 92 38 79 78 From majordomo-owner@erg.abdn.ac.uk Thu Mar 21 15:56:22 2002 Received: from sophia.inria.fr (sophia.inria.fr [138.96.32.20]) by erg.abdn.ac.uk (8.12.2/8.12.2) with SMTP id g2LFtmOM014468 for ; Thu, 21 Mar 2002 15:55:48 GMT Received: from sophia.inria.fr by sophia.inria.fr (8.11.6/8.11.6) with ESMTP id g2LFtmb21862 for ; Thu, 21 Mar 2002 16:55:48 +0100 (MET) X-Authentication-Warning: sophia.inria.fr: Host tac.inria.fr [138.96.24.102] claimed to be sophia.inria.fr Sender: Ghassane.Aniba@sophia.inria.fr Message-ID: <3C9A0283.A86EF2B0@sophia.inria.fr> Date: Thu, 21 Mar 2002 16:55:47 +0100 From: Ghassane Aniba Organization: INRIA Sophia Antipolis X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: fr-FR, en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Clear presentation, please :). References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean HI every body, i've read all the archive paper, but every time i found i misunderstood, what the writer would say. I hope some one to present clear simple explanation of: -> the steps to do from an IP paquet to MPEG2 TS. for example: |ip paquet(1500 bytes for example)| | | |encapsulated in What ?| | | ? | |MPEG TS| + |MPEG TS| +|MPEG TS| + .. another question: i've read that "we can map IP Networks to PID", but in multicasting how we can do that, we don't have a netword adress, as i know..!? Thank you and seeu. From majordomo-owner@erg.abdn.ac.uk Thu Mar 21 16:31:32 2002 Received: from ladron.cs.nmt.edu (ladron.cs.nmt.edu [129.138.6.58]) by erg.abdn.ac.uk (8.12.2/8.12.2) with SMTP id g2LGVBOM014833 for ; Thu, 21 Mar 2002 16:31:15 GMT Received: from nmttb97i6f89th ([129.138.6.121]) by ladron.cs.nmt.edu (8.11.2/8.11.2) with SMTP id g2LHhp610473; Thu, 21 Mar 2002 10:43:51 -0700 Message-ID: <003f01c1d0fe$c3f61700$79068a81@nmttb97i6f89th> Reply-To: "Kearney" From: "Kearney" To: Cc: References: <3C9A0283.A86EF2B0@sophia.inria.fr> Subject: Re: Clear presentation, please :). Date: Thu, 21 Mar 2002 09:35:16 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean > i've read all the archive paper, but every time i found i misunderstood, > what the writer would say. > I hope some one to present clear simple explanation of: > -> the steps to do from an IP paquet to MPEG2 TS. > for example: > |ip paquet(1500 bytes for example)| > | > | > |encapsulated in What ?| > | > | > ? > | > |MPEG TS| + |MPEG TS| +|MPEG TS| + .. > I suggest you read the ETSI document EN 301 192 "DVB specification for data broadcasting". This explains the various modes the DVB consortium sees for transmitting IP datagrams over MPEG-2 Transport Stream packets (188 byte cells). > another question: i've read that "we can map IP Networks to PID", but in > multicasting how we can do that, we don't have a netword adress, as i > know..!? An MPEG PID identifies a broadcast channel, not a point-to-point link; but you may map a network ID to a PID. But don't forget that the properties of a satellite network (a typical LFN) are vastly different from those of a true LAN. --cls From majordomo-owner@erg.abdn.ac.uk Thu Mar 21 17:11:06 2002 Received: from sophia.inria.fr (sophia.inria.fr [138.96.32.20]) by erg.abdn.ac.uk (8.12.2/8.12.2) with SMTP id g2LHAkOM015330 for ; Thu, 21 Mar 2002 17:10:47 GMT Received: from sophia.inria.fr by sophia.inria.fr (8.11.6/8.11.6) with ESMTP id g2LHAkb28772 for ; Thu, 21 Mar 2002 18:10:46 +0100 (MET) X-Authentication-Warning: sophia.inria.fr: Host tac.inria.fr [138.96.24.102] claimed to be sophia.inria.fr Sender: Ghassane.Aniba@sophia.inria.fr Message-ID: <3C9A1416.831E7768@sophia.inria.fr> Date: Thu, 21 Mar 2002 18:10:46 +0100 From: Ghassane Aniba Organization: INRIA Sophia Antipolis X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: fr-FR, en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: ISO/IEC 13818-1 and ISO/IEC 13818-6? References: <3C9A0283.A86EF2B0@sophia.inria.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean Hi every body, could someone send me these documents, please. Thank you. It's about MPEG-2 Transport Stream paquets seeu. -- Ghassane ANIBA INRIA (Projet PLANETE) | Email : ghassane.aniba@sophia.inria.fr 2004, Route des Lucioles BP 93 | Phone : +33 4 92 38 75 63 06902 Sophia Antipolis CEDEX France| Fax : +33 4 92 38 79 78 From majordomo-owner@erg.abdn.ac.uk Thu Mar 21 23:17:14 2002 Received: from ladron.cs.nmt.edu (ladron.cs.nmt.edu [129.138.6.58]) by erg.abdn.ac.uk (8.12.2/8.12.2) with SMTP id g2LNH3OM017945 for ; Thu, 21 Mar 2002 23:17:03 GMT Received: from nmttb97i6f89th ([129.138.6.121]) by ladron.cs.nmt.edu (8.11.2/8.11.2) with SMTP id g2M0To618224 for ; Thu, 21 Mar 2002 17:29:50 -0700 Message-ID: <001501c1d137$7b790620$79068a81@nmttb97i6f89th> Reply-To: "Kearney" From: "Kearney" To: References: <3C9A0283.A86EF2B0@sophia.inria.fr> <3C9A1416.831E7768@sophia.inria.fr> Subject: Re: ISO/IEC 13818-1 and ISO/IEC 13818-6? Date: Thu, 21 Mar 2002 16:21:16 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean These documents are available directly from ETSI - check their web site at http://www.etsi.org/getastandard/home.htm --cls ----- Original Message ----- From: "Ghassane Aniba" To: Sent: Thursday, March 21, 2002 9:10 AM Subject: ISO/IEC 13818-1 and ISO/IEC 13818-6? > Hi every body, > could someone send me these documents, please. Thank you. > It's about MPEG-2 Transport Stream paquets > seeu. > > -- > Ghassane ANIBA > INRIA (Projet PLANETE) | Email : > ghassane.aniba@sophia.inria.fr > 2004, Route des Lucioles BP 93 | Phone : +33 4 92 38 75 63 > 06902 Sophia Antipolis CEDEX France| Fax : +33 4 92 38 79 78 > From majordomo-owner@erg.abdn.ac.uk Fri Mar 22 16:57:57 2002 Received: from sophia.inria.fr (sophia.inria.fr [138.96.32.20]) by erg.abdn.ac.uk (8.12.2/8.12.2) with SMTP id g2MGvROM001317 for ; Fri, 22 Mar 2002 16:57:28 GMT Received: from sophia.inria.fr by sophia.inria.fr (8.11.6/8.11.6) with ESMTP id g2MGvQX22186 for ; Fri, 22 Mar 2002 17:57:27 +0100 (MET) X-Authentication-Warning: sophia.inria.fr: Host tac.inria.fr [138.96.24.102] claimed to be sophia.inria.fr Sender: Ghassane.Aniba@sophia.inria.fr Message-ID: <3C9B6275.F73584CF@sophia.inria.fr> Date: Fri, 22 Mar 2002 17:57:25 +0100 From: Ghassane Aniba Organization: INRIA Sophia Antipolis X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: fr-FR, en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: IP -> PES -> MPEG TS? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean Hi every body, i've a question (ofcourse ;) do we pu IP packet in PES then in MPEG TS, OR we put directly IP -> MPEG TS? seeu. -- Ghassane ANIBA INRIA (Projet PLANETE) | Email : ghassane.aniba@sophia.inria.fr 2004, Route des Lucioles BP 93 | Phone : +33 4 92 38 75 63 06902 Sophia Antipolis CEDEX France| Fax : +33 4 92 38 79 78 From majordomo-owner@erg.abdn.ac.uk Fri Mar 22 17:24:52 2002 Received: from ra.udcast.com (ANice-101-2-1-104.abo.wanadoo.fr [193.251.10.104]) by erg.abdn.ac.uk (8.12.2/8.12.2) with SMTP id g2MHOWOM001562 for ; Fri, 22 Mar 2002 17:24:32 GMT Received: (from pplc@localhost) by ra.udcast.com (8.11.0/8.11.0) id g2MHOUQ10348; Fri, 22 Mar 2002 18:24:30 +0100 Date: Fri, 22 Mar 2002 18:24:30 +0100 Message-Id: <200203221724.g2MHOUQ10348@ra.udcast.com> From: Patrick Cipiere To: ip-dvb@erg.abdn.ac.uk CC: ip-dvb@erg.abdn.ac.uk In-reply-to: <3C9B6275.F73584CF@sophia.inria.fr> (message from Ghassane Aniba on Fri, 22 Mar 2002 17:57:25 +0100) Subject: Re: IP -> PES -> MPEG TS? X-ERG-MailScanner: Found to be clean IP packet in MPE datagram section in MPEG2 Transport packets Patrick. -- UDcast: Full IP over Broadcast Media Phone: (+33) (0)4 93 00 16 99 Mobile: (+33) (0)6 14 21 55 98 Fax: (+33) (0)4 93 00 16 61 http://www.UDcast.com From majordomo-owner@erg.abdn.ac.uk Fri Mar 22 17:50:56 2002 Received: from sophia.inria.fr (sophia.inria.fr [138.96.32.20]) by erg.abdn.ac.uk (8.12.2/8.12.2) with SMTP id g2MHohOM001769 for ; Fri, 22 Mar 2002 17:50:44 GMT Received: from sophia.inria.fr by sophia.inria.fr (8.11.6/8.11.6) with ESMTP id g2MHohX25830 for ; Fri, 22 Mar 2002 18:50:43 +0100 (MET) X-Authentication-Warning: sophia.inria.fr: Host tac.inria.fr [138.96.24.102] claimed to be sophia.inria.fr Sender: Ghassane.Aniba@sophia.inria.fr Message-ID: <3C9B6EF2.F7A8CC68@sophia.inria.fr> Date: Fri, 22 Mar 2002 18:50:42 +0100 From: Ghassane Aniba Organization: INRIA Sophia Antipolis X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: fr-FR, en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Re: IP -> PES -> MPEG TS? References: <200203221724.g2MHOUQ10348@ra.udcast.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean HI, Patrick Cipiere wrote: > > IP packet in MPE datagram section in MPEG2 Transport packets > > Patrick. i ask if we can put directly ip in MPEG2 TP. As i know, we use MPE to have the destination adress, and so we could filter IP paquets in Layer 2. But, if we have a mapping between MAC Adress and PID in the receiver, so we don't need to transmet the MAC, because we already transmit PID. Could someone give me his opinion, thanks. -- Ghassane ANIBA INRIA (Projet PLANETE) | Email : ghassane.aniba@sophia.inria.fr 2004, Route des Lucioles BP 93 | Phone : +33 4 92 38 75 63 06902 Sophia Antipolis CEDEX France| Fax : +33 4 92 38 79 78 From majordomo-owner@erg.abdn.ac.uk Sun Mar 24 12:37:59 2002 Received: from sh.csm.jcsat.co.jp (root@sh.csm.jcsat.co.jp [163.142.0.34]) by erg.abdn.ac.uk (8.12.2/8.12.2) with SMTP id g2OCbNOM029084 for ; Sun, 24 Mar 2002 12:37:25 GMT Received: from localhost (root@localhost [127.0.0.1]) by sh.csm.jcsat.co.jp (8.11.6/3.7W) with ESMTP id g2OCbDI24762 for ; Sun, 24 Mar 2002 21:37:13 +0900 (JST) Date: Sun, 24 Mar 2002 06:07:56 +0900 (JST) Message-Id: <20020324.060756.103957645.takei@csm.jcsat.co.jp> To: ip-dvb@erg.abdn.ac.uk Subject: Re: IP -> PES -> MPEG TS? From: TAKEI jun In-Reply-To: <3C9B6EF2.F7A8CC68@sophia.inria.fr> References: <200203221724.g2MHOUQ10348@ra.udcast.com> <3C9B6EF2.F7A8CC68@sophia.inria.fr> Organization: JSAT Co. X-PGP-fingerprint: 6B 13 A8 85 D2 D5 F0 E8 C2 B3 FE 38 84 60 C5 1A X-GPG-fingerprint: 5281 880B 1688 8DCE ADC3 AD27 C466 5C87 0EF3 A912 X-Mailer: Mew version 2.2rc1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean From: Ghassane Aniba Subject: Re: IP -> PES -> MPEG TS? Date: Fri, 22 Mar 2002 18:50:42 +0100 Message-ID: <3C9B6EF2.F7A8CC68@sophia.inria.fr> Ghassane.Aniba> HI, Ghassane.Aniba> Ghassane.Aniba> Patrick Cipiere wrote: Ghassane.Aniba> > Ghassane.Aniba> > IP packet in MPE datagram section in MPEG2 Transport packets Ghassane.Aniba> > Ghassane.Aniba> > Patrick. Ghassane.Aniba> i ask if we can put directly ip in MPEG2 TP. As i Ghassane.Aniba> know, we use MPE to have the destination adress, and Ghassane.Aniba> so we could Ghassane.Aniba> filter IP paquets in Layer 2. But, if we have a Ghassane.Aniba> mapping between MAC Adress and PID in the receiver, so Ghassane.Aniba> we don't need to transmet the MAC, because we already Ghassane.Aniba> transmit PID. Could someone give me his opinion, Ghassane.Aniba> thanks. I can't understand why you want to map IP address or MAC address into PID. PID = 13 bit MAC = 48 bit(ethernet) IP = 32 bit or 128 bit PID has been designed as a PROGRAM IDENTIFIER in broadcasting world. MAC and IP address represent identification of the communication node. If you map MAC address and PID, PID will be a MAC address. That means PID is not Program ID but Receiver ID and the number of receiver would be less than 8191. Do you think it is scalable? -- JSAT Jun Takei From majordomo-owner@erg.abdn.ac.uk Sun Mar 24 23:23:24 2002 Received: from ladron.cs.nmt.edu (ladron.cs.nmt.edu [129.138.6.58]) by erg.abdn.ac.uk (8.12.2/8.12.2) with SMTP id g2ONMoOM003652 for ; Sun, 24 Mar 2002 23:22:51 GMT Received: from nmttb97i6f89th ([129.138.6.121]) by ladron.cs.nmt.edu (8.11.2/8.11.2) with SMTP id g2P0Zi605489 for ; Sun, 24 Mar 2002 17:35:44 -0700 Message-ID: <001d01c1d393$c85e6fd0$79068a81@nmttb97i6f89th> Reply-To: "Kearney" From: "Kearney" To: References: <200203221724.g2MHOUQ10348@ra.udcast.com><3C9B6EF2.F7A8CC68@sophia.inria.fr> <20020324.060756.103957645.takei@csm.jcsat.co.jp> Subject: Re: IP -> PES -> MPEG TS? Date: Sun, 24 Mar 2002 16:27:01 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean ----- Original Message ----- From: "TAKEI jun" To: Sent: Saturday, March 23, 2002 1:07 PM Subject: Re: IP -> PES -> MPEG TS? > > PID has been designed as a PROGRAM IDENTIFIER in broadcasting > world. Yes - it identifies a broadcast channel; if you "tune" your receiver to this PID you will receive all TS packets from the incoming TS multiplex of an MCPC channel which have exactly this PID value. This corresponds largely to a multicast group address on an Ethernet interface. > MAC and IP address represent identification of the > communication node. note quite! the IP address is clearly the identification of a node or an end system in a network, but the MAC level address is and identification of an interface on a communications link. Unfortunately the Ethernet/Token Ring LAN addresses are a combination of these two functions and this is largely due to the fact that they use broadcast channels where an explicit routing is not required. You can see the difference when you look at the "learning bridges" and the binding of IP addresses to e.g. ATM networks. > If you map MAC address and PID, PID will be a MAC > address. That means PID is not Program ID but Receiver ID and the > number of receiver would be less than 8191. Do you think it is > scalable? > correct. IP/DVB makes use of a broadcast channel, hence ther is no need for a MAC level address. If you need one for authorization and authentication then this is the concern of the return channel, not the forward channel. The IP address is totally sufficient to address individual station of you really need to. Finally - satellite networks behave differently from LANs (two-way, very short delay, cheap bandwidth) and, hence, transferring solutions from the LAN world to MPEG2-S networks is not a reasonable approach. --cls From majordomo-owner@erg.abdn.ac.uk Mon Mar 25 09:34:29 2002 Received: from ra.udcast.com (ANice-101-2-1-104.abo.wanadoo.fr [193.251.10.104]) by erg.abdn.ac.uk (8.12.2/8.12.2) with SMTP id g2P9YFOM014181 for ; Mon, 25 Mar 2002 09:34:18 GMT Received: (from pplc@localhost) by ra.udcast.com (8.11.0/8.11.0) id g2P9YFZ21747; Mon, 25 Mar 2002 10:34:15 +0100 Date: Mon, 25 Mar 2002 10:34:15 +0100 Message-Id: <200203250934.g2P9YFZ21747@ra.udcast.com> From: Patrick Cipiere To: ip-dvb@erg.abdn.ac.uk In-reply-to: <001d01c1d393$c85e6fd0$79068a81@nmttb97i6f89th> (clausen@cosy.sbg.ac.at) Subject: Re: IP -> PES -> MPEG TS? X-ERG-MailScanner: Found to be clean "Kearney" wrote: > Yes - it identifies a broadcast channel; if you "tune" your receiver to this > PID you will receive all TS packets from the incoming TS multiplex of an > MCPC channel which have exactly this PID value. This corresponds largely to > a multicast group address on an Ethernet interface. I do not agree. For me PID stands at the physical layer, and 13 bits is not enough to map a multicast IP address. I would prefer the ethernet scheme, mapping the IP V4 (or V6) multicast address on the IEEE 48 bits MAC address (link layer). > Finally - satellite networks behave differently from LANs (two-way, very > short delay, cheap bandwidth) and, hence, transferring solutions from the > LAN world to MPEG2-S networks is not a reasonable approach. I do not agree. When you use UDLR (RFC3077) the satellite link behaves as a broadcast LAN and you can re-use almost everything from the LAN work. Patrick. -- UDcast: Full IP over Broadcast Media Phone: (+33) (0)4 93 00 16 99 Mobile: (+33) (0)6 14 21 55 98 Fax: (+33) (0)4 93 00 16 61 http://www.UDcast.com From majordomo-owner@erg.abdn.ac.uk Mon Mar 25 10:14:19 2002 Received: from sophia.inria.fr (sophia.inria.fr [138.96.32.20]) by erg.abdn.ac.uk (8.12.2/8.12.2) with SMTP id g2PAE9OM014557 for ; Mon, 25 Mar 2002 10:14:11 GMT Received: from sophia.inria.fr by sophia.inria.fr (8.11.6/8.11.6) with ESMTP id g2PADH318133 for ; Mon, 25 Mar 2002 11:13:51 +0100 (MET) X-Authentication-Warning: sophia.inria.fr: Host tac.inria.fr [138.96.24.102] claimed to be sophia.inria.fr Sender: Ghassane.Aniba@sophia.inria.fr Message-ID: <3C9EF828.925E0A2C@sophia.inria.fr> Date: Mon, 25 Mar 2002 11:12:56 +0100 From: Ghassane Aniba Organization: INRIA Sophia Antipolis X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: fr-FR, en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: MAC or PID? References: <200203250934.g2P9YFZ21747@ra.udcast.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean HI, what's the problem if we don't use DSM_CC? could someone tell us what exactly the usefull thing in the DSM-CC encapsulation? thanks. -- Ghassane ANIBA INRIA (Projet PLANETE) | Email : ghassane.aniba@sophia.inria.fr 2004, Route des Lucioles BP 93 | Phone : +33 4 92 38 75 63 06902 Sophia Antipolis CEDEX France| Fax : +33 4 92 38 79 78 From majordomo-owner@erg.abdn.ac.uk Mon Mar 25 11:21:43 2002 Received: from [10.0.1.2] (maxp27.abdn.ac.uk [139.133.7.186]) by erg.abdn.ac.uk (8.12.2/8.12.2) with SMTP id g2PBLZOM015195 for ; Mon, 25 Mar 2002 11:21:36 GMT User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Mon, 25 Mar 2002 11:21:18 +0000 Subject: Re: MAC or PID? From: Gorry Fairhurst To: Message-ID: In-Reply-To: <3C9EF828.925E0A2C@sophia.inria.fr> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-ERG-MailScanner: Found to be clean on 25/3/02 10:12 am, Ghassane Aniba at Ghassane.Aniba@sophia.inria.fr wrote: > HI, > what's the problem if we don't use DSM_CC? > could someone tell us what exactly the usefull thing in the DSM-CC > encapsulation? > thanks. DSM-CC came from the video world as a way of communicating control data - it has lots of useful features to support this (look at the header), including ability to work with carousels. MPE adds some glue to make this work for IP. The point is, it never was very well suited to IP transport. Although you can run IP over anything (almost :-) ) it adds very significant complexity and processing to each IP datagram. Gorry Fairhurst. From majordomo-owner@erg.abdn.ac.uk Mon Mar 25 11:21:54 2002 Received: from [10.0.1.2] (maxp27.abdn.ac.uk [139.133.7.186]) by erg.abdn.ac.uk (8.12.2/8.12.2) with SMTP id g2PBLZOO015195 for ; Mon, 25 Mar 2002 11:21:40 GMT User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Mon, 25 Mar 2002 11:21:18 +0000 Subject: Re: IP -> PES -> MPEG TS? From: Gorry Fairhurst To: Message-ID: In-Reply-To: <20020324.060756.103957645.takei@csm.jcsat.co.jp> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-ERG-MailScanner: Found to be clean Let me try and help - You seem to be asking, *WHY* do this? First, let me say MPE can be used exactly as you say. I agree. Second, let's now look beyond what we have today. IP was originally seen as a supplementary service by DVB to video transport - BUT, DVB is now proving a good platform for building true IP networks (both terrestrial wireless and satellite). So, is it optimal, does MPE constrain the design? I'd argue it is inefficient (especially in terms of header processing) AND that current systems are far from plug-and-play. There's also potential for doing much more, when we look at DVB-T, two way DVB-S (DVB-RCS) and DVB switched networks. If you look at the requirements documents, the new encapsulation aims at the latter, while recognising that MPE would likely continue in use for some applications. on 23/3/02 9:07 pm, TAKEI jun at takei@csm.jcsat.co.jp wrote: > From: Ghassane Aniba > Subject: Re: IP -> PES -> MPEG TS? > Date: Fri, 22 Mar 2002 18:50:42 +0100 > Message-ID: <3C9B6EF2.F7A8CC68@sophia.inria.fr> > > Ghassane.Aniba> HI, > Ghassane.Aniba> > Ghassane.Aniba> Patrick Cipiere wrote: > Ghassane.Aniba> > > Ghassane.Aniba> > IP packet in MPE datagram section in MPEG2 Transport packets > Ghassane.Aniba> > > Ghassane.Aniba> > Patrick. > > > Ghassane.Aniba> i ask if we can put directly ip in MPEG2 TP. As i > Ghassane.Aniba> know, we use MPE to have the destination adress, and > Ghassane.Aniba> so we could > Ghassane.Aniba> filter IP paquets in Layer 2. But, if we have a > Ghassane.Aniba> mapping between MAC Adress and PID in the receiver, so > Ghassane.Aniba> we don't need to transmet the MAC, because we already > Ghassane.Aniba> transmit PID. Could someone give me his opinion, > Ghassane.Aniba> thanks. > > I can't understand why you want to map IP address or MAC address into > PID. > > PID = 13 bit > MAC = 48 bit(ethernet) > IP = 32 bit or 128 bit > > PID has been designed as a PROGRAM IDENTIFIER in broadcasting > world. MAC and IP address represent identification of the > communication node. If you map MAC address and PID, PID will be a MAC > address. PID is not really a MAC address. It's a subnetwork flow-id. There COULD be a one-to-one mapping between IP address and PID, or more-likely, several IP destination addresses map to the same PID. It could even be that the same IP address maps to several PIDs. (Such things are common in networks which support QoS, and need to assign e.g., priorities, to flows within a subnetwork.) Nothing that has been said so far on this list has assumed that you allocate one PID per receiver. That means it acts only as a pre-filter, some unwanted packets would still be received and sent to the IP layer. If it's IP packets, then this filtering can be done in the network layer by the IPv4 or IPv6 forwarding code. You can do this in hardware or software (providing you can find and filter the addresses easily). N.B. If you want to process non-IP datagrams (including arp), then you need to use a MAC frame. > That means PID is not Program ID but Receiver ID and the > number of receiver would be less than 8191. Do you think it is > scalable? Not scalable (but also note need for multicast and subnetwork broadcast). BUT, that was not what was being suggested. > -- > JSAT > Jun Takei > From majordomo-owner@erg.abdn.ac.uk Mon Mar 25 11:21:55 2002 Received: from [10.0.1.2] (maxp27.abdn.ac.uk [139.133.7.186]) by erg.abdn.ac.uk (8.12.2/8.12.2) with SMTP id g2PBLZON015195 for ; Mon, 25 Mar 2002 11:21:38 GMT User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Mon, 25 Mar 2002 11:21:18 +0000 Subject: Re: IP -> PES -> MPEG TS? From: Gorry Fairhurst To: Message-ID: In-Reply-To: <200203250934.g2P9YFZ21747@ra.udcast.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-ERG-MailScanner: Found to be clean on 25/3/02 9:34 am, Patrick Cipiere at Patrick.Cipiere@udcast.com wrote: > > "Kearney" wrote: > >> Yes - it identifies a broadcast channel; if you "tune" your receiver to this >> PID you will receive all TS packets from the incoming TS multiplex of an >> MCPC channel which have exactly this PID value. This corresponds largely to >> a multicast group address on an Ethernet interface. > > I do not agree. For me PID stands at the physical layer, and 13 bits > is not enough to map a multicast IP address. > I would prefer the ethernet scheme, mapping the IP V4 (or V6) > multicast address on the IEEE 48 bits MAC address (link layer). This is a useful debate.... You seem to have two contrasting viewpoints, and both have merits ;-) So, let me add some observations myself... The PID lets you specify a flow at the subnetwork level. What can/should we use this for? (i) We could use this to tell a multiplexor where to "forward" the data - if we have a hierarchy of multiplexors connected to several feeds, we can send some MPEG-2 TS to some feeds, others to only only one feed, etc. This is the basis of various schemes suggested/implemented for example to perform on-board MPEG-2 TS packet switching. (There is some resemblance to Ethernet switching here). (ii) We can use the PID as the basis for differentiating type of flows, some PIDs denote video streams, tables, use of encryption, presentation time stamps, etc. This is a demultiplexing function. (iii) We can use the PID as the first level of filtering at receivers. Receivers can filter and forward only a selected range of PID values to the host/router to which they are connected. This CAN reduce receiver processing. NOTE that the IP layer must still filter as well, but does not need to see every packet sent over the feed. So (iii) is the point in question... Consider a MPEG multiplex feeding a large group of receivers. I think the MAC address ***is*** useful. It provides per-receiver filters for unicast (reducing unwanted traffic at the receiver). If you wish to do multicast support, then you also need to expect IP-level filtering, because there is not a one-to-one mapping of IP group destination address to MAC address. I think if we go along this line, we should use a full MAC header - source, destination & type - with CRC-32. That way, we really do have a "LAN" in the sky, and can do proper LAN emulation, and support IPv6 as well as IPv4. On the other hand, why not also allow the next generation systems to use native IP support, without a MAC header? This would require the receiver to do per-packet IP level filtering, (as an IP router does). If we think carefully about the structure of the encapsulation, we should be able to allow (hardware?) processing of the IP address by the interface card - much the same as MAC addresses are currently processed. This can have several merits: (a) If we think about efficiency, we can now have a *VERY* small header per packet. I'm keen we get this right, if we can. (b) Some uses of DVB, are simply point-to-point links, or unidirectional point-to-multipoint links. I'm thinking here of uses by network service providers providing BGP-style connectivity between networks. Such topologies do not NEED inidividual terminal subnetwork addresses (MAC) (they can be "unumbered" IP interfaces at the network level too). Do this two cases capture to the two points of view? Are there other topologies / needs out there? > >> Finally - satellite networks behave differently from LANs (two-way, very >> short delay, cheap bandwidth) and, hence, transferring solutions from the >> LAN world to MPEG2-S networks is not a reasonable approach. > > I do not agree. When you use UDLR (RFC3077) the satellite link behaves > as a broadcast LAN and you can re-use almost everything from the LAN > work. Yes - in UDLR, you have a good case using MAC addresses with this, but that's may be not surprising, since it's an Ethernet LAN emulation scheme, rather than a native IP scheme. But there ***are*** other scenarios... What happens when we have several feeds in use simultaneously? There's also two-way satellite links. Satellite links with on-board processing (soonish). And, we shouldn't confine this debate to satellite: DVB-T has interesting possibilities for IP transport, and may also have an urgent need to address the issues of multiple feeds carrying the same multicast groups ( ;-) ). > > Patrick. What do you think? Gorry Fairhurst From majordomo-owner@erg.abdn.ac.uk Mon Mar 25 12:50:01 2002 Received: from sophia.inria.fr (sophia.inria.fr [138.96.32.20]) by erg.abdn.ac.uk (8.12.2/8.12.2) with SMTP id g2PCnpOM016056 for ; Mon, 25 Mar 2002 12:49:53 GMT Received: from sophia.inria.fr by sophia.inria.fr (8.11.6/8.11.6) with ESMTP id g2PCnmJ10948 for ; Mon, 25 Mar 2002 13:49:48 +0100 (MET) X-Authentication-Warning: sophia.inria.fr: Host tac.inria.fr [138.96.24.102] claimed to be sophia.inria.fr Sender: Ghassane.Aniba@sophia.inria.fr Message-ID: <3C9F1CEF.CCA79B16@sophia.inria.fr> Date: Mon, 25 Mar 2002 13:49:51 +0100 From: Ghassane Aniba Organization: INRIA Sophia Antipolis X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: fr-FR, en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: MPE, is it necessary? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean hi, thanks or G.F for his explanation. i want ask him, if i put directly IP packets in MPEG TP, and if i map IP adress with PID, where can i found a problem? Because with PID, i have all what i need. another thing, can some one tell me how many multicast adress are used until now? and since when? and how many they will be in the future, in your opinion? thanks. -- Ghassane ANIBA INRIA (Projet PLANETE) | Email : ghassane.aniba@sophia.inria.fr 2004, Route des Lucioles BP 93 | Phone : +33 4 92 38 75 63 06902 Sophia Antipolis CEDEX France| Fax : +33 4 92 38 79 78 From majordomo-owner@erg.abdn.ac.uk Mon Mar 25 17:06:50 2002 Received: from sophia.inria.fr (sophia.inria.fr [138.96.32.20]) by erg.abdn.ac.uk (8.12.2/8.12.2) with SMTP id g2PH6NOM019086 for ; Mon, 25 Mar 2002 17:06:24 GMT Received: from sophia.inria.fr by sophia.inria.fr (8.11.6/8.11.6) with ESMTP id g2PH6KJ04184 for ; Mon, 25 Mar 2002 18:06:20 +0100 (MET) X-Authentication-Warning: sophia.inria.fr: Host tac.inria.fr [138.96.24.102] claimed to be sophia.inria.fr Sender: Ghassane.Aniba@sophia.inria.fr Message-ID: <3C9F590F.B674548A@sophia.inria.fr> Date: Mon, 25 Mar 2002 18:06:23 +0100 From: Ghassane Aniba Organization: INRIA Sophia Antipolis X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: fr-FR, en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: How many people could pay for access to a satellite link? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean Hi every body, it's for G.F. How many Multicast IPv4 sources we have now, who can pay for a satellite link?( professionnal users). -- Ghassane ANIBA INRIA (Projet PLANETE) | Email : ghassane.aniba@sophia.inria.fr 2004, Route des Lucioles BP 93 | Phone : +33 4 92 38 75 63 06902 Sophia Antipolis CEDEX France| Fax : +33 4 92 38 79 78 From majordomo-owner@erg.abdn.ac.uk Tue Mar 26 06:27:12 2002 Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by erg.abdn.ac.uk (8.12.2/8.12.2) with SMTP id g2Q6QXOM026578 for ; Tue, 26 Mar 2002 06:26:34 GMT Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2Q6Qks04515 for ; Tue, 26 Mar 2002 08:26:46 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 26 Mar 2002 08:26:31 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 26 Mar 2002 08:26:31 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 26 Mar 2002 08:26:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: MPE, is it necessary? Date: Tue, 26 Mar 2002 08:26:30 +0200 Message-ID: <2BF0AD29BC31FE46B78877321144043178B694@trebe003.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MPE, is it necessary? Thread-Index: AcHT/qgLQZWhqU0KRha68mQH33Ko7AAAKByA From: To: X-OriginalArrivalTime: 26 Mar 2002 06:26:31.0418 (UTC) FILETIME=[2B410DA0:01C1D48F] X-ERG-MailScanner: Found to be clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by erg.abdn.ac.uk id g2Q6RC60026588 Gorry: > I'd argue it is inefficient (especially in terms of header processing) Do you have a report on this subject: experimental or simulated evidence? > i want ask him, if i put directly IP packets in MPEG TP, and Do you mean using the "data piping" option of DVB standards? > another thing, can some one tell me how many multicast adress are used > until now? and since when? and how many they will be in the future, in > your opinion? You can start from... http://www.iana.org/assignments/multicast-addresses ...and... http://www.iana.org/assignments/ipv6-multicast-addresses ...where you will find an up-to-date list of official assignments. It is impossible to say how many addresses will be used in future and the use of "link local" and domain administered ranges means that it is non-trivial to get data on the number of addresses used (inc. overlapping/colliding address usage). Best regards, Rod Walsh > -----Original Message----- > From: ext Ghassane Aniba [mailto:Ghassane.Aniba@sophia.inria.fr] > Sent: 25 March, 2002 14:50 > To: ip-dvb@erg.abdn.ac.uk > Subject: MPE, is it necessary? > > > hi, > thanks or G.F for his explanation. > i want ask him, if i put directly IP packets in MPEG TP, and > if i map IP > adress with PID, where can i found a problem? Because with PID, i have > all what i need. > another thing, can some one tell me how many multicast adress are used > until now? and since when? and how many they will be in the future, in > your opinion? > thanks. > > -- > Ghassane ANIBA > INRIA (Projet PLANETE) | Email : > ghassane.aniba@sophia.inria.fr > 2004, Route des Lucioles BP 93 | Phone : +33 4 92 38 75 63 > 06902 Sophia Antipolis CEDEX France| Fax : +33 4 92 38 79 78 > From majordomo-owner@erg.abdn.ac.uk Tue Mar 26 11:17:17 2002 Received: from [128.243.136.125] ([128.243.136.125]) by erg.abdn.ac.uk (8.12.2/8.12.2) with SMTP id g2QBHCOM029469 for ; Tue, 26 Mar 2002 11:17:12 GMT User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Tue, 26 Mar 2002 11:17:33 +0000 Subject: Re: MPE, is it necessary? From: Gorry Fairhurst To: Message-ID: In-Reply-To: <2BF0AD29BC31FE46B78877321144043178B694@trebe003.NOE.Nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-ERG-MailScanner: Found to be clean on 26/3/02 6:26 am, Rod.Walsh@nokia.com at Rod.Walsh@nokia.com wrote: > Gorry: >> I'd argue it is inefficient (especially in terms of header processing) > > Do you have a report on this subject: experimental or simulated evidence? > The ip-dvb site has a copy of a report from Skysteam and the header byte overhead: http://www.erg.abdn.ac.uk/users/gorry/ip-dvb/refs/mpe-ohead.pdf The requirements ID also provides some of the rationale for adopting a more lightweight (fewer header fields) encapsulation: http://search.ietf.org/internet-drafts/draft-fair-ipdvb-req-00.txt >> i want ask him, if i put directly IP packets in MPEG TP, and > > Do you mean using the "data piping" option of DVB standards? The requirements ID calls for a new encapsulation method, which we intend to discuss on this list. So far, I have received input from the University of Saltzburg with one proposed protocol, which could be developed to fit the requirements. This should appear as an ID in early April. Do your requirements for encapsulation differ (or agree) with those expressed in version -00 of the requirements ID? <> Gorry From majordomo-owner@erg.abdn.ac.uk Tue Mar 26 16:18:48 2002 Received: from ladron.cs.nmt.edu (ladron.cs.nmt.edu [129.138.6.58]) by erg.abdn.ac.uk (8.12.2/8.12.2) with SMTP id g2QGIQOM002633 for ; Tue, 26 Mar 2002 16:18:27 GMT Received: from nmttb97i6f89th ([129.138.6.121]) by ladron.cs.nmt.edu (8.11.2/8.11.2) with SMTP id g2QHVW618943 for ; Tue, 26 Mar 2002 10:31:32 -0700 Message-ID: <006101c1d4ea$d69ec650$79068a81@nmttb97i6f89th> Reply-To: "Kearney" From: "Kearney" To: References: Subject: Re: IP -> PES -> MPEG TS? Date: Tue, 26 Mar 2002 09:22:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-ERG-MailScanner: Found to be clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by erg.abdn.ac.uk id g2QGImxU002643 ----- Original Message ----- From: "Gorry Fairhurst" To: Sent: Monday, March 25, 2002 3:21 AM Subject: Re: IP -> PES -> MPEG TS? > This is a useful debate.... You seem to have two contrasting viewpoints, > and both have merits ;-) > > Maybe I am boring most of you with the following explanations and everything that I am going to say is very obvious to you - but let me pontificate a bit about addresses and identifiers. After all Gorr, has suggested we keep this discussion going. on 25/3/02 9:34 am, Patrick Cipiere at Patrick.Cipiere@udcast.com wrote: > For me PID stands at the physical layer correct. But before getting into an argument let´s look at some basic concepts: first of all, what is (the purpose of) a physical-level address ? It is an identification of a channel interface (usually called an adaptor), intended to help the adaptor to decide whether a block/frame/packet arriving over the channel is intended for it i.e. whether to take it off the channel or let pass. You see this clearly when you look at e.g. HDLC or BSC where a master-slave or a peer-peer operation (balanced mode) is possible. The master station can thus "poll" individual stations by setting the proper address bits in the header of the frame and/or in the balanced mode the stations identify the intended partner on the channel this way. This way the "medium access" can be handled in a controlled way. The scope of these identification fields is strictly limited to one link (channel - Ethernet calls this a "segment"). In the not so good old days you had to set dip switches to configure terminals or other stations connected to a particular wire; of course the number of switches was kept low - e.g. 6 or 8 switches = bits was considered sufficient. The minute you leave one link environment (segment), cross through a "forwarding device" to another link environment you need to introduce another level of identification - network level (logical) addresses which identify the device (host, node) attached to the adaptor. Of course the "forwarding device" will have to be informed about the mapping of these network-level addresses of the device to the physical addresses of the adaptor. Along came Ethernet which didn´t use dip switches any more but ICs and, hence could afford to use much longer physical level addresses. This allowed to make these addresses unique by e.g. including the manufacturer id, the date of its production etc etc. At the same time it made a separate network-level identification unneccessary - the 48-bit MAC level addresses of the old Ethernet (and its later derivatives) are a combination of these two identifications and are supposed to be unique. Ethernet was based on a common "bus" with broadcast properties and "forwarding devices" called repeaters. The addresses are "flat" in the sense that they do not contain any topological information which could be used to assist in routing and forwarding. And the whole architecture was based on the broadcast nature of the system - no "routing" was necessary. This changed when link-level bridges ("learning" and "transparent") were invented and all of a sudden the "forwarding devices" had to make forwarding decisions - which are based on the complete 48-bit MAC-level addresses and a learning algorithm. The IEEE 802 standard defines a fairly complex solution to this type of extended LAN. What do we learn from this recollection: network-level addresses and physical level address are two totally separate concepts which should be kept separate and not combined since the functions of routing/forwarding (switching) and interface identification are totally different. But LANs and particularly Ethernet/CSMA-CD (EN), being the most popular network, have made the IEEE 48-bit MAC addresses the most popular examples and almost all people are not aware of the subtle difference of the two addresses involved. Now let´s move on to multicasting and start again with EN: an EN interface operates either in a controlled mode or in promiscuous mode. In the latter it pulls of the channel any frame that comes along and delivers it tho the next level of protocol (the link level); in the controlled mode it filters the blocks and delivers only those where the destination address matches its own address - or the global broadcast address. When multicast was introduced, the MAC-level IEEE addresses were extended to include this functionality by interpreting the most significant bit as the individual/group bit - and the EN network adaptors all of a sudden had to implement a more complex filtering mechanism including a list of multicast addresses. Now the destination address field of every passing frame has to be checked not only against the devices MAC-level address and the broadcast bits but also against a whole list of multicast group addresses - and the number of entries in this list is quite limited. Depending on the processing speed and the data rate, most interfaces can not handle more then just a few simultaneously. Check the manufacturers specs! And finally, back to the MPEG-2 PID: it corresponds to the multicast EN addresses - i.e. the interface uses a (rather limited) list of PIDs it can filter at a time and only TS packets with these PID values are delivered to the next level of protocol. This is all a PID is - it is a physical level multicast asddress and does NOT identify an individual interface - and it also does NOT contain any network-level address information. BTW - the reason why MPE inverts the byte sequence of the MAC level address is that this allows the hardware to filter on the PID and a few bytes of the MAC-level address. > and 13 bits is not enough to map a multicast IP address. the PID is a link-level/MAC-level multicast id - the multicast IP address is a network-level address. You will need some sort of "address resolution" mechanism to bind the two. > I would prefer the ethernet scheme, mapping the IP V4 (or V6) > multicast address on the IEEE 48 bits MAC address (link layer). > IP multicast addresses are 24 bits - PIDs are 13 bits - no way you could use the EN scheme. But don´t forget - your interface might not be capable of discriminating more then -say- 16 or 20 PIDs simultaneously, so a pool of more than 8000 PIDs seems totally adequate. > Gorry wrote: So, let me add some observations myself... > > The PID lets you specify a flow at the subnetwork level. What can/should > we use this for? > > (i) We could use this to tell a multiplexor where to "forward" the > data - if we have a hierarchy of multiplexors connected to several feeds, > we can send some MPEG-2 TS to some feeds, others to only only one feed, > etc. > correct - 13818 introduces the concept of a "remultiplexor" where PIDs are rewritten and also used for forwarding decisions > This is the basis of various schemes suggested/implemented for example > to perform on-board MPEG-2 TS packet switching. (There is some > resemblance to Ethernet switching here). > > > (ii) We can use the PID as the basis for differentiating type of > flows, some PIDs denote video streams, tables, use of encryption, > presentation time stamps, etc. This is a demultiplexing function. > this is exactly what 13818-1 defines - you have a number of tables (PAT and a PMTs) per channel (transponder) specifying which PIDs are being used for which bouquets (services) and there are certainly possibilites to set up an "Internet bouquet" which has its own PMT and each entry in the PMT identifies a multicast group. In this casse you could "listen" to several IP multicast groups. > > (iii) We can use the PID as the first level of filtering at receivers. > Receivers can filter and forward only a selected range of PID values > to the host/router to which they are connected. This CAN reduce receiver > processing. NOTE that the IP layer must still filter as well, but does > not need to see every packet sent over the feed. > yes - and this "selected range" is rather limited - as mentioned above to approx. 10..20, maybe a few more if hardware speeds go up. But there is at least one level of protocol in between the TS-packet level and the IP level - some sort of "adaptation layer" doing encaspsulation fo the IP datgrams - for example PPP or AAL5 or some hybrid form such as PPPoM (PPP over Mpeg-2 - not yet5 invented!). And we could certainly filter also on this level - and also deliver link-level packets to different next-level protocols such as ARP or IP or some other network-level protocol. Actually, if you look at the PES and TableSection headers you will find fiels saying "stream_id" or "table_id" and these are typically fields used for discriminating and filtering on the next level of processing. > Let me stop at this point. Gorry, lets take up your item (iii) when we figured out if we agree so far. To summarize: (1) MAC-level addresses are identifiers for network interfaces and are used by adaptors to decide whether to deliver an incoming frrame to the link-level protocol. (2) PIDs are physical - level multicast group addresses which, of course, can be used for a multicast group of only 2 participants i.e. in a point-to-point mode. (3) IP addresses are network-level entities and ident6ify devices attached to adaptors; thea rea used by nodes for making routing decisions and by hosts for filtering on the nedtwork level. They can be either unicast or multicas addresses and they must be mapped to MAC-level addresses in some way. (4) IP datagrams (and other network layer protocol units) need to be encaspsulated by an adaptation layer before being segmented/reassembled into TS-packets (fixed length "cells"). This level of protocol can introduce yet another level of identification - for example "labels" or "tags" for switching purposes (a la MPLS) or multicast subgroups. (5) Every frame/packet/cell crossing a "segment" will carry a MAC-level address (individual or group) which is interpreted by the adaptors - but not every packet will carry a network-level address since this might have been replaced by a connection identifier (VC/VP_id) in a connection-oriented network. [you might consider using the PID as a VC and the link-level id as the VP] But let's always keep in mind: satellite bandwidth is expensive, and hence all address fields should only be as long as necessary and sufficient. > So (iii) is the point in question... > > Consider a MPEG multiplex feeding a large group of receivers. > I think the MAC address ***is*** useful. It provides per-receiver filters > for unicast (reducing unwanted traffic at the receiver). If you wish to do > multicast support, then you also need to expect IP-level filtering, because > there is not a one-to-one mapping of IP group destination address to MAC > address. I think if we go along this line, we should use a full MAC header - > source, destination & type - with CRC-32. That way, we really do have a > "LAN" in the sky, and can do proper LAN emulation, and support IPv6 as well > as IPv4. > > On the other hand, why not also allow the next generation systems to use > native IP support, without a MAC header? This would require the receiver to > do per-packet IP level filtering, (as an IP router does). If we think > carefully about the structure of the encapsulation, we should be able to > allow (hardware?) processing of the IP address by the interface card - much > the same as MAC addresses are currently processed. This can have several > merits: > (a) If we think about efficiency, we can now have a *VERY* small header per > packet. I'm keen we get this right, if we can. > (b) Some uses of DVB, are simply point-to-point links, or unidirectional > point-to-multipoint links. I'm thinking here of uses by network service > providers providing BGP-style connectivity between networks. Such topologies > do not NEED inidividual terminal subnetwork addresses (MAC) (they can be > "unumbered" IP interfaces at the network level too). > > > Do this two cases capture to the two points of view? > > Are there other topologies / needs out there? > > > > >> Finally - satellite networks behave differently from LANs (two-way, very > >> short delay, cheap bandwidth) and, hence, transferring solutions from the > >> LAN world to MPEG2-S networks is not a reasonable approach. > > > > I do not agree. When you use UDLR (RFC3077) the satellite link behaves > > as a broadcast LAN and you can re-use almost everything from the LAN > > work. > > Yes - in UDLR, you have a good case using MAC addresses with this, but > that's may be not surprising, since it's an Ethernet LAN emulation scheme, > rather than a native IP scheme. > > But there ***are*** other scenarios... > > What happens when we have several feeds in use simultaneously? > > There's also two-way satellite links. > > Satellite links with on-board processing (soonish). > > And, we shouldn't confine this debate to satellite: > > DVB-T has interesting possibilities for IP transport, and may also have an > urgent need to address the issues of multiple feeds carrying the same > multicast groups ( ;-) ). > > > What do you think? > > Gorry Fairhurst > > >