From owner-ip-dvb@erg.abdn.ac.uk Fri Aug 1 04:02:47 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7132Gc4006033 for ; Fri, 1 Aug 2003 04:02:17 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h7132GkX006032 for ip-dvb-subscribed-users; Fri, 1 Aug 2003 04:02:16 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from gw-nl5.philips.com (postfix@gw-nl5.philips.com [212.153.235.109]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7131hc4006013 for ; Fri, 1 Aug 2003 04:01:43 +0100 (BST) Received: from smtpscan-nl3.philips.com (smtpscan-nl3.philips.com [130.139.36.23]) by gw-nl5.philips.com (Postfix) with ESMTP id 0395454ED7 for ; Fri, 1 Aug 2003 05:01:42 +0200 (MET DST) Received: from smtpscan-nl3.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id 6B23F19C48 for ; Fri, 1 Aug 2003 05:01:42 +0200 (MEST) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl3.philips.com (Postfix) with ESMTP id BA59519C4F for ; Fri, 1 Aug 2003 05:01:41 +0200 (MEST) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id FAA01016 for ; Fri, 1 Aug 2003 05:01:41 +0200 (MEST) From: christophe.cadoret@philips.com Subject: Christophe Cadoret/REN/SC/PHILIPS is out of the office. To: ip-dvb@erg.abdn.ac.uk Message-ID: Date: Fri, 1 Aug 2003 05:00:50 +0200 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 01/08/2003 05:02:50 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk I will be out of the office starting 2003-07-28 and will not return until 2003-08-18. For urgent matters please contact Bernard Badefort or Franck Aumont Christophe From owner-ip-dvb@erg.abdn.ac.uk Fri Aug 1 08:50:11 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h717nlc4009703 for ; Fri, 1 Aug 2003 08:49:47 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h717nl7F009702 for ip-dvb-subscribed-users; Fri, 1 Aug 2003 08:49:47 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from sunmail.canal-plus.fr (sunmail.canal-plus.fr [194.2.208.66]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h717nNc4009680 for ; Fri, 1 Aug 2003 08:49:23 +0100 (BST) Received: from antivirus-gw.ctechno.net (servap08 [192.168.240.200]) by sunmail.canal-plus.fr (8.12.9/8.12.9) with ESMTP id h717nJ5q008477 for ; Fri, 1 Aug 2003 09:49:19 +0200 (MET DST) Content-Class: urn:content-classes:message Received: from servap08.ctechno.net ([127.0.0.1]) by antivirus-gw.ctechno.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 1 Aug 2003 09:49:18 +0200 Received: from intranet.canal-plus.fr ([172.20.11.68]) by mail2.ctechno.net with Microsoft SMTPSVC(5.0.2195.5329); Fri, 1 Aug 2003 09:49:18 +0200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Received: from canal-plus.fr ([192.168.243.239]) by intranet.canal-plus.fr (8.11.1/8.11.1) with ESMTP id h717nIx01021 for ; Fri, 1 Aug 2003 09:49:18 +0200 (MET DST) Message-ID: <3F2A1B94.4BCD9F55@canal-plus.fr> Date: Fri, 01 Aug 2003 09:49:40 +0200 From: "Bertrand WENDLING" Organization: CANAL+ Technologies X-Mailer: Mozilla 4.7 [en]C-CCK-MCD C+ (Win98; I) X-Accept-Language: fr,en MIME-Version: 1.0 To: Subject: Re: AW: About dest MAC@ References: <3141ED5F60D45E4BA847F18B2DFD92A801258372@exchange.iabg.de> Content-Type: multipart/mixed; boundary="------------14E5480F3EA7029AA7FBEA7E" X-OriginalArrivalTime: 01 Aug 2003 07:49:18.0465 (UTC) FILETIME=[697F0710:01C35801] X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk This is a multi-part message in MIME format. --------------14E5480F3EA7029AA7FBEA7E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Wolfgang, I thank you very much for your explanation, and I have some additional = questions to make sure I fully understand you explanation : The example is based on small ISP's feeding their network over satellite = link from a large teleport. For me, the link between the teleport and = the small ISP looks like a B to B link allowing then the small ISP to = provide B to C access to local customers. My question, is now the = following : why would a teleport service to ISP providers use MPEG2 - = DVB protocols (mostly designed for DTH TV services) for that B to B pure = data link ? I assume that this kind of data transmission is already = used since years over dedicated telecom satellites with other more = suited protocols ? This especially when your scenario requires a = bi-directional and permanent satellite link ? What do you think ? Bertrand > assume the following example operational scenario: > > A teleport service provider provides broadband Internet access via = DVB-S to smaller ISPs located in regions without terrestrial broadband = access. This teleport provider serves more customer on the same = transponder. It assigns to each of them a global routable IP address = space. Receiving traffic from the Internet destined to one of its = customer's IP address space the teleport service provider will broadcast = the traffic on the DVB-S link. As this link is shared by more customer, = the traffic "physically" will be received by all of them. In order to = allow efficient filtering, the teleport provider uses a specific PID for = each customer as well as the MAC address of the customer's receiving = equipment. This scenario could also include a "kind of manually = configured and therefore static address resolution" (mapping of = customer's IP address space to customer's PID / MAC address). Doing = things like address resolution automatically is somewhat difficult if = we're talking about uni-direc! > tional links. > > However this example operational scenario reflect many aspects Alain = and Gorry discussed: > > - The connected minor ISP could use the teleport service provider as = the only external access (leaf network with single access point) > - The connected minor ISP could use also other teleport service = providers / peering ISPs but do not transit traffic between them (leaf = network with several access points) > - The connected minor ISP could use also other teleport service = providers / peering ISPs and do transit traffic between them (transit = network with several access points) > > What I do not see so far as a common operational scenario is that one = customer will receive for its IP address range traffic via several = access router connected to the same DVB-S transponder. But also this = could change in future if IPv6 brings more possibilities for multihoming = and network renumbering. > > Cheers, > > Wolfgang > > > > > > > Dear Alain, dear Gorry, > > I am a little puzzled by this discussion, you should not > > forget that in a broadcast world (meaning DVB-MPEG2), it is > > very uncommon for the broadcaster to know the MAC and even > > the IP address of a receiver (today nearly all of them don't > > even have one). Receivers are bought in any kind of retail > > shop and are plug and play when connected to a dish. In a > > broadcast mode the only thing you need to know on the > > receiver side is what IP service I have to listen to in order > > to get access the expected service (the IP address is here > > used as another filtering criteria to extract the relevant IP > > sections in an IP stream). Regarding the broadcast technology > > (still meaning DVB-MPEG2), except for specific B to B > > application, it is uncommon to do unicast, just because of > > the cost of the bandwidth. Now, the interesting point is when > > a receiver have a broadcast access (e.g. a dish to get the > > MPEG2 signal), and a DSL access. In this case, the receiver > > will work in the same way as a PC connected to the DSL > > network, but might access data from both network (the MPEG 2 > > and the DSL one) for various application where two streams > > may be needed (the common one broadcasted, and the user > > specific one streamed over DSL). Now, assume that in case the > > broadcaster wants to send data to a specific user over the > > DVB-MPEG2 network, based on a request coming through the DSL > > network (back channel), he will have to give the receiver the > > DVB triplet (to locate the TS and PID) and an IP address to > > filter on. In any case, the only way the receiver can be > > known by the broadcaster is when he has a return channel > > (e.g. a DSL connection, and then, the IP address is allocated > > by the ISP). Could you perhaps explain a little more the > > concrete scenarios and operational configurations you have in > > mind ? Best regards Bertrand > > > > Dr G Fairhurst wrote: > > > > > alain.ritoux@6wind.com wrote: > > > > > > > > Dr G Fairhurst wrote: > > > > > > > > > > > > > >>- If the IRD is itself a router, there is still the > > case (that may > > > > >>be of (most?) common usage ??) that the network behind it is a > > > > >>leaf-network, and by no mean a transit network. > > > > > > > > > > > > > > > OK, so specifically you mean a leaf network where routing > > > > > protocols are not used to determine forwarding to the "leaf" > > > > > network. One example is a network with one external receive > > > > > interface (via the MPEG-2 port). > > > > > > > > Not exactly, in fact, the "leaf" network I had in mind could = have > > > > several point of access (i.e CPE), but does NOT provide transit, > > > > hence only packets destined to the "leaf" network should be > > > > accepted. > > > > > > > > > > OK, but what happens whene there are several places (networks) via > > > which the "leaf: network may receive an Ip packet? > > > - routers normally advertise that a site is reachable > > > via an interface. Do routers do this on each network to > > which they are > > > attached? > > > > > > If so, how do the routers connected to the MPEG-2 feed know > > whether to > > > forward the packet from the MPEG-2 feed via the other network(s) = to > > > the destination end host, or to discard this packet because = someone > > > else will be forwarding? - This is usually the function of the IP > > > routing protocol in combination with the link MAC address. > > > > > > In the case of just one receive interface, the above point is = moot, > > > and we don't have the same routing issues. > > > > > > > > > > > > > That is, theer are no alternative delivery paths, and > > therefore no > > > > > reachability via other routers that may also receive > > the packet. > > > > > Specifically you must also require all other routers to > > silently > > > > > drop packets with an unreachable network address. If you do = all > > > > > this, I agree - but although this would work, it seems > > a "tweak", > > > > > and I'm not sure the latter > > > > I admit this is tweaky, and I'm not definitly proud of it ;-) > > > > > > > > > is a robust recommendation (if one router returns an > > ICMP message > > > > > to the source, what happens??) > > > > Well, the source is informed that dest is unreachable, > > and may stop. > > > > So indeed, it works only when ALL routers perform the same = trick, > > > > which is somehow fragile I admit. > > > > > > > > > > Ok, so, you can do it this way if you have an operational need, = but > > > it's probably not a recommended solution. > > > > > > > > > > > > > My thoughts are that we have some cases here that can use IP > > > > > packets without MAC addresses, providing: > > > > > > > > > > (a) they can efficiently filter on IP level addresses > > > > > > > > > > AND > > > > > > > > > > (b) If they are routers they MUST also differentiate > > packets with > > > > > a MAC dest address from those without a MAC address, and MUST > > > > > discard packets with no MAC address that do not correspond to > > > > > their own IP address (or with all the rules above to the = prefix > > > > > used for hosts on a leaf IP network.) > > > > > > > Definitely agree, the trick was only for the case where > > there's no > > > > MAC addr. Of course, if there is a MAC addr, is MUST be used to > > > > reject or accept packets whatever their dst IP addr is. > > > > > > > > Alain. > > > > -- > > > > Alain RITOUX > > > > Tel +33-1-39-30-92-32 > > > > Fax +33-1-39-30-92-11 > > > > visit our web http://www.6wind.com > > > > -- > > This message and any attachments (the "message") is intended > > solely for the addressees and is confidential. If you receive > > this message in error, please delete it and immediately > > notify the sender. Any use not in accordance with its > > purpose, any dissemination or disclosure, either whole or > > partial, is prohibited except formal approval. The E-Mail > > transmission can not guarantee the integrity of this message. > > CANAL+TECHNOLOGIES will not therefore be liable for the message if > > CANAL+modified. > > > > > > -- This message and any attachments (the "message") is intended solely for = the addressees and is confidential. If you receive this message in error, = please delete it and immediately notify the sender. Any use not in accordance with its purpose, any dissemination or = disclosure, either whole or partial, is prohibited except formal approval. The E-Mail transmission can not guarantee the integrity of this message. CANAL+TECHNOLOGIES will not therefore be liable for the message if = modified. --------------14E5480F3EA7029AA7FBEA7E Content-Type: text/x-vcard; charset="us-ascii"; name="wendling.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Bertrand WENDLING Content-Disposition: attachment; filename="wendling.vcf" begin:vcard n:Bertrand;WENDLING tel;cell:+33 6 03 45 86 54 tel;fax:+33 1 71 71 50 51 tel;work:+33 1 71 71 53 57 x-mozilla-html:TRUE url:www.canalplus-technologies.com org:CANAL+ Technologies;Advanced Studies & Standardisation Department adr:;;34 place Raoul Dautry;75738 PARIS Cedex 15;;;France version:2.1 email;internet:wendling@canal-plus.fr title:Standards Officer fn:WENDLING Bertrand end:vcard --------------14E5480F3EA7029AA7FBEA7E-- From owner-ip-dvb@erg.abdn.ac.uk Fri Aug 1 10:43:21 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h719gRc4011567 for ; Fri, 1 Aug 2003 10:42:27 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h719gQwi011565 for ip-dvb-subscribed-users; Fri, 1 Aug 2003 10:42:27 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from mail1.iabg.de (mail1.iabg.de [194.139.245.9]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h719fic4011528 for ; Fri, 1 Aug 2003 10:41:44 +0100 (BST) Received: from mail1.iabg.de (localhost [127.0.0.1]) by localhost (Mailserver IABG) with ESMTP id 559A46C91 for ; Fri, 1 Aug 2003 11:41:39 +0200 (CEST) Received: from exchange.iabg.de (exchange.iabg.de [10.128.200.12]) by mail1.iabg.de (Mailserver IABG) with ESMTP id 4088E6BE7 for ; Fri, 1 Aug 2003 11:41:39 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: AW: AW: About dest MAC@ Date: Fri, 1 Aug 2003 11:41:40 +0200 Message-ID: <3141ED5F60D45E4BA847F18B2DFD92A801258373@exchange.iabg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: About dest MAC@ Thread-Index: AcNYBRBG1ZB/MsqOSZWWpf8y1j+8ewACwHEA From: "Fritsche Wolfgang" To: X-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 h719gLm3011558 Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Bertrand, one reason for using DVB-S are the costs of equipment, which is extremly cheap on the receiver side. Of course it is only cheap if DVB-S is used in an uni-directional way, that is the uplink happens in an other way, e.g. SCPC, narrow-band Internet, PSTN, ... Anyhow, these scenarios exist, and they will be affected by the address resolution / filtering issues Gorry and Alain discussed on this list. Wolfgang > > > Dear Wolfgang, > I thank you very much for your explanation, and I have some > additional questions to make sure I fully understand you > explanation : The example is based on small ISP's feeding > their network over satellite link from a large teleport. For > me, the link between the teleport and the small ISP looks > like a B to B link allowing then the small ISP to provide B > to C access to local customers. My question, is now the > following : why would a teleport service to ISP providers use > MPEG2 - DVB protocols (mostly designed for DTH TV services) > for that B to B pure data link ? I assume that this kind of > data transmission is already used since years over dedicated > telecom satellites with other more suited protocols ? This > especially when your scenario requires a bi-directional and > permanent satellite link ? What do you think ? Bertrand > > > assume the following example operational scenario: > > > > A teleport service provider provides broadband Internet access via > > DVB-S to smaller ISPs located in regions without > terrestrial broadband > > access. This teleport provider serves more customer on the same > > transponder. It assigns to each of them a global routable > IP address > > space. Receiving traffic from the Internet destined to one of its > > customer's IP address space the teleport service provider will > > broadcast the traffic on the DVB-S link. As this link is shared by > > more customer, the traffic "physically" will be received by all of > > them. In order to allow efficient filtering, the teleport provider > > uses a specific PID for each customer as well as the MAC address of > > the customer's receiving equipment. This scenario could > also include a > > "kind of manually configured and therefore static address > resolution" > > (mapping of customer's IP address space to customer's PID / MAC > > address). Doing things like address resolution automatically is > > somewhat difficult if we're talking about uni-direc! tional links. > > > > However this example operational scenario reflect many > aspects Alain > > and Gorry discussed: > > > > - The connected minor ISP could use the teleport service > provider as > > the only external access (leaf network with single access point) > > - The connected minor ISP could use also other teleport > service providers / peering ISPs but do not transit traffic > between them (leaf network with several access points) > > - The connected minor ISP could use also other teleport > service providers / peering ISPs and do transit traffic > between them (transit network with several access points) > > > > What I do not see so far as a common operational scenario > is that one > > customer will receive for its IP address range traffic via several > > access router connected to the same DVB-S transponder. But > also this > > could change in future if IPv6 brings more possibilities for > > multihoming and network renumbering. > > > > Cheers, > > > > Wolfgang > > > > > > > > > > > Dear Alain, dear Gorry, > > > I am a little puzzled by this discussion, you should not > forget that > > > in a broadcast world (meaning DVB-MPEG2), it is very uncommon for > > > the broadcaster to know the MAC and even the IP address of a > > > receiver (today nearly all of them don't even have one). > Receivers > > > are bought in any kind of retail shop and are plug and play when > > > connected to a dish. In a broadcast mode the only thing > you need to > > > know on the receiver side is what IP service I have to > listen to in > > > order to get access the expected service (the IP address is here > > > used as another filtering criteria to extract the relevant IP > > > sections in an IP stream). Regarding the broadcast technology > > > (still meaning DVB-MPEG2), except for specific B to B > > > application, it is uncommon to do unicast, just because of > > > the cost of the bandwidth. Now, the interesting point is when > > > a receiver have a broadcast access (e.g. a dish to get the > > > MPEG2 signal), and a DSL access. In this case, the receiver > > > will work in the same way as a PC connected to the DSL > > > network, but might access data from both network (the MPEG 2 > > > and the DSL one) for various application where two streams > > > may be needed (the common one broadcasted, and the user > > > specific one streamed over DSL). Now, assume that in case the > > > broadcaster wants to send data to a specific user over the > > > DVB-MPEG2 network, based on a request coming through the DSL > > > network (back channel), he will have to give the receiver the > > > DVB triplet (to locate the TS and PID) and an IP address to > > > filter on. In any case, the only way the receiver can be > > > known by the broadcaster is when he has a return channel > > > (e.g. a DSL connection, and then, the IP address is allocated > > > by the ISP). Could you perhaps explain a little more the > > > concrete scenarios and operational configurations you have in > > > mind ? Best regards Bertrand > > > > > > Dr G Fairhurst wrote: > > > > > > > alain.ritoux@6wind.com wrote: > > > > > > > > > > Dr G Fairhurst wrote: > > > > > > > > > > > > > > > > >>- If the IRD is itself a router, there is still the > > > case (that may > > > > > >>be of (most?) common usage ??) that the network > behind it is a > > > > > >>leaf-network, and by no mean a transit network. > > > > > > > > > > > > > > > > > > OK, so specifically you mean a leaf network where routing > > > > > > protocols are not used to determine forwarding to > the "leaf" > > > > > > network. One example is a network with one external receive > > > > > > interface (via the MPEG-2 port). > > > > > > > > > > Not exactly, in fact, the "leaf" network I had in mind could > > > > > have several point of access (i.e CPE), but does NOT provide > > > > > transit, hence only packets destined to the "leaf" network > > > > > should be accepted. > > > > > > > > > > > > > OK, but what happens whene there are several places > (networks) via > > > > which the "leaf: network may receive an Ip packet? > > > > - routers normally advertise that a site is reachable > > > > via an interface. Do routers do this on each network to > > > which they are > > > > attached? > > > > > > > > If so, how do the routers connected to the MPEG-2 feed know > > > whether to > > > > forward the packet from the MPEG-2 feed via the other > network(s) > > > > to the destination end host, or to discard this packet because > > > > someone else will be forwarding? - This is usually the > function of > > > > the IP routing protocol in combination with the link > MAC address. > > > > > > > > In the case of just one receive interface, the above point is > > > > moot, and we don't have the same routing issues. > > > > > > > > > > > > > > > > That is, theer are no alternative delivery paths, and > > > therefore no > > > > > > reachability via other routers that may also receive > > > the packet. > > > > > > Specifically you must also require all other routers to > > > silently > > > > > > drop packets with an unreachable network address. If you do > > > > > > all this, I agree - but although this would work, it seems > > > a "tweak", > > > > > > and I'm not sure the latter > > > > > I admit this is tweaky, and I'm not definitly proud of it ;-) > > > > > > > > > > > is a robust recommendation (if one router returns an > > > ICMP message > > > > > > to the source, what happens??) > > > > > Well, the source is informed that dest is unreachable, > > > and may stop. > > > > > So indeed, it works only when ALL routers perform the same > > > > > trick, which is somehow fragile I admit. > > > > > > > > > > > > > Ok, so, you can do it this way if you have an operational need, > > > > but it's probably not a recommended solution. > > > > > > > > > > > > > > > > My thoughts are that we have some cases here that > can use IP > > > > > > packets without MAC addresses, providing: > > > > > > > > > > > > (a) they can efficiently filter on IP level addresses > > > > > > > > > > > > AND > > > > > > > > > > > > (b) If they are routers they MUST also differentiate > > > packets with > > > > > > a MAC dest address from those without a MAC > address, and MUST > > > > > > discard packets with no MAC address that do not > correspond to > > > > > > their own IP address (or with all the rules above to the > > > > > > prefix used for hosts on a leaf IP network.) > > > > > > > > > Definitely agree, the trick was only for the case where > > > there's no > > > > > MAC addr. Of course, if there is a MAC addr, is MUST > be used to > > > > > reject or accept packets whatever their dst IP addr is. > > > > > > > > > > Alain. > > > > > -- > > > > > Alain RITOUX > > > > > Tel +33-1-39-30-92-32 > > > > > Fax +33-1-39-30-92-11 > > > > > visit our web http://www.6wind.com > > > > > > -- > > > This message and any attachments (the "message") is > intended solely > > > for the addressees and is confidential. If you receive > this message > > > in error, please delete it and immediately notify the sender. Any > > > use not in accordance with its purpose, any dissemination or > > > disclosure, either whole or partial, is prohibited except formal > > > approval. The E-Mail transmission can not guarantee the > integrity of > > > this message. > > > CANAL+TECHNOLOGIES will not therefore be liable for the > message if > > > CANAL+modified. > > > > > > > > > > > -- > This message and any attachments (the "message") is intended > solely for the addressees and is confidential. If you receive > this message in error, please delete it and immediately > notify the sender. Any use not in accordance with its > purpose, any dissemination or disclosure, either whole or > partial, is prohibited except formal approval. The E-Mail > transmission can not guarantee the integrity of this message. > CANAL+TECHNOLOGIES will not therefore be liable for the message if > CANAL+modified. > > > From owner-ip-dvb@erg.abdn.ac.uk Fri Aug 1 11:44:57 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h71Aiac4012959 for ; Fri, 1 Aug 2003 11:44:36 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h71Aiar6012958 for ip-dvb-subscribed-users; Fri, 1 Aug 2003 11:44:36 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from sunmail.canal-plus.fr (sunmail.canal-plus.fr [194.2.208.66]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h71AiDc4012937 for ; Fri, 1 Aug 2003 11:44:14 +0100 (BST) Received: from antivirus-gw.ctechno.net (servap08 [192.168.240.200]) by sunmail.canal-plus.fr (8.12.9/8.12.9) with ESMTP id h71AiA5q011730 for ; Fri, 1 Aug 2003 12:44:10 +0200 (MET DST) Content-Class: urn:content-classes:message Received: from servap08.ctechno.net ([127.0.0.1]) by antivirus-gw.ctechno.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 1 Aug 2003 12:44:09 +0200 Received: from intranet.canal-plus.fr ([172.20.11.68]) by mail1.ctechno.net with Microsoft SMTPSVC(5.0.2195.5329); Fri, 1 Aug 2003 12:44:08 +0200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Received: from canal-plus.fr ([192.168.243.239]) by intranet.canal-plus.fr (8.11.1/8.11.1) with ESMTP id h71Ai8x06081 for ; Fri, 1 Aug 2003 12:44:08 +0200 (MET DST) Message-ID: <3F2A448D.B29F73F6@canal-plus.fr> Date: Fri, 01 Aug 2003 12:44:30 +0200 From: "Bertrand WENDLING" Organization: CANAL+ Technologies X-Mailer: Mozilla 4.7 [en]C-CCK-MCD C+ (Win98; I) X-Accept-Language: fr,en MIME-Version: 1.0 To: Subject: Re: AW: AW: About dest MAC@ References: <3141ED5F60D45E4BA847F18B2DFD92A801258373@exchange.iabg.de> Content-Type: multipart/mixed; boundary="------------A546C2DA785BD9364A6AAFAB" X-OriginalArrivalTime: 01 Aug 2003 10:44:08.0907 (UTC) FILETIME=[D64971B0:01C35819] X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk This is a multi-part message in MIME format. --------------A546C2DA785BD9364A6AAFAB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ok, I have a better understanding on the application you have in mind. = Just two remarks for information (again), usual DVB receiver are = effectively cheap, but can handle only a limited bitrate dedicated to = data streams (usually 2 Mbits/s max), DVB receivers are designed in a way the audio and video stream are processed in a specific = and dedicated way at high bitrate where data are demuxed and filtered in = a much less efficient way introducing this kind of limitation. When speaking about uplink over SCPC, PSTN etc... You may have to take = into account the fact that this asymmetric way of processing is used = also at the server uplink side regarding the size of the data to be send = (for large amount of data, the satellite like is used, for small ones, the PSTN, narrow band internet return channel is = used. This to avoid the satellite transmission delay for small amount of = data as well as to make the best use of the bandwidth / transmission = cost between satellite / PSNT..... Bertrand Fritsche Wolfgang wrote: > Bertrand, > > one reason for using DVB-S are the costs of equipment, which is = extremly cheap on the receiver side. Of course it is only cheap if DVB-S = is used in an uni-directional way, that is the uplink happens in an = other way, e.g. SCPC, narrow-band Internet, PSTN, ... > > Anyhow, these scenarios exist, and they will be affected by the = address resolution / filtering issues Gorry and Alain discussed on this = list. > > Wolfgang > > > > > > > Dear Wolfgang, > > I thank you very much for your explanation, and I have some > > additional questions to make sure I fully understand you > > explanation : The example is based on small ISP's feeding > > their network over satellite link from a large teleport. For > > me, the link between the teleport and the small ISP looks > > like a B to B link allowing then the small ISP to provide B > > to C access to local customers. My question, is now the > > following : why would a teleport service to ISP providers use > > MPEG2 - DVB protocols (mostly designed for DTH TV services) > > for that B to B pure data link ? I assume that this kind of > > data transmission is already used since years over dedicated > > telecom satellites with other more suited protocols ? This > > especially when your scenario requires a bi-directional and > > permanent satellite link ? What do you think ? Bertrand > > > > > assume the following example operational scenario: > > > > > > A teleport service provider provides broadband Internet access via > > > DVB-S to smaller ISPs located in regions without > > terrestrial broadband > > > access. This teleport provider serves more customer on the same > > > transponder. It assigns to each of them a global routable > > IP address > > > space. Receiving traffic from the Internet destined to one of its > > > customer's IP address space the teleport service provider will > > > broadcast the traffic on the DVB-S link. As this link is shared by > > > more customer, the traffic "physically" will be received by all of > > > them. In order to allow efficient filtering, the teleport provider > > > uses a specific PID for each customer as well as the MAC address = of > > > the customer's receiving equipment. This scenario could > > also include a > > > "kind of manually configured and therefore static address > > resolution" > > > (mapping of customer's IP address space to customer's PID / MAC > > > address). Doing things like address resolution automatically is > > > somewhat difficult if we're talking about uni-direc! tional = links. > > > > > > However this example operational scenario reflect many > > aspects Alain > > > and Gorry discussed: > > > > > > - The connected minor ISP could use the teleport service > > provider as > > > the only external access (leaf network with single access point) > > > - The connected minor ISP could use also other teleport > > service providers / peering ISPs but do not transit traffic > > between them (leaf network with several access points) > > > - The connected minor ISP could use also other teleport > > service providers / peering ISPs and do transit traffic > > between them (transit network with several access points) > > > > > > What I do not see so far as a common operational scenario > > is that one > > > customer will receive for its IP address range traffic via several > > > access router connected to the same DVB-S transponder. But > > also this > > > could change in future if IPv6 brings more possibilities for > > > multihoming and network renumbering. > > > > > > Cheers, > > > > > > Wolfgang > > > > > > > > > > > > > > > Dear Alain, dear Gorry, > > > > I am a little puzzled by this discussion, you should not > > forget that > > > > in a broadcast world (meaning DVB-MPEG2), it is very uncommon = for > > > > the broadcaster to know the MAC and even the IP address of a > > > > receiver (today nearly all of them don't even have one). > > Receivers > > > > are bought in any kind of retail shop and are plug and play when > > > > connected to a dish. In a broadcast mode the only thing > > you need to > > > > know on the receiver side is what IP service I have to > > listen to in > > > > order to get access the expected service (the IP address is here > > > > used as another filtering criteria to extract the relevant IP > > > > sections in an IP stream). Regarding the broadcast technology > > > > (still meaning DVB-MPEG2), except for specific B to B > > > > application, it is uncommon to do unicast, just because of > > > > the cost of the bandwidth. Now, the interesting point is when > > > > a receiver have a broadcast access (e.g. a dish to get the > > > > MPEG2 signal), and a DSL access. In this case, the receiver > > > > will work in the same way as a PC connected to the DSL > > > > network, but might access data from both network (the MPEG 2 > > > > and the DSL one) for various application where two streams > > > > may be needed (the common one broadcasted, and the user > > > > specific one streamed over DSL). Now, assume that in case the > > > > broadcaster wants to send data to a specific user over the > > > > DVB-MPEG2 network, based on a request coming through the DSL > > > > network (back channel), he will have to give the receiver the > > > > DVB triplet (to locate the TS and PID) and an IP address to > > > > filter on. In any case, the only way the receiver can be > > > > known by the broadcaster is when he has a return channel > > > > (e.g. a DSL connection, and then, the IP address is allocated > > > > by the ISP). Could you perhaps explain a little more the > > > > concrete scenarios and operational configurations you have in > > > > mind ? Best regards Bertrand > > > > > > > > Dr G Fairhurst wrote: > > > > > > > > > alain.ritoux@6wind.com wrote: > > > > > > > > > > > > Dr G Fairhurst wrote: > > > > > > > > > > > > > > > > > > > >>- If the IRD is itself a router, there is still the > > > > case (that may > > > > > > >>be of (most?) common usage ??) that the network > > behind it is a > > > > > > >>leaf-network, and by no mean a transit network. > > > > > > > > > > > > > > > > > > > > > OK, so specifically you mean a leaf network where routing > > > > > > > protocols are not used to determine forwarding to > > the "leaf" > > > > > > > network. One example is a network with one external = receive > > > > > > > interface (via the MPEG-2 port). > > > > > > > > > > > > Not exactly, in fact, the "leaf" network I had in mind could > > > > > > have several point of access (i.e CPE), but does NOT provide > > > > > > transit, hence only packets destined to the "leaf" network > > > > > > should be accepted. > > > > > > > > > > > > > > > > OK, but what happens whene there are several places > > (networks) via > > > > > which the "leaf: network may receive an Ip packet? > > > > > - routers normally advertise that a site is reachable > > > > > via an interface. Do routers do this on each network to > > > > which they are > > > > > attached? > > > > > > > > > > If so, how do the routers connected to the MPEG-2 feed know > > > > whether to > > > > > forward the packet from the MPEG-2 feed via the other > > network(s) > > > > > to the destination end host, or to discard this packet because > > > > > someone else will be forwarding? - This is usually the > > function of > > > > > the IP routing protocol in combination with the link > > MAC address. > > > > > > > > > > In the case of just one receive interface, the above point is > > > > > moot, and we don't have the same routing issues. > > > > > > > > > > > > > > > > > > > That is, theer are no alternative delivery paths, and > > > > therefore no > > > > > > > reachability via other routers that may also receive > > > > the packet. > > > > > > > Specifically you must also require all other routers to > > > > silently > > > > > > > drop packets with an unreachable network address. If you = do > > > > > > > all this, I agree - but although this would work, it seems > > > > a "tweak", > > > > > > > and I'm not sure the latter > > > > > > I admit this is tweaky, and I'm not definitly proud of it = ;-) > > > > > > > > > > > > > is a robust recommendation (if one router returns an > > > > ICMP message > > > > > > > to the source, what happens??) > > > > > > Well, the source is informed that dest is unreachable, > > > > and may stop. > > > > > > So indeed, it works only when ALL routers perform the same > > > > > > trick, which is somehow fragile I admit. > > > > > > > > > > > > > > > > Ok, so, you can do it this way if you have an operational = need, > > > > > but it's probably not a recommended solution. > > > > > > > > > > > > > > > > > > > My thoughts are that we have some cases here that > > can use IP > > > > > > > packets without MAC addresses, providing: > > > > > > > > > > > > > > (a) they can efficiently filter on IP level addresses > > > > > > > > > > > > > > AND > > > > > > > > > > > > > > (b) If they are routers they MUST also differentiate > > > > packets with > > > > > > > a MAC dest address from those without a MAC > > address, and MUST > > > > > > > discard packets with no MAC address that do not > > correspond to > > > > > > > their own IP address (or with all the rules above to the > > > > > > > prefix used for hosts on a leaf IP network.) > > > > > > > > > > > Definitely agree, the trick was only for the case where > > > > there's no > > > > > > MAC addr. Of course, if there is a MAC addr, is MUST > > be used to > > > > > > reject or accept packets whatever their dst IP addr is. > > > > > > > > > > > > Alain. > > > > > > -- > > > > > > Alain RITOUX > > > > > > Tel +33-1-39-30-92-32 > > > > > > Fax +33-1-39-30-92-11 > > > > > > visit our web http://www.6wind.com > > > > > > > > -- > > > > This message and any attachments (the "message") is > > intended solely > > > > for the addressees and is confidential. If you receive > > this message > > > > in error, please delete it and immediately notify the sender. = Any > > > > use not in accordance with its purpose, any dissemination or > > > > disclosure, either whole or partial, is prohibited except formal > > > > approval. The E-Mail transmission can not guarantee the > > integrity of > > > > this message. > > > > CANAL+TECHNOLOGIES will not therefore be liable for the > > message if > > > > CANAL+modified. > > > > > > > > > > > > > > > > -- > > This message and any attachments (the "message") is intended > > solely for the addressees and is confidential. If you receive > > this message in error, please delete it and immediately > > notify the sender. Any use not in accordance with its > > purpose, any dissemination or disclosure, either whole or > > partial, is prohibited except formal approval. The E-Mail > > transmission can not guarantee the integrity of this message. > > CANAL+TECHNOLOGIES will not therefore be liable for the message if > > CANAL+modified. > > > > > > -- This message and any attachments (the "message") is intended solely for = the addressees and is confidential. If you receive this message in error, = please delete it and immediately notify the sender. Any use not in accordance with its purpose, any dissemination or = disclosure, either whole or partial, is prohibited except formal approval. The E-Mail transmission can not guarantee the integrity of this message. CANAL+TECHNOLOGIES will not therefore be liable for the message if = modified. --------------A546C2DA785BD9364A6AAFAB Content-Type: text/x-vcard; charset="us-ascii"; name="wendling.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Bertrand WENDLING Content-Disposition: attachment; filename="wendling.vcf" begin:vcard n:Bertrand;WENDLING tel;cell:+33 6 03 45 86 54 tel;fax:+33 1 71 71 50 51 tel;work:+33 1 71 71 53 57 x-mozilla-html:TRUE url:www.canalplus-technologies.com org:CANAL+ Technologies;Advanced Studies & Standardisation Department adr:;;34 place Raoul Dautry;75738 PARIS Cedex 15;;;France version:2.1 email;internet:wendling@canal-plus.fr title:Standards Officer fn:WENDLING Bertrand end:vcard --------------A546C2DA785BD9364A6AAFAB-- From owner-ip-dvb@erg.abdn.ac.uk Fri Aug 1 12:04:15 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h71B3uc4013278 for ; Fri, 1 Aug 2003 12:03:56 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h71B3tlF013277 for ip-dvb-subscribed-users; Fri, 1 Aug 2003 12:03:55 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from proxy.6wind.com (proxy.6wind.com [194.250.197.211]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h71B3Xc4013261 for ; Fri, 1 Aug 2003 12:03:34 +0100 (BST) Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id 628833B3 for ; Fri, 1 Aug 2003 13:03:36 +0200 (CEST) Received: from 6wind.com (vouvray.dev.6wind.com [10.16.0.135]) by intranet.6wind.com (Postfix) with ESMTP id 872F06E8; Fri, 1 Aug 2003 13:03:36 +0200 (CEST) Message-ID: <3F2A49C6.4060809@6wind.com> Date: Fri, 01 Aug 2003 13:06:46 +0200 From: alain.ritoux@6wind.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: Encaps methode : some examples X-Enigmail-Version: 0.71.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit To: undisclosed-recipients: ; X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Hi all, About en enc-method, and some previous questions about - AF pointer - 4-bytes alignment stuff I made the following assumptions : - 4-bytes alignement is to be enforced for SNDU start - AF pointer value 1 means that the next SNDU starts immedialtly after AF (same calcul as in the ule-method for payload pointer) So I draw some example that I hope will help clarify, and should cover all possible nasty cases. Could you please check them and tell me if anything is wrong ? Those examples could then (if correct !) be incorporated in the draft, in some annexe. Regards. Alain. In the following HDR means MPEG header, and is followed by the PUSI, AFC values. 1st case, simple just to show AF/PUSI usage and values ======================================================== SNDU A is 200 bytes long SNDU B is 200 bytes long +-----+------+------+- -+------+ | HDR | A000 | A001 | ... | A183 | +-----+------+------+- -+------+ PUSI = 1 AFC = 01 <== Adapt Field ==> +-----+----+----+----+----+------+- -+------+------+- -+------+ | HDR |0x03|0x02|0x01|0x11| A184 | ... | A199 | B000 | ... | B163 | +-----+----+----+----+---*+------+- -+------+*-----+- -+------+ PUSI = 1 * * AFC = 11 *********************** AF.ptr = 17 <--- 144 ---> <== Adapt Field ==> stuffing bytes +-----+----+----+----+----+------+- -+------+----+- -+----+ | HDR |0x03|0x02|0x01|0x00| B164 | ... | B199 |0xff| ... |0xff| +-----+----+----+----+---*+------+- -+------+----+- -+----+ PUSI = 0 * AFC = 11 ***// AF.ptr = 0 (no next SNDU) 2nd case, AF size pb ===================== SNDU A is 200 bytes long SNDU B is 346 bytes long +-----+------+------+- -+------+ | HDR | A000 | A001 | ... | A183 | +-----+------+------+- -+------+ PUSI = 1 AFC = 01 <== Adapt Field ==> +-----+----+----+----+----+------+- -+------+------+- -+------+ | HDR |0x03|0x02|0x01|0x11| A184 | ... | A199 | B000 | ... | B163 | +-----+----+----+----+---*+------+- -+------+*-----+- -+------+ PUSI = 1 * * AFC = 11 *********************** AF.ptr = 17 <-- 2 --> stuffing bytes +-----+------+- -+------+----+----+ | HDR | B164 | ... | B345 |0xff|0xff| +-----+------+- -+------+----+----+ PUSI = 0 AFC = 01 : no AF, because not enough room letf for it. 3rd case : alignement stuff ============================ SNDU A is 199 bytes long SNDU B is 200 bytes long +-----+------+------+- -+------+ | HDR | A000 | A001 | ... | A183 | +-----+------+------+- -+------+ PUSI = 1 AFC = 01 padding byte to keep 4-bytes alignement <== Adapt Field ==> | +-----+----+----+----+----+------+- -+------+--v-+------+- -+------+ | HDR |0x03|0x02|0x01|0x11| A184 | ... | A198 |0xff| B000 | ... | B163 | +-----+----+----+----+---*+------+- -+------+----+*-----+- -+------+ PUSI = 1 * * AFC = 11 **************************** AF.ptr = 17 : points to the next "aligned" SNDU <--- 144 ---> <== Adapt Field ==> stuffing bytes +-----+----+----+----+----+------+- -+------+----+- -+----+ | HDR |0x03|0x02|0x01|0x00| B164 | ... | B199 |0xff| ... |0xff| +-----+----+----+----+---*+------+- -+------+----+- -+----+ PUSI = 0 * AFC = 11 ***// AF.ptr = 0 (no next SNDU) 4th case : small packets ========================== SNDU A is 200 bytes long SNDU B is 100 bytes long SNDU C is 60 bytes long +-----+------+------+- -+------+ | HDR | A000 | A001 | ... | A183 | +-----+------+------+- -+------+ PUSI = 1 AFC = 01 <== Adapt Field ==> +-----+----+----+----+----+------+- -+------+------+- | HDR |0x03|0x02|0x01|0x11| A184 | ... | A199 | B000 | ... +-----+----+----+----+---*+------+- -+------+*-----+- PUSI = 1 * * AFC = 11 *********************** AF.ptr = 17 <--- 4 ---> stuffing bytes -+------+------+- -+------+----+- -+----+ ... | B099 | C000 | ... | C059 |0xff| ... |0xff| -+------+------+- -+------+----+- -+----+ 5th case : small packets, alignement stuff ============================================ SNDU A is 200 bytes long SNDU B is 97 bytes long SNDU C is 60 bytes long +-----+------+------+- -+------+ | HDR | A000 | A001 | ... | A183 | +-----+------+------+- -+------+ PUSI = 1 AFC = 01 <== Adapt Field ==> +-----+----+----+----+----+------+- -+------+------+- | HDR |0x03|0x02|0x01|0x11| A184 | ... | A199 | B000 | ... +-----+----+----+----+---*+------+- -+------+*-----+- PUSI = 1 * * AFC = 11 *********************** AF.ptr = 17 padding bytes to keep 4-bytes alignement / \ <--- 4 ---> / \ stuffing bytes -+------+----+----+----+------+- -+------+----+- -+----+ ... | B096 |0xff|0xff|0xff| C000 | ... | C059 |0xff| ... |0xff| -+------+----+----+----+------+- -+------+----+- -+----+ -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com From owner-ip-dvb@erg.abdn.ac.uk Fri Aug 1 14:20:46 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h71DKPc4015841 for ; Fri, 1 Aug 2003 14:20:25 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h71DKPGK015840 for ip-dvb-subscribed-users; Fri, 1 Aug 2003 14:20:25 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from mail1.iabg.de (mail1.iabg.de [194.139.245.9]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h71DK3c4015811 for ; Fri, 1 Aug 2003 14:20:03 +0100 (BST) Received: from mail1.iabg.de (localhost [127.0.0.1]) by localhost (Mailserver IABG) with ESMTP id BBF936DE1 for ; Fri, 1 Aug 2003 15:19:58 +0200 (CEST) Received: from exchange.iabg.de (exchange.iabg.de [10.128.200.12]) by mail1.iabg.de (Mailserver IABG) with ESMTP id A36C46DDF for ; Fri, 1 Aug 2003 15:19:58 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: AW: AW: AW: About dest MAC@ Date: Fri, 1 Aug 2003 15:20:00 +0200 Message-ID: <3141ED5F60D45E4BA847F18B2DFD92A801258374@exchange.iabg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: AW: About dest MAC@ Thread-Index: AcNYHuHb3JXs6IlYTUmU5FFMjjTFQQAECphA From: "Fritsche Wolfgang" To: X-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 h71DKO1D015837 Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Bertrand, I don't agree with your point of usual DVB-S receiver are handling only 2Mbit/s max, there are many (also cheap ones) with go far beyond this. And it's not only an issue of the receiver, it's also issue where the receiver is located in the satellite's footprint, and how big is the dish on the receiver side. However, my intention has only been to show you that there are operational scenarios in this areas, and from my point of view it's important to have this kind of discussion about address resolution / filtering / ... on this list. Cheers, Wolfgang > > > Ok, I have a better understanding on the application you have > in mind. Just two remarks for information (again), usual DVB > receiver are effectively cheap, but can handle only a limited > bitrate dedicated to data streams (usually 2 Mbits/s max), > DVB receivers are designed in a way the audio and video > stream are processed in a specific and dedicated way at high > bitrate where data are demuxed and filtered in a much less > efficient way introducing this kind of limitation. When > speaking about uplink over SCPC, PSTN etc... You may have to > take into account the fact that this asymmetric way of > processing is used also at the server uplink side regarding > the size of the data to be send (for large amount of data, > the satellite like is used, for small ones, the PSTN, narrow > band internet return channel is used. This to avoid the > satellite transmission delay for small amount of data as well > as to make the best use of the bandwidth / transmission cost > between satellite / PSNT..... Bertrand > > Fritsche Wolfgang wrote: > > > Bertrand, > > > > one reason for using DVB-S are the costs of equipment, which is > > extremly cheap on the receiver side. Of course it is only cheap if > > DVB-S is used in an uni-directional way, that is the uplink > happens in > > an other way, e.g. SCPC, narrow-band Internet, PSTN, ... > > > > Anyhow, these scenarios exist, and they will be affected by the > > address resolution / filtering issues Gorry and Alain discussed on > > this list. > > > > Wolfgang > > > > > > > > > > > Dear Wolfgang, > > > I thank you very much for your explanation, and I have some > > > additional questions to make sure I fully understand you > explanation > > > : The example is based on small ISP's feeding their network over > > > satellite link from a large teleport. For me, the link > between the > > > teleport and the small ISP looks like a B to B link allowing then > > > the small ISP to provide B to C access to local customers. My > > > question, is now the following : why would a teleport > service to ISP > > > providers use MPEG2 - DVB protocols (mostly designed for DTH TV > > > services) for that B to B pure data link ? I assume that > this kind > > > of data transmission is already used since years over dedicated > > > telecom satellites with other more suited protocols ? This > > > especially when your scenario requires a bi-directional and > > > permanent satellite link ? What do you think ? Bertrand > > > > > > > assume the following example operational scenario: > > > > > > > > A teleport service provider provides broadband Internet > access via > > > > DVB-S to smaller ISPs located in regions without > > > terrestrial broadband > > > > access. This teleport provider serves more customer on the same > > > > transponder. It assigns to each of them a global routable > > > IP address > > > > space. Receiving traffic from the Internet destined to > one of its > > > > customer's IP address space the teleport service provider will > > > > broadcast the traffic on the DVB-S link. As this link > is shared by > > > > more customer, the traffic "physically" will be > received by all of > > > > them. In order to allow efficient filtering, the > teleport provider > > > > uses a specific PID for each customer as well as the > MAC address > > > > of the customer's receiving equipment. This scenario could > > > also include a > > > > "kind of manually configured and therefore static address > > > resolution" > > > > (mapping of customer's IP address space to customer's PID / MAC > > > > address). Doing things like address resolution automatically is > > > > somewhat difficult if we're talking about uni-direc! tional > > > > links. > > > > > > > > However this example operational scenario reflect many > > > aspects Alain > > > > and Gorry discussed: > > > > > > > > - The connected minor ISP could use the teleport service > > > provider as > > > > the only external access (leaf network with single access point) > > > > - The connected minor ISP could use also other teleport > > > service providers / peering ISPs but do not transit > traffic between > > > them (leaf network with several access points) > > > > - The connected minor ISP could use also other teleport > > > service providers / peering ISPs and do transit traffic > between them > > > (transit network with several access points) > > > > > > > > What I do not see so far as a common operational scenario > > > is that one > > > > customer will receive for its IP address range traffic > via several > > > > access router connected to the same DVB-S transponder. But > > > also this > > > > could change in future if IPv6 brings more possibilities for > > > > multihoming and network renumbering. > > > > > > > > Cheers, > > > > > > > > Wolfgang > > > > > > > > > > > > > > > > > > > Dear Alain, dear Gorry, > > > > > I am a little puzzled by this discussion, you should not > > > forget that > > > > > in a broadcast world (meaning DVB-MPEG2), it is very uncommon > > > > > for the broadcaster to know the MAC and even the IP > address of a > > > > > receiver (today nearly all of them don't even have one). > > > Receivers > > > > > are bought in any kind of retail shop and are plug > and play when > > > > > connected to a dish. In a broadcast mode the only thing > > > you need to > > > > > know on the receiver side is what IP service I have to > > > listen to in > > > > > order to get access the expected service (the IP > address is here > > > > > used as another filtering criteria to extract the relevant IP > > > > > sections in an IP stream). Regarding the broadcast technology > > > > > (still meaning DVB-MPEG2), except for specific B to B > > > > > application, it is uncommon to do unicast, just > because of the > > > > > cost of the bandwidth. Now, the interesting point is when a > > > > > receiver have a broadcast access (e.g. a dish to get > the MPEG2 > > > > > signal), and a DSL access. In this case, the receiver > will work > > > > > in the same way as a PC connected to the DSL network, > but might > > > > > access data from both network (the MPEG 2 and the DSL > one) for > > > > > various application where two streams may be needed > (the common > > > > > one broadcasted, and the user specific one streamed > over DSL). > > > > > Now, assume that in case the broadcaster wants to > send data to a > > > > > specific user over the DVB-MPEG2 network, based on a request > > > > > coming through the DSL network (back channel), he > will have to > > > > > give the receiver the DVB triplet (to locate the TS > and PID) and > > > > > an IP address to filter on. In any case, the only way the > > > > > receiver can be known by the broadcaster is when he > has a return > > > > > channel (e.g. a DSL connection, and then, the IP address is > > > > > allocated by the ISP). Could you perhaps explain a > little more > > > > > the concrete scenarios and operational configurations > you have > > > > > in mind ? Best regards Bertrand > > > > > > > > > > Dr G Fairhurst wrote: > > > > > > > > > > > alain.ritoux@6wind.com wrote: > > > > > > > > > > > > > > Dr G Fairhurst wrote: > > > > > > > > > > > > > > > > > > > > > > >>- If the IRD is itself a router, there is still the > > > > > case (that may > > > > > > > >>be of (most?) common usage ??) that the network > > > behind it is a > > > > > > > >>leaf-network, and by no mean a transit network. > > > > > > > > > > > > > > > > > > > > > > > > OK, so specifically you mean a leaf network > where routing > > > > > > > > protocols are not used to determine forwarding to > > > the "leaf" > > > > > > > > network. One example is a network with one external > > > > > > > > receive interface (via the MPEG-2 port). > > > > > > > > > > > > > > Not exactly, in fact, the "leaf" network I had in > mind could > > > > > > > have several point of access (i.e CPE), but does > NOT provide > > > > > > > transit, hence only packets destined to the > "leaf" network > > > > > > > should be accepted. > > > > > > > > > > > > > > > > > > > OK, but what happens whene there are several places > > > (networks) via > > > > > > which the "leaf: network may receive an Ip packet? > > > > > > - routers normally advertise that a site is > reachable via an > > > > > > interface. Do routers do this on each network to > > > > > which they are > > > > > > attached? > > > > > > > > > > > > If so, how do the routers connected to the MPEG-2 feed know > > > > > whether to > > > > > > forward the packet from the MPEG-2 feed via the other > > > network(s) > > > > > > to the destination end host, or to discard this > packet because > > > > > > someone else will be forwarding? - This is usually the > > > function of > > > > > > the IP routing protocol in combination with the link > > > MAC address. > > > > > > > > > > > > In the case of just one receive interface, the > above point is > > > > > > moot, and we don't have the same routing issues. > > > > > > > > > > > > > > > > > > > > > > That is, theer are no alternative delivery paths, and > > > > > therefore no > > > > > > > > reachability via other routers that may also receive > > > > > the packet. > > > > > > > > Specifically you must also require all other routers to > > > > > silently > > > > > > > > drop packets with an unreachable network > address. If you > > > > > > > > do all this, I agree - but although this would work, it > > > > > > > > seems > > > > > a "tweak", > > > > > > > > and I'm not sure the latter > > > > > > > I admit this is tweaky, and I'm not definitly proud of it > > > > > > > ;-) > > > > > > > > > > > > > > > is a robust recommendation (if one router returns an > > > > > ICMP message > > > > > > > > to the source, what happens??) > > > > > > > Well, the source is informed that dest is unreachable, > > > > > and may stop. > > > > > > > So indeed, it works only when ALL routers perform > the same > > > > > > > trick, which is somehow fragile I admit. > > > > > > > > > > > > > > > > > > > Ok, so, you can do it this way if you have an operational > > > > > > need, but it's probably not a recommended solution. > > > > > > > > > > > > > > > > > > > > > > My thoughts are that we have some cases here that > > > can use IP > > > > > > > > packets without MAC addresses, providing: > > > > > > > > > > > > > > > > (a) they can efficiently filter on IP level addresses > > > > > > > > > > > > > > > > AND > > > > > > > > > > > > > > > > (b) If they are routers they MUST also differentiate > > > > > packets with > > > > > > > > a MAC dest address from those without a MAC > > > address, and MUST > > > > > > > > discard packets with no MAC address that do not > > > correspond to > > > > > > > > their own IP address (or with all the rules > above to the > > > > > > > > prefix used for hosts on a leaf IP network.) > > > > > > > > > > > > > Definitely agree, the trick was only for the case where > > > > > there's no > > > > > > > MAC addr. Of course, if there is a MAC addr, is MUST > > > be used to > > > > > > > reject or accept packets whatever their dst IP addr is. > > > > > > > > > > > > > > Alain. > > > > > > > -- > > > > > > > Alain RITOUX > > > > > > > Tel +33-1-39-30-92-32 > > > > > > > Fax +33-1-39-30-92-11 > > > > > > > visit our web http://www.6wind.com > > > > > > > > > > -- > > > > > This message and any attachments (the "message") is > > > intended solely > > > > > for the addressees and is confidential. If you receive > > > this message > > > > > in error, please delete it and immediately notify the sender. > > > > > Any use not in accordance with its purpose, any > dissemination or > > > > > disclosure, either whole or partial, is prohibited > except formal > > > > > approval. The E-Mail transmission can not guarantee the > > > integrity of > > > > > this message. > > > > > CANAL+TECHNOLOGIES will not therefore be liable for the > > > message if > > > > > CANAL+modified. > > > > > > > > > > > > > > > > > > > > > -- > > > This message and any attachments (the "message") is > intended solely > > > for the addressees and is confidential. If you receive > this message > > > in error, please delete it and immediately notify the sender. Any > > > use not in accordance with its purpose, any dissemination or > > > disclosure, either whole or partial, is prohibited except formal > > > approval. The E-Mail transmission can not guarantee the > integrity of > > > this message. > > > CANAL+TECHNOLOGIES will not therefore be liable for the > message if > > > CANAL+modified. > > > > > > > > > > > -- > This message and any attachments (the "message") is intended > solely for the addressees and is confidential. If you receive > this message in error, please delete it and immediately > notify the sender. Any use not in accordance with its > purpose, any dissemination or disclosure, either whole or > partial, is prohibited except formal approval. The E-Mail > transmission can not guarantee the integrity of this message. > CANAL+TECHNOLOGIES will not therefore be liable for the message if > CANAL+modified. > > > From owner-ip-dvb@erg.abdn.ac.uk Tue Aug 5 14:53:12 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h75DqeeG014861 for ; Tue, 5 Aug 2003 14:52:40 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h75DqeAX014860 for ip-dvb-subscribed-users; Tue, 5 Aug 2003 14:52:40 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h75DqOeG014847 for ; Tue, 5 Aug 2003 14:52:24 +0100 (BST) Message-ID: <3F2FB698.A9E7E2F6@erg.abdn.ac.uk> Date: Tue, 05 Aug 2003 14:52:24 +0100 From: Dr G Fairhurst Organization: ERG, Aberdeen, UK X-Mailer: Mozilla 4.77C-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: AW: AW: AW: About dest MAC@ References: <3141ED5F60D45E4BA847F18B2DFD92A801258374@exchange.iabg.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Fritsche Wolfgang wrote: > > Bertrand, > > I don't agree with your point of usual DVB-S receiver are handling > only 2Mbit/s max, there are many (also cheap ones) with go far beyond > this. And it's not only an issue of the receiver, it's also issue > where the receiver is located in the satellite's footprint, and how > big is the dish on the receiver side. > Sure, the technology is scalable, from a few Mbps, to 100 Mbps, or so. The RF intreface (antenna, LNB, etc) vary depending on the link/satellite configuration, but these don't impact the MPEG-2 transmission format. > However, my intention has only been to show you that there are > operational scenarios in this areas, and from my point of view it's > important to have this kind of discussion about address resolution > / filtering / ... on this list. > The draft charter at http://www.erg.abdn.ac.uk/ip-dvb/ said "The MPEG-2 Transport Stream provides a transmission network that has become widely use to support digital TV broadcast, including: DVB, DAB, ATSC, ISDB-T. These and related standards define a set of commercially available components that are increasingly being used to provide a general-purpose packet transmission network. MPEG-2 Transport networks are being used to build IP networks to supplement broadcast TV/audio services and also to provide one-way and two-way IP-only subnetworks." If that helps to clarify the scope - i.e. the focus should be on the IP services, but is not restricted to data-only IP services, it COULD also apply to digital TV broadcast applications that wish to also support IP services. I suggest that where existing standards already exist, such as for ATSC, and DVB digital TV broadcast applications, there may be a need to recommend how the IPv4/IPv6 service binds to these standards, and it may be desirable to recommend how to use such existing techniques, if these are applicable. Where there are no techniques, or the techniques are not well-suited to IP networks, then new techniques will need to be found. Either way, we need to set up some scenarios, so we know the various topologies and use-cases we are looking at. All inputs welcome!!! Gorry > Cheers, > > Wolfgang > > > > > > > Ok, I have a better understanding on the application you have > > in mind. Just two remarks for information (again), usual DVB > > receiver are effectively cheap, but can handle only a limited > > bitrate dedicated to data streams (usually 2 Mbits/s max), > > DVB receivers are designed in a way the audio and video > > stream are processed in a specific and dedicated way at high > > bitrate where data are demuxed and filtered in a much less > > efficient way introducing this kind of limitation. When > > speaking about uplink over SCPC, PSTN etc... You may have to > > take into account the fact that this asymmetric way of > > processing is used also at the server uplink side regarding > > the size of the data to be send (for large amount of data, > > the satellite like is used, for small ones, the PSTN, narrow > > band internet return channel is used. This to avoid the > > satellite transmission delay for small amount of data as well > > as to make the best use of the bandwidth / transmission cost > > between satellite / PSNT..... Bertrand > > > > Fritsche Wolfgang wrote: > > > > > Bertrand, > > > > > > one reason for using DVB-S are the costs of equipment, which is > > > extremly cheap on the receiver side. Of course it is only cheap if > > > DVB-S is used in an uni-directional way, that is the uplink > > happens in > > > an other way, e.g. SCPC, narrow-band Internet, PSTN, ... > > > > > > Anyhow, these scenarios exist, and they will be affected by the > > > address resolution / filtering issues Gorry and Alain discussed on > > > this list. > > > > > > Wolfgang > > > > > > > > > > > > > > > Dear Wolfgang, > > > > I thank you very much for your explanation, and I have some > > > > additional questions to make sure I fully understand you > > explanation > > > > : The example is based on small ISP's feeding their network over > > > > satellite link from a large teleport. For me, the link > > between the > > > > teleport and the small ISP looks like a B to B link allowing then > > > > the small ISP to provide B to C access to local customers. My > > > > question, is now the following : why would a teleport > > service to ISP > > > > providers use MPEG2 - DVB protocols (mostly designed for DTH TV > > > > services) for that B to B pure data link ? I assume that > > this kind > > > > of data transmission is already used since years over dedicated > > > > telecom satellites with other more suited protocols ? This > > > > especially when your scenario requires a bi-directional and > > > > permanent satellite link ? What do you think ? Bertrand > > > > > > > > > assume the following example operational scenario: > > > > > > > > > > A teleport service provider provides broadband Internet > > access via > > > > > DVB-S to smaller ISPs located in regions without > > > > terrestrial broadband > > > > > access. This teleport provider serves more customer on the same > > > > > transponder. It assigns to each of them a global routable > > > > IP address > > > > > space. Receiving traffic from the Internet destined to > > one of its > > > > > customer's IP address space the teleport service provider will > > > > > broadcast the traffic on the DVB-S link. As this link > > is shared by > > > > > more customer, the traffic "physically" will be > > received by all of > > > > > them. In order to allow efficient filtering, the > > teleport provider > > > > > uses a specific PID for each customer as well as the > > MAC address > > > > > of the customer's receiving equipment. This scenario could > > > > also include a > > > > > "kind of manually configured and therefore static address > > > > resolution" > > > > > (mapping of customer's IP address space to customer's PID / MAC > > > > > address). Doing things like address resolution automatically is > > > > > somewhat difficult if we're talking about uni-direc! tional > > > > > links. > > > > > > > > > > However this example operational scenario reflect many > > > > aspects Alain > > > > > and Gorry discussed: > > > > > > > > > > - The connected minor ISP could use the teleport service > > > > provider as > > > > > the only external access (leaf network with single access point) > > > > > - The connected minor ISP could use also other teleport > > > > service providers / peering ISPs but do not transit > > traffic between > > > > them (leaf network with several access points) > > > > > - The connected minor ISP could use also other teleport > > > > service providers / peering ISPs and do transit traffic > > between them > > > > (transit network with several access points) > > > > > > > > > > What I do not see so far as a common operational scenario > > > > is that one > > > > > customer will receive for its IP address range traffic > > via several > > > > > access router connected to the same DVB-S transponder. But > > > > also this > > > > > could change in future if IPv6 brings more possibilities for > > > > > multihoming and network renumbering. > > > > > > > > > > Cheers, > > > > > > > > > > Wolfgang > > > > > > > > > > > > > > > > > > > > > > > Dear Alain, dear Gorry, > > > > > > I am a little puzzled by this discussion, you should not > > > > forget that > > > > > > in a broadcast world (meaning DVB-MPEG2), it is very uncommon > > > > > > for the broadcaster to know the MAC and even the IP > > address of a > > > > > > receiver (today nearly all of them don't even have one). > > > > Receivers > > > > > > are bought in any kind of retail shop and are plug > > and play when > > > > > > connected to a dish. In a broadcast mode the only thing > > > > you need to > > > > > > know on the receiver side is what IP service I have to > > > > listen to in > > > > > > order to get access the expected service (the IP > > address is here > > > > > > used as another filtering criteria to extract the relevant IP > > > > > > sections in an IP stream). Regarding the broadcast technology > > > > > > (still meaning DVB-MPEG2), except for specific B to B > > > > > > application, it is uncommon to do unicast, just > > because of the > > > > > > cost of the bandwidth. Now, the interesting point is when a > > > > > > receiver have a broadcast access (e.g. a dish to get > > the MPEG2 > > > > > > signal), and a DSL access. In this case, the receiver > > will work > > > > > > in the same way as a PC connected to the DSL network, > > but might > > > > > > access data from both network (the MPEG 2 and the DSL > > one) for > > > > > > various application where two streams may be needed > > (the common > > > > > > one broadcasted, and the user specific one streamed > > over DSL). > > > > > > Now, assume that in case the broadcaster wants to > > send data to a > > > > > > specific user over the DVB-MPEG2 network, based on a request > > > > > > coming through the DSL network (back channel), he > > will have to > > > > > > give the receiver the DVB triplet (to locate the TS > > and PID) and > > > > > > an IP address to filter on. In any case, the only way the > > > > > > receiver can be known by the broadcaster is when he > > has a return > > > > > > channel (e.g. a DSL connection, and then, the IP address is > > > > > > allocated by the ISP). Could you perhaps explain a > > little more > > > > > > the concrete scenarios and operational configurations > > you have > > > > > > in mind ? Best regards Bertrand > > > > > > > > > > > > Dr G Fairhurst wrote: > > > > > > > > > > > > > alain.ritoux@6wind.com wrote: > > > > > > > > > > > > > > > > Dr G Fairhurst wrote: > > > > > > > > > > > > > > > > > > > > > > > > > >>- If the IRD is itself a router, there is still the > > > > > > case (that may > > > > > > > > >>be of (most?) common usage ??) that the network > > > > behind it is a > > > > > > > > >>leaf-network, and by no mean a transit network. > > > > > > > > > > > > > > > > > > > > > > > > > > > OK, so specifically you mean a leaf network > > where routing > > > > > > > > > protocols are not used to determine forwarding to > > > > the "leaf" > > > > > > > > > network. One example is a network with one external > > > > > > > > > receive interface (via the MPEG-2 port). > > > > > > > > > > > > > > > > Not exactly, in fact, the "leaf" network I had in > > mind could > > > > > > > > have several point of access (i.e CPE), but does > > NOT provide > > > > > > > > transit, hence only packets destined to the > > "leaf" network > > > > > > > > should be accepted. > > > > > > > > > > > > > > > > > > > > > > OK, but what happens whene there are several places > > > > (networks) via > > > > > > > which the "leaf: network may receive an Ip packet? > > > > > > > - routers normally advertise that a site is > > reachable via an > > > > > > > interface. Do routers do this on each network to > > > > > > which they are > > > > > > > attached? > > > > > > > > > > > > > > If so, how do the routers connected to the MPEG-2 feed know > > > > > > whether to > > > > > > > forward the packet from the MPEG-2 feed via the other > > > > network(s) > > > > > > > to the destination end host, or to discard this > > packet because > > > > > > > someone else will be forwarding? - This is usually the > > > > function of > > > > > > > the IP routing protocol in combination with the link > > > > MAC address. > > > > > > > > > > > > > > In the case of just one receive interface, the > > above point is > > > > > > > moot, and we don't have the same routing issues. > > > > > > > > > > > > > > > > > > > > > > > > > That is, theer are no alternative delivery paths, and > > > > > > therefore no > > > > > > > > > reachability via other routers that may also receive > > > > > > the packet. > > > > > > > > > Specifically you must also require all other routers to > > > > > > silently > > > > > > > > > drop packets with an unreachable network > > address. If you > > > > > > > > > do all this, I agree - but although this would work, it > > > > > > > > > seems > > > > > > a "tweak", > > > > > > > > > and I'm not sure the latter > > > > > > > > I admit this is tweaky, and I'm not definitly proud of it > > > > > > > > ;-) > > > > > > > > > > > > > > > > > is a robust recommendation (if one router returns an > > > > > > ICMP message > > > > > > > > > to the source, what happens??) > > > > > > > > Well, the source is informed that dest is unreachable, > > > > > > and may stop. > > > > > > > > So indeed, it works only when ALL routers perform > > the same > > > > > > > > trick, which is somehow fragile I admit. > > > > > > > > > > > > > > > > > > > > > > Ok, so, you can do it this way if you have an operational > > > > > > > need, but it's probably not a recommended solution. > > > > > > > > > > > > > > > > > > > > > > > > > My thoughts are that we have some cases here that > > > > can use IP > > > > > > > > > packets without MAC addresses, providing: > > > > > > > > > > > > > > > > > > (a) they can efficiently filter on IP level addresses > > > > > > > > > > > > > > > > > > AND > > > > > > > > > > > > > > > > > > (b) If they are routers they MUST also differentiate > > > > > > packets with > > > > > > > > > a MAC dest address from those without a MAC > > > > address, and MUST > > > > > > > > > discard packets with no MAC address that do not > > > > correspond to > > > > > > > > > their own IP address (or with all the rules > > above to the > > > > > > > > > prefix used for hosts on a leaf IP network.) > > > > > > > > > > > > > > > Definitely agree, the trick was only for the case where > > > > > > there's no > > > > > > > > MAC addr. Of course, if there is a MAC addr, is MUST > > > > be used to > > > > > > > > reject or accept packets whatever their dst IP addr is. > > > > > > > > > > > > > > > > Alain. > > > > > > > > -- > > > > > > > > Alain RITOUX > > > > > > > > Tel +33-1-39-30-92-32 > > > > > > > > Fax +33-1-39-30-92-11 > > > > > > > > visit our web http://www.6wind.com > > > > > > > > > > > > -- > > > > > > This message and any attachments (the "message") is > > > > intended solely > > > > > > for the addressees and is confidential. If you receive > > > > this message > > > > > > in error, please delete it and immediately notify the sender. > > > > > > Any use not in accordance with its purpose, any > > dissemination or > > > > > > disclosure, either whole or partial, is prohibited > > except formal > > > > > > approval. The E-Mail transmission can not guarantee the > > > > integrity of > > > > > > this message. > > > > > > CANAL+TECHNOLOGIES will not therefore be liable for the > > > > message if > > > > > > CANAL+modified. > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > This message and any attachments (the "message") is > > intended solely > > > > for the addressees and is confidential. If you receive > > this message > > > > in error, please delete it and immediately notify the sender. Any > > > > use not in accordance with its purpose, any dissemination or > > > > disclosure, either whole or partial, is prohibited except formal > > > > approval. The E-Mail transmission can not guarantee the > > integrity of > > > > this message. > > > > CANAL+TECHNOLOGIES will not therefore be liable for the > > message if > > > > CANAL+modified. > > > > > > > > > > > > > > > > -- > > This message and any attachments (the "message") is intended > > solely for the addressees and is confidential. If you receive > > this message in error, please delete it and immediately > > notify the sender. Any use not in accordance with its > > purpose, any dissemination or disclosure, either whole or > > partial, is prohibited except formal approval. The E-Mail > > transmission can not guarantee the integrity of this message. > > CANAL+TECHNOLOGIES will not therefore be liable for the message if > > CANAL+modified. > > > > > > From owner-ip-dvb@erg.abdn.ac.uk Thu Aug 7 11:21:42 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h77ALMeG022159 for ; Thu, 7 Aug 2003 11:21:22 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h77ALMjC022158 for ip-dvb-subscribed-users; Thu, 7 Aug 2003 11:21:22 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from proxy.6wind.com (proxy.6wind.com [194.250.197.211]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h77AKreG022125 for ; Thu, 7 Aug 2003 11:20:53 +0100 (BST) Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id 10D5263E for ; Thu, 7 Aug 2003 12:20:54 +0200 (CEST) Received: from 6wind.com (vouvray.dev.6wind.com [10.16.0.135]) by intranet.6wind.com (Postfix) with ESMTP id 4D51C639; Thu, 7 Aug 2003 12:20:52 +0200 (CEST) Message-ID: <3F3228C4.8010400@6wind.com> Date: Thu, 07 Aug 2003 12:24:04 +0200 From: alain.ritoux@6wind.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IPDVB Subject: "enc" method : pb in small SNDU X-Enigmail-Version: 0.71.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Hi all, First, about encapsulation methods, apart from answers from Gorry, I do feel a little bit alone :-( Is this because I try to smash already opened doors, or because of holiday period, or ... Nevertheless, I think there is a little flaw with the "enc" method, with respect to small packets. Indeed, if, I take back from my previous mail the example from case 3 : SNDU A is 200 bytes long SNDU B is 100 bytes long SNDU C is 60 bytes long +-----+------+------+- -+------+ | HDR | A000 | A001 | ... | A183 | +-----+------+------+- -+------+ PUSI = 1 AFC = 01 <== Adapt Field ==> +-----+----+----+----+----+------+- -+------+------+- | HDR |0x03|0x02|0x01|0x11| A184 | ... | A199 | B000 | ... +-----+----+----+----+---*+------+- -+------+*-----+- PUSI = 1 * * AFC = 11 *********************** AF.ptr = 17 <--- 4 ---> stuffing bytes -+------+------+- -+------+----+- -+----+ ... | B099 | C000 | ... | C059 |0xff| ... |0xff| -+------+------+- -+------+----+- -+----+ In the second TS cell, PUSI = 1 helps knowing a new SNDU starts, the AF helps finding its start : so SNDU-B is found. well, SNDu-B has its size included, so finding the start of SDNU-C is feasible (keeping apart any alignement stuff), but I see nothing that tells the receiver that - a SNDU-C is to be found - there is no SNDU-D starting after SNDU-C SOLUTION : To do that, the solution proposed in the "ule" method is applicable, hence having and "end" indicator 0x00 0x00. This would lead to <== Adapt Field ==> +-----+----+----+----+----+------+- -+------+------+- | HDR |0x03|0x02|0x01|0x11| A184 | ... | A199 | B000 | ... +-----+----+----+----+---*+------+- -+------+*-----+- PUSI = 1 * * AFC = 11 *********************** AF.ptr = 17 <-- 2 --> stuffing bytes -+------+------+- -+------+----+----+----+----+ ... | B099 | C000 | ... | C059 |0x00|0x00|0xff|0xff| -+------+------+- -+------+----+----+----+----+ / \ end-indicator This would also need, for a simpliest implementation purpose, and may remove some nasty case I haven't seen yet, to adopt the same resolution as in "ule" method: "If the TS Packet carrying the final part of a SNDU has either zero or one byte of unused payload, the encapsulator will start transmission of the next SNDU in a new TS Packet. For the case of one remaining byte this MUST be assigned the value of 0x00, but this value MUST be ignored at the receiver." note that is uncenessary (for it is implicitly done) if the 4-bytes alignement is required as I suggested. Regards. Alain. -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com From owner-ip-dvb@erg.abdn.ac.uk Fri Aug 8 06:06:30 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7855keG006065 for ; Fri, 8 Aug 2003 06:05:46 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h7855k4U006064 for ip-dvb-subscribed-users; Fri, 8 Aug 2003 06:05:46 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from gateway.hns.com (gateway.hns.com [208.236.67.14]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7855QeH006050 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 8 Aug 2003 06:05:27 +0100 (BST) Received: from excore8.hns.com (excore8.hns.com [139.85.52.156]) by gateway.hns.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id h7855Mo5023745 for ; Fri, 8 Aug 2003 01:05:23 -0400 (EDT) Received: from atlas (atlas.hns.com [139.85.177.110]) by excore8.hns.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id h7850Ik7019360 for ; Fri, 8 Aug 2003 01:05:07 -0400 (EDT) Subject: Roderick Ragland/HNS is out of the office. From: rragland@hns.com To: ip-dvb@erg.abdn.ac.uk Message-ID: Date: Fri, 8 Aug 2003 01:02:49 -0400 X-MIMETrack: Serialize by Router on Atlas/HNS(Release 5.0.12 |February 13, 2003) at 08/08/2003 01:03:09 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk I will be out of the office starting 08/07/2003 and will not return until 08/18/2003. I will respond to your message when I return. From owner-ip-dvb@erg.abdn.ac.uk Thu Aug 14 07:50:57 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7E6ocPv027790 for ; Thu, 14 Aug 2003 07:50:38 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h7E6ocRY027789 for ip-dvb-subscribed-users; Thu, 14 Aug 2003 07:50:38 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from proxy.6wind.com (proxy.6wind.com [194.250.197.211]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7E6oIPv027776 for ; Thu, 14 Aug 2003 07:50:18 +0100 (BST) Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id 4B3D94EA for ; Thu, 14 Aug 2003 08:50:18 +0200 (CEST) Received: from 6wind.com (vouvray.dev.6wind.com [10.16.0.135]) by intranet.6wind.com (Postfix) with ESMTP id 015F36A9; Thu, 14 Aug 2003 08:50:17 +0200 (CEST) Message-ID: <3F3B31E9.5020204@6wind.com> Date: Thu, 14 Aug 2003 08:53:29 +0200 From: alain.ritoux@6wind.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IPDVB Subject: "ule" and last byte X-Enigmail-Version: 0.71.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Precision about the "ule" method wrt the last byte The sentence (p11) "If the TS packet carrying the final part of SNDU has either 0 or 1 byte of unused payload, the encapsulator will start transmission of the next SNDU in a new TS packet". I think it is to allow enough room for the payload pointer, is this correct, or is there any other motivation ? Does this includes the payload pointer ? I mean : (MPEG_HDR)(End of SNDU-A)[1 byte left] ==> OK send it now but, in the following case (MPEG_HDR)(End of SNDU-A)[2 bytes left] it will become, with a SNDU-B (MPEG_HDR)(Payload Pointer)(End of SNDU-A)(start SNDU-B) ^^^^^^^^^^^^^^ Only 1 byte ! so, was it to be sent at once, or is the second TS cell legal ? because in the second case, it would mean that the SNDU length is not yet available, until a second TS cell is received, which is not really a pleasant thing. 1) If having the SNDU length split over 2 cell is a pb, then the sentence should more replaced with something like : "If there is not enough room in a TS packet to put the first 2 bytes of an SNDU (possibly due to the needed payload pointer), the encapsulator will start transmission of this SNDU in a new TS packet. The remaining bytes, MUST be set ...." 2) if such a length split is not a pb, then first sentence is a bit hard because, in case of multiple SNDU in a single TS cell, there is not the payload pointer pb : (MPEG_HDR)(End of SNDU-A)(SNDU-B)[1 byte left] OK keep it, because SDNU-C can start in this TS_cell : (MPEG_HDR)(End of SNDU-A)(SNDU-B)(start SNDU-C) ^^^^^^^^^^^^^^^ 1 byte hence the sentence could be rephrased into something like "If the TS packet carrying the final part of SNDU has either 0 or 1 byte of unused payload and the PUSI bit clear, the encapsulator will start transmission of the next SNDU in a new TS packet". so it would relax the condition when PUSi bit is set, i.e. there won't be other payload pointer added. I would prefer solution 1) Your thoughts ? Regards. Alain. -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com From owner-ip-dvb@erg.abdn.ac.uk Mon Aug 18 15:58:35 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7IEvhPv027963 for ; Mon, 18 Aug 2003 15:57:43 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h7IEvhlB027962 for ip-dvb-subscribed-users; Mon, 18 Aug 2003 15:57:43 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from notesmta.nera.no (notesmta.nera.no [194.19.8.41]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7IEuxPv027919; Mon, 18 Aug 2003 15:57:00 +0100 (BST) In-Reply-To: <41256C94.00456EDB.00@estecmail4.estec.esa.int> MIME-Version: 1.0 Sensitivity: To: ip-dvb@erg.abdn.ac.uk Cc: IP-dvb@erg.abdn.ac.uk Subject: Re: Differences between INT and MMT tables for address resolution? X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: From: Harald Skinnemoen Date: Mon, 18 Aug 2003 16:57:05 +0200 X-MIMETrack: Serialize by Router on NotesMTA/NERA(Release 6.0.1|February 07, 2003) at 2003-08-18 16:54:32, Serialize complete at 2003-08-18 16:54:32 Content-Type: multipart/alternative; boundary="=_alternative 00524869C1256D86_=" X-MailScanner: Found to be clean, Found to be clean X-MailScanner-SpamScore: s Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk This is a multipart message in MIME format. --=_alternative 00524869C1256D86_= Content-Type: text/plain; charset="US-ASCII" Hi all, I'm looking for some further info on the practical use of the INT tables. Does anybody know of anyone who has implemented satellite multicast by using the INT tables? Seems to me the MMT tables are used in at least a couple of systems. I'm however not sure how users satisfaction is, as it seems to me it can't offer the same dynamics and flexibility as a terrestrial IP multicast system. Best regards, /Harald Please respond to ip-dvb@erg.abdn.ac.uk Sent by: owner-ip-dvb@erg.abdn.ac.uk To: IP-dvb@erg.abdn.ac.uk cc: Subject: Differences between INT and MMT tables for address resolution? Before delving into the DVB archives, does somebody know: a. Where the Multicast Map Table is officially defined ? Is there a DVB reference ? b. What is the relation between the INT (IP/MAC Notification Table) , as defined in ETSI EN Draft 301 192 v1.3.1 (2002-12) ? In addition to offering unicast/MAC streams/platform concept, is it making the MMT obsolete ? Is there a reference to minutes of some DVB meeting that explains the relation between the two ? My understanding is that EN 301 192 v1.3.1 (DVB data broadcasting) document now includes the document referenced in Gorries report from Atlanta (ETSI EN drTS 102 00X V0.4.2 (2002-07) "Specification for IP Notification in DVB Systems Use of the IP/MAC Notification Table"). Regards, Frank --=_alternative 00524869C1256D86_= Content-Type: text/html; charset="US-ASCII"
Hi all,

I'm looking for some further info on the practical use of the INT tables.  Does anybody know of anyone who has implemented satellite multicast by using the INT tables?

Seems to me the MMT tables are used in at least a couple of systems. I'm however not sure how users satisfaction is, as it seems to me it can't offer the same dynamics and flexibility as a terrestrial IP multicast system.

Best regards,

/Harald
 

Please respond to ip-dvb@erg.abdn.ac.uk

Sent by:        owner-ip-dvb@erg.abdn.ac.uk

To:        IP-dvb@erg.abdn.ac.uk
cc:        

Subject:        Differences between  INT and MMT tables for address resolution?


Before delving into the DVB archives, does somebody know:
a. Where the Multicast Map Table is officially defined ? Is there a DVB
reference ?
b. What is the relation between the INT (IP/MAC Notification Table) , as
defined in ETSI EN Draft 301 192 v1.3.1 (2002-12) ? In addition to offering
unicast/MAC streams/platform concept, is it  making the MMT obsolete  ? Is
there a reference to minutes of some DVB meeting that explains the relation
between the two ?
My understanding is that EN 301 192 v1.3.1 (DVB data broadcasting)  document
now includes the document referenced in Gorries report from Atlanta (ETSI EN
drTS 102 00X V0.4.2 (2002-07) "Specification for IP Notification in DVB
Systems Use of the IP/MAC Notification Table").

Regards, Frank



--=_alternative 00524869C1256D86_=-- From owner-ip-dvb@erg.abdn.ac.uk Tue Aug 19 13:25:05 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7JAfvZj007041 for ; Tue, 19 Aug 2003 11:41:57 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h7JAfvmC007040 for ip-dvb-subscribed-users; Tue, 19 Aug 2003 11:41:57 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7JAfRZk007018 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 19 Aug 2003 11:41:28 +0100 (BST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h7JAfPB26297 for ; Tue, 19 Aug 2003 13:41:27 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 19 Aug 2003 13:41:25 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 19 Aug 2003 13:41:24 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 19 Aug 2003 13:41:24 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3663E.6F1B53C9" Subject: RE: Differences between INT and MMT tables for address resolution? Date: Tue, 19 Aug 2003 13:41:23 +0300 Message-ID: <2BF0AD29BC31FE46B78877321144043101B9E4D6@trebe003.europe.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Differences between INT and MMT tables for address resolution? Thread-Index: AcNlmt9VGm2lwcNxRrKJ2gSCdWp8FwAlq2eg From: To: X-OriginalArrivalTime: 19 Aug 2003 10:41:24.0166 (UTC) FILETIME=[6F877660:01C3663E] X-MailScanner: Found to be clean, Found to be clean X-MailScanner-SpamScore: s, s Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3663E.6F1B53C9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Harald et al. =20 Though I'm not exactly up-to-date on this, Astra TRP 1053 seems to carry = INT for unicast (19.2 DegEast, 10.77325 GHz, Horizontal, 22MS/s, 5/6) (a = colleage told me) =20 With reference to Frank's earlier question: INT is now specified and = officially (ETSI) standardised in ETSI EN 301 192 V1.3.1 (2003-05). No = other reference should be used, unless the standard is updated, which = can be "polled" from the www.etsi.org site using the "data broadcasting" = string in the keyword search for "get a standard / free download". =20 Given that the specification only became an official ETSI standard in = May, it would suprise me if there are already many implemenations to = choose from, since ETSI works more towards concensus, standard, = implementation, rather than the IETF, implement, concensus, standard. (I = am certain there are several proprietry implementations based on one of = the proposals before INT was designed by concesus, which should migrate = to INT over time). =20 Does anyone have an MMT reference (to standard or standards = contribution)? Since it is DVB-RCS specific, I had a look at the DVB-RC* = ones listed at www.dvb.org (based on the "mmt" and "multicast" strings): * DVB-RCC (return channel for cable): ES 200 800; TR101 196 says use EN = 301 192 for MAC/IP mapping * DVB-RCL (return channel for LMDS): EN 301 199; TR 101 205 says use EN = 301 192 for MAC/IP mapping * DVB-RCT (return channel for terrestrial) : EN 301 958 says use EN 301 = 192 for MAC/IP mapping * DVB-RCG (GSM): EN 301 195 says nothing * DVB-RCP (PSTN/ISDN): ETS 300 801 says nothing * DVB:RCCS (SMATV + measurement guidelines): TR 101 201; TR 101 290 say = nothing =20 DVB-RCS: Digital Video Broadcasting (DVB); Interaction channel for = satellite distribution systems) documents say this: * ETSI TR 101 790 V1.2.1 (2003-01) - guidelines - says a fair amount = about multicast including: Multicast PID Mapping Table (identified by = the Elementary Loop with the stream type =3D 0x05 and table id =3D 0xA7 = in the RCS content descriptor) parsed from PMT using IP/DVB Service = linkage from RCS/Map Table. However, this Multicast PID Mapping table is = neither referenced nor specified. * ETSI EN 301 790 V1.3.1 (2003-03) - standard/specification - says = nothing =20 (nothing =3D nothing in respect to mmt & multicast :) =20 Thus I can conclude that MMT =3D Multicast PID Mapping Table and was = mentioned as recently at January 2003, but not is in the DVB-RCS = standard, only in the guidelines. Does anyone have a reference to the = specification? =20 Cheers, Rod. =20 -----Original Message----- From: ext Harald Skinnemoen [mailto:harald.skinnemoen@nera.no] Sent: Monday, August 18, 2003 5:57 PM To: ip-dvb@erg.abdn.ac.uk Cc: IP-dvb@erg.abdn.ac.uk Subject: Re: Differences between INT and MMT tables for address = resolution? Hi all,=20 I'm looking for some further info on the practical use of the INT = tables. Does anybody know of anyone who has implemented satellite = multicast by using the INT tables?=20 Seems to me the MMT tables are used in at least a couple of systems. I'm = however not sure how users satisfaction is, as it seems to me it can't = offer the same dynamics and flexibility as a terrestrial IP multicast = system.=20 Best regards,=20 /Harald=20 =20 Please respond to ip-dvb@erg.abdn.ac.uk=20 Sent by: owner-ip-dvb@erg.abdn.ac.uk=20 To: IP-dvb@erg.abdn.ac.uk=20 cc: =20 Subject: Differences between INT and MMT tables for address = resolution?=20 Before delving into the DVB archives, does somebody know: a. Where the Multicast Map Table is officially defined ? Is there a DVB reference ? b. What is the relation between the INT (IP/MAC Notification Table) , as defined in ETSI EN Draft 301 192 v1.3.1 (2002-12) ? In addition to = offering unicast/MAC streams/platform concept, is it making the MMT obsolete ? = Is there a reference to minutes of some DVB meeting that explains the = relation between the two ? My understanding is that EN 301 192 v1.3.1 (DVB data broadcasting) = document now includes the document referenced in Gorries report from Atlanta = (ETSI EN drTS 102 00X V0.4.2 (2002-07) "Specification for IP Notification in DVB Systems Use of the IP/MAC Notification Table"). Regards, Frank ------_=_NextPart_001_01C3663E.6F1B53C9 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi=20 Harald et al.
 
Though=20 I'm not exactly up-to-date on this, Astra TRP 1053 seems to carry INT = for=20 unicast (19.2 DegEast, 10.77325 GHz, Horizontal, 22MS/s, 5/6) (a = colleage told=20 me)
 
With=20 reference to Frank's earlier question: INT is now specified and = officially=20 (ETSI) standardised in ETSI EN 301 192 V1.3.1 (2003-05). No other = reference=20 should be used, unless the standard is updated, which can be "polled" = from the=20 www.etsi.org site using the "data=20 broadcasting" string in the keyword search for "get a standard /=20 free download".
 
Given=20 that the specification only became an official ETSI standard in May, it = would=20 suprise me if there are already many implemenations to choose from, = since ETSI=20 works more towards concensus, standard, implementation, rather than the = IETF,=20 implement, concensus, standard. (I am certain there are several=20 proprietry implementations based on one of the proposals before INT = was=20 designed by concesus, which should migrate to INT over=20 time).
 
Does=20 anyone have an MMT reference (to standard or standards contribution)? = Since it=20 is DVB-RCS specific, I had a look at the DVB-RC* ones listed at www.dvb.org (based on the "mmt" and = "multicast" strings):
*=20 DVB-RCC (return channel for cable): ES 200 800; TR101 196 says use = EN 301=20 192 for MAC/IP mapping
*=20 DVB-RCL (return channel for LMDS): EN 301 199; TR 101 205 says use EN = 301 192=20 for MAC/IP mapping
*=20 DVB-RCT (return channel for terrestrial) : EN 301 958 says use EN 301 = 192 for=20 MAC/IP mapping
*=20 DVB-RCG (GSM): EN 301 195 says nothing
*=20 DVB-RCP (PSTN/ISDN): ETS 300 801 says nothing
* DVB:RCCS (SMATV + = measurement=20 guidelines): TR 101 201; TR 101 290 say nothing
 
DVB-RCS: Digital = Video=20 Broadcasting (DVB); Interaction=20 channel for satellite distribution systems) = documents say=20 this:
* ETSI=20 TR 101 790 V1.2.1 (2003-01) - guidelines - says a fair = amount about=20 multicast including: Multicast PID Mapping Table (identified by the Elementary Loop with the = stream=20 type =3D 0x05 and table id =3D 0xA7 in the RCS content = descriptor) parsed=20 from PMT using IP/DVB Service linkage from RCS/Map Table. However, = this=20 Multicast PID Mapping table is neither referenced nor=20 specified.
* ETSI EN 301 = 790 V1.3.1=20 (2003-03) - standard/specification - says=20 nothing
 
(nothing =3D nothing in respect to mmt & = multicast=20 :)
 
Thus I=20 can conclude that MMT =3D Multicast = PID Mapping=20 Table and was = mentioned as=20 recently at January 2003, but not is in the DVB-RCS standard, only in = the=20 guidelines. Does anyone have a reference to the=20 specification?
 
Cheers, Rod.
 
-----Original Message-----
From: ext Harald = Skinnemoen=20 [mailto:harald.skinnemoen@nera.no]
Sent: Monday, August 18, = 2003=20 5:57 PM
To: ip-dvb@erg.abdn.ac.uk
Cc:=20 IP-dvb@erg.abdn.ac.uk
Subject: Re: Differences between INT = and MMT=20 tables for address resolution?


Hi all,

I'm = looking for=20 some further info on the practical use of the INT tables.  Does = anybody=20 know of anyone who has implemented satellite multicast by using the = INT=20 tables?

Seems to me = the MMT tables=20 are used in at least a couple of systems. I'm however not sure how = users=20 satisfaction is, as it seems to me it can't offer the same dynamics = and=20 flexibility as a terrestrial IP multicast system.

Best regards,

/Harald
 

Please respond to=20 ip-dvb@erg.abdn.ac.uk=20

Sent by:   =    =20  owner-ip-dvb@erg.abdn.ac.uk=20

To:     =  =20  IP-dvb@erg.abdn.ac.uk=20
cc:     =    =20

Subject:  =20      Differences between=20  INT and MMT tables for address resolution? =


Before delving into the DVB archives, does somebody=20 know:

a. Where the Multicast Map = Table is=20 officially defined ? Is there a DVB
reference = ?

b. What is the relation between the INT (IP/MAC = Notification Table)=20 , as
defined in ETSI EN Draft 301 192 v1.3.1 (2002-12) ? In = addition to=20 offering
unicast/MAC streams/platform concept, is it  making = the MMT=20 obsolete  ? Is
there a reference to minutes of some DVB = meeting that=20 explains the relation
between the two ?

My understanding is that EN 301 192 v1.3.1 (DVB data = broadcasting)=20  document
now includes the document referenced in Gorries = report from=20 Atlanta (ETSI EN
drTS 102 00X V0.4.2 (2002-07) "Specification for = IP=20 Notification in DVB
Systems Use of the IP/MAC Notification=20 Table").


Regards,=20 Frank




------_=_NextPart_001_01C3663E.6F1B53C9-- From owner-ip-dvb@erg.abdn.ac.uk Tue Aug 19 16:45:14 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7JFigJu018798 for ; Tue, 19 Aug 2003 16:44:42 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h7JFigRc018797 for ip-dvb-subscribed-users; Tue, 19 Aug 2003 16:44:42 +0100 (BST) Date: Tue, 19 Aug 2003 16:44:42 +0100 (BST) Message-Id: <200308191544.h7JFigRc018797@mavis.erg.abdn.ac.uk> X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f From: "Clawson, Michael" To: "'ip-dvb@erg.abdn.ac.uk'" Subject: RE: Differences between INT and MMT tables for address X-MailScanner: Found to be clean resolution? Date: Tue, 19 Aug 2003 11:27:29 -0400 Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk The timing of this is interesting to me as I have recently been wrestling with the same issues... I also have had no luck finding anything on the MMT in the specs other than the reference in i.6.1 of ETSI TR 101 790, but one of our vendors told me that their implementation is based on SatLabs System Recommendations which does include a definition of the MMT. Of special notice to me was the value that they indicate for table_id. They say 0xC0 which would seem, to me at least, to contradict the aforementioned reference to MMT in 101 790 which is 0xA7. Here is the information for their doc: SatLabs System Recommendations Published by: SatLabs c/o Xavier Lobao, ESTEC www.satlabs.org Version 1.1 July 2003 From owner-ip-dvb@erg.abdn.ac.uk Wed Aug 20 11:58:45 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7KAwG2p003283 for ; Wed, 20 Aug 2003 11:58:16 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h7KAwGjd003282 for ip-dvb-subscribed-users; Wed, 20 Aug 2003 11:58:16 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from notesmta.nera.no (notesmta.nera.no [194.19.8.41]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7KAvk2p003252 for ; Wed, 20 Aug 2003 11:57:46 +0100 (BST) In-Reply-To: <2BF0AD29BC31FE46B78877321144043101B9E4D6@trebe003.europe.nokia.com> MIME-Version: 1.0 Sensitivity: To: ip-dvb@erg.abdn.ac.uk Subject: RE: Differences between INT and MMT tables for address resolution? X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: From: Harald Skinnemoen Date: Wed, 20 Aug 2003 12:58:01 +0200 X-MIMETrack: Serialize by Router on NotesMTA/NERA(Release 6.0.1|February 07, 2003) at 20.08.2003 12:55:17, Serialize complete at 20.08.2003 12:55:17 Content-Type: multipart/alternative; boundary="=_alternative 003C615BC1256D88_=" X-MailScanner: Found to be clean, Found to be clean X-MailScanner-SpamScore: s Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk This is a multipart message in MIME format. --=_alternative 003C615BC1256D88_= Content-Type: text/plain; charset="US-ASCII" I can add the following info: The use of MMT was input to the ESA SatLabs group by SES Astra, and in in their Recommendation for DVB-RCS, just recently publihed. It's based on a specific implementation. The "problem", if you wish, with MMT is that it is quite limited, and does not allow a multicast stream to e.g. be split on two more more downlink beams. The use of INT tables does, and can do more than just map IP multicast addresses to PIDs as I understand. The SatLabs doc (which can be freely downloaded from the ESA/Estec website) says IGMP is not to be used over the satelilte link, only locally. Both options appear to be (with my limited knowledge) restricted to (or at least best suited for) static multicast, where a service provider predefines a set of groups that a user can wish to subscribe to or not. If your favorite group is not there, then it's not obvious how you can ask for it in an integrated process. Further, it seems to me that one risks sending groups with no listeners (I may be wrong here, so I'm happy for any input). I'm basically looking for ways of doing dynamic multicast over DVB-RCS, and how this would potentially interact with MMT and INT (or even other ways if relevant) I am working with a spec on this topic for ETSI (WG BSM), and looking for input and information on DVB-RCS and multicast in general. Also - Nera (where I work) has done some work on dynamic multicast, but in this case all multicast is sent with one and the same PID. Any info is appreciated. /harald Please respond to ip-dvb@erg.abdn.ac.uk Sent by: owner-ip-dvb@erg.abdn.ac.uk To: cc: (bcc: Harald Skinnemoen/NOBBA/NERA) Subject: RE: Differences between INT and MMT tables for address resolution? Hi Harald et al. Though I'm not exactly up-to-date on this, Astra TRP 1053 seems to carry INT for unicast (19.2 DegEast, 10.77325 GHz, Horizontal, 22MS/s, 5/6) (a colleage told me) With reference to Frank's earlier question: INT is now specified and officially (ETSI) standardised in ETSI EN 301 192 V1.3.1 (2003-05). No other reference should be used, unless the standard is updated, which can be "polled" from the www.etsi.org site using the "data broadcasting" string in the keyword search for "get a standard / free download". Given that the specification only became an official ETSI standard in May, it would suprise me if there are already many implemenations to choose from, since ETSI works more towards concensus, standard, implementation, rather than the IETF, implement, concensus, standard. (I am certain there are several proprietry implementations based on one of the proposals before INT was designed by concesus, which should migrate to INT over time). Does anyone have an MMT reference (to standard or standards contribution)? Since it is DVB-RCS specific, I had a look at the DVB-RC* ones listed at www.dvb.org (based on the "mmt" and "multicast" strings): * DVB-RCC (return channel for cable): ES 200 800; TR101 196 says use EN 301 192 for MAC/IP mapping * DVB-RCL (return channel for LMDS): EN 301 199; TR 101 205 says use EN 301 192 for MAC/IP mapping * DVB-RCT (return channel for terrestrial) : EN 301 958 says use EN 301 192 for MAC/IP mapping * DVB-RCG (GSM): EN 301 195 says nothing * DVB-RCP (PSTN/ISDN): ETS 300 801 says nothing * DVB:RCCS (SMATV + measurement guidelines): TR 101 201; TR 101 290 say nothing DVB-RCS: Digital Video Broadcasting (DVB); Interaction channel for satellite distribution systems) documents say this: * ETSI TR 101 790 V1.2.1 (2003-01) - guidelines - says a fair amount about multicast including: Multicast PID Mapping Table (identified by the Elementary Loop with the stream type = 0x05 and table id = 0xA7 in the RCS content descriptor) parsed from PMT using IP/DVB Service linkage from RCS/Map Table. However, this Multicast PID Mapping table is neither referenced nor specified. * ETSI EN 301 790 V1.3.1 (2003-03) - standard/specification - says nothing (nothing = nothing in respect to mmt & multicast :) Thus I can conclude that MMT = Multicast PID Mapping Table and was mentioned as recently at January 2003, but not is in the DVB-RCS standard, only in the guidelines. Does anyone have a reference to the specification? Cheers, Rod. -----Original Message----- From: ext Harald Skinnemoen [mailto:harald.skinnemoen@nera.no] Sent: Monday, August 18, 2003 5:57 PM To: ip-dvb@erg.abdn.ac.uk Cc: IP-dvb@erg.abdn.ac.uk Subject: Re: Differences between INT and MMT tables for address resolution? Hi all, I'm looking for some further info on the practical use of the INT tables. Does anybody know of anyone who has implemented satellite multicast by using the INT tables? Seems to me the MMT tables are used in at least a couple of systems. I'm however not sure how users satisfaction is, as it seems to me it can't offer the same dynamics and flexibility as a terrestrial IP multicast system. Best regards, /Harald Please respond to ip-dvb@erg.abdn.ac.uk Sent by: owner-ip-dvb@erg.abdn.ac.uk To: IP-dvb@erg.abdn.ac.uk cc: Subject: Differences between INT and MMT tables for address resolution? Before delving into the DVB archives, does somebody know: a. Where the Multicast Map Table is officially defined ? Is there a DVB reference ? b. What is the relation between the INT (IP/MAC Notification Table) , as defined in ETSI EN Draft 301 192 v1.3.1 (2002-12) ? In addition to offering unicast/MAC streams/platform concept, is it making the MMT obsolete ? Is there a reference to minutes of some DVB meeting that explains the relation between the two ? My understanding is that EN 301 192 v1.3.1 (DVB data broadcasting) document now includes the document referenced in Gorries report from Atlanta (ETSI EN drTS 102 00X V0.4.2 (2002-07) "Specification for IP Notification in DVB Systems Use of the IP/MAC Notification Table"). Regards, Frank --=_alternative 003C615BC1256D88_= Content-Type: text/html; charset="US-ASCII"
I can add the following info:

The use of MMT was input to the ESA SatLabs group by SES Astra, and in in their Recommendation for DVB-RCS, just recently publihed. It's based on a specific implementation. The "problem", if you wish, with MMT is that it is quite limited, and does not allow a multicast stream to e.g. be split on two more more downlink beams. The use of INT tables does, and can do more than just map IP multicast addresses to PIDs as I understand. The SatLabs doc (which can be freely downloaded from the ESA/Estec website) says IGMP is not to be used over the satelilte link, only locally.

Both options appear to be (with my limited knowledge) restricted to (or at least best suited for) static multicast, where a service provider predefines a set of groups that a user can wish to subscribe to or not. If your favorite group is not there, then it's not obvious how you can ask for it in an integrated process. Further, it seems to me that one risks sending groups with no listeners (I may be wrong here, so I'm happy for any input).

I'm basically looking for ways of doing dynamic multicast over DVB-RCS, and how this would potentially interact with MMT and INT (or even other ways if relevant)

I am working with a spec on this topic for ETSI (WG BSM), and looking for input and information on DVB-RCS and multicast in general. Also - Nera (where I work) has done some work on dynamic multicast, but in this case all multicast is sent with one and the same PID.

Any info is appreciated.

/harald



Please respond to ip-dvb@erg.abdn.ac.uk

Sent by:        owner-ip-dvb@erg.abdn.ac.uk

To:        <ip-dvb@erg.abdn.ac.uk>
cc:         (bcc: Harald Skinnemoen/NOBBA/NERA)

Subject:        RE: Differences between INT and MMT tables for address resolution?

Hi Harald et al.
 
Though I'm not exactly up-to-date on this, Astra TRP 1053 seems to carry INT for unicast (19.2 DegEast, 10.77325 GHz, Horizontal, 22MS/s, 5/6) (a colleage told me)
 
With reference to Frank's earlier question: INT is now specified and officially (ETSI) standardised in ETSI EN 301 192 V1.3.1 (2003-05). No other reference should be used, unless the standard is updated, which can be "polled" from the www.etsi.org site using the "data broadcasting" string in the keyword search for "get a standard / free download".
 
Given that the specification only became an official ETSI standard in May, it would suprise me if there are already many implemenations to choose from, since ETSI works more towards concensus, standard, implementation, rather than the IETF, implement, concensus, standard. (I am certain there are several proprietry implementations based on one of the proposals before INT was designed by concesus, which should migrate to INT over time).
 
Does anyone have an MMT reference (to standard or standards contribution)? Since it is DVB-RCS specific, I had a look at the DVB-RC* ones listed at www.dvb.org (based on the "mmt" and "multicast" strings):
* DVB-RCC (return channel for cable): ES 200 800; TR101 196 says use EN 301 192 for MAC/IP mapping
* DVB-RCL (return channel for LMDS): EN 301 199; TR 101 205 says use EN 301 192 for MAC/IP mapping
* DVB-RCT (return channel for terrestrial) : EN 301 958 says use EN 301 192 for MAC/IP mapping
* DVB-RCG (GSM): EN 301 195 says nothing
* DVB-RCP (PSTN/ISDN): ETS 300 801 says nothing
* DVB:RCCS (SMATV + measurement guidelines): TR 101 201; TR 101 290 say nothing
 
DVB-RCS: Digital Video Broadcasting (DVB); Interaction channel for satellite distribution systems) documents say this:
* ETSI TR 101 790 V1.2.1 (2003-01) - guidelines - says a fair amount about multicast including: Multicast PID Mapping Table (identified by the Elementary Loop with the stream type = 0x05 and table id = 0xA7 in the RCS content descriptor) parsed from PMT using IP/DVB Service linkage from RCS/Map Table. However, this Multicast PID Mapping table is neither referenced nor specified.
* ETSI EN 301 790 V1.3.1 (2003-03) - standard/specification - says nothing
 
(nothing = nothing in respect to mmt & multicast :)
 
Thus I can conclude that MMT = Multicast PID Mapping Table and was mentioned as recently at January 2003, but not is in the DVB-RCS standard, only in the guidelines. Does anyone have a reference to the specification?
 
Cheers, Rod.
 
-----Original Message-----
From: ext Harald Skinnemoen [mailto:harald.skinnemoen@nera.no]
Sent: Monday, August 18, 2003 5:57 PM
To: ip-dvb@erg.abdn.ac.uk
Cc: IP-dvb@erg.abdn.ac.uk
Subject: Re: Differences between INT and MMT tables for address resolution?

Hi all,

I'm looking for some further info on the practical use of the INT tables.  Does anybody know of anyone who has implemented satellite multicast by using the INT tables?

Seems to me the MMT tables are used in at least a couple of systems. I'm however not sure how users satisfaction is, as it seems to me it can't offer the same dynamics and flexibility as a terrestrial IP multicast system.

Best regards,

/Harald
 

Please respond to ip-dvb@erg.abdn.ac.uk

Sent by:        owner-ip-dvb@erg.abdn.ac.uk

To:        IP-dvb@erg.abdn.ac.uk
cc:        

Subject:        Differences between  INT and MMT tables for address resolution?


Before delving into the DVB archives, does somebody know:

a. Where the Multicast Map Table is officially defined ? Is there a DVB
reference ?

b. What is the relation between the INT (IP/MAC Notification Table) , as
defined in ETSI EN Draft 301 192 v1.3.1 (2002-12) ? In addition to offering
unicast/MAC streams/platform concept, is it  making the MMT obsolete  ? Is
there a reference to minutes of some DVB meeting that explains the relation
between the two ?

My understanding is that EN 301 192 v1.3.1 (DVB data broadcasting)  document
now includes the document referenced in Gorries report from Atlanta (ETSI EN
drTS 102 00X V0.4.2 (2002-07) "Specification for IP Notification in DVB
Systems Use of the IP/MAC Notification Table").


Regards, Frank

--=_alternative 003C615BC1256D88_=-- From owner-ip-dvb@erg.abdn.ac.uk Wed Aug 20 13:48:34 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7KClt2p007745 for ; Wed, 20 Aug 2003 13:47:55 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h7KClskr007744 for ip-dvb-subscribed-users; Wed, 20 Aug 2003 13:47:55 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7KClc2p007726 for ; Wed, 20 Aug 2003 13:47:38 +0100 (BST) Message-ID: <3F436DEB.4FFCA94F@erg.abdn.ac.uk> Date: Wed, 20 Aug 2003 13:47:38 +0100 From: Dr G Fairhurst Organization: ERG, Aberdeen, UK X-Mailer: Mozilla 4.77C-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: "ule" and last byte References: <3F3B31E9.5020204@6wind.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk See my thoughts in-line: alain.ritoux@6wind.com wrote: > > Precision about the "ule" method wrt the last byte > > The sentence (p11) > "If the TS packet carrying the final part of SNDU has either > 0 or 1 byte of unused payload, the encapsulator will start > transmission of the next SNDU in a new TS packet". > > I think it is to allow enough room for the payload pointer, > is this correct, or is there any other motivation ? Yes, you are correct, there are two issues, and I can see three scenarios: (i) There is a corner case, where the payload has 1 byte left, and no PUSI previously set (i.e. where the TS Packet contains only the end of a SNDU that was started in a previous TS Packet). In this case, the SNDU may wish to set the PUSI, and this will incur a 1B payload pointer (to be inserted after the TS Packet header) - the value should be the position of the first byte of the SNDU within the TS Packey payload, however, addition of the Payload start pointer, has "eaten" the byte to be used, and the SNDU may not now be started within the current TS Packet. (ii) An encapsulator that has no more data to send may wish to signal this. The normal procedure is to stuff/PAD. Suppose the encapsulator has two bytes left, but the PUSI was not set. So the first byte would be used for the Payload start, leaving one byte for Payload data. ULE howver defines a padding sequence that is 2 bytes long, with only one byte spare, this would imply sending one byte at the last position in a TS Packet and the second as the first byte of a continuation TS packet. (The remainder of this continuation packet would then be discarded). This seems complex. (iii) There is a varient of the above where one byte is left, and the PUSI was set (and hence a paylaod start pointer was already present in the current TS Packet, however the encapsulator has no more data and wishes to send a 2B "PAD/Idle" value. The diagrams in: http://www.erg.abdn.ac.uk/ip-dvb/meetings/IETF-57-Vienna/ (presented in Vienna) may help. This requires a new rule to say what to do. I proposed that we add a rule that says that the receiver NEVER uses the last two bytes of the TS Packet Payload, if a SNDU finishes leaving two or less bytes of unused payload. In the worst case, this ammounts to an extra ~1% overhead, normally traffic patterns will make it is much less. > Does this includes the payload pointer ? > I mean : > (MPEG_HDR)(End of SNDU-A)[1 byte left] ==> OK send it now > but, in the following case > (MPEG_HDR)(End of SNDU-A)[2 bytes left] > it will become, with a SNDU-B > (MPEG_HDR)(Payload Pointer)(End of SNDU-A)(start SNDU-B) > ^^^^^^^^^^^^^^ > Only 1 byte ! > so, was it to be sent at once, or is the second TS cell legal ? > because in the second case, it would mean that the SNDU length > is not yet available, until a second TS cell is received, which > is not really a pleasant thing. > > 1) If having the SNDU length split over 2 cell is a pb, then the > sentence should more replaced with something like : > > "If there is not enough room in a TS packet to put the first > 2 bytes of an SNDU (possibly due to the needed payload pointer), > the encapsulator will start transmission of this SNDU in a new > TS packet. The remaining bytes, MUST be set ...." > > 2) if such a length split is not a pb, then first sentence is a bit > hard because, in case of multiple SNDU in a single TS cell, there > is not the payload pointer pb : > (MPEG_HDR)(End of SNDU-A)(SNDU-B)[1 byte left] > OK keep it, because SDNU-C can start in this TS_cell : > (MPEG_HDR)(End of SNDU-A)(SNDU-B)(start SNDU-C) > ^^^^^^^^^^^^^^^ > 1 byte > hence the sentence could be rephrased into something like > "If the TS packet carrying the final part of SNDU has either > 0 or 1 byte of unused payload and the PUSI bit clear, the > encapsulator will start transmission of the next SNDU in a new > TS packet". > so it would relax the condition when PUSI bit is set, i.e. > there won't be other payload pointer added. > > I would prefer solution 1) > Your thoughts ? > If we tell the receiver that a SNDU never starts in the last two bytes of a TS Packet, there is no need for complex logic to set the PUSI, and cope with the possibility of a split "length/pad" sequence over a TS Packet Payload Boundary... > Regards. > Alain. > -- > Alain RITOUX > Tel +33-1-39-30-92-32 > Fax +33-1-39-30-92-11 > visit our web http://www.6wind.com From owner-ip-dvb@erg.abdn.ac.uk Wed Aug 20 15:56:30 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7KEu52p012985 for ; Wed, 20 Aug 2003 15:56:05 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h7KEu5vg012984 for ip-dvb-subscribed-users; Wed, 20 Aug 2003 15:56:05 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from proxy.6wind.com (proxy.6wind.com [194.250.197.211]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7KEtK2p012938 for ; Wed, 20 Aug 2003 15:55:21 +0100 (BST) Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id 81B1B3C5 for ; Wed, 20 Aug 2003 16:55:21 +0200 (CEST) Received: from 6wind.com (vouvray.dev.6wind.com [10.16.0.135]) by intranet.6wind.com (Postfix) with ESMTP id 65B03622; Wed, 20 Aug 2003 16:55:21 +0200 (CEST) Message-ID: <3F438C99.1040806@6wind.com> Date: Wed, 20 Aug 2003 16:58:33 +0200 From: alain.ritoux@6wind.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Re: "ule" and last byte References: <3F3B31E9.5020204@6wind.com> <3F436DEB.4FFCA94F@erg.abdn.ac.uk> In-Reply-To: <3F436DEB.4FFCA94F@erg.abdn.ac.uk> X-Enigmail-Version: 0.71.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Cmoments inside Dr G Fairhurst wrote: > See my thoughts in-line: > > alain.ritoux@6wind.com wrote: > >>Precision about the "ule" method wrt the last byte >> >>The sentence (p11) >>"If the TS packet carrying the final part of SNDU has either >>0 or 1 byte of unused payload, the encapsulator will start >>transmission of the next SNDU in a new TS packet". >> >>I think it is to allow enough room for the payload pointer, >>is this correct, or is there any other motivation ? > > > Yes, you are correct, there are two issues, and I can see three > scenarios: > > (i) There is a corner case, where the payload has 1 byte left, > and no PUSI previously set (i.e. where the TS Packet contains > only the end of a SNDU that was started in a previous TS Packet). > > In this case, the SNDU may wish to set the PUSI, and this will > incur a 1B payload pointer (to be inserted after the TS Packet > header) - the value should be the position of the first byte > of the SNDU within the TS Packey payload, however, addition of > the Payload start pointer, has "eaten" the byte to be used, and > the SNDU may not now be started within the current TS Packet. > > (ii) An encapsulator that has no more data to send may wish to > signal this. The normal procedure is to stuff/PAD. > > Suppose the encapsulator has two bytes left, but the PUSI > was not set. So the first byte would be used for the Payload > start, leaving one byte for Payload data. ULE howver defines > a padding sequence that is 2 bytes long, with only > one byte spare, this would imply sending one byte at the last > position in a TS Packet and the second as the first byte of > a continuation TS packet. (The remainder of this continuation > packet would then be discarded). This seems complex. I don't see it as a pb, for my understanding that such a padding was only needed if a next SNDU could start in the following bytes. but in this case, the rule about having 1 byte or less available already forbids the sender to start a new SNDU. > > (iii) There is a varient of the above where one byte is left, > and the PUSI was set (and hence a paylaod start pointer was > already present in the current TS Packet, however the encapsulator > has no more data and wishes to send a 2B "PAD/Idle" value. This is already covered by the fact that there is only one byte left, and so a new TS cell MUST be used, and the reciever using the same rule won't expect a new SNDU > > The diagrams in: > http://www.erg.abdn.ac.uk/ip-dvb/meetings/IETF-57-Vienna/ > (presented in Vienna) may help. Ooops, I hought they were teh commented parts of the ULE drafts and didn"t read them carefully :-( > > This requires a new rule to say what to do. > > I proposed that we add a rule that says that the receiver > NEVER uses the last two bytes of the TS Packet Payload, if a > SNDU finishes leaving two or less bytes of unused payload. In the > worst case, this ammounts to an extra ~1% overhead, normally > traffic patterns will make it is much less. Maybe it is not necessary to forbid usage of the last 2 bytes, but only to the last byte hence can be restricted to : "The receiver NEVER uses the last byte of a TS Packet Payload if a SNDU finishes leaving one or less byte of unused payload." so it is possible to start a new SNDU with exaclty the SNDU length, is saves one byte, .... I feel I'm starting to get greedy about bytes ;-) Whatever, the sending rule should also be changed, because the current one only speak about the bytes left after putting and SNDU, and doens't explicitly see the payload_pointer pb. So it is better to speak about how many bytes of the next SNDU can be stored : "If there is not enough room in a TS packet to put the first 2 bytes of an SNDU (possibly due to the needed payload pointer), the encapsulator will start transmission of this SNDU in a new TS packet. The remaining bytes, MUST be set ...." This in my opinion should solve everything, - always enough place for padding with end-indicator - no length split (not really cool to manage) - no corner case in sight ;-) but maybe the avoidance of the last 2 bytes helps avoiding another pb I haven't seen ? Regards. Alain. -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com From owner-ip-dvb@erg.abdn.ac.uk Thu Aug 21 12:44:47 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7LBi22p028784 for ; Thu, 21 Aug 2003 12:44:02 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h7LBi1LU028783 for ip-dvb-subscribed-users; Thu, 21 Aug 2003 12:44:01 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7LBhd2p028747 for ; Thu, 21 Aug 2003 12:43:39 +0100 (BST) Message-ID: <3F44B06C.BA00A38B@erg.abdn.ac.uk> Date: Thu, 21 Aug 2003 12:43:41 +0100 From: Dr G Fairhurst Organization: ERG, Aberdeen, UK X-Mailer: Mozilla 4.77C-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: How does MPE handle the last byte? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Before we suggest a strategy for the new encapsulation formats, can someone tell me what happens in real implementations when MPE employs section packing (i.e. is allowed to start a new encapsulated MPE packet following the rpeviosu in the same MPEG-2 TS Packet). Problem case: When TS Packet payload is nearly full... i.e. when a SNDI (IP packet, etc) occupies all but the last byte of the final MPEG-2 TS-Packet Payload, and there is another IP packet waiting to be sent. What does the encapsulator do if this TS-Packet has no PUSI set, since setting the PUSI flag implies that encapsulator would also include a Payload start pointer in the first position after the TS-Packet header. This pointer consumes the last byte... leaving nothing for it to point at. A picture: +----------------------\\------------------+--+ |........................ \\ SNDU..........|XX| +--------------------------\\--------------+--+ ^ | NO PUSI - and Hence no payload pointer here. Gorry From owner-ip-dvb@erg.abdn.ac.uk Thu Aug 21 13:39:27 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7LCd6Gm001499 for ; Thu, 21 Aug 2003 13:39:06 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h7LCd5HT001497 for ip-dvb-subscribed-users; Thu, 21 Aug 2003 13:39:05 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7LCcgGn001471 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 21 Aug 2003 13:38:43 +0100 (BST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h7LCcgB15066 for ; Thu, 21 Aug 2003 15:38:42 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 21 Aug 2003 15:38:42 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 21 Aug 2003 15:38:42 +0300 Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 21 Aug 2003 15:38:41 +0300 Received: from trebe004.NOE.Nokia.com ([172.22.232.177]) by esebe015.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 21 Aug 2003 15:38:41 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: How does MPE handle the last byte? Date: Thu, 21 Aug 2003 15:38:41 +0300 Message-ID: <481D6FFB3BD60E4CB590F39C5909840001E43CEB@trebe004.europe.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: How does MPE handle the last byte? Thread-Index: AcNn3E+LzZwFstGVTzSkJBqabH06AAAAcPVA From: To: X-OriginalArrivalTime: 21 Aug 2003 12:38:41.0750 (UTC) FILETIME=[27150F60:01C367E1] X-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 h7LCd30S001494 Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Hi Gorry et al., Just a comment that including a pointer in a TS packet that did not contain at least the first byte of a new section would seem to be against the MPEG-2 spec. Quoting 2.4.4.1 of ISO 13818-1, "When no section begins in a given Transport Stream packet, then the payload_unit_start_indicator shall be set to 0 and no pointer shall be sent in the payload of that packet." Best regards, Juha-Pekka Luoma Nokia Research Center -----Original Message----- From: ext Dr G Fairhurst [mailto:gorry@erg.abdn.ac.uk] Sent: 21 August, 2003 14:44 To: ip-dvb@erg.abdn.ac.uk Subject: How does MPE handle the last byte? Before we suggest a strategy for the new encapsulation formats, can someone tell me what happens in real implementations when MPE employs section packing (i.e. is allowed to start a new encapsulated MPE packet following the rpeviosu in the same MPEG-2 TS Packet). Problem case: When TS Packet payload is nearly full... i.e. when a SNDI (IP packet, etc) occupies all but the last byte of the final MPEG-2 TS-Packet Payload, and there is another IP packet waiting to be sent. What does the encapsulator do if this TS-Packet has no PUSI set, since setting the PUSI flag implies that encapsulator would also include a Payload start pointer in the first position after the TS-Packet header. This pointer consumes the last byte... leaving nothing for it to point at. A picture: +----------------------\\------------------+--+ |........................ \\ SNDU..........|XX| +--------------------------\\--------------+--+ ^ | NO PUSI - and Hence no payload pointer here. Gorry From owner-ip-dvb@erg.abdn.ac.uk Thu Aug 21 14:07:34 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7LD6lGm002728 for ; Thu, 21 Aug 2003 14:06:47 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h7LD6k26002724 for ip-dvb-subscribed-users; Thu, 21 Aug 2003 14:06:47 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from ra.udcast.com (IDENT:root@vlm6a1-150.n.club-internet.fr [212.195.38.150]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7LD5qGm002670 for ; Thu, 21 Aug 2003 14:05:53 +0100 (BST) Received: (from pplc@localhost) by ra.udcast.com (8.11.0/8.11.0) id h7LD4sN04965; Thu, 21 Aug 2003 15:04:54 +0200 Date: Thu, 21 Aug 2003 15:04:54 +0200 Message-Id: <200308211304.h7LD4sN04965@ra.udcast.com> From: Patrick Cipiere To: ip-dvb@erg.abdn.ac.uk In-reply-to: <3F44B06C.BA00A38B@erg.abdn.ac.uk> (message from Dr G Fairhurst on Thu, 21 Aug 2003 12:43:41 +0100) Subject: Re: How does MPE handle the last byte? X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk > What does the encapsulator do if this TS-Packet has no PUSI > set, since setting the PUSI flag implies that encapsulator > would also include a Payload start pointer in the first > position after the TS-Packet header. This pointer consumes > the last byte... leaving nothing for it to point at. >From ISO/IEC 13818-1 -------------------- 2.4.4.2 Semantics definition of fields in pointer syntax pointer_field This is an 8-bit field whose value shall be the number of bytes, immediately following the pointer_field until the first byte of the first section that is present in the payload of the Transport Stream packet (so a value of 0x00 in the pointer_field indicates that the section starts immediately after the pointer_field). When at least one section begins in a given Transport Stream packet, then the payload_unit_start_indicator (refer to 2.4.3.2) shall be set to 1 and the first byte of the payload of that Transport Stream packet shall contain the pointer. When no section begins in a given Transport Stream packet, then the payload_unit_start_indicator shall be set to 0 and no pointer shall be sent in the payload of that packet. My understanding, and my implementation: 1)if we have only 1 byte left, and no PUSI bit already set, i do not think we can do anything with this byte. This even can't be ISO/IEC 13818-1 conformant, because we have to shift the current payload by one byte, set the PUSI bit to one and set the pointer_field to 183, which points outside of the transport packet paylaod ... 2)if we have only 2 bytes left, and no PUSI bit already set, we could use these 2 bytes. Shift the the current payload by one byte, set the PUSI bit to one and set the pointer_field to 182, and have the first byte of the new payload unit in the last byte of the transport packet. Then is is a matter of space vs cpu decision: move 182 bytes to save 1 byte for the bandwidth's sake. This will depend on the cpu cycles available on the encapsulator. Anyway, the receiver/decoder must be able to deal with such situations. 1) is an error: pointer outside of the transport packet 2) is OK 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 owner-ip-dvb@erg.abdn.ac.uk Thu Aug 21 14:20:04 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7LD6pGm002736 for ; Thu, 21 Aug 2003 14:06:51 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h7LD6puJ002735 for ip-dvb-subscribed-users; Thu, 21 Aug 2003 14:06:51 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7LD61Gm002685 for ; Thu, 21 Aug 2003 14:06:01 +0100 (BST) Message-ID: <3F44C3BB.834A513F@erg.abdn.ac.uk> Date: Thu, 21 Aug 2003 14:06:03 +0100 From: Dr G Fairhurst Organization: ERG, Aberdeen, UK X-Mailer: Mozilla 4.77C-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: How does MPE handle the last byte? References: <481D6FFB3BD60E4CB590F39C5909840001E43CEB@trebe004.europe.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Quite so. I didn't mean to imply that, I wanted to make sure we understood what SHOULD happen if the MPEG-2 TS-Packet didn't contain a pointer, i.e. it had one byte of payload left, *AND* the encapsulator was configured to start the next payload directly folloiwng the previous (what I call "section packing"). So, after processing the end of the payload section, the packet has no pointer (and PUSI==0), and one spare byte. To start a new payload, it needs to set PUSI=1, and include a 1 B pointer - but that consumes the last byte, so it's silly. What happens? Gorry juha-pekka.luoma@nokia.com wrote: > > Hi Gorry et al., > > Just a comment that including a pointer in a TS packet that did not contain at least the first byte of a new section would seem to be against the MPEG-2 spec. Quoting 2.4.4.1 of ISO 13818-1, > > "When no section begins in a given Transport Stream packet, then the payload_unit_start_indicator shall be set to 0 and no pointer shall be sent in the payload of that packet." > > Best regards, > > Juha-Pekka Luoma > Nokia Research Center > > -----Original Message----- > From: ext Dr G Fairhurst [mailto:gorry@erg.abdn.ac.uk] > Sent: 21 August, 2003 14:44 > To: ip-dvb@erg.abdn.ac.uk > Subject: How does MPE handle the last byte? > > Before we suggest a strategy for the new encapsulation formats, > can someone tell me what happens in real implementations when MPE > employs section packing (i.e. is allowed to start a new encapsulated > MPE packet following the rpeviosu in the same MPEG-2 TS Packet). > > Problem case: > > When TS Packet payload is nearly full... i.e. when > a SNDI (IP packet, etc) occupies all but the last byte of > the final MPEG-2 TS-Packet Payload, and there is another > IP packet waiting to be sent. > > What does the encapsulator do if this TS-Packet has no PUSI > set, since setting the PUSI flag implies that encapsulator > would also include a Payload start pointer in the first > position after the TS-Packet header. This pointer consumes > the last byte... leaving nothing for it to point at. > > A picture: > > +----------------------\\------------------+--+ > |........................ \\ SNDU..........|XX| > +--------------------------\\--------------+--+ > > ^ > | > NO PUSI - and Hence no payload pointer here. > > Gorry From owner-ip-dvb@erg.abdn.ac.uk Thu Aug 21 14:37:12 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7LDaNGm003789 for ; Thu, 21 Aug 2003 14:36:23 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h7LDaNfA003788 for ip-dvb-subscribed-users; Thu, 21 Aug 2003 14:36:23 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7LDZoGm003738 for ; Thu, 21 Aug 2003 14:35:50 +0100 (BST) Message-ID: <3F44CAB8.AB2EA136@erg.abdn.ac.uk> Date: Thu, 21 Aug 2003 14:35:52 +0100 From: Dr G Fairhurst Organization: ERG, Aberdeen, UK X-Mailer: Mozilla 4.77C-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: How does MPE handle the last byte? References: <200308211304.h7LD4sN04965@ra.udcast.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk OK, seems clear to me. So, if I understand this, it means: The receiver stops processing the MPEG-2 TS Packet Payload after it has processed the end of the MPE Section, when there is no PUSI set. That is, it will silently discard the last (unused) byte in the example below? Gorry Patrick Cipiere wrote: > > > What does the encapsulator do if this TS-Packet has no PUSI > > set, since setting the PUSI flag implies that encapsulator > > would also include a Payload start pointer in the first > > position after the TS-Packet header. This pointer consumes > > the last byte... leaving nothing for it to point at. > > >From ISO/IEC 13818-1 > -------------------- > 2.4.4.2 Semantics definition of fields in pointer syntax pointer_field > This is an 8-bit field whose value shall be the number of bytes, > immediately following the pointer_field until the first byte of the > first section that is present in the payload of the Transport Stream > packet (so a value of 0x00 in the pointer_field indicates that the > section starts immediately after the pointer_field). When at least one > section begins in a given Transport Stream packet, then the > payload_unit_start_indicator (refer to 2.4.3.2) shall be set to 1 and > the first byte of the payload of that Transport Stream packet shall > contain the pointer. When no section begins in a given Transport > Stream packet, then the payload_unit_start_indicator shall be set to 0 > and no pointer shall be sent in the payload of that packet. > > My understanding, and my implementation: > > 1)if we have only 1 byte left, and no PUSI bit already set, i do not > think we can do anything with this byte. > This even can't be ISO/IEC 13818-1 conformant, because we have to > shift the current payload by one byte, set the PUSI bit to one and > set the pointer_field to 183, which points outside of the transport > packet paylaod ... > > 2)if we have only 2 bytes left, and no PUSI bit already set, we could > use these 2 bytes. > Shift the the current payload by one byte, set the PUSI bit to one and > set the pointer_field to 182, and have the first byte of the new > payload unit in the last byte of the transport packet. > Then is is a matter of space vs cpu decision: move 182 bytes to save > 1 byte for the bandwidth's sake. > This will depend on the cpu cycles available on the encapsulator. > > Anyway, the receiver/decoder must be able to deal with such > situations. > 1) is an error: pointer outside of the transport packet > 2) is OK > > 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 owner-ip-dvb@erg.abdn.ac.uk Thu Aug 21 14:25:05 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7LDOjGm003400 for ; Thu, 21 Aug 2003 14:24:45 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h7LDOjAX003399 for ip-dvb-subscribed-users; Thu, 21 Aug 2003 14:24:45 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from esacom57-int.estec.esa.int (esacom57-ext.estec.esa.int [131.176.107.4]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7LDONGm003364 for ; Thu, 21 Aug 2003 14:24:23 +0100 (BST) Received: from esacom52.estec.esa.int (esacom52.estec.esa.int [131.176.7.7]) by esacom57-int.estec.esa.int (8.12.9/8.12.9/ESA-External-v3.2) with ESMTP id h7LDOI7f012773 for ; Thu, 21 Aug 2003 15:24:18 +0200 (MET DST) Received: from estecmta1.estec.esa.int (estecmta1.estec.esa.int [131.176.1.131]) by esacom52.estec.esa.int (8.12.9/8.12.9/ESA-Internal-v3.2) with ESMTP id h7LDOHi1023747 for ; Thu, 21 Aug 2003 15:24:17 +0200 (MET DST) Subject: RE: Differences between INT and MMT tables for address resolution? To: ip-dvb@erg.abdn.ac.uk X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: Frank.Zeppenfeldt@esa.int Date: Thu, 21 Aug 2003 15:24:16 +0100 X-MIMETrack: Serialize by Router on estecmta1/estec/ESA(Release 5.0.11 |July 24, 2002) at 21/08/2003 03:24:17 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Dear Harald, a. I can also add, recalling the discussion within SatLabs (www.satlabs.org) on the INT/MMT topic, additional conclusions of the SatLabs meeting on 1/2 April 2003 were that the INT table : - is just too complicated. Already now people have different interpretations on how to use it, - allows not enough dynamics: multiple tables need to be scanned when e.g. a new service/multicast group is introduced in the network, - needs an official platform_id registration at DVB bodies: this means delay and paperwork. Therefore, MMT was preferred as a first step for interoperability between DVB-RCS Hubs/Terminals. b. Concerning the MMT dynamics, in a future regenerative DVB-RCS system to be launched in 2004, the MMT will be used, and by allowing IGMP to travel over the satellite link and let the NCC update the MMT accordingly some degree of dynamics can be achieved. Regards, Frank Frank.Zeppenfeldt@esa.int http://telecom.esa.int/ From owner-ip-dvb@erg.abdn.ac.uk Thu Aug 21 14:44:30 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7LDhWGm004030 for ; Thu, 21 Aug 2003 14:43:32 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h7LDhW1Z004028 for ip-dvb-subscribed-users; Thu, 21 Aug 2003 14:43:32 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from Outgoing-SMTP.gilat.com ([199.203.106.52]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7LDh8Gm004007 for ; Thu, 21 Aug 2003 14:43:08 +0100 (BST) Received: from mail.gilat.com (unverified) by Outgoing-SMTP.gilat.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 21 Aug 2003 16:39:23 +0200 Received: by mail.gilat.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Aug 2003 16:34:11 +0200 Message-ID: <4937F3760ADC614BA4C8F1642FF911CE01A71CEE@gexd> From: Dor Snapir - Israel To: "'ip-dvb@erg.abdn.ac.uk'" Subject: RE: How does MPE handle the last byte? Date: Thu, 21 Aug 2003 16:38:37 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-8" X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk I am using SkyStream SMR24 and here's what it does: If there is only one byte left, it will reset the PUSI to zero and insert FF in the last byte If there are two bytes left it will set the PUSI to 1 and the last byte to 3E (table ID) Dor -----Original Message----- From: Dr G Fairhurst [mailto:gorry@erg.abdn.ac.uk] Sent: Thursday, August 21, 2003 1:44 PM To: ip-dvb@erg.abdn.ac.uk Subject: How does MPE handle the last byte? Before we suggest a strategy for the new encapsulation formats, can someone tell me what happens in real implementations when MPE employs section packing (i.e. is allowed to start a new encapsulated MPE packet following the rpeviosu in the same MPEG-2 TS Packet). Problem case: When TS Packet payload is nearly full... i.e. when a SNDI (IP packet, etc) occupies all but the last byte of the final MPEG-2 TS-Packet Payload, and there is another IP packet waiting to be sent. What does the encapsulator do if this TS-Packet has no PUSI set, since setting the PUSI flag implies that encapsulator would also include a Payload start pointer in the first position after the TS-Packet header. This pointer consumes the last byte... leaving nothing for it to point at. A picture: +----------------------\\------------------+--+ |........................ \\ SNDU..........|XX| +--------------------------\\--------------+--+ ^ | NO PUSI - and Hence no payload pointer here. Gorry From owner-ip-dvb@erg.abdn.ac.uk Thu Aug 21 15:04:58 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7LE4aGm004833 for ; Thu, 21 Aug 2003 15:04:36 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h7LE4aUL004832 for ip-dvb-subscribed-users; Thu, 21 Aug 2003 15:04:36 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from notesmta.nera.no (notesmta.nera.no [194.19.8.41]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7LE3xGm004770 for ; Thu, 21 Aug 2003 15:03:59 +0100 (BST) In-Reply-To: MIME-Version: 1.0 Sensitivity: To: ip-dvb@erg.abdn.ac.uk Subject: RE: Differences between INT and MMT tables for address resolution? X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: From: Harald Skinnemoen Date: Thu, 21 Aug 2003 16:04:10 +0200 X-MIMETrack: Serialize by Router on NotesMTA/NERA(Release 6.0.1|February 07, 2003) at 21.08.2003 16:01:30, Serialize complete at 21.08.2003 16:01:30 Content-Type: multipart/alternative; boundary="=_alternative 004D6C5EC1256D89_=" X-MailScanner: Found to be clean, Found to be clean X-MailScanner-SpamScore: s Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk This is a multipart message in MIME format. --=_alternative 004D6C5EC1256D89_= Content-Type: text/plain; charset="US-ASCII" Thanks Frank, most helpful. A few more follow-up questions: - Do you know if I (or ETSI) can obtain technical details on the dynamic MMT solution? - Does the concept of dynamic MMT in any way require a regenerative DVB-RCS system? - May I assume the system will still be used in a star network configuration wrt. multicast...? BTW, I assume this regenerative systems is the AMERHIS system, which is well described on the ESA web. Best regards, /harald Please respond to ip-dvb@erg.abdn.ac.uk Sent by: owner-ip-dvb@erg.abdn.ac.uk To: ip-dvb@erg.abdn.ac.uk cc: (bcc: Harald Skinnemoen/NOBBA/NERA) Subject: RE: Differences between INT and MMT tables for address resolution? Dear Harald, a. I can also add, recalling the discussion within SatLabs (www.satlabs.org) on the INT/MMT topic, additional conclusions of the SatLabs meeting on 1/2 April 2003 were that the INT table : - is just too complicated. Already now people have different interpretations on how to use it, - allows not enough dynamics: multiple tables need to be scanned when e.g. a new service/multicast group is introduced in the network, - needs an official platform_id registration at DVB bodies: this means delay and paperwork. Therefore, MMT was preferred as a first step for interoperability between DVB-RCS Hubs/Terminals. b. Concerning the MMT dynamics, in a future regenerative DVB-RCS system to be launched in 2004, the MMT will be used, and by allowing IGMP to travel over the satellite link and let the NCC update the MMT accordingly some degree of dynamics can be achieved. Regards, Frank Frank.Zeppenfeldt@esa.int http://telecom.esa.int/ --=_alternative 004D6C5EC1256D89_= Content-Type: text/html; charset="US-ASCII"
Thanks Frank,

most helpful. A few more follow-up questions:

- Do you know if I (or ETSI) can obtain technical details on the dynamic MMT solution?

- Does the concept of dynamic MMT in any way require a regenerative DVB-RCS system?

- May I assume the system will still be used in a star network configuration wrt. multicast...?

BTW, I assume this regenerative systems is the AMERHIS system, which is well described on the ESA web.

Best regards,

/harald


Please respond to ip-dvb@erg.abdn.ac.uk

Sent by:        owner-ip-dvb@erg.abdn.ac.uk

To:        ip-dvb@erg.abdn.ac.uk
cc:         (bcc: Harald Skinnemoen/NOBBA/NERA)

Subject:        RE: Differences between INT and MMT tables for address resolution?


Dear Harald,

a. I can also add, recalling the discussion within SatLabs (www.satlabs.org)
on the INT/MMT topic, additional conclusions of the SatLabs meeting on 1/2
April 2003 were that the INT table :

- is just too complicated. Already now people have different interpretations
on how to use it,
- allows not enough dynamics: multiple tables need to be scanned when e.g. a
new service/multicast group is introduced in the network,
- needs an official platform_id registration at DVB bodies: this means delay
and paperwork.

Therefore, MMT was preferred as a first step for interoperability between
DVB-RCS Hubs/Terminals.

b. Concerning the MMT dynamics, in a future regenerative DVB-RCS system  to
be launched in 2004,  the MMT will be  used, and by allowing IGMP to travel
over the satellite link and let the NCC update the MMT accordingly  some
degree of dynamics can be achieved.

Regards, Frank

Frank.Zeppenfeldt@esa.int
http://telecom.esa.int/

--=_alternative 004D6C5EC1256D89_=-- From owner-ip-dvb@erg.abdn.ac.uk Thu Aug 21 15:48:21 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7LElpGm006416 for ; Thu, 21 Aug 2003 15:47:51 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h7LElo9M006415 for ip-dvb-subscribed-users; Thu, 21 Aug 2003 15:47:50 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from cpt077.canal-plus.fr (cpt077.canal-plus.fr [194.2.208.77]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7LElSGm006399 for ; Thu, 21 Aug 2003 15:47:28 +0100 (BST) Received: from antivirus-gw.ctechno.net (servap08 [192.168.240.200]) by cpt077.canal-plus.fr (8.12.9/8.12.9) with ESMTP id h7LEl56H025873 for ; Thu, 21 Aug 2003 16:47:23 +0200 (MEST) Content-Class: urn:content-classes:message Received: from servap08.ctechno.net ([127.0.0.1]) by antivirus-gw.ctechno.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 21 Aug 2003 16:47:05 +0200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Received: from intranet.canal-plus.fr ([172.20.11.68]) by mail2.ctechno.net with Microsoft SMTPSVC(5.0.2195.5329); Thu, 21 Aug 2003 16:47:04 +0200 Received: from canal-plus.fr ([192.168.243.239]) by intranet.canal-plus.fr (8.11.1/8.11.1) with ESMTP id h7LEl3x11520; Thu, 21 Aug 2003 16:47:03 +0200 (MET DST) Message-ID: <3F44DBBE.306377BC@canal-plus.fr> Date: Thu, 21 Aug 2003 16:48:30 +0200 From: "Bertrand WENDLING" Organization: CANAL+ Technologies X-Mailer: Mozilla 4.7 [en]C-CCK-MCD C+ (Win98; I) X-Accept-Language: fr,en MIME-Version: 1.0 To: Cc: Subject: RE: Differences between INT and MMT tables for address resolution? Content-Type: multipart/mixed; boundary="------------72CA4D2919791930B394E577" X-OriginalArrivalTime: 21 Aug 2003 14:47:04.0214 (UTC) FILETIME=[161BCB60:01C367F3] X-MailScanner: Found to be clean, Found to be clean X-MailScanner-SpamScore: ss, s Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk This is a multi-part message in MIME format. --------------72CA4D2919791930B394E577 Content-Type: multipart/alternative; boundary="------------4412CFD3AF5615A9CEE7E2AA" --------------4412CFD3AF5615A9CEE7E2AA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Frank, I am surprised by the points you are giving in your last email regarding the INT (from DVB participant side point of view ) : - is just too complicated. Already now people have different interpretations on how to use it, I think that the INT table is clearly define in the Etsi standard. The question that I saw are more linked to the understanding of the way MPE protocol is used rather than the INT table. Again, by referring to the DVB-Etsi standards and implementation guidelines, I think that is shall be ok as no specific interpretation issues have be put on the table during DVB working sessions neither regarding MPE or INT and this since many month for MPE. - allows not enough dynamics: multiple tables need to be scanned when e.g. a new service/multicast group is introduced in the network, The INT is one and only one table, therefore I don't see the meaning of this remark ? Rescan of the INT is easy as based on a PMT version number change. This is done this way because all STB monitor only one and one table all the time, the PMT.... Therefore if the PMT changes, the STB check what table version number has changed, if it is the INT, then the STB know about something new. Regarding the NIT, BAT etc tables... they are mainly used at the scanning level only as they are semi-static tables. If the remark mean PMT and SDT.... when new service is introduced on new PID (which is not mandatory, as several IP services can be transmitted on a single PID), then, there is no relation with the INT, but with the base of DVB (like PMT because ghost PID are not allowed)... - needs an official platform_id registration at DVB bodies: this means delay and paperwork. You need anyway official ids before being able to broadcast anything on air (network_id, broadcast_id etc...). Getting a DVB id is as easy a sending an email... Kind regards Bertrand Dear Harald, a. I can also add, recalling the discussion within SatLabs (www.satlabs.org) on the INT/MMT topic, additional conclusions of the SatLabs meeting on 1/2 April 2003 were that the INT table : - is just too complicated. Already now people have different interpretations on how to use it, - allows not enough dynamics: multiple tables need to be scanned when e.g. a new service/multicast group is introduced in the network, - needs an official platform_id registration at DVB bodies: this means delay and paperwork. Therefore, MMT was preferred as a first step for interoperability between DVB-RCS Hubs/Terminals. b. Concerning the MMT dynamics, in a future regenerative DVB-RCS system to be launched in 2004, the MMT will be used, and by allowing IGMP to travel over the satellite link and let the NCC update the MMT accordingly some degree of dynamics can be achieved. Regards, Frank Frank.Zeppenfeldt@esa.int http://telecom.esa.int/ -- This message and any attachments (the "message") is intended solely for = the addressees and is confidential. If you receive this message in error, = please delete it and immediately notify the sender. Any use not in accordance with its purpose, any dissemination or = disclosure, either whole or partial, is prohibited except formal approval. The E-Mail transmission can not guarantee the integrity of this message. CANAL+TECHNOLOGIES will not therefore be liable for the message if = modified. --------------4412CFD3AF5615A9CEE7E2AA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Frank,
I am surprised by the points you are giving in your last email = regarding the INT (from DVB participant side point of view ) :

- is just too complicated. Already now = people have different interpretations on how to use it,
I think that the INT table is clearly define in the Etsi standard. The question that I saw are more linked to the = understanding of the way MPE protocol is used rather than the INT table. Again, by = referring to the DVB-Etsi standards and implementation guidelines, I think that is shall be ok as no specific interpretation issues have be put on the = table during DVB working sessions neither regarding MPE or INT and this since many month for MPE.

- allows not enough dynamics: multiple = tables need to be scanned when e.g. a new service/multicast group is introduced in the network,
The INT is one and only one table, therefore I don't see the meaning of this remark ? Rescan of the INT is easy as = based on a PMT version number change. This is done this way because all STB = monitor only one and one table all the time, the PMT.... Therefore if the PMT = changes, the STB check what table version number has changed, if it is the INT, then the STB know about something new. Regarding the NIT, BAT etc = tables...  they are mainly used at the scanning level only as they are semi-static tables.
If the remark mean PMT and SDT....  = when new service is introduced on new PID (which is not mandatory, as several IP services can be transmitted on a single PID), then, there is no = relation with the INT, but with the base of DVB (like PMT because ghost PID are not allowed)...

- needs an official platform_id = registration at DVB bodies: this means delay and paperwork.
You need anyway official ids before being = able to broadcast anything on air (network_id, broadcast_id etc...). Getting a DVB id is as easy a sending an email...

Kind regards
Bertrand
 
 

Dear Harald,

a. I can also add, recalling the discussion within SatLabs = (www.satlabs.org)
on the INT/MMT topic, additional conclusions of the SatLabs meeting on 1/2
April 2003 were that the INT table :

- is just too complicated. Already now people have different = interpretations
on how to use it,
- allows not enough dynamics: multiple tables need to be scanned = when e.g. a
new service/multicast group is introduced in the network,
- needs an official platform_id registration at DVB bodies: this = means delay
and paperwork.

Therefore, MMT was preferred as a first step for interoperability = between
DVB-RCS Hubs/Terminals.

b. Concerning the MMT dynamics, in a future regenerative DVB-RCS = system  to
be launched in 2004,  the MMT will be  used, and by = allowing IGMP to travel
over the satellite link and let the NCC update the MMT = accordingly  some
degree of dynamics can be achieved.

Regards, Frank

Frank.Zeppenfeldt@esa.int
http://telecom.esa.int/
 
 
 

This message and any attachments (the "message") is intended solely for = the addressees and is confidential. If you receive this message in = error, please delete it and immediately notify the sender. Any use not = in accordance with its purpose, any dissemination or disclosure, either = whole or partial, is prohibited except formal approval. The E-Mail = transmission can not guarantee the integrity of this = message.
CANAL+TECHNOLOGIES will not therefore be liable for = the message if modified.

--------------4412CFD3AF5615A9CEE7E2AA-- --------------72CA4D2919791930B394E577 Content-Type: text/x-vcard; charset="us-ascii"; name="wendling.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Bertrand WENDLING Content-Disposition: attachment; filename="wendling.vcf" begin:vcard n:Bertrand;WENDLING tel;cell:+33 6 03 45 86 54 tel;fax:+33 1 71 71 50 51 tel;work:+33 1 71 71 53 57 x-mozilla-html:TRUE url:www.canalplus-technologies.com org:CANAL+ Technologies;Advanced Studies & Standardisation Department adr:;;34 place Raoul Dautry;75738 PARIS Cedex 15;;;France version:2.1 email;internet:wendling@canal-plus.fr title:Standards Officer fn:WENDLING Bertrand end:vcard --------------72CA4D2919791930B394E577-- From owner-ip-dvb@erg.abdn.ac.uk Thu Aug 21 16:32:35 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7LFW4Gm008211 for ; Thu, 21 Aug 2003 16:32:04 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h7LFW4DL008210 for ip-dvb-subscribed-users; Thu, 21 Aug 2003 16:32:04 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from ra.udcast.com (IDENT:root@vlm6a1-209.n.club-internet.fr [212.195.38.209]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7LFVbGm008185 for ; Thu, 21 Aug 2003 16:31:38 +0100 (BST) Received: (from pplc@localhost) by ra.udcast.com (8.11.0/8.11.0) id h7LFV2T05318; Thu, 21 Aug 2003 17:31:03 +0200 Date: Thu, 21 Aug 2003 17:31:03 +0200 Message-Id: <200308211531.h7LFV2T05318@ra.udcast.com> From: Patrick Cipiere To: ip-dvb@erg.abdn.ac.uk In-reply-to: <3F44CAB8.AB2EA136@erg.abdn.ac.uk> (message from Dr G Fairhurst on Thu, 21 Aug 2003 14:35:52 +0100) Subject: Re: How does MPE handle the last byte? X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk > So, if I understand this, it means: > > The receiver stops processing the MPEG-2 TS Packet > Payload after it has processed the end of the MPE Section, > when there is no PUSI set. > > That is, it will silently discard the last (unused) > byte in the example below? Yes, and - the unused byte(s) have to be filled with 0xff - the next pointer_field has to be 0x00 >From ISO/IEC 13818-1 -------------------- Adaptation fields may occur in Transport Stream packets carrying PSI sections. Within a Transport Stream, packet stuffing bytes of value 0xFF may be found in the payload of Transport Stream packets carrying PSI and/or private_sections only after the last byte of a section. In this case all bytes until the end of the Transport Stream packet shall also be stuffing bytes of value 0xFF. These bytes may be discarded by a decoder. In such a case, the payload of the next Transport Stream packet with the same PID value shall begin with a pointer_field of value 0x00 indicating that the next section starts immediately thereafter. It is important to note that within Transport Stream packets of any single PID value, one section must be finished before the next one is allowed to be started, or else it is not possible to identify to which section header the data belongs. If a section finishes before the end of a Transport Stream packet, but it is not convenient to open another section, a stuffing mechanism is provided to fill up the space. Stuffing is performed by filling each remaining byte of the packet with the value 0xFF. Consequently the table_id value 0xFF is forbidden, or else this would be confused with stuffing. Once a 0xFF byte has occurred at the end of a section, then the rest of the Transport Stream packet must be stuffed with 0xFF bytes, allowing a decoder to discard the rest of the Transport Stream packet. Stuffing can also be performed using the normal adaptation_field mechanism. 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 owner-ip-dvb@erg.abdn.ac.uk Fri Aug 22 08:26:39 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7M7PgGm011709 for ; Fri, 22 Aug 2003 08:25:42 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h7M7PgoM011708 for ip-dvb-subscribed-users; Fri, 22 Aug 2003 08:25:42 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from proxy.6wind.com (proxy.6wind.com [194.250.197.211]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7M7P1Gm011693 for ; Fri, 22 Aug 2003 08:25:01 +0100 (BST) Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id 1BBD55F8 for ; Fri, 22 Aug 2003 09:25:01 +0200 (CEST) Received: from 6wind.com (vouvray.dev.6wind.com [10.16.0.135]) by intranet.6wind.com (Postfix) with ESMTP id DEAA6641; Fri, 22 Aug 2003 09:25:00 +0200 (CEST) Message-ID: <3F45C60D.8040903@6wind.com> Date: Fri, 22 Aug 2003 09:28:13 +0200 From: alain.ritoux@6wind.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Re: How does MPE handle the last byte? References: <200308211531.h7LFV2T05318@ra.udcast.com> In-Reply-To: <200308211531.h7LFV2T05318@ra.udcast.com> X-Enigmail-Version: 0.71.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk rq inside, Patrick Cipiere wrote: >>So, if I understand this, it means: >> >>The receiver stops processing the MPEG-2 TS Packet >>Payload after it has processed the end of the MPE Section, >>when there is no PUSI set. >> >>That is, it will silently discard the last (unused) >>byte in the example below? Both points are also my understanding. > > Yes, and > - the unused byte(s) have to be filled with 0xff > - the next pointer_field has to be 0x00 >>From ISO/IEC 13818-1 > -------------------- > > Adaptation fields may occur in Transport Stream packets carrying PSI > sections. > > Within a Transport Stream, packet stuffing bytes of value 0xFF may be > found in the payload of Transport Stream packets carrying PSI and/or > private_sections only after the last byte of a section. In this case > all bytes until the end of the Transport Stream packet shall also be > stuffing bytes of value 0xFF. These bytes may be discarded by a ^^^^^^^^^^^^^^^^^^^^^^^^ To keep in sync whith what is done in the DVB world, maybe the ULE-method should force padding & stuffing to be done also with 0xff, (as in the ENC-Method). To have it simple, maybe then, in the ULE, the end-indicator should be set to 0xffff (instead of 0x0000), which of course would forbid SNDU with such a length field, but is it a big deal ? Regards Alain. -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com From owner-ip-dvb@erg.abdn.ac.uk Sat Aug 23 11:29:38 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7NATDGm007546 for ; Sat, 23 Aug 2003 11:29:13 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h7NATCGY007545 for ip-dvb-subscribed-users; Sat, 23 Aug 2003 11:29:12 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from ra.udcast.com (IDENT:root@vlm6b1-184.n.club-internet.fr [212.195.39.184]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7NASiGm007515 for ; Sat, 23 Aug 2003 11:28:45 +0100 (BST) Received: (from pplc@localhost) by ra.udcast.com (8.11.0/8.11.0) id h7N7L0K08372; Sat, 23 Aug 2003 09:21:00 +0200 Date: Sat, 23 Aug 2003 09:21:00 +0200 Message-Id: <200308230721.h7N7L0K08372@ra.udcast.com> From: Patrick Cipiere To: ip-dvb@erg.abdn.ac.uk In-reply-to: <3F45C60D.8040903@6wind.com> (alain.ritoux@6wind.com) Subject: Re: How does MPE handle the last byte? X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk alain.ritoux@6wind.com wrote (>): > To keep in sync whith what is done in the DVB world, maybe the > ULE-method should force padding & stuffing to be done also with 0xff, > (as in the ENC-Method). Yes, we should definitely be conformant with existing standards. This one is not DVB but ISO/IEC 13818-1 (mpeg2) > To have it simple, maybe then, in the ULE, the end-indicator should > be set to 0xffff (instead of 0x0000), which of course would forbid SNDU > with such a length field, but is it a big deal ? In the ISO/IEC 13818-1 and DVB standards, the unused bits/bytes are most of the times (always?) set to 1 (0xff for bytes), so i guess we should keep that. In ISO/IEC 13818-1 it is not said that a 0xff byte marks the end of a payload, but when a payload ends the stuffing bytes should (must?) be 0xff. The end of the payload is known by the upper layer: section (MPE being one of the numerous sections available: datagram section) So if in the ULE, `end-indicator' is a marker, 0xffff might not be the right choice, 0x0000 would look more natural Anyway, i do not see the reason why we need an `end-indicator' marker. Like MPE, the SNDUs carry a length information which is enough for this layer to extract the information from the mpeg2 layer. 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 owner-ip-dvb@erg.abdn.ac.uk Mon Aug 25 13:44:18 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7PChc4u019675 for ; Mon, 25 Aug 2003 13:43:38 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h7PChcFL019674 for ip-dvb-subscribed-users; Mon, 25 Aug 2003 13:43:38 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7PCh34u019645 for ; Mon, 25 Aug 2003 13:43:03 +0100 (BST) Message-ID: <3F4A0458.4635607A@erg.abdn.ac.uk> Date: Mon, 25 Aug 2003 13:43:04 +0100 From: Dr G Fairhurst Organization: ERG, Aberdeen, UK X-Mailer: Mozilla 4.77C-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: How does MPE handle the last byte? References: <200308230721.h7N7L0K08372@ra.udcast.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Based on this thread, I'm going to propose that we change the end-indicator marker in ULE to be OxFFFF. This harmonises it with the "enc" draft, and also with MPE and otehr MPEG-2 usage. Has anyone any objections? Gorry See in-line, for a more detailed response. Patrick Cipiere wrote: > > alain.ritoux@6wind.com wrote (>): > > > To keep in sync whith what is done in the DVB world, maybe the > > ULE-method should force padding & stuffing to be done also with 0xff, > > (as in the ENC-Method). > > Yes, we should definitely be conformant with existing standards. > This one is not DVB but ISO/IEC 13818-1 (mpeg2) > Agreed, so we should conform (as best we can) with this, and the way it is used by thoses standards that build on it. > > To have it simple, maybe then, in the ULE, the end-indicator should > > be set to 0xffff (instead of 0x0000), which of course would forbid SNDU > > with such a length field, but is it a big deal ? > > In the ISO/IEC 13818-1 and DVB standards, the unused bits/bytes are > most of the times (always?) set to 1 (0xff for bytes), so i guess we > should keep that. > Yes, I'd be happy for that, if people think this is better. It's slightly harder to implement - but I guess that's not really an issue. It also prevents having a datagram of size "0xFFFF" - I don't see that as a problem.... if anyone does then please do say. One other positive point is that it would "fix" one difference between the two encpasulation formats. > In ISO/IEC 13818-1 it is not said that a 0xff byte marks the end > of a payload, but when a payload ends the stuffing bytes should > (must?) be 0xff. The end of the payload is known by the upper layer: section > (MPE being one of the numerous sections available: datagram section) > > So if in the ULE, `end-indicator' is a marker, 0xffff might not be the > right choice, 0x0000 would look more natural. That was the original rationale, if I recall correctly. > Anyway, i do not see the reason why we need an `end-indicator' marker. > Like MPE, the SNDUs carry a length information which is enough for > this layer to extract the information from the mpeg2 layer. > > 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 owner-ip-dvb@erg.abdn.ac.uk Thu Aug 28 17:56:20 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7SGtYsH019006 for ; Thu, 28 Aug 2003 17:55:34 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h7SGtYL6019005 for ip-dvb-subscribed-users; Thu, 28 Aug 2003 17:55:34 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from proxy.6wind.com (proxy.ipv6.6wind.com [194.250.197.211]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7SGsesH018957 for ; Thu, 28 Aug 2003 17:54:40 +0100 (BST) Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id F3BEECF for ; Thu, 28 Aug 2003 18:54:40 +0200 (CEST) Received: from 6wind.com (vouvray.dev.6wind.com [10.16.0.135]) by intranet.6wind.com (Postfix) with ESMTP id B5FB37B6; Thu, 28 Aug 2003 18:54:40 +0200 (CEST) Message-ID: <3F4E3492.1090007@6wind.com> Date: Thu, 28 Aug 2003 18:57:54 +0200 From: alain.ritoux@6wind.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IPDVB Subject: Corrections/Evolutions for ULE draft X-Enigmail-Version: 0.71.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean, Found to be clean X-MailScanner-SpamScore: s Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Hi Gorry and all, For the ULE methode, I made the following hypothsis : - Padding at the end of TS si dobne with 0xff - End Indicator is 0xffff - It is forbidden for a SNDU to start in a TS cell if it has not room left for its first 2 bytes So to summary all previous things, and have all sugestions in a single mail (sorry for repetition with older postings), I would propose the following changes for the draft : 1) p3 reference ---------------- [draft-unisal-ipdvb-enc-01.txt] would become [CLAUSEN] and the referecne section will be added [CLAUSEN] draf-clausen-ipdvb-enc-01.txt 2) About the MPEG Header -------------------------- 3. Description of Method. To have a stand alone document (without any implementation need for a non free norm), maybe a MPEG header description could be provided, with all the fixed fields values set (sync byte, AFC, ...) and the needed explication for the others (PUSI, Countiunuity Counter ...) This I would have preferred, but I don't know wheter this is legally feasible or not, with respect to ISO. Or maybe permission can be requested to ISO for doing such. 3) Precision about SNDU format ------------------------------- 4. SDNU Format "The special value 0x0000 indicates that there are no further SNDU within the current TS packet (see section 5.1). The maximum value is 65531" becomes "The special value 0xffff indicates that there are no further SNDU within the current TS packet (see section 5.1). The maximum value is 65530" ... following then Length and Type field definition, add : "The length andd type filed are transmitted, with the most significant byte first", hence a 1000 bytes IPv4 packet encapsulation would begin with : 0x03 0xE8 0x08 0x00 0x45 ..." Add the CRC-32 definition. Even if it is the same as the Ethernet CRC-32, may be the polynomail should be provided: x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x^1+x^0 (IF this is the good one ...) 4) Encapsulator processing ---------------------------- management of the last byte(s) on p11 "If the TS Packet carrying the final part of a SNDU has either zero or one byte of unused payload, the encapsulator will start transmission of the next SNDU in a new TS Packet. For the case of one remaining byte this MAY be assigned the value of 0x00, but this value MUST NOT be required at the receiver." would become "If there is not enough room in a TS packet to put the first 2 bytes of an SNDU (possibly due to the needed payload pointer), the encapsulator will start transmission of this SNDU in a new TS packet. The remaining bytes, MUST be set to 0xff and MUST be ignored by the receiver" (The same rule can be applied to the ENC method) This is relatively a little bit different from what you proposed in your slides, but straightforward to implement: if (PUSI == 1) Needed = 2; else Needed = 3; if (bytes letf >= Needed) { if (PUSI == 0) { set PUSI = 1; insert paload pointer; } sart new SNDU in this TS; } else { padd with 0xff; New(); } The packing requirement seem ot me too light : "... it MAY start SNDU in the next available byte of the TS packet payload" would become "... it SHOULD start SNDU in the next available byte of the TS packet payload. The reciever MUST be able to process such packed SNDU" Moreover, the PayloadPointer definition is a little bit vague. So "If the PUSI is set by this operation, the payload pointer MUST be assigned to the position of the byte following the end of the first SNDU in the TS Packet payload." would become "If the PUSI is set by this operation, the payload pointer MUST be inserted as the first byte of the payload. It is an 8-bit field whose value shall be the number of bytes, immediately following the pointer_field until the first byte of the first SNDU that is present in the payload of the Transport Stream packet (so a value of 0x00 in the payload pointer indicates that the SNDU starts immediately after the payload pointer)." Withe the new end indicator value figure 6 +-------------+ | Subnetwork | | DU 3 | +-------------+ \ \ \ \ \ \ +------+--------+--------+----------+ |MPEG-2| end of | 0x0000 | Unused | |Header| SNDU 3 | | | +------+--------+--------+----------+ PUSI=0 End Indicator would become +-------------+ | Subnetwork | | DU 3 | +-------------+ \ \ \ \ \ \ +------+--------+--------+----------+ |MPEG-2| end of | 0xffff | Unused | |Header| SNDU 3 | | | +------+--------+--------+----------+ PUSI=0 End Indicator 5) Decapsulator processing --------------------------- About the payload pointer checking : "A receiver that has partially received a SNDU (in the Current SNDU buffer) MUST also check the Payload Pointer, of any received packets with a PUSI value of 1. A Payload Pointer value of 1 indicates that the receiver MUST discard any previously unreassembled SNDU, and start processing the new SNDU that directly follows the Payload Pointer." Ther seems to be a conflict with the definition of the payload pointer proposed to be in sync wiht DVB world, for in this case a value of '1' is legal. Only a value of 0 is suspect. More over, is this paragraph needed, as the following already includes the while case (about unfinished SNDU btw s/ANDU/SNDU) where (PayloadPointer - 1) would become (PayloadPointer). 6) Reference section ---------------------- It is a bit hard for a newbie, and most of them are for having some background so having them separated could help (especially, as some are NOT FREE) : Directly related ones: - [ISO-MPEG] - [ETSI-DAT] - [ISO-DMSCC] "Not so important" ones (hmmm, see there no disrespect) - all [ATSC-xx] (btw [ATS-DAT] and [ATSC-DATG] are not used in the text) - [ETSI-DVBS] - [ETSI-DVBT] - [ETSI-DVBC] (btw [ISO-AUD] and [ISO-VID] are not used in the text) - [ETSI-RCS] is used in the 1; Introduction, but not defined. 7) Exemples -------------- This would lead to the following exemples that could be provided in the draft in some annex part. (Thanks to tell if there is any error) A) Simple case =============== SNDU A is 200 bytes long SNDU B is 200 bytes long PP=0 +-----+----+------+- -+------+ | HDR |0x00| A000 | ... | A182 | +-----+---*+-*----+- -+------+ PUSI=1 * * **** PP=17 +-----+----+------+- -+------+------+- -+------+ | HDR |0x11| A183 | ... | A199 | B000 | ... | B165 | +-----+---*+------+- -+------+*-----+- -+------+ PUSI=1 * * *********************** <--- 150 ---> stuffing bytes +-----+------+- -+------+----+- -+----+ | HDR | B166 | ... | B199 |0xff| ... |0xff| +-----+------+- -+------+----+- -+----+ PUSI=0 no PP B) Corny cases with last byte ============================== SNDU A is 183 bytes long SNDU B is 182 bytes long SNDU C is 181 bytes long SNDU D is 185 bytes long SNDU E is 364 bytes long PP=0 +-----+----+------+- -+------+ | HDR |0x00| A000 | ... | A182 | +-----+---*+-*----+- -+------+ PUSI=1 * * **** unused PP=0 byte +-----+----+------+- -+------+----+ | HDR |0x00| B000 | ... | B181 |0xff| +-----+---*+-*----+- -+------+----+ PUSI=1 * * **** PP=0 +-----+----+------+- -+------+------+------+ | HDR |0x00| C000 | ... | C180 | D000 | D001 | +-----+---*+-*----+- -+------+------+------+ PUSI=1 * * **** unused byte +-----+------+- -+------+----+ | HDR | D002 | ... | D184 |0xff| +-----+------+- -+------+----+ PUSI=0 no PP PP=0 +-----+----+------+- -+------+ | HDR |0x00| E000 | ... | E182 | +-----+--*-+-*----+- -+------+ PUSI=1 * * ***** PP=181 +-----+----+------+- -+------+------+------+ | HDR |0xb5| E183 | ... | E363 | F000 | F001 | +-----+---*+------+- -+------+*-----+------+ PUSI=1 * * *********************** +-----+------+- -+------+ | HDR | F002 | ... | F099 | ... +-----+------+- -+------+ PUSI=0 C) Small packets ================== SNDU A is 200 bytes long SNDU B is 60 bytes long SNDU C is 60 bytes long PP=0 +-----+----+------+- -+------+ | HDR |0x00| A000 | ... | A182 | +-----+---*+-*----+- -+------+ PUSI=1 * * **** PP=17 +-----+----+------+- -+------+------+- | HDR |0x11| A183 | ... | A199 | B000 | ... +-----+---*+------+- -+------+*-----+- PUSI=1 * * *********************** <--- 46 ---> stuffing bytes including end-indicator -+------+------+- -+------+----+- -+----+ ... | B059 | C000 | ... | C059 |0xff| ... |0xff| -+------+------+- -+------+----+- -+----+ Any comment welcomed. Cheers. Alain. -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com From owner-ip-dvb@erg.abdn.ac.uk Thu Aug 28 19:30:12 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7SITFsH023506 for ; Thu, 28 Aug 2003 19:29:15 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h7SITEOC023505 for ip-dvb-subscribed-users; Thu, 28 Aug 2003 19:29:14 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley-ipv6.erg.abdn.ac.uk [IPv6:2001:630:241:1:20a:95ff:fe7d:5f0c]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7SISEsI023454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 28 Aug 2003 19:28:14 +0100 (BST) Message-ID: <3F4E49BF.2030403@erg.abdn.ac.uk> Date: Thu, 28 Aug 2003 19:28:15 +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: ip-dvb@erg.abdn.ac.uk Subject: Re: Corrections/Evolutions for ULE draft References: <3F4E3492.1090007@6wind.com> In-Reply-To: <3F4E3492.1090007@6wind.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Thanks Alain, I think you're hinting that the ULE draft needs a "rev", and I'd agree with this! Your inputs here will be **very** helpful (together with others from the list), and I will set aside some time at the start of September to do an overhaul of the document. (For the "snipped" parts see Alains previous email.) In the mean-time, if anyone has any other comments/corrects, please do send them either directly to me, or via the ip-dvb list. There is one thing I'd like to get a feeling for from the list: Do we need to support a maximum paylaod size of approx 64KB? I've asked this several times, and most people seem to agree we don't need to support payloads this big, nor is it likely to be significant issue for this type of network in the future. I'd advocate at least 16 KB, could we live with a little less than 32 KB as the maximum payload size??? Is there anyone with other views out there? Thoughts? Gorry alain.ritoux@6wind.com wrote: > Hi Gorry and all, > > For the ULE methode, I made the following hypothsis : > - Padding at the end of TS si dobne with 0xff > - End Indicator is 0xffff > - It is forbidden for a SNDU to start in a TS cell if > it has not room left for its first 2 bytes > > So to summary all previous things, and have all sugestions in a single > mail (sorry for repetition with older postings), I would propose the > following changes for the draft : > > <> > > 3) Precision about SNDU format > ------------------------------- > 4. SDNU Format > "The special value 0x0000 indicates that there are no further SNDU > within the current TS packet (see section 5.1). The maximum value is > 65531" > becomes > "The special value 0xffff indicates that there are no further SNDU > within the current TS packet (see section 5.1). The maximum value is > 65530" > > <> > > > Any comment welcomed. > Cheers. > > Alain. From owner-ip-dvb@erg.abdn.ac.uk Fri Aug 29 00:05:49 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7SN33rr005246 for ; Fri, 29 Aug 2003 00:03:03 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h7SN32m6005242 for ip-dvb-subscribed-users; Fri, 29 Aug 2003 00:03:02 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from bonnie.ses-astra.com (bonnie.ses-astra.com [194.154.219.59]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7SN1Srs005175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 29 Aug 2003 00:01:56 +0100 (BST) Received: from marge.gen.btz.aia.lu (marge.gen.btz.aia.lu [193.168.96.8]) by bonnie.ses-astra.com (8.12.9/8.12.9) with ESMTP id h7SN1OkI029500 for ; Fri, 29 Aug 2003 01:01:24 +0200 (CEST) Subject: Joel Grotz is out of office. From: Joel.Grotz@ses-astra.com To: ip-dvb@erg.abdn.ac.uk Message-ID: Date: Fri, 29 Aug 2003 01:01:23 +0200 X-MIMETrack: Serialize by Router on marge/BTZ(Release 5.0.12 |February 13, 2003) at 29/08/2003 01:01:24 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk I will be out of the office starting 08/23/2003 and will not return until 09/04/2003. If required, I will respond to your message when I return to office. Best Regards, Joel Grotz From owner-ip-dvb@erg.abdn.ac.uk Fri Aug 29 09:15:41 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7T8F6GL024213 for ; Fri, 29 Aug 2003 09:15:06 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h7T8F66S024210 for ip-dvb-subscribed-users; Fri, 29 Aug 2003 09:15:06 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from proxy.6wind.com (proxy.ipv6.6wind.com [194.250.197.211]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7T8ECGL024143 for ; Fri, 29 Aug 2003 09:14:12 +0100 (BST) Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id D5519631 for ; Fri, 29 Aug 2003 10:14:11 +0200 (CEST) Received: from 6wind.com (vouvray.dev.6wind.com [10.16.0.135]) by intranet.6wind.com (Postfix) with ESMTP id C82F5641; Fri, 29 Aug 2003 10:14:11 +0200 (CEST) Message-ID: <3F4F0C15.6030502@6wind.com> Date: Fri, 29 Aug 2003 10:17:25 +0200 From: alain.ritoux@6wind.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Re: Corrections/Evolutions for ULE draft References: <3F4E3492.1090007@6wind.com> <3F4E49BF.2030403@erg.abdn.ac.uk> In-Reply-To: <3F4E49BF.2030403@erg.abdn.ac.uk> X-Enigmail-Version: 0.71.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Gorry Fairhurst wrote: > > There is one thing I'd like to get a feeling for from the list: > > Do we need to support a maximum paylaod size of approx 64KB? > I've asked this several times, and most people seem to agree we don't > need to support payloads this big, nor is it likely to be significant > issue for this type of network in the future. I'd advocate at least 16 > KB, could we live with a little less than 32 KB as the maximum payload > size??? Is there anyone with other views out there? > Thoughts? > Indeed, I once proposed to reduce it more than that, but mainly I was thinking "ethernet", and I see now that in the core, MTU are getting higher !! On FreeBSD implementation ATM interface have ~9K MTU. And I've read something about some links also with 9K MTU. I feel comfortable with 16K, which leaves 2 bits for any creative usage ;-) btw : what about next header in ULE method, for as alignement is clearly not aimed, maybe 1 byte is enough, reducing encaps overhead from 8 to 7. And to kkep possible type extension (if 256 space gets exausted, the mlength field, could be specified to cover type-field + payload + CRC, instead of just payload + CRC still "next header" considerations: if is is an ether_type, there can be pb for non-defined ether_types, such as ROHC :-( and so it would block the draft UNTIL and ether type is (ever?) adopted, because choosing a non-ether-type for one of the protocols might result in a future conflict. same thing for PPP-types : I haven't found PPP-type for MPLS still with the same subject : are two differnet values needed for ROHC4 and ROHC6, for ROHC packets are asociated to specific flows that share some common info (such as addresses, and especially IP version!). I had a look a RFC3241, and there is no ROHC-v4 and ROHC-v6 separation for PPP, rather a separation between ROHC-with-small-CID ROHC-with-large-CID, which is said not to be needed ("p2 ROHC does not require that the link layer be able to indicate the types of datagrams carried in the link layer frames.") ???? So, I think, a single netx header value could be used. Your thoughts ? Cheers. Alain. -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com From owner-ip-dvb@erg.abdn.ac.uk Fri Aug 29 10:44:13 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7T9hdGL027226 for ; Fri, 29 Aug 2003 10:43:39 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h7T9hdV1027225 for ip-dvb-subscribed-users; Fri, 29 Aug 2003 10:43:39 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from pop016.verizon.net (pop016pub.verizon.net [206.46.170.173]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7T9gfGL027175 for ; Fri, 29 Aug 2003 10:42:41 +0100 (BST) Received: from copernicus ([68.163.167.68]) by pop016.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20030829094235.TDKI10125.pop016.verizon.net@copernicus> for ; Fri, 29 Aug 2003 04:42:35 -0500 Message-ID: <01e601c36e11$e0abf110$c602a8c0@copernicus> From: "Marie-Jose Montpetit" To: References: <3F4E3492.1090007@6wind.com> <3F4E49BF.2030403@erg.abdn.ac.uk> <3F4F0C15.6030502@6wind.com> Subject: Re: Corrections/Evolutions for ULE draft Date: Fri, 29 Aug 2003 05:42:34 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authentication-Info: Submitted using SMTP AUTH at pop016.verizon.net from [68.163.167.68] at Fri, 29 Aug 2003 04:42:35 -0500 X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk I actually doubt that any satellite system will ever be attached directly to the core networks :-) I am more concerned by the probability of loss in the satellite channel (no flame from the PHY guys please, I know the link is almost error free but almost is not fully). Hence the probability that one segment of a packet is lost is proportional to the number of fragments and then the whole things may be lost (if no higher layer recovery mechanisms) so much to say for the savings of encapsulations. I would vote for 16k. Marie-Jose ----- Original Message ----- From: To: Sent: Friday, August 29, 2003 4:17 AM Subject: Re: Corrections/Evolutions for ULE draft > Gorry Fairhurst wrote: > > > > > There is one thing I'd like to get a feeling for from the list: > > > > Do we need to support a maximum paylaod size of approx 64KB? > > I've asked this several times, and most people seem to agree we don't > > need to support payloads this big, nor is it likely to be significant > > issue for this type of network in the future. I'd advocate at least 16 > > KB, could we live with a little less than 32 KB as the maximum payload > > size??? Is there anyone with other views out there? > > Thoughts? > > > > Indeed, I once proposed to reduce it more than that, but mainly I > was thinking "ethernet", and I see now that in the core, MTU are > getting higher !! > On FreeBSD implementation ATM interface have ~9K MTU. And I've read > something about some links also with 9K MTU. I feel comfortable > with 16K, which leaves 2 bits for any creative usage ;-) > > btw : what about next header in ULE method, for as alignement is > clearly not aimed, maybe 1 byte is enough, reducing encaps overhead > from 8 to 7. And to kkep possible type extension (if 256 space > gets exausted, the mlength field, could be specified to cover > type-field + payload + CRC, instead of just payload + CRC > > still "next header" considerations: if is is an ether_type, there > can be pb for non-defined ether_types, such as ROHC :-( > and so it would block the draft UNTIL and ether type is (ever?) > adopted, because choosing a non-ether-type for one of the protocols > might result in a future conflict. > same thing for PPP-types : I haven't found PPP-type for MPLS > > still with the same subject : are two differnet values needed for > ROHC4 and ROHC6, for ROHC packets are asociated to specific flows > that share some common info (such as addresses, and especially IP > version!). I had a look a RFC3241, and there is no ROHC-v4 and > ROHC-v6 separation for PPP, rather a separation between > ROHC-with-small-CID ROHC-with-large-CID, which is said not to be > needed ("p2 ROHC does not require that the link layer be able to > indicate the types of datagrams carried in the link layer > frames.") ???? > So, I think, a single netx header value could be used. > > Your thoughts ? > > Cheers. > Alain. > -- > Alain RITOUX > Tel +33-1-39-30-92-32 > Fax +33-1-39-30-92-11 > visit our web http://www.6wind.com > From owner-ip-dvb@erg.abdn.ac.uk Fri Aug 29 11:10:26 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7TA9lGL028176 for ; Fri, 29 Aug 2003 11:09:47 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h7TA9lRA028175 for ip-dvb-subscribed-users; Fri, 29 Aug 2003 11:09:47 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from proxy.6wind.com (proxy.ipv6.6wind.com [194.250.197.211]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h7TA8nGL028125 for ; Fri, 29 Aug 2003 11:08:50 +0100 (BST) Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id 611B0127 for ; Fri, 29 Aug 2003 12:08:50 +0200 (CEST) Received: from 6wind.com (vouvray.dev.6wind.com [10.16.0.135]) by intranet.6wind.com (Postfix) with ESMTP id 536F559E; Fri, 29 Aug 2003 12:08:50 +0200 (CEST) Message-ID: <3F4F26F4.6030304@6wind.com> Date: Fri, 29 Aug 2003 12:12:04 +0200 From: alain.ritoux@6wind.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Re: Corrections/Evolutions for ULE draft References: <3F4E3492.1090007@6wind.com> <3F4E49BF.2030403@erg.abdn.ac.uk> <3F4F0C15.6030502@6wind.com> <01e601c36e11$e0abf110$c602a8c0@copernicus> In-Reply-To: <01e601c36e11$e0abf110$c602a8c0@copernicus> X-Enigmail-Version: 0.71.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Marie-Jose Montpetit wrote: > I actually doubt that any satellite system will ever be attached directly to > the core networks :-) > > I am more concerned by the probability of loss in the satellite channel (no > flame from the PHY guys please, I know the link is almost error free but > almost is not fully). Hence the probability that one segment of a packet is > lost is proportional to the number of fragments and then the whole things > may be lost (if no higher layer recovery mechanisms) so much to say for the > savings of encapsulations. I would vote for 16k. > btw, for my personnal culture, does somebody know the residual bit error rate of TS cells, (i.e. after corrector codes) on satelite links ? or at least the order of mangitude, or the common values if there are different kind od DVB links ? Thanks, Alain. -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com