From majordomo-owner@erg.abdn.ac.uk Mon Sep 2 21:03:32 2002 Received: from [10.0.1.10] (maxp31.abdn.ac.uk [139.133.7.190]) by erg.abdn.ac.uk (8.12.6/8.12.6) with SMTP id g82K3BaG006898 for ; Mon, 2 Sep 2002 21:03:12 +0100 (BST) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Mon, 02 Sep 2002 21:03:10 +0100 Subject: Minutes of 2nd Open IP-DVB Meeting (IP over MPEG-2 Transport) From: gorry To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" X-MailScanner: Found to be clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by erg.abdn.ac.uk id g82K3WSj006907 Minutes of 2nd Open IP-DVB Meeting (IP over MPEG-2 Transport) 14:00 Monday, 24th June Hosted by Alcatel Space Industries, Toulouse, France Agenda 5 minutes: Agenda bashing 5 minutes: Working Group Status 15 minutes: Review charter http://www.erg.abdn.ac.uk/users/gorry/ip-dvb/charter.html Review of current IDs 20 minutes: draft-fair-ipdvb-req-01.txt 20 minutes: draft-unisal-ipdvb-enc-00.txt 20 minutes: Other needed IDs Break 5 minutes: Attendance at IETF 10 minutes: Links with other WGs 10 minutes: Timeline --------------- Stephane Combes started the meeting with a welcome to ASPI Toulouse. Gorry Fairhurst and Marie-Jose Montpetit chaired the meeting. There were no new agenda items, but Stephane Combes was asked to start with the first presentation to allow time to prepare the other presentations. Presentation of Alcatel Space Industries (ASPI) activities ========================================================== Stephane Combes provided a presentation of a range of Alcatel Space Industries (ASPI) activities relating to Internet service provision via satellite using DVB-based systems. This showed the perceived need for two work in two areas: MPE enhancement (short term) He noted the issue of no MAC-level source address in the basic MPE encapsulation. This raised issues for multicast encpasulation when there were several sources. There was also interest from ISPs in MPEG-2 delivery of an Ethernet Like layer (in the manner of ADSL). MPLS and PPoE options were also being investigated. MPE replacement (long term) Longer-term he saw a need for a dynamic address resolution process, and better support for multicast. Security issues also needed to be addressed. Some work had already been done by ASPI on MPE replacement, defining a protocol called IP-Dedicated. This was aimed at two-way DVB-RCS based satellite systems. One key feature of this work was the use of L3 filters (i.e., internet address filters in the receivers), but he concluded a simple level 2 filter was also desirable to reduce layer 3 processing. This would also allow virtual subnetworks to be configured and to lead to future L2 switching within a DVB multiplexor (or DVB-capable on-board processing satellite). He described two current projects looking at IP over MPEG-2 transmission that have been funded by the European Commission (IST-Brahms, IST-SATIP6). Longer-term he saw the need to improve IPv6 support. Some ASPI work had some associated IPR. It was thought that the ip-dvb activity would complement this work, and ASPI would like to support it. REVIEW OF CHARTER ================= Gorry presented a status report for the ip-dvb activity. This covered, liasons with DVB, the desired work of the group, and the charter. Marie-Jose suggested that a short one page summary document should be prepared to position the work clearly. This could be used as a marketing document for briefing DVB equipment manufacturers on the proposed new protocol stack. When asked, she agreed to draft this document for the mailing list. No new items were suggested for the charter. REVIEW OF IDS ============= Gorry Fairhurst presented the status of the two IDs (no other authors were present). REQUIREMENTS (draft-fair-ipdvb-req-01.txt) The requirements draft had recently been updated to -01, to include rationale for signalling following the combined meeting with DVB-GBS. This DVB working group had produced an DVB draft for signalling (INT). This would be based on DVB SI signalling tables. A new version of the INT document was in preparation, status was not known. Diagrams had also been added, to the -01 draft. Gorry asked for corrections / comments. One issue raised by the DVB INT draft was the need for ³platform ids² to describe the scope of the addresses being advertised. A single MPEG-2 TS logical channel could be used to address several virtual private networks, each with overlapping address space, and uniquely identified by MAC address and platform ID. Was this a good idea? There was some discussion of whether this approach was suited to more general Interent needs. No conclusion. ENCAPSULATION (draft-unisal-ipdvb-enc-00.txt) The encapsulation draft was presented and a discussion followed. Patrick Cipiere asked why there was no MAC address in the basic header format, only as an extension header? Since MPE included a destination MAC address, some suggested that L2 addresses should at least be part of the basic encapsulation. There was discussion about the possibility of using the most significant bits of the length field to hold two flag bits (as originally suggested by Patrick on the mailing list). One signalling bit could indicate presence of a MAC source address, another a MAC destination address. This also seemed to have the advantage that a 01 setting would be backwards compatible with MPE, and 00 would be equivalent to the current proposal (-00). Marie-Jose asked when a MAC address was actually required.... This should be documented. If we proceede with this - we would need to find space for the signalling bits in the fixed header. Two places were possible, one in the length field and one in the type field. Do we need to support packets greater than 16 KB? When this had previously been posted as a proposal to the list it had received little comment. It was agreed to take this to the list again, in time for the next rev of the draft. Gorry said the current case for using the AFC bits in the MPEG-2 TS Packet header was not well stated at the moment. This should be updated in the next draft. ADDRESS RESOLUTION Gorry Fairhurst suggested there was now a need for an ID from the ip-dvb activity to clarify how address resolution could work. IPv6 ==== Marie-Jose presented a set of slides on IPv6 and looked at RFC2461 and RDISC. The meeting concluded that some attention should be paid to router and neighbourhood discovery when looking at addrress resolution for IPv6. A critical look at multi-homing may also be appropriate for home scenarios were DVB and other broadband services may all be present. IP-CC ===== Pekka (Nokia) presented a set of slides on the proposed role of IP-CC for service discovery. This draft proposal had previously been presented at DVB-GBS working group, and was intended to provide service discovery. The current proposal was aimed at DVB-T (terrestrial) TV networks supporting IP services. There were similarities to the way SAP is used in current IP multicast networks, but a broader scope was envisaged for the new protocol. One key issue was to provide mechanisms for location-based delivery, in which the service was associated with a geographical region. The proposal seemed to be complimentary to the proposed work on IP over MPEG-2. It was discussed whether this work was within the charter of the ip-dvb activity - or whether it should be placed with another working group. Since it was not within the current charter, there was no decision to progress with this within the group. CONCLUSIONS ============= There was discussion of the possibility of developing some reference implementations to allow experimentation with the new encapsulation. Frank Zeppenfeldt from the European Space Agency said they would be interested in receiving project ideas associated with implementation of the new encapsulation (and possibly other protocol components). The meeting agreed that more work was required to understand exactly what was being proposed before we were ready to bring this to the IETF, but that considerable progress had been made and that there was a clear enthusiasm to proceed. Would we be ready for October? Gorry agreed to contact the appropriate IESG Area Directors to ask about the possibility of a BoF in Atlanta. He would also contact the DVB-GBS WG chair to find out progress with their signalling work. The circulated attendance sheet showed 14 people were present. Thanks to Stephane Combes for arranging lunch and for the good local organisation of this meeting. From majordomo-owner@erg.abdn.ac.uk Tue Sep 3 10:40:45 2002 Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.12.6/8.12.6) with ESMTP id g839e8aG010417 for ; Tue, 3 Sep 2002 10:40:10 +0100 (BST) Message-ID: <3D748377.71AAD976@erg.abdn.ac.uk> Date: Tue, 03 Sep 2002 10:40:07 +0100 From: Dr G Fairhurst Reply-To: gorry@erg.abdn.ac.uk 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: demo stream, filter questions References: <003b01c24ffd$7043b1c0$2b98fe91@dpiag.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean Some immediate questions/comments in-line to try to discover whether the encapsulation has the correct features for users. Gorry --- > Karsten Siebert wrote: > > After reading the IP/DVB drafts we've implemented a sample > encapsulation mode in our encapsulator (see below) and passed some > data, to see, if the normal section packing method (without use of > adaptation field) would be efficient enough for the receiver to > de-capsulate the payload. And yes, PUSI and length are efficient to > re-construct the payload (even when packed). We've just passed entire > MAC frames over the link in this sample (also do not worry about the > type, we've just picked 0x800 in the example). > The ID suggests you should be able to packet several IP datagrams in the same MPEG-2 TS packet. It would be interesting to see an IP packet size of 40B, and show how this is sent. Can you do this? > What comes in mind here is that the MPE header is used as hardware > filtering at "MAC/Section" level also. DVB streams are normally high > speed streams (in the future > 100 mbps packet throughput (QAM, > 8PSK)). So... There are several questions here. 1) How significant a feature is "section filtering". I would be interested to know how important this feature is. As I see it, it gives the encapsulator the possibility of forming seperate logical subnetworks within the same MPEG-2 TS Logical Channel. Is this just feature-overload? Is there a good reason for not using a separate PID for each subnetwork? 2) MAC address filtering - we NEED this to run routing protocols, do we need it for directly connected end hosts? If hardware filtering is indeed required, could it not use the IPv4 / IPv6 header? Is this good / bad? > I cannot imagine, that a standard receiver filters at IP or > similar levels in software. MPE has the MAC address field, which tells > the local hardware to set a section level filter. The "minimal header > has no such capability. Will receivers get all packets on that PID ? Yes, currently they would. > How do you build groups of receiver devices ? Use another PID? > > > Karsten > > > (In case one is interested we also have colored pdf version of the > demo output for better visibility of individual bytes) > > > The demo system transmits complete Ethernet frames, section_type > (equal to Ethernet protocol identifier) is copied from Ethernet > header. section_length = tot_len of section - 4 (in bytes). > > Syntax No. of bits Identifier > > MPM_section() { > > section_type 16 uimsbf > section_length 16 uimsbf > > for(i=0; i data_byte [i] 8 bslbf > } > > section_crc32 32 rpchof > } > > > Two UDP packets (100 byte payload "a"), > Section packing disabled, PID 0x64, > PUSI set in both TS packets, > Pointer byte set in both TS packets, > > Packet length 188 > 4740641700080000920002a0b0c0d00002a0b0c0d00800450000802097000040 > 11d872c0a80009c0a8000a04000312006c719b61616161616161616161616161 > 6161616161616161616161616161616161616161616161616161616161616161 > 6161616161616161616161616161616161616161616161616161616161616161 > 616161616161616161616161616161616161616161616134087b04ffffffffff > ffffffffffffffffffffffffffffffffffffffffffffffffffffffff > > Packet length 188 > 4740641800080000920002a0b0c0d00002a0b0c0d00800450000802098000040 > 11d871c0a80009c0a8000a04000312006c719b61616161616161616161616161 > 6161616161616161616161616161616161616161616161616161616161616161 > 6161616161616161616161616161616161616161616161616161616161616161 > 616161616161616161616161616161616161616161616145e70541ffffffffff > ffffffffffffffffffffffffffffffffffffffffffffffffffffffff > > > Two UDP packets (100 byte payload "a"), > Section packing enabled, PID 0x64, > PUSI set in first TS packet, > Pointer byte set in first TS packet, > > Packet length 188 > 4740641900080000920002a0b0c0d00002a0b0c0d00800450000802099000040 > 11d870c0a80009c0a8000a04000312006c719b61616161616161616161616161 > 6161616161616161616161616161616161616161616161616161616161616161 > 6161616161616161616161616161616161616161616161616161616161616161 > 61616161616161616161616161616161616161616161619710a3130800009200 > 02a0b0c0d00002a0b0c0d0080045000080209a00004011d86fc0a800 > > Packet length 188 > 4700641a09c0a8000a04000312006c719b616161616161616161616161616161 > 6161616161616161616161616161616161616161616161616161616161616161 > 6161616161616161616161616161616161616161616161616161616161616161 > 616161616161616161616161616161616161616161c818168bffffffffffffff > ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff > ffffffffffffffffffffffffffffffffffffffffffffffffffffffff > > Three UDP packets (100 byte payload "a"), > Section packing enabled, PID 0x64, > PUSI set in first two TS packets, > Pointer byte set in first two TS packets, > > Packet length 188 > 4740641b00080000920002a0b0c0d00002a0b0c0d0080045000080209b000040 > 11d86ec0a80009c0a8000a04000312006c719b61616161616161616161616161 > 6161616161616161616161616161616161616161616161616161616161616161 > 6161616161616161616161616161616161616161616161616161616161616161 > 61616161616161616161616161616161616161616161611aefb0d90800009200 > 02a0b0c0d00002a0b0c0d0080045000080209c00004011d86dc0a800 > > Packet length 188 > 4740641c7509c0a8000a04000312006c719b6161616161616161616161616161 > 6161616161616161616161616161616161616161616161616161616161616161 > 6161616161616161616161616161616161616161616161616161616161616161 > 61616161616161616161616161616161616161616161949b3409080000920002 > a0b0c0d00002a0b0c0d0080045000080209d00004011d86cc0a80009c0a8000a > 04000312006c719b6161616161616161616161616161616161616161 > > Packet length 188 > 4700641d61616161616161616161616161616161616161616161616161616161 > 6161616161616161616161616161616161616161616161616161616161616161 > 6161616161616161616161616161616161616161466c925bffffffffffffffff > ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff > ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff > ffffffffffffffffffffffffffffffffffffffffffffffffffffffff > > From majordomo-owner@erg.abdn.ac.uk Tue Sep 3 15:22:13 2002 Received: from raptor.micronas.com (raptor.micronas.com [192.166.137.1]) by erg.abdn.ac.uk (8.12.6/8.12.6) with SMTP id g83ELwaG013582 for ; Tue, 3 Sep 2002 15:22:00 +0100 (BST) Received: from virtue.micronas.com by raptor.micronas.com via smtpd (for mavis.erg.abdn.ac.uk [139.133.204.77]) with SMTP; 3 Sep 2002 14:21:59 UT Received: FROM n-aadolf.micronas.com BY VIRTUE.Micronas.com ; Tue Sep 03 16:21:57 2002 +0200 Date: Tue, 3 Sep 2002 16:21:56 +0200 From: Alexander Adolf To: ip-dvb@erg.abdn.ac.uk Subject: Re: demo stream, filter questions In-Reply-To: <3D748377.71AAD976@erg.abdn.ac.uk> Message-ID: X-Mailer: PC-Pine 4.44 http://www.washington.edu/pine/ Organization: Micronas GmbH http://www.micronas.com X-Message-Flag: Worried about Outlook viruses? Switch to PINE! Info @ http://www.washington.edu/pine/ X-X-Sender: adoale@ambassador.micronas.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MailScanner: Found to be clean Dear Gorry, dear Colleagues, On 2002-09-03T10:40+0100, Dr G Fairhurst wrote: > [...] > > What comes in mind here is that the MPE header is used as hardware > > filtering at "MAC/Section" level also. DVB streams are normally high > > speed streams (in the future > 100 mbps packet throughput (QAM, > > 8PSK)). Today 100 Mbps are reality on satellite systems. Looking into the future I would expect the satellite operators to add some multiples to that. One day we will probably run into physical restrictions imposed by the earth's atmosphere. However I am not an expert on this so please don't ask me how far we will get... ;-) And then there is still otical fibre where you get several Gbps today. > So... There are several questions here. > > 1) How significant a feature is "section filtering". I would > be interested to know how important this feature is. As I see it, > it gives the encapsulator the possibility of forming seperate > logical subnetworks within the same MPEG-2 TS Logical Channel. > Is this just feature-overload? Is there a good reason for not > using a separate PID for each subnetwork? Taking into account the transmission link speeds I just mentioned, a good amount of the filtering definitely has to be done in hardware. But apart from that, 'just' using another PID in a DVB network is not as easy as it might seem. As DVB networks are television broadcast networks (if not by nature then by descent), they are subject to regulatory administration in many parts of the world. So you might simply not be allowed to introduce a new PID since you haven't registered it with your regulator. Of course you can always register a new one, but that takes away any dynamicity (which we probably will want). Another constraint are the commercial arrangements and business models of network operators and service providers (duh, I managed to say the nasty 'C' and 'B' words in one sentence!). Often a (e.g. IP) service provider rents a specific bandwidth on a specific PID from a network operator. This approach could be favorable to both of them since it will then be easier to multiplex in the (e.g. IP) service and provide easier network planning for the operator. Additionally a malfunction of the 'bought-in' service will be much less likely to affect other services. Some service providers have the model that they feed their service to as many (DVB) distribution networks as possible. In the above mentioned scenario (renting a specific PID), their service need not be taylored to the specific distribution network and they are (almost) the sole responsible for the functioning or malfunctioning of their service, as blunt PID remultiplexing today is as common and reliable as - say - sliced bread. As you can see there are many implications, boundary conditions and limitations due to the fact that DVB networks are being operated as television distribution networks and not as generic interconnection networks. The section filtering invented by MPEG and adopted by DVB is especially well suited for these (TV) broadcast medium environments where remultiplexing comes into play. > 2) MAC address filtering - we NEED this to run routing protocols, > do we need it for directly connected end hosts? If hardware > filtering is indeed required, could it not use the IPv4 / IPv6 header? > Is this good / bad? > > > I cannot imagine, that a standard receiver filters at IP or > > similar levels in software. MPE has the MAC address field, which tells > > the local hardware to set a section level filter. The "minimal header > > has no such capability. Will receivers get all packets on that PID ? > > Yes, currently they would. > > > How do you build groups of receiver devices ? > > Use another PID? > [...] No (for the above mentioned reasons). That is - amongst others - why DVB crafted a solution to convey information about IP addresses being targetted by specific streams or services. I am currently working on getting clearance for forwarding the latest draft of this to you. Best regards, --alexander adolf Chairman DVB GBS -- +++ ATTENTION +++ new location as of 2002-06-10 +++++++++++++++++++++ +++ new address: Frankenthalerstrasse 2, D-81539 Muenchen, Germany ++ +++ new phone: +49 89 54845 7203 +++ new fax: +49 89 54845 7900 +++++ Alexander Adolf, Dipl.-Ing.(FH) -------------------------------------- Concept Engineer ----------------------------------------------------- System Software ------------------------------------ info@micronas.com Micronas Gmbh - Munich Office ----------------------- www.micronas.com From majordomo-owner@erg.abdn.ac.uk Wed Sep 4 12:02:29 2002 Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.12.6/8.12.6) with ESMTP id g84B1maG022115 for ; Wed, 4 Sep 2002 12:01:49 +0100 (BST) Message-ID: <3D75E81C.24D678A@erg.abdn.ac.uk> Date: Wed, 04 Sep 2002 12:01:49 +0100 From: Dr G Fairhurst Reply-To: gorry@erg.abdn.ac.uk 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: demo stream, filter questions References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean This seems very helpful in clarifying why MPE is designed the way it is, and the role that MPE is expected to play in the future - particularly how it matches DVB Multiplex operational needs for TV. I think we **should** update section 5 of the requirements draft text, based on this discussion. http://www.erg.abdn.ac.uk/users/gorry/ip-dvb/ids/draft-fair-ipdvb-req-01.txt I could write this based on your mail, but would you be willing to supply 2-3 text paragraphs to add/replace those on MPE? Please do see in-line questions. Gorry Alexander Adolf wrote: > > Dear Gorry, dear Colleagues, > > On 2002-09-03T10:40+0100, Dr G Fairhurst wrote: > > > [...] > > > What comes in mind here is that the MPE header is used as hardware > > > filtering at "MAC/Section" level also. DVB streams are normally high > > > speed streams (in the future > 100 mbps packet throughput (QAM, > > > 8PSK)). > > Today 100 Mbps are reality on satellite systems. Looking into the > future I would expect the satellite operators to add some multiples to > that. One day we will probably run into physical restrictions imposed > by the earth's atmosphere. However I am not an expert on this so > please don't ask me how far we will get... ;-) And then there is still > otical fibre where you get several Gbps today. Yes, true TV mutiplexes are often high rate, and in the future data ones may also be. There are still many data services that use lower-rate multiplexes (much less than a full transponder/repeater). > > > So... There are several questions here. > > > > 1) How significant a feature is "section filtering". I would > > be interested to know how important this feature is. As I see it, > > it gives the encapsulator the possibility of forming seperate > > logical subnetworks within the same MPEG-2 TS Logical Channel. > > Is this just feature-overload? Is there a good reason for not > > using a separate PID for each subnetwork? > > Taking into account the transmission link speeds I just mentioned, a > good amount of the filtering definitely has to be done in hardware. I agree, hardware assist is good for high data rates (and high packet rates). MPE and the lightweight encapsulation could both use hardware filters in future. > > But apart from that, 'just' using another PID in a DVB network is not > as easy as it might seem. > > As DVB networks are television broadcast networks (if not by nature > then by descent), they are subject to regulatory administration in > many parts of the world. So you might simply not be allowed to > introduce a new PID since you haven't registered it with your > regulator. Of course you can always register a new one, but that takes > away any dynamicity (which we probably will want). > > Another constraint are the commercial arrangements and business models > of network operators and service providers (duh, I managed to say the > nasty 'C' and 'B' words in one sentence!). Often a (e.g. IP) service > provider rents a specific bandwidth on a specific PID from a network > operator. This approach could be favorable to both of them since it > will then be easier to multiplex in the (e.g. IP) service and provide > easier network planning for the operator. Additionally a malfunction > of the 'bought-in' service will be much less likely to affect other > services. > > Some service providers have the model that they feed their service to > as many (DVB) distribution networks as possible. In the above > mentioned scenario (renting a specific PID), their service need not > be taylored to the specific distribution network and they are > (almost) the sole responsible for the functioning or malfunctioning of > their service, as blunt PID remultiplexing today is as common and > reliable as - say - sliced bread. > > As you can see there are many implications, boundary conditions and > limitations due to the fact that DVB networks are being operated as > television distribution networks and not as generic interconnection > networks. The section filtering invented by MPEG and adopted by DVB is > especially well suited for these (TV) broadcast medium environments > where remultiplexing comes into play. > OK, so this is a good reason in TV networks why section-handling is useful. Is this really also the case in data networks? > > 2) MAC address filtering - we NEED this to run routing protocols, > > do we need it for directly connected end hosts? If hardware > > filtering is indeed required, could it not use the IPv4 / IPv6 header? > > Is this good / bad? > > > > > I cannot imagine, that a standard receiver filters at IP or > > > similar levels in software. MPE has the MAC address field, which tells > > > the local hardware to set a section level filter. The "minimal header > > > has no such capability. Will receivers get all packets on that PID ? > > > > Yes, currently they would. > > > > > How do you build groups of receiver devices ? > > > > Use another PID? > > [...] > > No (for the above mentioned reasons). That is - amongst others - why > DVB crafted a solution to convey information about IP addresses being > targetted by specific streams or services. I am currently working on > getting clearance for forwarding the latest draft of this to you. > OK, but if you choose to use section filters, there may also be drawbacks? 1) MPE has more header fields and options - therefore harder to process, more complex software / additional silicon. 2) More complex address resolution (another thing to signal) 3) Multicast handling isn't clear to me. If I am an ISP wanting to offer unicast, I can use section headers to separate the clients into manageable groups (private networks). If I wish to add multicast support to my clients, what should I do? I may not want to send each multicast packet once per "section address", that would be wasteful replication of packets with the same content. So, do I form another section address for all multicast groups? - that doesn't seem to provide any section level filtering, we need to look to MAC source/destination addresses or IP addresses to filter. I don't yet see the added beenfit in processing the section header. Another posibility, do I send one section address per multicast group, then I can do section filtering - but I need to resolve the IP address to a section address. This seems teh smae function as MAC source/destination addresses. So there's no added benefit here either? Have I missed something? Can someone help me understand this? > Best regards, > > --alexander adolf > Chairman DVB GBS > > -- > +++ ATTENTION +++ new location as of 2002-06-10 +++++++++++++++++++++ > +++ new address: Frankenthalerstrasse 2, D-81539 Muenchen, Germany ++ > +++ new phone: +49 89 54845 7203 +++ new fax: +49 89 54845 7900 +++++ > > Alexander Adolf, Dipl.-Ing.(FH) -------------------------------------- > Concept Engineer ----------------------------------------------------- > System Software ------------------------------------ info@micronas.com > Micronas Gmbh - Munich Office ----------------------- www.micronas.com From majordomo-owner@erg.abdn.ac.uk Wed Sep 4 13:06:22 2002 Received: from post.webmailer.de (natpost.webmailer.de [192.67.198.65]) by erg.abdn.ac.uk (8.12.6/8.12.6) with SMTP id g84C5uaG022997 for ; Wed, 4 Sep 2002 13:05:57 +0100 (BST) Received: from news (dialin-145-254-148-203.arcor-ip.net [145.254.148.203]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id OAA11242 for ; Wed, 4 Sep 2002 14:05:49 +0200 (MET DST) Message-ID: <002c01c2540b$46e9dc20$cb94fe91@dpiag.de> Reply-To: "Karsten Siebert" From: "Karsten Siebert" To: References: <3D75E81C.24D678A@erg.abdn.ac.uk> Subject: Re: demo stream, filter questions Date: Wed, 4 Sep 2002 14:04:29 +0200 Organization: data planet international AG 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 5.50.4133.2400 Disposition-Notification-To: "Karsten Siebert" X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-MailScanner: Found to be clean One word on IP multicast: RFC1112 is used to set the DSM-CC section MAC address filter. The transmitter fills the section header MAC bytes accordingly, when sending to an IP multicast group. If a host at the receive site joins a group the receiver listens to IGMP messages and sets the filter. The more different IP multicast groups you are going to join, the more section filters are set (often max. per receiver equals 32). But you can set, how many filter bytes are valid and you could ignore some (which at the other hand would give the filter less strength and more other packets would pass to the next level (IP)). Sometimes receiver manufacturers just enable a 12 bytes filter option (which really includes all the DSM-CC header bytes), you can ignore specific bytes (for instance the scrambling bytes). Unfortunately today no relationship between PID setting and section filter setting exists. A couple of years ago we introduced a so called auto mode (last two bytes of MAC address & 0x1fff -> PID). In case you join a group, the entire chain from IP over MAC filter to PID filter will bet set. Works well, but this approach is very static and a better approach is to introduce additional service information for MAC addresses (as proposed for instance by A92 (ATSC)). Karsten From owner-ip-dvb@erg.abdn.ac.uk Fri Sep 6 13:41:29 2002 Received: from mavis.erg.abdn.ac.uk (localhost [127.0.0.1]) by erg.abdn.ac.uk (8.12.6/8.12.6) with ESMTP id g86Cesla020789 for ; Fri, 6 Sep 2002 13:40:54 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.6/8.12.2/Submit) id g86Cesn9020788 for ip-dvb-subscribed-users; Fri, 6 Sep 2002 13:40:54 +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 community13.interfree.it (community13.interfree.it [213.158.72.96]) by erg.abdn.ac.uk (8.12.6/8.12.6) with SMTP id g86Cebla020751 for ; Fri, 6 Sep 2002 13:40:37 +0100 (BST) Received: (qmail 20196 invoked by uid 320); 6 Sep 2002 12:40:38 -0000 Date: 6 Sep 2002 12:40:38 -0000 Message-ID: <20020906124038.20195.qmail@community13.interfree.it> From: gpastore@interfree.it () To: ip-dvb@erg.abdn.ac.uk Subject: DVB MPE and Adaptation Field 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 All, I'm following your activities as regards the project of a new method of encapsulation for IP datagrams over MPEG-2. I have a question for you. In the ETSI TR 101 202 it is stated, as regards the DVB MPE, that the Adaptation Field of the MPEG packet can be used for alignment purposes. My question is: is it possible to use the Adaptation Field to transport private data when the MPE is adopted?. Thank you in advance. Best regards Gaetano Pastore ----------------------------------------------------- Salve, il messaggio che hai ricevuto è stato inviato per mezzo del sistema di web mail interfree. Se anche tu vuoi una casella di posta free visita il sito http://club.interfree.it Ti aspettiamo! ----------------------------------------------------- From owner-ip-dvb@erg.abdn.ac.uk Fri Sep 6 13:55:27 2002 Received: from mavis.erg.abdn.ac.uk (localhost [127.0.0.1]) by erg.abdn.ac.uk (8.12.6/8.12.6) with ESMTP id g86Csrla020923 for ; Fri, 6 Sep 2002 13:54:53 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.6/8.12.2/Submit) id g86CsrwM020922 for ip-dvb-subscribed-users; Fri, 6 Sep 2002 13:54:53 +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 community10.interfree.it (community10.interfree.it [213.158.72.65]) by erg.abdn.ac.uk (8.12.6/8.12.6) with SMTP id g86Csala020909 for ; Fri, 6 Sep 2002 13:54:40 +0100 (BST) Received: (qmail 1283 invoked by uid 320); 6 Sep 2002 12:54:35 -0000 Date: 6 Sep 2002 12:54:35 -0000 Message-ID: <20020906125435.1282.qmail@community10.interfree.it> From: gpastore@interfree.it () To: ip-dvb@erg.abdn.ac.uk Subject: DVB MPE and Adaptation Field 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 All, I'm following your activities as regards the project of a new method of encapsulation for IP datagrams over MPEG-2. I have a question for you. In the ETSI TR 101 202 it is stated, as regards the DVB MPE, that the Adaptation Field of the MPEG packet can be used for alignment purposes. My question is: is it possible to use the Adaptation Field to transport private data when the MPE is adopted?. Thank you in advance. Best regards Gaetano Pastore ----------------------------------------------------- Salve, il messaggio che hai ricevuto è stato inviato per mezzo del sistema di web mail interfree. Se anche tu vuoi una casella di posta free visita il sito http://club.interfree.it Ti aspettiamo! ----------------------------------------------------- From owner-ip-dvb@erg.abdn.ac.uk Fri Sep 6 22:48:44 2002 Received: from mavis.erg.abdn.ac.uk (localhost [127.0.0.1]) by erg.abdn.ac.uk (8.12.6/8.12.6) with ESMTP id g86Lma62024981 for ; Fri, 6 Sep 2002 22:48:36 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.6/8.12.2/Submit) id g86LmZ2M024977 for ip-dvb-subscribed-users; Fri, 6 Sep 2002 22:48:35 +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 hotmail.com (f122.pav1.hotmail.com [64.4.31.122]) by erg.abdn.ac.uk (8.12.6/8.12.6) with SMTP id g86LmH62024962 for ; Fri, 6 Sep 2002 22:48:18 +0100 (BST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 6 Sep 2002 14:48:12 -0700 Received: from 12.153.34.50 by pv1fd.pav1.hotmail.msn.com with HTTP; Fri, 06 Sep 2002 21:48:11 GMT X-Originating-IP: [12.153.34.50] From: "Carl Zen" To: ip-dvb@erg.abdn.ac.uk Subject: Regarding conveying IP related info in DVB-RCS Date: Fri, 06 Sep 2002 17:48:11 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 06 Sep 2002 21:48:12.0604 (UTC) FILETIME=[19135FC0:01C255EF] 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, For those who are familiar with the DVB-RCS ETSI standard, I find a distinct lack of information about conveying IP related configuration (IP address, subnet mask, QoS parameters, unicast, multicast routes) etc., from the NCC network to the RCSTs. There are no descriptive tables defined in the standard, except one (which is not detailed). Is SNMP, the only way to do this? Thanks for your time Carl Zen _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From owner-ip-dvb@erg.abdn.ac.uk Mon Sep 9 15:25:24 2002 Received: from mavis.erg.abdn.ac.uk (localhost [127.0.0.1]) by erg.abdn.ac.uk (8.12.6/8.12.6) with ESMTP id g89EOn62012686 for ; Mon, 9 Sep 2002 15:24:49 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.6/8.12.2/Submit) id g89EOnd2012685 for ip-dvb-subscribed-users; Mon, 9 Sep 2002 15:24:49 +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 mailing.unile.it (mailing.unile.it [193.204.77.251]) by erg.abdn.ac.uk (8.12.6/8.12.6) with SMTP id g89EOD62012671 for ; Mon, 9 Sep 2002 15:24:13 +0100 (BST) Received: from adedbook.unile.it (gisisvr1.unile.it [193.204.77.70]) by mailing.unile.it (8.11.6+Sun/8.11.6) with SMTP id g89GNpS05841 for ; Mon, 9 Sep 2002 16:23:51 GMT Date: Mon, 9 Sep 2002 16:23:51 GMT Message-Id: <200209091623.g89GNpS05841@mailing.unile.it> From: Alessandro De Donno To: ip-dvb@erg.abdn.ac.uk Subject: "Frame" DVB X-Mailer: Sylpheed version 0.8.2 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 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 Hello, I'd like to know what we intend for "frame DVB" (i.e. the "level 2", if this definition has a sense): o the 204-bytes TS packet after Reed-Solomon, or o the 204-bytes TS packet + inner coding (> 204 bytes), or o ??? In general, how do you compare DVB-S stack protocols with ISO/OSI model? According with ETSI EN 300 421, an idea may be: o level 1: modulation and baseband shaping; o level 2 ("sublevel 1"): from inner coding to energy dispersal; o level 2 ("sublevel 2"): MPEG-2 TS (and MPE?); o level 3: IP. TIA, aded PS: ...and sorry for my English :-) From owner-ip-dvb@erg.abdn.ac.uk Tue Sep 10 09:31:35 2002 Received: from mavis.erg.abdn.ac.uk (localhost [127.0.0.1]) by erg.abdn.ac.uk (8.12.6/8.12.6) with ESMTP id g8A8V062019353 for ; Tue, 10 Sep 2002 09:31:00 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.6/8.12.2/Submit) id g8A8V0Pg019352 for ip-dvb-subscribed-users; Tue, 10 Sep 2002 09:31:00 +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 [10.0.1.13] (maxp32.abdn.ac.uk [139.133.7.191]) by erg.abdn.ac.uk (8.12.6/8.12.6) with SMTP id g8A8Uk62019332 for ; Tue, 10 Sep 2002 09:30:47 +0100 (BST) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Tue, 10 Sep 2002 09:30:49 +0100 Subject: Re: "Frame" DVB From: gorry To: Message-ID: In-Reply-To: <200209091623.g89GNpS05841@mailing.unile.it> Mime-version: 1.0 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 on 9/9/02 5:23 pm, Alessandro De Donno at alessandro.dedonno@unile.it wrote: > Hello, > > I'd like to know what we intend for "frame DVB" (i.e. the "level 2", if > this definition has a sense): > > o the 204-bytes TS packet after Reed-Solomon, or > o the 204-bytes TS packet + inner coding (> 204 bytes), or > o ??? Frame should be defined as 184B of data payload. That way you can add 4B of TS packet header and then coding overhead. > > In general, how do you compare DVB-S stack protocols with ISO/OSI model? > According with ETSI EN 300 421, an idea may be: > > o level 1: modulation and baseband shaping; Also preamble to the burst, gurad time, etc. when using DVB-RCS.] > o level 2 ("sublevel 1"): from inner coding to energy dispersal; No. This is a level 1 function - appropriate to a single medium. > o level 2 ("sublevel 2"): MPEG-2 TS (and MPE?); Yes, or any other encapsulation, e.g., DSM-CC carousel, data piping, etc. > o level 3: IP. > > TIA, > aded > > PS: ...and sorry for my English :-) > From owner-ip-dvb@erg.abdn.ac.uk Wed Sep 11 10:09:24 2002 Received: from mavis.erg.abdn.ac.uk (localhost [127.0.0.1]) by erg.abdn.ac.uk (8.12.6/8.12.6) with ESMTP id g8B98o62029908 for ; Wed, 11 Sep 2002 10:08:50 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.6/8.12.2/Submit) id g8B98o7q029907 for ip-dvb-subscribed-users; Wed, 11 Sep 2002 10:08: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 mailing.unile.it (mailing.unile.it [193.204.77.251]) by erg.abdn.ac.uk (8.12.6/8.12.6) with SMTP id g8B98O62029894 for ; Wed, 11 Sep 2002 10:08:32 +0100 (BST) Received: from adedbook.unile.it (gisisvr1.unile.it [193.204.77.70]) by mailing.unile.it (8.11.6+Sun/8.11.6) with SMTP id g8BB81S19490 for ; Wed, 11 Sep 2002 11:08:02 GMT Date: Wed, 11 Sep 2002 11:08:02 GMT Message-Id: <200209111108.g8BB81S19490@mailing.unile.it> From: Alessandro De Donno To: ip-dvb@erg.abdn.ac.uk Subject: Re: "Frame" DVB In-Reply-To: References: <200209091623.g89GNpS05841@mailing.unile.it> X-Mailer: Sylpheed version 0.8.2 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 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 Il giorno Tue, 10 Sep 2002 09:30:49 +0100, in uno stato di totale incoscienza, gorry casualmente disse: > on 9/9/02 5:23 pm, Alessandro De Donno at alessandro.dedonno@unile.it > wrote: Thanks gorry for your replay. I think it's really hard to compare DVB-S and ISO/OSI model under a "level" point of view! Just another question. We have two coding (outer and inner) and not only one "powered" (for example Reed-Solomon) because it would be more expensive (i.e. a RS(255,188,8) instead of RS(204,188,8)). And above all we want to avoid that random errors (on single bits) enter in the interleaver because it couldn't correct burst errors (single bit errors + burst errors). The dimensions of the interleaver are based on RS codeword (204 bytes), so we can't make the interleaver bigger. Is this correct? If not, why two coding? Or: why an interleaver based on RS codeword? Thanks again, gorry. aded From owner-ip-dvb@erg.abdn.ac.uk Wed Sep 11 10:41:28 2002 Received: from mavis.erg.abdn.ac.uk (localhost [127.0.0.1]) by erg.abdn.ac.uk (8.12.6/8.12.6) with ESMTP id g8B9es62000174 for ; Wed, 11 Sep 2002 10:40:54 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.6/8.12.2/Submit) id g8B9esW5000173 for ip-dvb-subscribed-users; Wed, 11 Sep 2002 10:40:54 +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.6/8.12.6) with ESMTP id g8B9eZ62000159 for ; Wed, 11 Sep 2002 10:40:35 +0100 (BST) Message-ID: <3D7F0F93.D47F1172@erg.abdn.ac.uk> Date: Wed, 11 Sep 2002 10:40:35 +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: "Frame" DVB References: <200209091623.g89GNpS05841@mailing.unile.it> <200209111108.g8BB81S19490@mailing.unile.it> 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 I don't think this is relevent to the CHARTER of the ip-dvb list, see: http://www.erg.abdn.ac.uk/users/gorry/ip-dvb/charter.html So, I suggest you discontinue this discussion on this mailing list, it may be more appropriate to carry out on another list. best wishes, Gorry Alessandro De Donno wrote: > > Il giorno Tue, 10 Sep 2002 09:30:49 +0100, in uno stato di totale > incoscienza, > gorry casualmente disse: > > > on 9/9/02 5:23 pm, Alessandro De Donno at alessandro.dedonno@unile.it > > wrote: > > Thanks gorry for your replay. I think it's really hard to compare DVB-S > and ISO/OSI model under a "level" point of view! > > Just another question. > We have two coding (outer and inner) and not only one "powered" (for > example Reed-Solomon) because it would be more expensive (i.e. a > RS(255,188,8) instead of RS(204,188,8)). And above all we want to avoid > that random errors (on single bits) enter in the interleaver because it > couldn't correct burst errors (single bit errors + burst errors). The > dimensions of the interleaver are based on RS codeword (204 bytes), so > we can't make the interleaver bigger. > > Is this correct? If not, why two coding? Or: why an interleaver based on > RS codeword? > > Thanks again, gorry. > > aded From owner-ip-dvb@erg.abdn.ac.uk Sun Sep 29 21:11:55 2002 Received: from mavis.erg.abdn.ac.uk (localhost [127.0.0.1]) by erg.abdn.ac.uk (8.12.6/8.12.6) with ESMTP id g8TKBlC5019202 for ; Sun, 29 Sep 2002 21:11:47 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.6/8.12.2/Submit) id g8TKBkR4019201 for ip-dvb-subscribed-users; Sun, 29 Sep 2002 21:11: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 [139.133.207.88] (inspiration-mac.erg.abdn.ac.uk [139.133.207.88]) by erg.abdn.ac.uk (8.12.6/8.12.6) with ESMTP id g8TKBYC5019189; Sun, 29 Sep 2002 21:11:35 +0100 (BST) User-Agent: Microsoft-Entourage/9.0.2.4011 Date: Sun, 29 Sep 2002 21:11:38 +0100 Subject: Re: IP Multicast over DVB_RCS From: Alastair Matthews To: Marshall Eubanks CC: Message-ID: In-Reply-To: Mime-version: 1.0 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 On 29/9/02 1:44 pm, "Marshall Eubanks" wrote: You might want to try this question on the following list ip-dvb@erg.abdn.ac.uk Info http://www.erg.abdn.ac.uk/ip-dvb/ Archive http://www.erg.abdn.ac.uk/ip-dvb/archive/ A. > Hello; > > Does anyone have any experience with DVB-RCS and multicast ? > > (This is a European standard for two data transmission over satellite video > links, > somewhat akin to DOCSIS 1.1 - see, e.g., > > http://www.erg.abdn.ac.uk/public_html/research/future-net/digital-video/bband- > sat.html > > It is supposed to support IP multicast - are > there any instantiations ? Does this include IGMPv3 ? > > Feel free to respond off-list, but the answer might be of general interest. > > Regards > Marshall Eubanks > From owner-ip-dvb@erg.abdn.ac.uk Sun Sep 29 21:47:43 2002 Received: from mavis.erg.abdn.ac.uk (localhost [127.0.0.1]) by erg.abdn.ac.uk (8.12.6/8.12.6) with ESMTP id g8TKlbC5019605 for ; Sun, 29 Sep 2002 21:47:37 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.6/8.12.2/Submit) id g8TKlbae019604 for ip-dvb-subscribed-users; Sun, 29 Sep 2002 21:47:37 +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 multicasttech.com (IDENT:root@lennon.multicasttech.com [63.105.122.7]) by erg.abdn.ac.uk (8.12.6/8.12.6) with SMTP id g8TKlRC5019590; Sun, 29 Sep 2002 21:47:28 +0100 (BST) Received: from [68.100.14.43] (account ) by multicasttech.com (CommuniGate Pro WebUser 3.4.8) with HTTP id 1443418; Sun, 29 Sep 2002 15:42:40 -0400 From: "Marshall Eubanks" Subject: Re: IP Multicast over DVB_RCS To: Alastair Matthews , Marshall Eubanks Cc: X-Mailer: CommuniGate Pro Web Mailer v.3.4.8 Date: Sun, 29 Sep 2002 15:42:40 -0400 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit 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 On Sun, 29 Sep 2002 21:11:38 +0100 Alastair Matthews wrote: > On 29/9/02 1:44 pm, "Marshall Eubanks" wrote: > Thanks ! Will there be a BOF or a WG meeting in Atlanta for this ? Marshall > You might want to try this question on the following list > > ip-dvb@erg.abdn.ac.uk > > Info > http://www.erg.abdn.ac.uk/ip-dvb/ > > Archive > http://www.erg.abdn.ac.uk/ip-dvb/archive/ > > A. > > > > > Hello; > > > > Does anyone have any experience with DVB-RCS and multicast ? > > > > (This is a European standard for two data transmission over satellite video > > links, > > somewhat akin to DOCSIS 1.1 - see, e.g., > > > > http://www.erg.abdn.ac.uk/public_html/research/future-net/digital-video/bband- > > sat.html > > > > It is supposed to support IP multicast - are > > there any instantiations ? Does this include IGMPv3 ? > > > > Feel free to respond off-list, but the answer might be of general interest. > > > > Regards > > Marshall Eubanks > > >