From owner-ipdvb@erg.abdn.ac.uk Mon Nov 1 03:20:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01711 for ; Mon, 1 Nov 2004 03:20:50 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COXeA-0000MW-Cy for ipdvb-archive@ietf.org; Mon, 01 Nov 2004 03:34:39 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iA17NJWw028256 for ; Mon, 1 Nov 2004 07:23:19 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iA17NJUT028255 for ipdvb-subscribed-users; Mon, 1 Nov 2004 07:23:19 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@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.11/8.12.11) with ESMTP id iA17MKr7028228 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 1 Nov 2004 07:22:21 GMT Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA17MI320774 for ; Mon, 1 Nov 2004 09:22:19 +0200 (EET) X-Scanned: Mon, 1 Nov 2004 09:21:25 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id iA17LPn6020338 for ; Mon, 1 Nov 2004 09:21:25 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00gKDICA; Mon, 01 Nov 2004 09:21:23 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA17LNS03254 for ; Mon, 1 Nov 2004 09:21:23 +0200 (EET) Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Nov 2004 08:59:27 +0200 Received: from trebe051.NOE.Nokia.com ([172.22.124.60]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Nov 2004 08:59:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: security considerations wrt/ draft-ietf-ipdvb-arch-01.txt Date: Mon, 1 Nov 2004 08:59:25 +0200 Message-ID: Thread-Topic: security considerations wrt/ draft-ietf-ipdvb-arch-01.txt Thread-Index: AcS9ysTRiQtiITVVSua/IXGCo9YlyQAHoZ2A From: To: X-OriginalArrivalTime: 01 Nov 2004 06:59:25.0195 (UTC) FILETIME=[528FC5B0:01C4BFE0] X-ERG-MailScanner: Found to be clean, Found to be clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by erg.abdn.ac.uk id iA17NHL5028252 Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 0.3 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Content-Transfer-Encoding: 8bit Please see in-line... > -----Original Message----- > From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk]On > Behalf Of ext George Gross > Sent: Friday, October 29, 2004 3:14 PM > To: ipdvb@erg.abdn.ac.uk > Subject: RE: security considerations wrt/ draft-ietf-ipdvb-arch-01.txt > > > Hi Rod, > > On Fri, 29 Oct 2004 Rod.Walsh@nokia.com wrote: > > > George's observations are valid, but I an sure that > mandiating a link > > level security will significantly reduce the deployability of this > > architecture. In the short and medium term there is no hope of > > convergence to a single "MPEG2-TS link layer security" method. > > So what I think I hear you saying here is that the IPDVB is > not one link > layer really, but "N" different vendor-specific link layers, each with > their own link layer security service. is this a fair assessment? It's one model but I don't feel it's comprehensive enough. The MPEG2-TS layer in question does not come with security, but in DVB, ATSC etc. various security solutions have come in. Most of these are describe as CA and most are "security by obscurity". With or without CA, IPsec and higher layer protection is feasible. Just within the DVB world there are a couple of security solutions (symulcrypt and somethingelse-crypt - me not being an MPEG2 security expert who'd remember the name) > It seems to me, IPDVB without security is a non-starter. Yet the above > would lead me to conclude that there is a tacit assumption that IPDVB > implementations are vendor-specific. IPDVB can assume that some networks are totally insecure and some are totally secure. The grey world inbetween has not been considered. (Note, "totally secure" is the simple way of saying secure enough not to worry source and destination about additional security). > When I contrast this aspect of IPDVB with the IEEE 802.11 and > IEEE 802.16 > wireless standards, the lack of a common security service > looks to be a > barrier to its acceptance, economies of scale, and a widespread > interoperability between different IPDVB vendor's equipment. Very true. WLAN security is much more designed for wide ranging adoption. Among other things, currently DVB is working on technologies to enable IP Datacast over DVB-H. Among this are security technologies including both "open" and "closed" proposals - time will tell what is the final solution, but I do hope a common open security service will come about to enable the acceptance, economies of scale, and a widespread interoperability required for the mobile internet world. In anycase, this will be security at IP layer and above. So the DVB working assuption is that IP over DVB will be protected above link layer. This may be a reasonable assumption for IETF-IPDVB to adopt. > > So I think George is right when he asks for a "definition > of what that > > security service is, and how it would be integrated with > the IP layer > > related services, such as DVB address resolution" - the document is > > well on the way to this. However, the architecture needs to > be modular > > enough to enable the current mix of solutions to be used and make > > space for future ones. > > Agreed. For starters, I would like to see a list of > references enumerating > the relevant security services, assuming they are in the public domain > > > > IMHO, some requirements and guidelines on the link layer > security would be sufficient. > > That would be a good first step, although I am not confident that such > guidelines will be enough to avoid a future security exposure > along the > lines that I sketched. Or other scenarios yet to be discussed > that lurk in > the IPDVB link layer. Unfortunately, since this is an informational > document, its statements are not normative. A vendor could claim IPDVB > compliance even if its products are not secure. (I mean "sufficient for the framework I-D") > > Given what we saw with the 802.11b security debacle, it would be > worthwhile to have a strong industry-wide IPDVB security > standard. If one > of the IPDVB vendors doesn't "get it right" like as happened > with 802.11b, > then all IPDVB deployments get a publicity blackeye even if their own > respective security service is adequate. Though I agree, we need to debate whether this is the right forum and right time in this forum. > > What I think this all points to is the need for a standards > track IPDVB > security protocol document that straddles the vendor-specific DVB link > layers. I don't know IPDVB history in other SDO, so this may > have already > been tried and stalled in those venues. Could someone who knows that > history please offer some perspective? > > In the IETF MSEC venue, we do have IP-layer candidate > solutions that could > be extended and applied to IPDVB's problem. Would this working group > consider such an approach? Unsuprisingly IPsec (with MSEC's contribution to ESP) and MIKEY are among the proposals in DVB and 3GPP for mobile mass media IP multicast security. (Beware, I am not good at opening cans of worms and I do not have all the references to documents as I am not active in security - I can forward requests but with low QoS) Cheers, Rod. > > br, > George > > > > From owner-ipdvb@erg.abdn.ac.uk Mon Nov 1 03:31:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02955 for ; Mon, 1 Nov 2004 03:31:55 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COXqP-0000lF-RE for ipdvb-archive@ietf.org; Mon, 01 Nov 2004 03:47:18 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iA17PjEh028333 for ; Mon, 1 Nov 2004 07:25:45 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iA17Pi40028332 for ipdvb-subscribed-users; Mon, 1 Nov 2004 07:25:44 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iA17OYsV028291 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 1 Nov 2004 07:24:36 GMT Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA17OYl07389 for ; Mon, 1 Nov 2004 09:24:34 +0200 (EET) X-Scanned: Mon, 1 Nov 2004 09:24:07 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id iA17O73e000614 for ; Mon, 1 Nov 2004 09:24:07 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00bZxRjk; Mon, 01 Nov 2004 09:24:06 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA17Nva18005 for ; Mon, 1 Nov 2004 09:23:57 +0200 (EET) Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Nov 2004 08:59:27 +0200 Received: from trebe051.NOE.Nokia.com ([172.22.124.60]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Nov 2004 08:59:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: security considerations wrt/ draft-ietf-ipdvb-arch-01.txt Date: Mon, 1 Nov 2004 08:59:26 +0200 Message-ID: Thread-Topic: security considerations wrt/ draft-ietf-ipdvb-arch-01.txt Thread-Index: AcS93W3L6Ztkep9XTn+ATt/GVyKshgACnR0Q From: To: X-OriginalArrivalTime: 01 Nov 2004 06:59:24.0568 (UTC) FILETIME=[52301980:01C4BFE0] X-ERG-MailScanner: Found to be clean, Found to be clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by erg.abdn.ac.uk id iA17PfLS028326 Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 0.3 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 8bit Thanks for the clarification - sorry abour being too lazy to read the charter (or too busy to think of it :) BTW, although George is making good points (which I mostly agree with) these can not be solved in the framework without some length of work and strong DVB liaison even at this stage (as the related DVB work is in progress) so it could be best to move towards modifing the I-D to accomodate furture security work. (George ocrrect me if I'm wrong but I have the impression that "a subsequent plug-in IPDVB security framework" would be more along the lines of your thoughts, given that a framework would be describing the current solutions and the need to fill gaps and improve interoperability). (So far this has not been part of the WG charter so the framework security considerations do already seem to be a good effort in my eyes. On one hand I'd like to encourage the WG to look into these security aspects more. On the other, it may be better to keep focused and wait for the DVB IP security solution dust to settle.) Cheers, Rod. > -----Original Message----- > From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk]On > Behalf Of ext Gorry Fairhurst > Sent: Friday, October 29, 2004 8:09 PM > To: ipdvb@erg.abdn.ac.uk > Subject: Re: security considerations wrt/ draft-ietf-ipdvb-arch-01.txt > > > > > Thanks Rod! > > I will respond more to the detail at a later date, but to answer the > following quickly: > > > > > Also, what is the "statement of intent"? (i.e. I assume the > intention > > is to give this to the IESG to become an Informational RFC, but the > > WGLC doesn't say. Experimental could be an option if there is any > > intent to turn this into a normative specification once other IPDVB > > I-Ds progress - though I have not got the impression that this has > > been asked for). > > > > Cheers, Rod. > > > > It is not the intention to change THIS document into a > protocol spec - > although the WG is now invited/expected to work on the other Charter > items which relate to implementing elements of the architecture. > > The document was written in reponse to the following charter item: > > "Specify the requirements and architecture for supporting > IPv4/IPv6 via > MPEG-2 transmission networks. Such requirements should consider the > range of platforms currently (or anticipated to be) in use. This draft > will be an Informational RFC." > > When completed it will therefore be put to the IESG for proposed > publication as an INFORMATIONAL document, although the final > classification is of course determined by the IESG, not the WG. > > > > Best wishes, > > Gorry Fairhurst > (ipdvb WG Chair) > > From owner-ipdvb@erg.abdn.ac.uk Tue Nov 2 06:30:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08513 for ; Tue, 2 Nov 2004 06:30:03 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COx6b-0007AT-KX for ipdvb-archive@ietf.org; Tue, 02 Nov 2004 06:45:42 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iA2Ah8XZ006550 for ; Tue, 2 Nov 2004 10:43:08 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iA2Ah87B006549 for ipdvb-subscribed-users; Tue, 2 Nov 2004 10:43:08 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iA2Ag7Ou006512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 2 Nov 2004 10:42:08 GMT Message-ID: <41876480.7000801@erg.abdn.ac.uk> Date: Tue, 02 Nov 2004 10:42:08 +0000 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: I-D ACTION:draft-fair-ipdvb-ar-02.txt (repost) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit By mistake, the announcement below, was not relayed to this list. This is an individual submission, but does appear to match a WG Charter item. Please send comments to the ipdvb mailing list. Gorry Fairhurst --- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Address Resolution for IP datagrams over MPEG-2 networks Author(s) : G. Fairhurst, et al. Filename : draft-fair-ipdvb-ar-02.txt Pages : 17 Date : 2004-10-21 This document describes the current mechanisms to bind IPv4/IPv6 addresses and flows to MPEG-2 Transport Streams (TS). For MPEG-2 systems to become true subnetworks of the general Internet, methods are required to signal IPv4/v6 addresses to the link receivers and transmitters; this is known as Address Resolution (AR), or Neighbour Discovery (ND). Although AR is often associated with Ethernet [RFC803], it is essential to the operation of any L2 network. In MPEG-2 networks, address resolution is a three level process: the IP address is resolved to a NPA/MAC address, then associated with a Packet ID (PID) and finally to a specific transmission multiplex. Address resolution complements the higher layer resource discovery tools that are used to advertise IP sessions. In this document the different mechanisms used for address resolution for MPEG-2 are reviewed and their compliance to AR requirements established. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-fair-ipdvb-ar-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-fair-ipdvb-ar-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-fair-ipdvb-ar-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. From owner-ipdvb@erg.abdn.ac.uk Tue Nov 2 07:03:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10387 for ; Tue, 2 Nov 2004 07:03:40 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COxd9-0007nB-BC for ipdvb-archive@ietf.org; Tue, 02 Nov 2004 07:19:19 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iA2BHBWX007316 for ; Tue, 2 Nov 2004 11:17:11 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iA2BHBVM007315 for ipdvb-subscribed-users; Tue, 2 Nov 2004 11:17:11 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iA2BGf82007297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 2 Nov 2004 11:16:42 GMT Message-ID: <41876C9A.5030304@erg.abdn.ac.uk> Date: Tue, 02 Nov 2004 11:16:42 +0000 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: Re: security considerations wrt/ draft-ietf-ipdvb-arch-01.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit On clarification of the AR work scope: Rod.Walsh@nokia.com wrote: > * I get the impression that it is an intentional limitation of the AR that it > applies only to the current TS (as you would expect cf ARP). This is a sensible > limitation but it's worth stating explicitly. > (i.e. that address resolution for other TSes, e.g. for moving TS and mobility > optimisation, is not in scope). > > Cheers, Rod. > > My understanding was that the scope of any new work will be to resolve *within* a transport multiplex (i.e. a single physical bearer). The proposals to date do not allow the possibility of a TS logical channel (i.e. PID value) to be changed during (re)multiplexing - there are scenarios in which this can happen - and there are specific solutions already in this space (guidance on how to use these is within scope). Providing AR services that span multiple physical bearers is significantly more complex and typically requires processing of SI table information - solutions also already exist in this space e.g. proposed by ATSC and DVB (guidance on how to use these is within scope). I'd encourage an approach which is simple. Rod is that any help? Do other people have thoughts? Gorry From owner-ipdvb@erg.abdn.ac.uk Tue Nov 2 07:09:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11155 for ; Tue, 2 Nov 2004 07:09:07 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COxiQ-0007v0-H5 for ipdvb-archive@ietf.org; Tue, 02 Nov 2004 07:24:47 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iA2BSk56007688 for ; Tue, 2 Nov 2004 11:28:46 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iA2BSkjl007687 for ipdvb-subscribed-users; Tue, 2 Nov 2004 11:28:46 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iA2BSEu0007668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 2 Nov 2004 11:28:14 GMT Message-ID: <41876F4F.7080308@erg.abdn.ac.uk> Date: Tue, 02 Nov 2004 11:28:15 +0000 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Subject: End of WGLC: draft-ietf-ipdvb-arch-01.txt Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Content-Transfer-Encoding: 7bit The WGLC for the above ID ended at midnight on 29th October 2004. A summary of the issues raised is provided below. Gorry Fairhurst (IPDVB WG CHAIR) -------------- Comments were received from: George Gross Rod Walsh Haitham Cruickshank All authors have also reviewed this version of the ID: M.J. Montpetit Gorry Fairhurst Horst D. Clausen Bernhard Collini-Nocker Hilmar Linder -------------- * Section 8: Security Considerations * Section 8.1 - Link Encryption - Should the IPDVB architecture require at least ONE security service? Current text: "MPE supports optional link encryption using a pair of bits within the MPE protocol header to indicate the use of encryption. To support optional link level encryption, it is recommended that a new encapsulation also supports optional encryption of the SNDU payload. Furthermore, it may be desirable to encrypt/authenticate some/all of the SNDU headers. The method of encryption and the way in which keys are exchanged is beyond the scope of the ULE Specification. However, the specification must provide appropriate code points to allow such encryption to be implemented at the link layer." * The IPDVB arch document should identify its requirements on these security services: point-to-point encryption between head-end and individual subscriber, source authentication when binding IP addresses and MAC addresses, mutual authentication between the subscriber terminal and head-end, etc. * Optional MPE/ULE layer encryption (which encapsulates the IP packets), requires any hacker to have the encryption key to see any user data in these SNDUs. * IPDVB can assume that some networks are totally insecure and some are totally secure. * There is a case to be made for an industry-wide IPDVB security service: - superior security, due to peer review by the IETF community, - inter-operability, fostering economies of scale like that seen for 802 wireless. * The way things stand at the moment in this document, an IPDVB vendor does not have to implement any security standards. They can produce products that only transmit cleartext and still they can assert that they are IETF IPDVB "standards compliant". Further, any two vendors that do implement a DVB security service are unlikely to inter-operate, since none was mandated as a must implement. This could be a DVB link-layer service or it could a MSEC layer-3 overlay. The former option makes this group's work dependent on another SDO. The latter option could be advanced by this working group in cooperation with MSEC... * We need to debate whether this is the right forum and right time in this forum. * These can not be solved in the framework without some length of work and strong DVB liaison even at this stage (as the related DVB work is in progress) so it could be best to move towards modifing the I-D to accomodate furture security work. * Encourage the WG to look into these security aspects more. * It may be better to keep focused and wait for the DVB IP security solution dust to settle. * List of references enumerating the relevant security services, assuming they are in the public domain. * Need for a standards track IPDVB security protocol document? - This issue needs to be resolved. --------------- * Scope of AR: * I get the impression that it is an intentional limitation of the AR that it applies only to the current TS (as you would expect cf ARP). This is a sensible limitation but it's worth stating explicitly. (i.e. that address resolution for other TSes, e.g. for moving TS and mobility optimisation, is not in scope). - I think the WG would could work with any of these issues, if there is expertise and with appropriate collaboration (or inputs from other standards bodies). --------------- * Editorial NiTs (see also http://www.erg.abdn.ac.uk/ip-dvb/archive/msg00817.html) * the "Change Notice:" should be described in a annex including a note to the RFC Editor that they are not to be included in the RFC * "D-TV" of figure 1 should be "terrestrial" to be in line with "satelite" and "cable" (all 3 can deliver D-TV and more). * "Data-cast" is correctly spelt "Datacast" and is more commonly known as "IP Datacast" in this context (other-than-IP packetisation over broacast also gets labelled datacast from time to time) * 5.4 AR Authentication "Servers should perform authorisation issue before they allow a L2 address to be used." - remove "issue". ------------------ Gorry Fairhurst (IPDVB WG Chair) From owner-ipdvb@erg.abdn.ac.uk Tue Nov 2 09:36:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24745 for ; Tue, 2 Nov 2004 09:36:54 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP01R-0002zV-94 for ipdvb-archive@ietf.org; Tue, 02 Nov 2004 09:52:34 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iA2Dw0bV012275 for ; Tue, 2 Nov 2004 13:58:01 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iA2Dw0MJ012272 for ipdvb-subscribed-users; Tue, 2 Nov 2004 13:58:00 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iA2DuG5Z012200 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 2 Nov 2004 13:56:18 GMT Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA2DuHl18713 for ; Tue, 2 Nov 2004 15:56:17 +0200 (EET) X-Scanned: Tue, 2 Nov 2004 15:55:48 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id iA2DtmLK023111 for ; Tue, 2 Nov 2004 15:55:48 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00EJ4q7n; Tue, 02 Nov 2004 15:55:48 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA2DtWa25873 for ; Tue, 2 Nov 2004 15:55:32 +0200 (EET) Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 2 Nov 2004 15:55:29 +0200 Received: from trebe051.NOE.Nokia.com ([172.22.124.60]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 2 Nov 2004 15:55:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: security considerations wrt/ draft-ietf-ipdvb-arch-01.txt Date: Tue, 2 Nov 2004 15:55:29 +0200 Message-ID: Thread-Topic: security considerations wrt/ draft-ietf-ipdvb-arch-01.txt Thread-Index: AcTAz3D2lwEUaXRRRNKnNtNnaXyj/wAE/hbg From: To: X-OriginalArrivalTime: 02 Nov 2004 13:55:29.0946 (UTC) FILETIME=[9D2037A0:01C4C0E3] X-ERG-MailScanner: Found to be clean, Found to be clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by erg.abdn.ac.uk id iA2Dvsru012268 Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 0.3 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 8bit We agree on this issue of scope. How about stating it explicitly in the document? (i.e. that address resolution for other TSes, e.g. for moving TS and mobility optimisation, is not in scope)? Cheers, Rod. > -----Original Message----- > From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk]On > Behalf Of ext Gorry Fairhurst > Sent: Tuesday, November 02, 2004 1:17 PM > To: ipdvb@erg.abdn.ac.uk > Subject: Re: security considerations wrt/ draft-ietf-ipdvb-arch-01.txt > > > > On clarification of the AR work scope: > > Rod.Walsh@nokia.com wrote: > > > > > * I get the impression that it is an intentional limitation > of the AR that it > > applies only to the current TS (as you would expect cf > ARP). This is > a sensible > > limitation but it's worth stating explicitly. > > (i.e. that address resolution for other TSes, e.g. for > moving TS and > mobility > > optimisation, is not in scope). > > > > > > > Cheers, Rod. > > > > > > My understanding was that the scope of any new work will be > to resolve > *within* a transport multiplex (i.e. a single physical bearer). The > proposals to date do not allow the possibility of a TS > logical channel > (i.e. PID value) to be changed during (re)multiplexing - there are > scenarios in which this can happen - and there are specific solutions > already in this space (guidance on how to use these is within scope). > > Providing AR services that span multiple physical bearers is > significantly more complex and typically requires processing > of SI table > information - solutions also already exist in this space e.g. > proposed > by ATSC and DVB (guidance on how to use these is within scope). > > I'd encourage an approach which is simple. > > Rod is that any help? Do other people have thoughts? > > Gorry > > From owner-ipdvb@erg.abdn.ac.uk Tue Nov 2 11:14:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05101 for ; Tue, 2 Nov 2004 11:14:11 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP1Xb-0005MY-TH for ipdvb-archive@ietf.org; Tue, 02 Nov 2004 11:29:52 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iA2FZkhs015113 for ; Tue, 2 Nov 2004 15:35:46 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iA2FZkl5015112 for ipdvb-subscribed-users; Tue, 2 Nov 2004 15:35:46 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from nab.org (foxtrot.nab.org [209.116.240.194]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iA2FXxPx015042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 2 Nov 2004 15:34:01 GMT Received: from ([199.29.3.1]) by maildc2.nab.org with ESMTP id 4028857.2657347; Tue, 02 Nov 2004 10:17:12 -0500 Received: by mail.NAB.ORG with Internet Mail Service (5.5.2653.19) id <47VLJ6XS>; Tue, 2 Nov 2004 10:17:12 -0500 Message-ID: <5A659834E1607E4EBD72FCE2FE5C9CF108EDC65F@mail.NAB.ORG> From: "Allison, Art" To: "'ipdvb@erg.abdn.ac.uk'" Subject: RE: security considerations wrt/ draft-ietf-ipdvb-arch-01.txt Date: Tue, 2 Nov 2004 10:17:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 It should be clear to anyone informed about MPEG2 TS multiplexers that using a fixed PID introduces significant complexity for management of a TS intended for broadcast to consumers. Re-multiplexers drop such PIDs from the stream unless specifically programed for special treatment of the fixed PID (the value of which has to be communicated via 'other' means). IMHO, this makes the entire solution/approach developed by this group generally useless for the transmission path from a broadcaster to the consumer (which also goes through cable system remultiplexers). The address resolution and scoping of 'network' issues have been resolved by the ATSC. The method of delivery of IP traffic that is documented is proven. It is offered in products from multiple vendors and is being used every day (and has been for a few years) in the real world for delivery of IP traffic via over the air broadcast to consumers. Inventing another solution for the broadcast OTA link seems to be wasted effort - especially a solution that is fundimentially as flawed as to require a fixed PID. Perhaps now is the time to recognize that this IETF work is really optimized for other MPEG-TS-using networks and its claimed scope should be reduced to the other transmission links, where folks determine that the 2.2% overhead the 'fixed PID' approach requires is actually less than one obtains with DSMCC for the traffic they expect to flow. Art Allison NAB S&T p.s. If someone would like more information see A/92 and applicable parts of A/90 at www.atsc.org. Also note, as it may not be obvious, that the DSMCC-based technology in these standards is seperable from the ATSC announcement technology and then is applicable to any TS. -----Original Message----- From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk] Sent: Tuesday, November 02, 2004 6:17 AM To: ipdvb@erg.abdn.ac.uk Subject: Re: security considerations wrt/ draft-ietf-ipdvb-arch-01.txt On clarification of the AR work scope: Rod.Walsh@nokia.com wrote: > * I get the impression that it is an intentional limitation of the AR that it > applies only to the current TS (as you would expect cf ARP). This is a sensible > limitation but it's worth stating explicitly. > (i.e. that address resolution for other TSes, e.g. for moving TS and mobility > optimisation, is not in scope). > > Cheers, Rod. > > My understanding was that the scope of any new work will be to resolve *within* a transport multiplex (i.e. a single physical bearer). The proposals to date do not allow the possibility of a TS logical channel (i.e. PID value) to be changed during (re)multiplexing - there are scenarios in which this can happen - and there are specific solutions already in this space (guidance on how to use these is within scope). Providing AR services that span multiple physical bearers is significantly more complex and typically requires processing of SI table information - solutions also already exist in this space e.g. proposed by ATSC and DVB (guidance on how to use these is within scope). I'd encourage an approach which is simple. Rod is that any help? Do other people have thoughts? Gorry From owner-ipdvb@erg.abdn.ac.uk Tue Nov 2 12:58:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18171 for ; Tue, 2 Nov 2004 12:58:48 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP3As-0000CB-98 for ipdvb-archive@ietf.org; Tue, 02 Nov 2004 13:14:31 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iA2HB8Qn017607 for ; Tue, 2 Nov 2004 17:11:08 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iA2HB7IJ017606 for ipdvb-subscribed-users; Tue, 2 Nov 2004 17:11:07 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iA2H9nVr017559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 2 Nov 2004 17:09:50 GMT Message-ID: <4187BF5E.9030604@erg.abdn.ac.uk> Date: Tue, 02 Nov 2004 17:09:50 +0000 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: Re: security considerations wrt/ draft-ietf-ipdvb-arch-01.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit The architecture not only covers ULE, it covers methods such as MPE (DSM-CC encaps) and usage of the DVB INT Table, etc. It also includes the usage with UDLR, ARP, ND, etc as a networking technology. So, if we're talking about arp, ND, then I was assuming this was all over a single PID (or potentially group of PIDs) and that this defined a subnetwork. Gorry Rod.Walsh@nokia.com wrote: > We agree on this issue of scope. How about stating it explicitly in the document? (i.e. that address resolution for other TSes, e.g. for moving TS and mobility optimisation, is not in scope)? > > Cheers, Rod. > > > >>-----Original Message----- >>From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk]On >>Behalf Of ext Gorry Fairhurst >>Sent: Tuesday, November 02, 2004 1:17 PM >>To: ipdvb@erg.abdn.ac.uk >>Subject: Re: security considerations wrt/ draft-ietf-ipdvb-arch-01.txt >> >> >> >>On clarification of the AR work scope: >> >>Rod.Walsh@nokia.com wrote: >> >> >> >>>* I get the impression that it is an intentional limitation >> >>of the AR that it >> > applies only to the current TS (as you would expect cf >>ARP). This is >>a sensible >> > limitation but it's worth stating explicitly. >> > (i.e. that address resolution for other TSes, e.g. for >>moving TS and >>mobility >> > optimisation, is not in scope). >> >> >> >>>Cheers, Rod. >>> >>> >> >>My understanding was that the scope of any new work will be >>to resolve >>*within* a transport multiplex (i.e. a single physical bearer). The >>proposals to date do not allow the possibility of a TS >>logical channel >>(i.e. PID value) to be changed during (re)multiplexing - there are >>scenarios in which this can happen - and there are specific solutions >>already in this space (guidance on how to use these is within scope). >> >>Providing AR services that span multiple physical bearers is >>significantly more complex and typically requires processing >>of SI table >>information - solutions also already exist in this space e.g. >>proposed >>by ATSC and DVB (guidance on how to use these is within scope). >> >>I'd encourage an approach which is simple. >> >>Rod is that any help? Do other people have thoughts? >> >>Gorry >> >> > > > From owner-ipdvb@erg.abdn.ac.uk Tue Nov 2 13:02:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19209 for ; Tue, 2 Nov 2004 13:02:14 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP3EC-0000NW-Nb for ipdvb-archive@ietf.org; Tue, 02 Nov 2004 13:17:57 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iA2HEKj5017728 for ; Tue, 2 Nov 2004 17:14:20 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iA2HEKis017727 for ipdvb-subscribed-users; Tue, 2 Nov 2004 17:14:20 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iA2HCHxg017648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 2 Nov 2004 17:12:18 GMT Message-ID: <4187BFF2.9070602@erg.abdn.ac.uk> Date: Tue, 02 Nov 2004 17:12:18 +0000 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: Re: security considerations wrt/ draft-ietf-ipdvb-arch-01.txt References: <5A659834E1607E4EBD72FCE2FE5C9CF108EDC65F@mail.NAB.ORG> In-Reply-To: <5A659834E1607E4EBD72FCE2FE5C9CF108EDC65F@mail.NAB.ORG> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit Art, which document are you referring to? The version of A/92 which I have relates only to multicast packet delivery. Is there an update that covers more? I can't find how the bindings apply to usage of arp for IPv4 (or how these multicast mappings relate to ND for IPv6). Gorry Allison, Art wrote: > It should be clear to anyone informed about MPEG2 TS multiplexers that using > a fixed PID introduces significant complexity for management of a TS > intended for broadcast to consumers. Re-multiplexers drop such PIDs from the > stream unless specifically programed for special treatment of the fixed PID > (the value of which has to be communicated via 'other' means). IMHO, this > makes the entire solution/approach developed by this group generally useless > for the transmission path from a broadcaster to the consumer (which also > goes through cable system remultiplexers). > Is this not scenario A in the above document? > The address resolution and scoping of 'network' issues have been resolved by > the ATSC. The method of delivery of IP traffic that is documented is proven. > It is offered in products from multiple vendors and is being used every day > (and has been for a few years) in the real world for delivery of IP traffic > via over the air broadcast to consumers. > > Inventing another solution for the broadcast OTA link seems to be wasted > effort - especially a solution that is fundimentially as flawed as to > require a fixed PID. > > Perhaps now is the time to recognize that this IETF work is really optimized > for other MPEG-TS-using networks and its claimed scope should be reduced to > the other transmission links, where folks determine that the 2.2% overhead > the 'fixed PID' approach requires is actually less than one obtains with > DSMCC for the traffic they expect to flow. > Which 2.2% do you mean? > Art Allison > NAB S&T > p.s. If someone would like more information see A/92 and applicable parts of > A/90 at www.atsc.org. Also note, as it may not be obvious, that the > DSMCC-based technology in these standards is seperable from the ATSC > announcement technology and then is applicable to any TS. > > -----Original Message----- > From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk] > Sent: Tuesday, November 02, 2004 6:17 AM > To: ipdvb@erg.abdn.ac.uk > Subject: Re: security considerations wrt/ draft-ietf-ipdvb-arch-01.txt > > > > On clarification of the AR work scope: > > Rod.Walsh@nokia.com wrote: > > > >>* I get the impression that it is an intentional limitation of the AR that > > it > > applies only to the current TS (as you would expect cf ARP). This is > a sensible > > limitation but it's worth stating explicitly. > > (i.e. that address resolution for other TSes, e.g. for moving TS and > mobility > > optimisation, is not in scope). > > > >>Cheers, Rod. >> >> > > > My understanding was that the scope of any new work will be to resolve > *within* a transport multiplex (i.e. a single physical bearer). The > proposals to date do not allow the possibility of a TS logical channel > (i.e. PID value) to be changed during (re)multiplexing - there are > scenarios in which this can happen - and there are specific solutions > already in this space (guidance on how to use these is within scope). > > Providing AR services that span multiple physical bearers is > significantly more complex and typically requires processing of SI table > information - solutions also already exist in this space e.g. proposed > by ATSC and DVB (guidance on how to use these is within scope). > > I'd encourage an approach which is simple. > > Rod is that any help? Do other people have thoughts? > > Gorry > > From owner-ipdvb@erg.abdn.ac.uk Sun Nov 7 18:11:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08813 for ; Sun, 7 Nov 2004 18:11:08 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQwC9-0007Uf-Ov for ipdvb-archive@ietf.org; Sun, 07 Nov 2004 18:11:38 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iA7MXvit018900 for ; Sun, 7 Nov 2004 22:33:57 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iA7MXuw2018898 for ipdvb-subscribed-users; Sun, 7 Nov 2004 22:33:57 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from [130.129.134.197] ([130.129.134.197]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iA7MW6DL018829 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Sun, 7 Nov 2004 22:32:19 GMT User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sun, 07 Nov 2004 16:42:26 -0500 Subject: ATSC From: Gorry Fairhurst To: , "ipdvb@erg.abdn.ac.uk" Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 7bit Art, Sorry for the terse answer, earlier. The authors (and I do expect the WG too) value the inputs and experience of both the ATSC & DVB communities. The chief goal of the WG is to develop protocols and documents to define how the IP protocol suite (both IPv4 and IPv6) is to use these services as a link within the Internet. It includes specification of appropriate ways to bind the end-to-end IP addresses to the L2 network. This also explicitly includes how arp, neighbor discovery would be used, how to handle multicast routing, support for Uni-directional links, etc. There are many scenarios in which MPEG-2 is used, and one of the objectives of the (arch) document that just went through WGLC was to define specific scenarios as useful basis for future work. 6 of these were defined. Scenario A relates to the broadcast TV case (as in figure 4.1 of A/90), which you referred to. In this case, the text of the Internet Draft seems to follow the requirements, that you mentioned, i.e.: Section 3.3 says: "In a more complex example, the same TS may be fed to multiple MPEG-2 multiplexors and these may, in turn, feed other MPEG-2 multiplexors (remultiplexing). Remultiplexing may occur in several places (and is common in Scenarios A and B of section 3.1)." And 5.1 says: "Elements (ii) and (iii) need to be de-referenced via indexes to the Service Information (i.e. the Program Map Table, PMT) when the MPEG-2 Transmission Network includes remultiplexors that renumber the PID values of the TS Logical Channels that they process. (Note that PIDs are not intended to be end-to-end identifiers). However, although such use is common in broadcast TV networks, many private networks do not need to employ multiplexors that renumber PIDs (see section 3.2)." As far as I can see, the set of ATSC references in the arch document refer only to push (uni-directional) transmission of IP multicast content. While IP multicast is in important service for MPEG-2 bearers, the WG scope is to provide IP in general (unicast, multicast, routing, etc), linking IP networks using the MPEG-2 link. It would also be useful to point the WG to any other documents from the ATSC community that relate to two-way IP services. Best wishes, Gorry Fairhurst. Allison, Art wrote: > It should be clear to anyone informed about MPEG2 TS multiplexers that using > a fixed PID introduces significant complexity for management of a TS > intended for broadcast to consumers. Re-multiplexers drop such PIDs from the > stream unless specifically programed for special treatment of the fixed PID > (the value of which has to be communicated via 'other' means). IMHO, this > makes the entire solution/approach developed by this group generally useless > for the transmission path from a broadcaster to the consumer (which also > goes through cable system remultiplexers). > > The address resolution and scoping of 'network' issues have been resolved by > the ATSC. The method of delivery of IP traffic that is documented is proven. > It is offered in products from multiple vendors and is being used every day > (and has been for a few years) in the real world for delivery of IP traffic > via over the air broadcast to consumers. > > Inventing another solution for the broadcast OTA link seems to be wasted > effort - especially a solution that is fundimentially as flawed as to > require a fixed PID. > > Perhaps now is the time to recognize that this IETF work is really optimized > for other MPEG-TS-using networks and its claimed scope should be reduced to > the other transmission links, where folks determine that the 2.2% overhead > the 'fixed PID' approach requires is actually less than one obtains with > DSMCC for the traffic they expect to flow. > > Art Allison > NAB S&T > p.s. If someone would like more information see A/92 and applicable parts of > A/90 at www.atsc.org. Also note, as it may not be obvious, that the > DSMCC-based technology in these standards is seperable from the ATSC > announcement technology and then is applicable to any TS. > > -----Original Message----- > From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk] > Sent: Tuesday, November 02, 2004 6:17 AM > To: ipdvb@erg.abdn.ac.uk > Subject: Re: security considerations wrt/ draft-ietf-ipdvb-arch-01.txt > > From owner-ipdvb@erg.abdn.ac.uk Mon Nov 8 15:55:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00843 for ; Mon, 8 Nov 2004 15:55:34 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRGYg-0005NJ-1B for ipdvb-archive@ietf.org; Mon, 08 Nov 2004 15:56:14 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iA8K9nw8017639 for ; Mon, 8 Nov 2004 20:09:49 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iA8K9mcu017638 for ipdvb-subscribed-users; Mon, 8 Nov 2004 20:09:48 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from nab.org (foxtrot.nab.org [209.116.240.194]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iA8K7qJb017585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 8 Nov 2004 20:07:54 GMT Received: from ([199.29.3.1]) by maildc2.nab.org with ESMTP id 4028857.2740752; Mon, 08 Nov 2004 15:07:17 -0500 Received: by mail.NAB.ORG with Internet Mail Service (5.5.2653.19) id <47VLKWFL>; Mon, 8 Nov 2004 15:07:17 -0500 Message-ID: <5A659834E1607E4EBD72FCE2FE5C9CF103B799E1@mail.NAB.ORG> From: "Allison, Art" To: ipdvb@erg.abdn.ac.uk Subject: RE: ATSC Date: Mon, 8 Nov 2004 15:07:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Gorry Thanks for the post. I also have been pressed for time. My post was triggered by the 'fixed PID' discussion. The architectural requirements for Scenario A indeed reasonably address the broadcasting case (and as such did cross the threshold of justifying a last call comment). But then it seemed those aspects were being ignored by the discussion of fixed PIDs. While it may be technically feasible to establish a few logical individual connections from an OTA emission facility and consumer devices (through use of some other return channel), it is clear that this does not scale well beyond, say, a few thousand such connections. This is not a conceptual flaw in the arch doc per se; as parts can be addressed in different drafts. It seems best to fit the scope of the drafts to follow to the scenarios they fit. What does make sense for OTA is multicast, and it appears that perhaps the needs in the other scenarios and the needs of OTA are enough different that attempting to have one-to-one for OTA covered in the same document may either constrain the other scenarios or inadequately cover OTA. The other needs seem more pressing as well, perhaps it is wise to separate those and finish them. The committee members may find ATSC A/96 - 'Interaction Channel Protocols' of some interest with respect to the two-way standardization work; though it may not be directly usable. See http://www.atsc.org/standards/A_96.pdf Art -----Original Message----- From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk] Sent: Sunday, November 07, 2004 4:42 PM To: AAllison@nab.org; ipdvb@erg.abdn.ac.uk Subject: ATSC Art, Sorry for the terse answer, earlier. The authors (and I do expect the WG too) value the inputs and experience of both the ATSC & DVB communities. The chief goal of the WG is to develop protocols and documents to define how the IP protocol suite (both IPv4 and IPv6) is to use these services as a link within the Internet. It includes specification of appropriate ways to bind the end-to-end IP addresses to the L2 network. This also explicitly includes how arp, neighbor discovery would be used, how to handle multicast routing, support for Uni-directional links, etc. There are many scenarios in which MPEG-2 is used, and one of the objectives of the (arch) document that just went through WGLC was to define specific scenarios as useful basis for future work. 6 of these were defined. Scenario A relates to the broadcast TV case (as in figure 4.1 of A/90), which you referred to. In this case, the text of the Internet Draft seems to follow the requirements, that you mentioned, i.e.: Section 3.3 says: "In a more complex example, the same TS may be fed to multiple MPEG-2 multiplexors and these may, in turn, feed other MPEG-2 multiplexors (remultiplexing). Remultiplexing may occur in several places (and is common in Scenarios A and B of section 3.1)." And 5.1 says: "Elements (ii) and (iii) need to be de-referenced via indexes to the Service Information (i.e. the Program Map Table, PMT) when the MPEG-2 Transmission Network includes remultiplexors that renumber the PID values of the TS Logical Channels that they process. (Note that PIDs are not intended to be end-to-end identifiers). However, although such use is common in broadcast TV networks, many private networks do not need to employ multiplexors that renumber PIDs (see section 3.2)." As far as I can see, the set of ATSC references in the arch document refer only to push (uni-directional) transmission of IP multicast content. While IP multicast is in important service for MPEG-2 bearers, the WG scope is to provide IP in general (unicast, multicast, routing, etc), linking IP networks using the MPEG-2 link. It would also be useful to point the WG to any other documents from the ATSC community that relate to two-way IP services. Best wishes, Gorry Fairhurst. Allison, Art wrote: > It should be clear to anyone informed about MPEG2 TS multiplexers that > using a fixed PID introduces significant complexity for management of > a TS intended for broadcast to consumers. Re-multiplexers drop such > PIDs from the stream unless specifically programed for special > treatment of the fixed PID (the value of which has to be communicated > via 'other' means). IMHO, this makes the entire solution/approach > developed by this group generally useless for the transmission path > from a broadcaster to the consumer (which also goes through cable system remultiplexers). > > The address resolution and scoping of 'network' issues have been > resolved by the ATSC. The method of delivery of IP traffic that is documented is proven. > It is offered in products from multiple vendors and is being used > every day (and has been for a few years) in the real world for > delivery of IP traffic via over the air broadcast to consumers. > > Inventing another solution for the broadcast OTA link seems to be > wasted effort - especially a solution that is fundimentially as flawed > as to require a fixed PID. > > Perhaps now is the time to recognize that this IETF work is really > optimized for other MPEG-TS-using networks and its claimed scope > should be reduced to the other transmission links, where folks > determine that the 2.2% overhead the 'fixed PID' approach requires is > actually less than one obtains with DSMCC for the traffic they expect to flow. > > Art Allison > NAB S&T > p.s. If someone would like more information see A/92 and applicable > parts of A/90 at www.atsc.org. Also note, as it may not be obvious, > that the DSMCC-based technology in these standards is seperable from > the ATSC announcement technology and then is applicable to any TS. > > -----Original Message----- > From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk] > Sent: Tuesday, November 02, 2004 6:17 AM > To: ipdvb@erg.abdn.ac.uk > Subject: Re: security considerations wrt/ draft-ietf-ipdvb-arch-01.txt > > From owner-ipdvb@erg.abdn.ac.uk Tue Nov 9 20:50:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09422 for ; Tue, 9 Nov 2004 20:50:27 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRhdq-0004ac-2U for ipdvb-archive@ietf.org; Tue, 09 Nov 2004 20:51:23 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iAA1DvaH027514 for ; Wed, 10 Nov 2004 01:13:57 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iAA1Dv7j027513 for ipdvb-subscribed-users; Wed, 10 Nov 2004 01:13:57 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from [130.129.134.197] ([130.129.134.197]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iAA1CpP6027475 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Wed, 10 Nov 2004 01:13:09 GMT User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 09 Nov 2004 20:12:47 -0500 Subject: Re: ATSC From: Gorry Fairhurst To: Message-ID: In-Reply-To: <5A659834E1607E4EBD72FCE2FE5C9CF103B799E1@mail.NAB.ORG> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit On 8/11/04 3:07 pm, "Allison, Art" wrote: > Gorry > > The committee members may find ATSC A/96 - 'Interaction Channel Protocols' > of some interest with respect to the two-way standardization work; though it > may not be directly usable. See http://www.atsc.org/standards/A_96.pdf > > A small correction, the document is at: http://www.atsc.org/standards/a_96.pdf I'd recommend reading sections 6 & 7 which discuss networking - although the description is rather end-host centric, its clear this also anticipates routing/bridging to a LAN. Gorry From owner-ipdvb@erg.abdn.ac.uk Thu Nov 11 08:17:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07611 for ; Thu, 11 Nov 2004 08:17:01 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSEq6-0001eM-5M for ipdvb-archive@ietf.org; Thu, 11 Nov 2004 08:18:14 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iABCV41V011429 for ; Thu, 11 Nov 2004 12:31:05 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iABCV4W6011428 for ipdvb-subscribed-users; Thu, 11 Nov 2004 12:31:04 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@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.11/8.12.11) with ESMTP id iABCTaKU011361 for ; Thu, 11 Nov 2004 12:29:36 GMT Received: from esacom52.estec.esa.int (esacom52.estec.esa.int [131.176.7.7]) by esacom57-int.estec.esa.int (8.12.10/8.12.10/ESA-External-v3.2) with ESMTP id iABCTVaT003282 for ; Thu, 11 Nov 2004 13:29:31 +0100 (MET) Received: from estecmta1.estec.esa.int (estecmta1.estec.esa.int [131.176.1.131]) by esacom52.estec.esa.int (8.12.10/8.12.10/ESA-Internal-v3.2) with ESMTP id iABCTT2H002341 for ; Thu, 11 Nov 2004 13:29:30 +0100 (MET) Subject: Encapsulation issues for DVB-S2: work will start soon in DVB-GBS To: ipdvb@erg.abdn.ac.uk X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: Frank.Zeppenfeldt@esa.int Date: Thu, 11 Nov 2004 13:29:25 +0100 X-MIMETrack: Serialize by Router on estecmta1/estec/ESA(Release 5.0.11 |July 24, 2002) at 11/11/2004 01:29:30 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 0.3 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Dear list, You are probably aware of the DVB-S2 standard, for which commercial products are expected very soon. See http://www.dvb.org/documents/white-papers/wp06.DVB-S2.final.pdf for some background reading. In addition to the standard way of using MPE for encapsulation of IP or other protocols as used by these future DVB-S2 products, there is also a mode defined in the DVB-S2 standard called Generic Stream (GS) which many in the satellite industry consider the preferred method for efficient transport of data, bypassing all MPEG-2 and MPE issues. Unfortunately however, there is no adaptation layer yet defined for any protocol over DVB-S2/GS. It is worthwhile to consider that up to now only a relatively small set of requirements for such an adaption layer has been generated by the DVB-RCS group, which are mainly interested in interactive services. The DVB-S2 standard will however also be used in e.g.: - satellite ISP's for trunking using IPv4, IPv6, MPLS, UDLR in both DVB-S/SCPC and DVB-S2/terrestrial scenarios - SNG (Satellite New Gathering) scenarios contributing MPEG-4 over IPv4 - satellite access networks using PPPoE - VoIP satellite trunks links with header compression requirements - satellite networks that will require link layer security (ref. ULE security discussions on this list) We would like to inform you that it has just been made known that the GBS group of DVB will take the responsibilty to work on this adaptation layer. Taking into account that GBS orginally came up with MPE, we consider it important that as soon as possible proper requirements from the IP-over-satellite community are forwarded to this starting ad-hoc group, and that all previous work as captured in the various ipdvb drafts is considered and possibly re-used. If you are a DVB member you might consider to attend this first meeting which has been preliminary announced to be held in Munich, 15 and 16 December 2004 and come forward with your requirements. ESA will be very pleased to present any inputs or suggestions coming from this list during that meeting. Best regards, Frank Zeppenfeldt ESA Telecom http://telecom.esa.int/ipv6 From owner-ipdvb@erg.abdn.ac.uk Thu Nov 11 14:44:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16610 for ; Thu, 11 Nov 2004 14:44:25 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSKt4-0002WO-A6 for ipdvb-archive@ietf.org; Thu, 11 Nov 2004 14:45:42 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iABJETiJ021201 for ; Thu, 11 Nov 2004 19:14:29 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iABJESdW021200 for ipdvb-subscribed-users; Thu, 11 Nov 2004 19:14:28 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from [130.129.134.197] ([130.129.134.197]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iABJCw8U021133 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 11 Nov 2004 19:13:02 GMT User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 11 Nov 2004 14:12:52 -0500 Subject: Jabber server at IETF-61. From: Gorry Fairhurst To: "ipdvb@erg.abdn.ac.uk" Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit For those people that like to use Jabber, this WG has a jabber room allocated to it at the following server: ipdvb@ietf.xmpp.org If anyone intends to use jabber remotely to participate, then please let me know, and I'll do my best to ensure questions are relayed to the room (I'll also call for a jabber scribe!). IETF jabber lists are archived. Information about jabber tools for various platforms is at: http://www.xmpp.org/ietf-chat.html Best wishes, Gorry From owner-ipdvb@erg.abdn.ac.uk Thu Nov 11 14:47:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16903 for ; Thu, 11 Nov 2004 14:47:25 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSKvl-0002aS-RK for ipdvb-archive@ietf.org; Thu, 11 Nov 2004 14:48:42 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iABJCjfM021131 for ; Thu, 11 Nov 2004 19:12:45 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iABJCiQb021130 for ipdvb-subscribed-users; Thu, 11 Nov 2004 19:12:44 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from smtp106.mail.sc5.yahoo.com (smtp106.mail.sc5.yahoo.com [66.163.169.226]) by erg.abdn.ac.uk (8.12.11/8.12.11) with SMTP id iABJAels021054 for ; Thu, 11 Nov 2004 19:10:41 GMT Received: from unknown (HELO mdolan.tbt.com) (mikedolus@148.63.99.97 with login) by smtp106.mail.sc5.yahoo.com with SMTP; 11 Nov 2004 19:10:38 -0000 Message-Id: <6.1.2.0.2.20041111105129.02ff2488@pop.mail.yahoo.com> X-Sender: mikedolus@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 11 Nov 2004 11:10:27 -0800 To: ipdvb@erg.abdn.ac.uk From: Michael A Dolan Subject: Re: ATSC In-Reply-To: References: <5A659834E1607E4EBD72FCE2FE5C9CF103B799E1@mail.NAB.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 I observe the work of this group, and regrettably do not have the time to actively participate. I think this has all been said before, and my apologies if I am repeating it too much, but maybe a little repeat is OK? I think the key thing for the group to keep in mind as you review your architecture and scope is that there are systems in use today on ATSC and DVB MPEG-2 transports that, while simplistic, are not wrong for some applications. And, they are not likely to change, and are in fact growing. These systems followed ISO's recommendation (13818-6 amendment) on how to carry network packets. And, devices today that work with MPEG-2 are used to encoding and decoding all non-video, non-audio information (including network packets and other things) in MPEG-2 sections, not raw transport packets. Devices that handle the multiplexing stages of the transport encode and decode processes (which may be different devices) are used to operating with these headers without necessarily knowing what's in the payload. For multicast and other inherently large payload packet applications, the overhead of the section header is obviously not an issue, and service discovery is done by "other means" more compatible with overall service discovery on the transport. Many times, the IP stream is related to only one set of components in the multiplex, and service discovery is done at a layer higher than the IP stream itself to be sure one decodes the "right" IP stream. That is not to say that an efficient means is not also needed for the carriage of small packets (telnet sessions and general IP traffic), and design work needed to make an MPEG-2 transport a "real" link route, where that is its primary purpose. Also, be careful how you define the subnet. An MPEG-2 transport is a multiplex, and all components of the multiplex are never decoded concurrently, when used for television anyway. Thus, the subnet is something less than the full transport. A/92 treated this topic. Also note that A/96 is about the return channel operation using more traditional transports to connect from the decoder back into the Internet. Regards, Mike At 11/9/2004 05:12 PM, Gorry Fairhurst wrote: >On 8/11/04 3:07 pm, "Allison, Art" wrote: > > > Gorry > > > > > > The committee members may find ATSC A/96 - 'Interaction Channel Protocols' > > of some interest with respect to the two-way standardization work; > though it > > may not be directly usable. See http://www.atsc.org/standards/A_96.pdf > > > > >A small correction, the document is at: > >http://www.atsc.org/standards/a_96.pdf > >I'd recommend reading sections 6 & 7 which discuss networking - although >the description is rather end-host centric, its clear this also anticipates >routing/bridging to a LAN. > >Gorry From owner-ipdvb@erg.abdn.ac.uk Tue Nov 16 09:42:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03309 for ; Tue, 16 Nov 2004 09:42:23 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU4ZW-0006ur-59 for ipdvb-archive@ietf.org; Tue, 16 Nov 2004 09:44:42 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iAGE5CCR000260 for ; Tue, 16 Nov 2004 14:05:12 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iAGE5BBL000259 for ipdvb-subscribed-users; Tue, 16 Nov 2004 14:05:11 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iAGE40Mp000201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 16 Nov 2004 14:04:03 GMT Message-ID: <419A08D1.4070809@erg.abdn.ac.uk> Date: Tue, 16 Nov 2004 14:04:01 +0000 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: Slides from IETF-61 at Washington Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit I enclose a link to copies of the slides presented at the last ipdvb meeting in PDF format. These slides may be down-loaded from: http://www.erg.abdn.ac.uk/ip-dvb/meetings/11-11-02-IETF-61-Washington/ At the end of the meeting, an additional presentation was also made by Joerg Ott (Co-Chair of MMUSIC in the Transport Area). this was a cross-area co-ordination activity on protocols that will support DVB audiovisual services over IP. If copies of this become available, this will also be uploaded to the same directory. Copies of the minutes will be sent later to this list (and then to the IETF proceedings). Best wishes, Gorry Fairhurst (ipdvb WG Chair) From owner-ipdvb@erg.abdn.ac.uk Fri Nov 19 12:08:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21926 for ; Fri, 19 Nov 2004 12:08:57 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVCIf-00019I-RI for ipdvb-archive@ietf.org; Fri, 19 Nov 2004 12:11:58 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iAJGYfud015944 for ; Fri, 19 Nov 2004 16:34:41 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iAJGYegM015943 for ipdvb-subscribed-users; Fri, 19 Nov 2004 16:34:40 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iAJGXWpd015904 for ; Fri, 19 Nov 2004 16:33:33 GMT Received: by rproxy.gmail.com with SMTP id g11so155689rne for ; Fri, 19 Nov 2004 08:33:30 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=FNvFRy4HKW/6+11zuOVtHJ/1c1VGxYR1CfQwAOJCeUkyBXRTvl0/SrTKTrnSt5+bAcQswzqcKhELV3T6yBcj9fNkO+/ls0f+DVg379pj8eTXdl7ve7rKNiuNjCFLuR9JhoEIiBTOYm6whTy7xKU19rS6tpyZZgcoMYtU2DTJxFA= Received: by 10.39.1.5 with SMTP id d5mr398662rni; Fri, 19 Nov 2004 08:31:03 -0800 (PST) Received: by 10.38.81.3 with HTTP; Fri, 19 Nov 2004 08:31:03 -0800 (PST) Message-ID: Date: Fri, 19 Nov 2004 16:31:03 +0000 From: James Courtier-Dutton To: ipdvb@erg.abdn.ac.uk Subject: PPP over MPEG-TS over Satellite Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Has there been any discussions on the use of PPP over Satellite? E.g. a PPP SNDU Or would the preferred method be PPP over Ethernet over Satellite? This would allow for the Satellite provider to wholesale Satellite users to ISPs. The ISPs could then use PPP to control access, in much the same way as used on ADSL today. James From owner-ipdvb@erg.abdn.ac.uk Tue Nov 23 04:59:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22011 for ; Tue, 23 Nov 2004 04:59:13 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWXVl-0006IM-6E for ipdvb-archive@ietf.org; Tue, 23 Nov 2004 05:03:01 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iAN9I5Mr008153 for ; Tue, 23 Nov 2004 09:18:05 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iAN9I5P5008152 for ipdvb-subscribed-users; Tue, 23 Nov 2004 09:18:05 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iAN9GmhS008098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 23 Nov 2004 09:16:49 GMT Message-ID: <41A30001.1010907@erg.abdn.ac.uk> Date: Tue, 23 Nov 2004 09:16:49 +0000 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: Final issues to be resolved priot to ULE rev -03: IANA Procedures Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Bernhard, ipdvb WG, There were two issues that were addressed at the IETF-61 meeting - This is the second, the IANA considerations section. Please give this prompt attention, it would be good to receive email supporting this text or requesting clarification. When both issues are complete the authors will be ready to submit the final edits to make rev -03 of ULE (which will be put to WGLC). Gorry (as ULE Co-Author) --- 2) IANA Considerations To make things consistent throughout I replaced *all* mentions of extensions to say "Extension Header" (there were lots of variants :-(). The IANA also provided helpful advice on registry format, and suggested the following format for the registry 0 - which seemed good to me, have you thoughts/opinions on this? Is this OK with you? --- IANA Guidelines The following contains the IANA guidelines for management of the ULE Next-Header registry. This registry allocates values decimal 0-512 (0x0000-0x01FF, hexadecimal). It MUST NOT allocate values greater than 0x01FF (decimal). It subdivides the Next-Header registry in the following way: 1) 0-255 (decimal) IANA assigned values indicating Mandatory Extension Headers (or link-dependent type fields) for ULE, requiring expert review leading to prior issue of an IETF RFC. This specification must define the value, and the name associated with the Extension Header. It must also define the need for the extension and the intended use. The size of the Extension Header must also be specified. Assignments made in this document: Type Name Reference 0: Test-SNDU Section 4.7.4. 1: Bridged-SNDU Section 4.7.5. 2) 256-511 (decimal) IANA assigned values indicating Optional Extension Headers for ULE, requiring expert review leading to prior issue of an IETF RFC. This specification must define the value, and the name associated with the Extension Header. The entry must specify range of allowable H-LEN values that are permitted (in the range 1-5). It must also define the need for the extension and the intended use. Assignments made in this document: Type Name H-LEN Reference 256: Extension-Padding 1-5 Section 5. From owner-ipdvb@erg.abdn.ac.uk Tue Nov 23 05:00:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22203 for ; Tue, 23 Nov 2004 05:00:45 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWXXF-0006JS-5T for ipdvb-archive@ietf.org; Tue, 23 Nov 2004 05:04:33 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iAN9JRo4008205 for ; Tue, 23 Nov 2004 09:19:27 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iAN9JRj7008204 for ipdvb-subscribed-users; Tue, 23 Nov 2004 09:19:27 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iAN9H0vu008107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 23 Nov 2004 09:17:02 GMT Message-ID: <41A3000D.3040502@erg.abdn.ac.uk> Date: Tue, 23 Nov 2004 09:17:01 +0000 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: Final issues to be resolved priot to ULE rev -03: CRC mismatch Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: 7bit Bernhard, ipdvb WG, There were two issues that were addressed at the IETF-61 meeting - one was the bit of text we had trouble agreeing on, the second was the IANA considerations section. I shall post both separately (the first isssue and proposed new text is provided below, together with the rationale). Please give this prompt attention, it would be good to receive email supporting this text or requesting clarification. When these are complete the authors will be ready to submit the final edits to make rev -03 of ULE. Gorry (as ULE Co-Author) --- CRC MISMATCH ISSUE - Section 7.2 There was discussion at the IETF-61 about whether the Receiver SHOULD/MUST/MAY discard the remaining TS Packet payload (if any) following a CRC mismatch and return to the Idle State. This is a common point of dispute in IETF WGs - the usual philosophy being "liberal in what you accept and conservative in what you send". Whatever is decided by this WG, it is best that this is documented (as agreed in the IETF-61 meeting). Please bear in mind that, IETF protocols should not mandate implementation methods. To summarise the discussion: MUST discard and enter idle state - seems very strong when the impact is not to forward bad data, but to result in unnecessary processing - the consensus seemed to be that any processing/design issues could possibly be overcome in the future, and we shouldn't constrain the spec because of this. SHOULD discard and enter idle state - is my new suggestion, i.e. Implementors are advised to take this approach, unless they understand the implications and decide there is a good reason to do otherwise. MAY discard and enter idle state - was also proposed, suggesting that it is entirely valid for an implementor to discard the reassembly buffer at this stage (and by implication this is a good idea, unless the implementor is wiser). I propose some text below: ------------ Proposed text for ULE rev 03 ------------ 7.2 Processing of a Received SNDU When in the Reassembly State, the Receiver reads a 2 byte SNDU Length Field from the TS Packet payload. If the value is less than or equal to 4, or equal to 0xFFFF, the Receiver discards the Current SNDU and the remaining TS Packet payload and returns to the Idle State. Receipt of an invalid Length Field is an error event and SHOULD be recorded as an SNDU length error. If the Length of the Current SNDU is greater than 4, the Receiver accepts bytes from the TS Packet payload to the Current SNDU buffer until either Length bytes in total are received, or the end of the TS Packet is reached. When Current SNDU length equals the value of the Length Field, the Receiver MUST calculate and verify the CRC value (section 4.6). SNDUs that contain an invalid CRC value MUST be discarded. Mismatch of the CRC is an error event and SHOULD be recorded as a CRC error. The under-lying physical-layer processing (e.g. forward error correction coding) often results in patterns of errors, rather than since bit errors, so the Receiver needs to be robust to arbitrary patterns of corruption to the TS Packet and payload, including potential corruption of the PUSI, PP, and SNDU Length fields (see also 7.2.1). Therefore, a Receiver SHOULD discard the remaining TS Packet payload (if any) following a CRC mismatch and return to the Idle State. ... 7.2.1 Reassembly Payload Pointer Checking ... --------------- From owner-ipdvb@erg.abdn.ac.uk Tue Nov 23 09:37:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14524 for ; Tue, 23 Nov 2004 09:37:34 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWbrA-0000k7-E8 for ipdvb-archive@ietf.org; Tue, 23 Nov 2004 09:41:25 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iANDUYLb016024 for ; Tue, 23 Nov 2004 13:30:34 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iANDUXxx016023 for ipdvb-subscribed-users; Tue, 23 Nov 2004 13:30:33 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from loewe.cosy.sbg.ac.at (loewe.cosy.sbg.ac.at [141.201.2.12]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iANDToNL015992 for ; Tue, 23 Nov 2004 13:29:50 GMT Received: from [141.201.2.21] (milbe.cosy.sbg.ac.at [141.201.2.21]) by loewe.cosy.sbg.ac.at (8.8.8/8.8.7) with ESMTP id OAA16179 for ; Tue, 23 Nov 2004 14:29:50 +0100 (MET) Message-ID: <41A33B30.6010804@cosy.sbg.ac.at> Date: Tue, 23 Nov 2004 14:29:20 +0100 From: Bernhard Collini-Nocker User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: Re: Final issues to be resolved priot to ULE rev -03: CRC mismatch References: <41A3000D.3040502@erg.abdn.ac.uk> In-Reply-To: <41A3000D.3040502@erg.abdn.ac.uk> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: 7bit Dear Gorry, I support the text proposing "SHOULD". Regards, Bernhard Gorry Fairhurst wrote: > > Bernhard, ipdvb WG, > > There were two issues that were addressed at the IETF-61 meeting - one was > the bit of text we had trouble agreeing on, the second was the IANA > considerations section. > > I shall post both separately (the first isssue and proposed new text is > provided below, together with the rationale). > > Please give this prompt attention, it would be good to receive email > supporting this text or requesting clarification. When these are > complete the authors will be ready to submit the final edits to make rev > -03 of ULE. > > Gorry > (as ULE Co-Author) > > --- > > CRC MISMATCH ISSUE - Section 7.2 > > There was discussion at the IETF-61 about whether the Receiver > SHOULD/MUST/MAY > discard the remaining TS Packet payload (if any) following a CRC mismatch > and return to the Idle State. > > This is a common point of dispute in IETF WGs - the usual philosophy being > "liberal in what you accept and conservative in what you send". Whatever > is decided by this WG, it is best that this is documented (as agreed in > the IETF-61 meeting). Please bear in mind that, IETF protocols should > not mandate implementation methods. > > To summarise the discussion: > > MUST discard and enter idle state - seems very strong when the impact is > not > to forward bad data, but to result in unnecessary processing - the > consensus > seemed to be that any processing/design issues could possibly be > overcome in > the future, and we shouldn't constrain the spec because of this. > > SHOULD discard and enter idle state - is my new suggestion, i.e. > Implementors are advised to take this approach, unless they understand the > implications and decide there is a good reason to do otherwise. > > MAY discard and enter idle state - was also proposed, suggesting that it is > entirely valid for an implementor to discard the reassembly buffer at this > stage (and by implication this is a good idea, unless the implementor is > wiser). > > > I propose some text below: > > > ------------ Proposed text for ULE rev 03 ------------ > > 7.2 Processing of a Received SNDU > > When in the Reassembly State, the Receiver reads a 2 byte SNDU Length Field > from the TS Packet payload. If the value is less than or equal to 4, or > equal to 0xFFFF, the Receiver discards the Current SNDU and the > remaining TS > Packet payload and returns to the Idle State. Receipt of an invalid Length > Field is an error event and SHOULD be recorded as an SNDU length error. > > If the Length of the Current SNDU is greater than 4, the Receiver accepts > bytes from the TS Packet payload to the Current SNDU buffer until either > Length bytes in total are received, or the end of the TS Packet is reached. > When Current SNDU length equals the value of the Length Field, the Receiver > MUST calculate and verify the CRC value (section 4.6). SNDUs that > contain an > invalid CRC value MUST be discarded. Mismatch of the CRC is an error event > and SHOULD be recorded as a CRC error. The under-lying physical-layer > processing (e.g. forward error correction coding) often results in patterns > of errors, rather than since bit errors, so the Receiver needs to be robust > to arbitrary patterns of corruption to the TS Packet and payload, including > potential corruption of the PUSI, PP, and SNDU Length fields (see also > 7.2.1). Therefore, a Receiver SHOULD discard the remaining TS Packet > payload > (if any) following a CRC mismatch and return to the Idle State. > > ... > > 7.2.1 Reassembly Payload Pointer Checking > > ... > > > --------------- > > > > > > > From owner-ipdvb@erg.abdn.ac.uk Tue Nov 23 09:51:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16377 for ; Tue, 23 Nov 2004 09:51:17 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWc4S-0002pN-8C for ipdvb-archive@ietf.org; Tue, 23 Nov 2004 09:55:08 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iANDZnxo016222 for ; Tue, 23 Nov 2004 13:35:49 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iANDZmBB016221 for ipdvb-subscribed-users; Tue, 23 Nov 2004 13:35:49 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from loewe.cosy.sbg.ac.at (loewe.cosy.sbg.ac.at [141.201.2.12]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iANDXTFB016133 for ; Tue, 23 Nov 2004 13:33:29 GMT Received: from [141.201.2.21] (milbe.cosy.sbg.ac.at [141.201.2.21]) by loewe.cosy.sbg.ac.at (8.8.8/8.8.7) with ESMTP id OAA16843 for ; Tue, 23 Nov 2004 14:33:29 +0100 (MET) Message-ID: <41A33C0B.5080203@cosy.sbg.ac.at> Date: Tue, 23 Nov 2004 14:32:59 +0100 From: Bernhard Collini-Nocker User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: Re: Final issues to be resolved priot to ULE rev -03: IANA Procedures References: <41A30001.1010907@erg.abdn.ac.uk> In-Reply-To: <41A30001.1010907@erg.abdn.ac.uk> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Dear Gorry, thanks for the revised text, which is supported by me. Regards, Bernhard Gorry Fairhurst wrote: > > > Bernhard, ipdvb WG, > > There were two issues that were addressed at the IETF-61 meeting - This > is the second, the IANA considerations section. > > Please give this prompt attention, it would be good to receive email > supporting this text or requesting clarification. When both issues are > complete the authors will be ready to submit the final edits to make rev > -03 of ULE (which will be put to WGLC). > > Gorry > (as ULE Co-Author) > > --- > > 2) IANA Considerations > > To make things consistent throughout I replaced *all* mentions of > extensions > to say "Extension Header" (there were lots of variants :-(). The IANA also > provided helpful advice on registry format, and suggested the following > format for the registry 0 - which seemed good to me, have you > thoughts/opinions on this? Is this OK with you? > > --- > > IANA Guidelines > > The following contains the IANA guidelines for management of the ULE > Next-Header registry. This registry allocates values decimal 0-512 > (0x0000-0x01FF, hexadecimal). It MUST NOT allocate values greater than > 0x01FF (decimal). > > It subdivides the Next-Header registry in the following way: > > 1) 0-255 (decimal) IANA assigned values indicating Mandatory Extension > Headers (or link-dependent type fields) for ULE, requiring expert review > leading to prior issue of an IETF RFC. This specification must define the > value, and the name associated with the Extension Header. It must also > define the need for the extension and the intended use. The size of the > Extension Header must also be specified. > > Assignments made in this document: > > Type Name Reference > 0: Test-SNDU Section 4.7.4. > 1: Bridged-SNDU Section 4.7.5. > > > 2) 256-511 (decimal) IANA assigned values indicating Optional Extension > Headers for ULE, requiring expert review leading to prior issue of an IETF > RFC. This specification must define the value, and the name associated with > the Extension Header. The entry must specify range of allowable H-LEN > values > that are permitted (in the range 1-5). It must also define the need for the > extension and the intended use. > > Assignments made in this document: > > Type Name H-LEN Reference > 256: Extension-Padding 1-5 Section 5. > From owner-ipdvb@erg.abdn.ac.uk Tue Nov 23 12:45:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02859 for ; Tue, 23 Nov 2004 12:45:33 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWemy-0000x8-43 for ipdvb-archive@ietf.org; Tue, 23 Nov 2004 12:49:27 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iANGO2rx021018 for ; Tue, 23 Nov 2004 16:24:02 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iANGO12v021017 for ipdvb-subscribed-users; Tue, 23 Nov 2004 16:24:02 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from telecom-bg.com (telecom-bg.com [212.56.10.2]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iANGMdjK020966 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 23 Nov 2004 16:22:40 GMT Received: from localhost ([127.0.0.1]) by telecom-bg.com with esmtp (Exim 4.34) id 1CX1B1-0003H5-1o for ip-dvb@erg.abdn.ac.uk; Wed, 24 Nov 2004 19:43:35 +0200 Received: from telecom-bg.com ([127.0.0.1]) by localhost (mail [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10881-07 for ; Wed, 24 Nov 2004 19:43:34 +0200 (EET) Received: from [212.56.10.34] (helo=[212.56.10.34]) by telecom-bg.com with esmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1CX1B0-0003H0-6g for ip-dvb@erg.abdn.ac.uk; Wed, 24 Nov 2004 19:43:34 +0200 From: Stefan Baryakov Organization: Telecom Group Ltd To: ip-dvb@erg.abdn.ac.uk Subject: SkyStream SMR-24 info Date: Tue, 23 Nov 2004 18:22:13 +0200 User-Agent: KMail/1.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200411231822.13921.stefan@telecom-bg.com> X-Virus-Scanned: by amavisd-new at telecom-bg.com X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Hi all, Does someone here have a user manuals for SkyStream SMR-24 ? Any help will be highly appreciated. I apologize if this is off topic. Thanks ! Stefan B. From owner-ipdvb@erg.abdn.ac.uk Fri Nov 26 06:17:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28377 for ; Fri, 26 Nov 2004 06:17:50 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXeB6-00062N-Qa for ipdvb-archive@ietf.org; Fri, 26 Nov 2004 06:22:17 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iAQAffp4021716 for ; Fri, 26 Nov 2004 10:41:41 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iAQAfeKW021715 for ipdvb-subscribed-users; Fri, 26 Nov 2004 10:41:41 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iAQAcpte021621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 26 Nov 2004 10:38:52 GMT Message-ID: <41A707BC.2010104@erg.abdn.ac.uk> Date: Fri, 26 Nov 2004 10:38:52 +0000 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: Re: PPP over MPEG-TS over Satellite References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Can you please say a little more about your intended scenario, and how you were envisaging using PPP? Gorry James Courtier-Dutton wrote: > Has there been any discussions on the use of PPP over Satellite? > > E.g. a PPP SNDU > > Or would the preferred method be PPP over Ethernet over Satellite? > > This would allow for the Satellite provider to wholesale Satellite > users to ISPs. The ISPs could then use PPP to control access, in much > the same way as used on ADSL today. > > James > > From owner-ipdvb@erg.abdn.ac.uk Fri Nov 26 13:16:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04364 for ; Fri, 26 Nov 2004 13:16:07 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXkhy-00088P-AO for ipdvb-archive@ietf.org; Fri, 26 Nov 2004 13:20:38 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iAQHDFme029214 for ; Fri, 26 Nov 2004 17:13:15 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iAQHDFSX029213 for ipdvb-subscribed-users; Fri, 26 Nov 2004 17:13:15 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.205]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iAQHCj7g029193 for ; Fri, 26 Nov 2004 17:12:45 GMT Received: by rproxy.gmail.com with SMTP id g11so498174rne for ; Fri, 26 Nov 2004 09:12:45 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=W7bhtdtGIHDtczl9A725DgcQq656yQ0iunOP+SVF1cHl9ThliYpqNck3jTSW1ZWznpTn3rPg8sWRUfarhzlrh6Q/ij4uIDBTe2x2zsUBpUjVcJt0VD9Mbn5mM/+nvnMpkxDScBCpu0e7UGdGqBlaGVgveM5tn83coxp2NxfR+8k= Received: by 10.38.73.61 with SMTP id v61mr406326rna; Fri, 26 Nov 2004 09:12:45 -0800 (PST) Received: by 10.38.81.2 with HTTP; Fri, 26 Nov 2004 09:12:45 -0800 (PST) Message-ID: Date: Fri, 26 Nov 2004 17:12:45 +0000 From: James Courtier-Dutton To: ipdvb@erg.abdn.ac.uk Subject: Re: PPP over MPEG-TS over Satellite In-Reply-To: <41A707BC.2010104@erg.abdn.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <41A707BC.2010104@erg.abdn.ac.uk> X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit On Fri, 26 Nov 2004 10:38:52 +0000, Gorry Fairhurst wrote: > Can you please say a little more about your intended scenario, and how you > were envisaging using PPP? > > Gorry > > > > James Courtier-Dutton wrote: > > > Has there been any discussions on the use of PPP over Satellite? > > > > E.g. a PPP SNDU > > > > Or would the preferred method be PPP over Ethernet over Satellite? > > > > This would allow for the Satellite provider to wholesale Satellite > > users to ISPs. The ISPs could then use PPP to control access, in much > > the same way as used on ADSL today. > > > > James > > User's Host PC -> Ethernet -> Satellite access terminal or mobile terminal -> Satellite hub -> L2TP link to ISP. The Mobile terminal would somehow be assigned a multiplex ID unique to this Mobile terminal. The Mobile terminal would then add the multiplex ID to the beginning of the PPP frame and send it over the satellite. The Satellite hub would then re-multiplex the PPP from the satellite into L2TP sessions and forward the PPP to the ISP. The ISP would then use PPP to assign IP addresses to PPP clients using standard PPP negotiation. The advantage of this would be that the IP addresses assigned would then be in the ISP domain, and the ISP could treat the MT in exactly the same way it treats dialup modem or ADSL users, by assigning them IP addresses using PPP. A similar comparison would be using PPPoE on cable TV networks. James From owner-ipdvb@erg.abdn.ac.uk Tue Nov 30 00:04:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21574 for ; Tue, 30 Nov 2004 00:04:16 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ0GZ-00016m-78 for ipdvb-archive@ietf.org; Tue, 30 Nov 2004 00:09:31 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iAU4Q4O3009298 for ; Tue, 30 Nov 2004 04:26:04 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iAU4Q3cY009297 for ipdvb-subscribed-users; Tue, 30 Nov 2004 04:26:04 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from web42209.mail.yahoo.com (web42209.mail.yahoo.com [66.218.93.220]) by erg.abdn.ac.uk (8.12.11/8.12.11) with SMTP id iAU4OoK0009252 for ; Tue, 30 Nov 2004 04:24:51 GMT Received: (qmail 3762 invoked by uid 60001); 30 Nov 2004 04:24:44 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=4jfiM4tZnznF2HkuNiJb6xNzhhd0r4BJqkGCq3ljqN+M5IkroGVPYm4+7ewfr6xEKQMNyS/fVn8sPkJivCX5g/1AoyDED2C/v84bEdSprjEGyWU8Ln7DzrTGrcA3eoZLgOGTvvBhdvWR+Cv17R+kWjyoCjGLh9JoYsUX1IxK1ls= ; Message-ID: <20041130042444.3760.qmail@web42209.mail.yahoo.com> Received: from [202.88.190.30] by web42209.mail.yahoo.com via HTTP; Mon, 29 Nov 2004 20:24:44 PST Date: Mon, 29 Nov 2004 20:24:44 -0800 (PST) From: Siva Veerepalli Subject: DVB-H MPE/timeslice question To: ipdvb@erg.abdn.ac.uk MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 I have been reading the DVB-H standard, and have a question regarding MPE bursts and time slicing. The standard says each ES i.e., MPE stream is transmitted as a burst within a time slice. It also says that there can be more than one elementary stream within a single time slice. I am assuming this means, there can be other ES's such as PSI/SI in addition to the MPE stream of interest in the time slot. However, I have not found anything explicitly stated that indicates that there can be multiple MPE streams within a single time slice, i.e., two bursts of elementary streams within the same time slice. Can some one please clarify this? If this is possible, it would have an impact on the implementation of the receiver since n*x memory (where n is the number of MPE-FEC bursts and x is a max of 2Mb)would be required in the receiver. I guess a more basic question is, would a receiver need more than one MPE burst to present a program of interest? thanks, Siva __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail From owner-ipdvb@erg.abdn.ac.uk Tue Nov 30 04:28:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25459 for ; Tue, 30 Nov 2004 04:28:17 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ4O5-0006Fu-JM for ipdvb-archive@ietf.org; Tue, 30 Nov 2004 04:33:35 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iAU93oTi014640 for ; Tue, 30 Nov 2004 09:03:50 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iAU93o4W014639 for ipdvb-subscribed-users; Tue, 30 Nov 2004 09:03:50 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iAU93Kq2014622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 30 Nov 2004 09:03:21 GMT Message-ID: <41AC3751.3030405@erg.abdn.ac.uk> Date: Tue, 30 Nov 2004 09:03:13 +0000 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: Re: PPP over MPEG-TS over Satellite References: <41A707BC.2010104@erg.abdn.ac.uk> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit The ULE framing is generic, and you could use it to support a PPP frame. The following ULE link addressing schemes are allowed: (i) No MAC/Link address (ii) MAC/Link dst address only. (iii) MAC src and dst addresses (iv) Link address + MAC src and dst addresses Which would be most appropriate? The EtherType for PPPoE (0x880B) is certainly supported by ULE, since it falls in the range of IANA-assigned EtherTypes. I'm not yet aware of anyone who has used ULE in this way. If there are additional issues or some experience, perhaps someone on the list could add a reply to this? Best wishes, Gorry James Courtier-Dutton wrote: > On Fri, 26 Nov 2004 10:38:52 +0000, Gorry Fairhurst > wrote: > >>Can you please say a little more about your intended scenario, and how you >>were envisaging using PPP? >> >>Gorry >> >> >> >>James Courtier-Dutton wrote: >> >> >>>Has there been any discussions on the use of PPP over Satellite? >>> >>>E.g. a PPP SNDU >>> >>>Or would the preferred method be PPP over Ethernet over Satellite? >>> >>>This would allow for the Satellite provider to wholesale Satellite >>>users to ISPs. The ISPs could then use PPP to control access, in much >>>the same way as used on ADSL today. >>> >>>James >>> > > > User's Host PC -> Ethernet -> Satellite access terminal or mobile > terminal -> Satellite hub -> L2TP link to ISP. > > The Mobile terminal would somehow be assigned a multiplex ID unique to > this Mobile terminal. > The Mobile terminal would then add the multiplex ID to the beginning > of the PPP frame and send it over the satellite. The Satellite hub > would then re-multiplex the PPP from the satellite into L2TP sessions > and forward the PPP to the ISP. > The ISP would then use PPP to assign IP addresses to PPP clients using > standard PPP negotiation. > The advantage of this would be that the IP addresses assigned would > then be in the ISP domain, and the ISP could treat the MT in exactly > the same way it treats dialup modem or ADSL users, by assigning them > IP addresses using PPP. > A similar comparison would be using PPPoE on cable TV networks. > > James > > From owner-ipdvb@erg.abdn.ac.uk Tue Nov 30 04:33:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25795 for ; Tue, 30 Nov 2004 04:33:22 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ4T0-0006L8-P9 for ipdvb-archive@ietf.org; Tue, 30 Nov 2004 04:38:40 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iAU8hD0V014216 for ; Tue, 30 Nov 2004 08:43:13 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iAU8hD4d014215 for ipdvb-subscribed-users; Tue, 30 Nov 2004 08:43:13 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from natsmtp00.rzone.de (natsmtp00.rzone.de [81.169.145.165]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iAU8gV2R014187 for ; Tue, 30 Nov 2004 08:42:31 GMT Received: from news (hmln-d9b8ef43.pool.mediaWays.net [217.184.239.67]) by post.webmailer.de (8.13.1/8.13.1) with ESMTP id iAU8gTLD002694; Tue, 30 Nov 2004 09:42:30 +0100 (MET) Message-ID: <003301c4d6b8$066315e0$43efb8d9@dpiag.de> From: "Karsten Siebert @ dpi AG" To: Cc: References: <20041130042444.3760.qmail@web42209.mail.yahoo.com> Subject: Re: DVB-H MPE/timeslice question Date: Tue, 30 Nov 2004 09:38:51 +0100 Organization: data planet international AG MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by erg.abdn.ac.uk id iAU8hD0V014216 X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable Pls. see below: Rgds, Karsten -----Urspr=FCngliche Nachricht----- Von: "Siva Veerepalli" An: Gesendet: Dienstag, 30. November 2004 05:24 Betreff: DVB-H MPE/timeslice question > I have been reading the DVB-H standard, and have a > question regarding MPE bursts and time slicing. The > standard says each ES i.e., MPE stream is transmitted > as a burst within a time slice. It also says that > there can be more than one elementary stream within a > single time slice. This is correct. > I am assuming this means, there can be other ES's such > as PSI/SI in addition to the MPE stream of interest in > the time slot. PSI/SI do not run in slices, they are send continuousely. However, I have not found anything > explicitly stated that indicates that there can be > multiple MPE streams within a single time slice, i.e., > two bursts of elementary streams within the same time > slice. In general one burst refers to one time slice, but you can pass more than one IP stream in one burst (buffer both streams in the same burst buffer = and send this burst in one time slice. To differenciate the MACs, you still h= ave bytes 5 and 6 (other are used for real time data and buffer address location). With our IPE this can be even IPv4 and IPv6 mixed in one burst / time sli= ce. > > Can some one please clarify this? If this is possible, > it would have an impact on the implementation of the > receiver since n*x memory (where n is the number of > MPE-FEC bursts and x is a max of 2Mb)would be required > in the receiver. > n * 2 mb would be required, if you want to receive more than one independ= ent burst. Have a look into the DVB-H implementation guidelines. > I guess a more basic question is, would a receiver > need more than one MPE burst to present a program of > interest? No. In general programs will not be splitted. > > thanks, > Siva > > > > __________________________________ > Do you Yahoo!? > Read only the mail you want - Yahoo! Mail SpamGuard. > http://promotions.yahoo.com/new_mail From owner-ipdvb@erg.abdn.ac.uk Tue Nov 30 16:49:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16665 for ; Tue, 30 Nov 2004 16:49:29 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZFxS-00033h-4O for ipdvb-archive@ietf.org; Tue, 30 Nov 2004 16:54:53 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iAULAbMa004538 for ; Tue, 30 Nov 2004 21:10:37 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iAULAb3o004536 for ipdvb-subscribed-users; Tue, 30 Nov 2004 21:10:37 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iAUL83mc004436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 30 Nov 2004 21:08:05 GMT Message-ID: <41ACE135.1070105@erg.abdn.ac.uk> Date: Tue, 30 Nov 2004 21:08:05 +0000 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: I-D ACTION: draft-ietf-ipdvb-ule-03.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over DVB Working Group of the IETF. Title : Ultra Lightweight Encapsulation (ULE) for transmission of IP datagrams over MPEG-2/DVB networks Author(s) : G. Fairhurst, et al. Filename : draft-ietf-ipdvb-ule-03.txt Pages : 45 Date : 2004-11-30 The MPEG-2 TS has been widely accepted not only for providing digital TV services, but also as a subnetwork technology for building IP networks. This document describes an Ultra Lightweight Encapsulation (ULE) mechanism for the transport of IPv4 and IPv6 Datagrams and other network protocol packets directly over ISO MPEG- 2 Transport Streams (TS) as TS Private Data. ULE supports an extension format that allows it to carry both optional (with an explicit extension length) and mandatory (with an implicit extension length) header information to assist in network/Receiver processing of a SNDU. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipdvb-ule-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipdvb-ule-03". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipdvb-ule-03". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ From owner-ipdvb@erg.abdn.ac.uk Tue Nov 30 17:26:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22793 for ; Tue, 30 Nov 2004 17:26:02 -0500 (EST) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZGWs-00054u-Pl for ipdvb-archive@ietf.org; Tue, 30 Nov 2004 17:31:28 -0500 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iAULmFQT005805 for ; Tue, 30 Nov 2004 21:48:15 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id iAULmEOs005803 for ipdvb-subscribed-users; Tue, 30 Nov 2004 21:48:15 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id iAULkwYT005753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 30 Nov 2004 21:46:59 GMT Message-ID: <41ACEA54.6020507@erg.abdn.ac.uk> Date: Tue, 30 Nov 2004 21:47:00 +0000 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: WG Last-Call (WGLC) for comments: draft-ietf-ipdvb-ule-03.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit This note starts the WG two week Last-Call for comments for the WG document named below: draft-ietf-ipdvb-ule-03.txt The Last-Call will end on 15/12/2004. Members of the IETF ipdvb WG are asked to read the above draft and send any issues, comments, or corrections to this mailing list. The WGLC procedure is the last chance for this working group to modify/correct this document. Please do forward any comments to the list. Best wishes, Gorry Fairhurst (ipdvb WG Chair)