From owner-ipdvb@erg.abdn.ac.uk Mon Aug 01 08:19:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzZGw-0006wE-W5 for ipdvb-archive@megatron.ietf.org; Mon, 01 Aug 2005 08:19:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05012 for ; Mon, 1 Aug 2005 08:19:55 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzZnC-0006FH-3O for ipdvb-archive@ietf.org; Mon, 01 Aug 2005 08:53:20 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j71C8ACS000704 for ; Mon, 1 Aug 2005 13:08:10 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j71C8Apj000703 for ipdvb-subscribed-users; Mon, 1 Aug 2005 13:08:10 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from [139.133.204.42] (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j71C82XX000684 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Mon, 1 Aug 2005 13:08:03 +0100 (BST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Mon, 01 Aug 2005 14:09:48 +0200 Subject: Agenda for meeting on Wednesaday From: Gorry Fairhurst To: CC: Margaret Wasserman 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-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Here is the final Agenda for the ipdvb WG meeting (note the Agenda at the IETF meeting web site reflects the original draft agenda, rather than the one that was sent to the list/agenda email exploders). Best wishes, Gorry (ipdvb WG Chair) gorry@erg.abdn.ac.uk ----- IP over Digital Video Broadcast (ipdvb) WG 10:30-12:30, August 3, 2005 Internet Area 1. Agenda Bashing (10 minutes) - Chair * Agenda changes * Election of Scribe for Proceedings * Jabber Scribe 2. Document Status (5 minutes) - Chair * Documents in Last Call - None. * Documents in IESG Review: draft-ietf-ipdvb-ule-06 (Proposed Standard) * Documents in RFC Editor Queue: draft-ietf-ipdvb-arch-04 (Informational) * Published RFCs - None. 3. Uni-directional Lighweight Encapsulation (10 minutes) - B C-N http://www.ietf.org/internet-drafts/draft-ietf-ipdvb-ule-06.txt * Actions arising from * Assignment of code-points for SMPTE/DVB/ATSC 4. Address Resolution (15 minutes) - M-J Montpetit/G Fairhurst http://www.ietf.org/internet-drafts/draft-ietf-ipdvb-ar-00.txt * L2 Resolution * L3 Resolution: ND, UDLR, etc. * Contributions required 5. IP Address Configuration for ipdvb (10 minutes) - M Stiemerling http://www.ietf.org/internet-drafts/draft-stiemerling-ipdvb-config-01.txt * Requirements and scenarios * Future directions for this draft 6. ULE Security Extension (20 minutes) - Haitham Cruikshank http://www.ietf.org/internet-drafts/draft-cruickshank-ipdvb-sec-00.txt * Rationale * Security Header Extension proposal * Appropriateness of the technique 7. IP Encapsulation for DVB-S.2 (20 minutes) - Jerome Lacan http://www.ietf.org/internet-drafts/draft-cantillo-ipdvb-s2encaps-00.txt * Requirements and scenarios * Future directions for this draft 8. Review of Milestones (10 minutes) - Chair 8. A.O.B. Archive: http://www.erg.abdn.ac.uk/ipdvb/archive Other related drafts: http://www.ietf.org/internet-drafts/draft-bormann-rohc-over-802-01.txt http://www.ietf.org/internet-drafts/draft-montpetit-ipdvb-config-00.txt http://www.ietf.org/internet-drafts/draft-miloucheva-udlr-mipv6-00.txt From owner-ipdvb@erg.abdn.ac.uk Mon Aug 01 11:01:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzbn6-0004CJ-1n for ipdvb-archive@megatron.ietf.org; Mon, 01 Aug 2005 11:01:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14563 for ; Mon, 1 Aug 2005 11:01:17 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzcJN-0004bx-CO for ipdvb-archive@ietf.org; Mon, 01 Aug 2005 11:34:42 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j71Eq8FL004684 for ; Mon, 1 Aug 2005 15:52:08 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j71Eq8P9004683 for ipdvb-subscribed-users; Mon, 1 Aug 2005 15:52:08 +0100 (BST) X-Authentication-Warning: dee.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.13.4/8.13.4) with ESMTP id j71Eq149004664 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 1 Aug 2005 15:52:03 +0100 (BST) Received: from ([199.29.3.25]) by maildc2.nab.org with ESMTP id 4028857.5985184; Mon, 01 Aug 2005 10:35:40 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: Proposed Changes to ULE text - Format descriptors for SI sign alling Date: Mon, 1 Aug 2005 10:35:39 -0400 Message-ID: Thread-Topic: Proposed Changes to ULE text - Format descriptors for SI sign alling Thread-Index: AcWWECEA3nMvZ75zQ/K+GbJR91X9YgAhLr8A From: "Allison, Art" To: 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 j71Eq8Bo004680 Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 8bit See embedded/edit. -----Original Message----- From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] Sent: Sunday, July 31, 2005 4:26 PM To: ipdvb@erg.abdn.ac.uk Subject: Re: Proposed Changes to ULE text - Format descriptors for SI sign alling Gorry said: The IETF defines (in RFC2119) that SHOULD, means "that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course". In this case, it means "implement this" or the implication may be that the stream is dropped by a TS multiplexor that does not recognise it. Gorry Art observes: First, I would not expect lack of an MRD in the program element loop of the PMT section to result in dropping the stream with a given PID value. Lack of an entry (the program element loop) that identifies the PID in the PMT would be expected to result in the stream being dropped by a general purpose multiplexer. This situation is sometimes called a 'orphan' PID. Second, implementers oft decide not to provide support for optional logic as it adds development and testing time. So one must expect some receivers conforming to the RFC will not have ability to discriminate based on the MRD value, but all tolerate its presence. I see other implications than the one Gorry cited for general purpose MPEG-2 distribution systems. These implications arise from the fact that PID values for payload streams are free to be changed by MPEG-S TS equipment, provided the PSI reflects the change. I1: So, if the PID value of the ULE stream is changed by a multiplexer in the distribution path, a receiver which was set up to receive a stream with a certain PID value would have no way to verify that the stream was a ULE stream. A receiver selecting and decoding this PID could produce an output formatted per ULE rules that was not really IP traffic. It could lead to bad data or result in intermittent loss of data by down stream consumers (and the receiver that disembeds the IP from the TS packets can legitimately signal the ULE stream on that PID was fine here.) I2: Without the MRD, a receiver cannot search the TS and locate the stream(s) that are ULE sent using arbitrary PID values over standard MPEG-2 compliant networks. So I ask: Q1: What are the "valid reasons in particular circumstances to ignore a particular item" in this particular case? Q2: Is it to use a PID value that is set and communicated 'out of band' to the receiver, and to force all equipment to not change that PID value? If so, that could work for that case; but that is a private network, not a general purpose one, and private networks can relax the requirement if needed (these are voluntary RFCs after all). Q3: However, given the lack of robustness/reliability that results from lack of the MRD, is the bit rate savings for not sending the MRD judged worth the inability to identify ULE streams sent over 'normal' general purpose MPEG-2 networks? I posited need for a SHALL, with wording that excluded use MPEG-2 transport packets with a PMT (but which might not meet other MPEG-2 TS requirements) and Adam reworded my posit to strictly apply to all use (which I can support as well). Art __________________ Art Allison Director, Advanced Engineering NAB Science & Technology 1771 N St NW, Washington DC 20036 202 429 5418 From owner-ipdvb@erg.abdn.ac.uk Tue Aug 02 04:47:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzsRD-0006ma-5B for ipdvb-archive@megatron.ietf.org; Tue, 02 Aug 2005 04:47:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00551 for ; Tue, 2 Aug 2005 04:47:48 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzsxe-00032i-0r for ipdvb-archive@ietf.org; Tue, 02 Aug 2005 05:21:23 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j728bP3X024008 for ; Tue, 2 Aug 2005 09:37:25 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j728bPP0024007 for ipdvb-subscribed-users; Tue, 2 Aug 2005 09:37:25 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from [139.133.204.42] (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j728bJa6023991 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 2 Aug 2005 09:37:21 +0100 (BST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 02 Aug 2005 10:39:06 +0200 Subject: ipdvb meeting Arrangements Audio/Slides/Jabber at IETF-63 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-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Draft slides are available for those not able to make the meeting, or who wish to follow on the laptop (these will be updated as new slides arrive). These are at: http://www.erg.abdn.ac.uk/ipdvb/meetings/IETF-63-Paris-August-2005/ The audio is being streamed - so this is available to all: http://videolab.uoregon.edu/events/ietf/ For those people that like to use Jabber to follow the meeting remotely, this WG has a Jabber room allocated to it at the following server: ipdvb@ietf.xmpp.org If anyone intends to use jabber to participate remotely , then please do 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 to let you find out what is going on in the meeting room!). 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 Tue Aug 02 10:01:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzxKp-0006ft-Fj for ipdvb-archive@megatron.ietf.org; Tue, 02 Aug 2005 10:01:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20480 for ; Tue, 2 Aug 2005 10:01:33 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzxrJ-0000xU-1g for ipdvb-archive@ietf.org; Tue, 02 Aug 2005 10:35:10 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j72DpmFt000533 for ; Tue, 2 Aug 2005 14:51:48 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j72DpmZs000532 for ipdvb-subscribed-users; Tue, 2 Aug 2005 14:51:48 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from [139.133.204.42] (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j72DpagB000512 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 2 Aug 2005 14:51:42 +0100 (BST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 02 Aug 2005 15:53:24 +0200 Subject: Re: Proposed Changes to ULE text - Format descriptors for SI sign alling From: Gorry Fairhurst To: "ipdvb@erg.abdn.ac.uk" Message-ID: In-Reply-To: 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-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Art, others, I'd like to respond to the SHOULD/SHALL thread as the WG Chair. The reason an additional paragraph was inserted, was to associate a ULE stream with a format descriptor that had been allocated by SMPTE. This now forms one of three paragraphs in the introduction of the ULE encapsulation spec. Looking at the thread, I believe the term "SHOULD" in the new para is correct in the IETF sense, in that there are cases where the ULE protocol could function without the information (e.g. A private network). This was also discussed on the list earlier. I'll present a slide with this text again at the IETF meeting tomorrow, and if there are more views, I'll make sure they are discussed on this list. Although the *encapsulation* work is now complete, the topics of addressing and identification of the set of TS to be used is now very much a work-in-progress. The AR document (see below) is intended to describe the process of binding/associating IPv4/IPv6 addresses with MPEG-2 Transport Streams (TS). In this latter context, the discussion seems valuable. The AR document needs to explain why and how to use the PMT, when you need it, when you may not do it, and what other protocol parameters need to be set to complete the mappings for IPv4/v6 multicast/unicast etc. This discussion thread provides useful inputs to this document, which we will try to now include in section 4. http://www.ietf.org/internet-drafts/draft-ietf-ipdvb-ar-00.txt Gorry From owner-ipdvb@erg.abdn.ac.uk Tue Aug 02 14:29:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E01Vq-0000Zq-7F for ipdvb-archive@megatron.ietf.org; Tue, 02 Aug 2005 14:29:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09793 for ; Tue, 2 Aug 2005 14:29:12 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E022L-00055p-74 for ipdvb-archive@ietf.org; Tue, 02 Aug 2005 15:02:51 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j72ILp3O006819 for ; Tue, 2 Aug 2005 19:21:51 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j72ILplC006818 for ipdvb-subscribed-users; Tue, 2 Aug 2005 19:21:51 +0100 (BST) X-Authentication-Warning: dee.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.13.4/8.13.4) with ESMTP id j72ILk0N006803 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 2 Aug 2005 19:21:47 +0100 (BST) Received: from ([199.29.3.25]) by maildc2.nab.org with ESMTP id 4028857.6002143; Tue, 02 Aug 2005 14:05:27 -0400 Subject: RE: Proposed Changes to ULE text - Format descriptors for SI sign alling MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-class: urn:content-classes:message Date: Tue, 2 Aug 2005 14:05:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: Thread-Topic: Proposed Changes to ULE text - Format descriptors for SI sign alling Thread-Index: AcWXbVoP14pSoMWySquPrmBYzGhhEgAHg8Uw From: "Allison, Art" To: 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 j72ILpp4006815 Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 8bit Ahh, point taken. In the encapsulation work, SHOULD seems appropriate and matches the scope. In the transport/binding/association using a MPEG-2 delivery system, a SHALL of some form seems correct. I apologize for missing the context as I thought we were discussing the transport work , not the final encapsulation work, as the time for substantive change discussion about that is past. Unless someone proved it is broken.) Art __________________ Art Allison Director, Advanced Engineering NAB Science & Technology 1771 N St NW, Washington DC 20036 202 429 5418 -----Original Message----- From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] Sent: Tuesday, August 02, 2005 9:53 AM To: ipdvb@erg.abdn.ac.uk Subject: Re: Proposed Changes to ULE text - Format descriptors for SI sign alling Art, others, I'd like to respond to the SHOULD/SHALL thread as the WG Chair. The reason an additional paragraph was inserted, was to associate a ULE stream with a format descriptor that had been allocated by SMPTE. This now forms one of three paragraphs in the introduction of the ULE encapsulation spec. Looking at the thread, I believe the term "SHOULD" in the new para is correct in the IETF sense, in that there are cases where the ULE protocol could function without the information (e.g. A private network). This was also discussed on the list earlier. I'll present a slide with this text again at the IETF meeting tomorrow, and if there are more views, I'll make sure they are discussed on this list. Although the *encapsulation* work is now complete, the topics of addressing and identification of the set of TS to be used is now very much a work-in-progress. The AR document (see below) is intended to describe the process of binding/associating IPv4/IPv6 addresses with MPEG-2 Transport Streams (TS). In this latter context, the discussion seems valuable. The AR document needs to explain why and how to use the PMT, when you need it, when you may not do it, and what other protocol parameters need to be set to complete the mappings for IPv4/v6 multicast/unicast etc. This discussion thread provides useful inputs to this document, which we will try to now include in section 4. http://www.ietf.org/internet-drafts/draft-ietf-ipdvb-ar-00.txt Gorry From owner-ipdvb@erg.abdn.ac.uk Wed Aug 03 11:36:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0LIS-0002zA-Gv for ipdvb-archive@megatron.ietf.org; Wed, 03 Aug 2005 11:36:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26086 for ; Wed, 3 Aug 2005 11:36:42 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0Lp9-0006zn-Gj for ipdvb-archive@ietf.org; Wed, 03 Aug 2005 12:10:32 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j73FWT1N005063 for ; Wed, 3 Aug 2005 16:32:29 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j73FWTJL005062 for ipdvb-subscribed-users; Wed, 3 Aug 2005 16:32:29 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from hnse2.hns.com (hnse2.hns.com [208.236.67.201]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j73FWMWw005047 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Wed, 3 Aug 2005 16:32:23 +0100 (BST) Received: from excore8.hns.com (excore8.hns.com [139.85.52.126]) by hnse2.hns.com (Switch-3.1.7/Switch-3.1.0) with ESMTP id j73FWGt6019831 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 3 Aug 2005 11:32:16 -0400 (EDT) Received: from hns.com (rasnvpn28.hns.com [139.85.221.111]) by excore8.hns.com (Switch-3.1.7/Switch-3.1.0) with ESMTP id j73FW8qT004202 for ; Wed, 3 Aug 2005 11:32:09 -0400 (EDT) Message-ID: <42F0E373.2080309@hns.com> Date: Wed, 03 Aug 2005 11:32:03 -0400 From: John Border User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: Adding ULE into a network already using MPE... References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Filtered: Sendmail Attachment Filter v2.8.1 excore8.hns.com j73FW8qT004202 X-AntiVirus: Sendmail Anti-Virus Filter excore8.hns.com 4.4.00 4549 j73FW8qT004202 X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Has anyone looked at the operational problems associated with adding ULE use to a network which has some deployed terminals which only understand MPE? John From owner-ipdvb@erg.abdn.ac.uk Wed Aug 03 11:36:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0LIS-0002z9-ER for ipdvb-archive@megatron.ietf.org; Wed, 03 Aug 2005 11:36:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26084 for ; Wed, 3 Aug 2005 11:36:42 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0Lp9-0006zz-Cy for ipdvb-archive@ietf.org; Wed, 03 Aug 2005 12:10:32 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j73FIIkN004650 for ; Wed, 3 Aug 2005 16:18:18 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j73FIIBW004649 for ipdvb-subscribed-users; Wed, 3 Aug 2005 16:18:18 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from [139.133.204.42] (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j73FIDAn004632 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Wed, 3 Aug 2005 16:18:13 +0100 (BST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Wed, 03 Aug 2005 17:20:01 +0200 Subject: IETF63 -Request for slides updates. 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-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Dear Presenters, Thank you to those who presented and/or attended at the ipdvb meeting this morning. We had 49 attendees at the meeting and from where I was looking, we covered the Agenda. Minutes will be issued (when the note-taker has done the appropriate work). If you made a presentation, and updated your slides from what was sent to the draft agenda, PLEASE DO send me the updates by 16th August, and I'll upload to the web site and also the IETF meeting proceedings. Draft slides will continue to be at: http://www.erg.abdn.ac.uk/ipdvb/meetings/IETF-63-Paris-August-2005/ Gorry From owner-ipdvb@erg.abdn.ac.uk Wed Aug 03 11:38:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0LKd-00048Z-6k for ipdvb-archive@megatron.ietf.org; Wed, 03 Aug 2005 11:38:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26229 for ; Wed, 3 Aug 2005 11:38:56 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0LrK-00076Z-8e for ipdvb-archive@ietf.org; Wed, 03 Aug 2005 12:12:47 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j73FZFA0005182 for ; Wed, 3 Aug 2005 16:35:15 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j73FZFFt005181 for ipdvb-subscribed-users; Wed, 3 Aug 2005 16:35:15 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from hnse2.hns.com (hnse2.hns.com [208.236.67.202]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j73FZAZl005132 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Wed, 3 Aug 2005 16:35:11 +0100 (BST) Received: from excore8.hns.com (excore8.hns.com [139.85.52.156]) by hnse2.hns.com (Switch-3.1.7/Switch-3.1.0) with ESMTP id j73FZ4xH020428 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 3 Aug 2005 11:35:04 -0400 (EDT) Received: from hns.com (rasnvpn28.hns.com [139.85.221.111]) by excore8.hns.com (Switch-3.1.7/Switch-3.1.0) with ESMTP id j73FYuiv004721; Wed, 3 Aug 2005 11:34:57 -0400 (EDT) Message-ID: <42F0E41B.3040402@hns.com> Date: Wed, 03 Aug 2005 11:34:51 -0400 From: John Border User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: Non-IP Protocol Support References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Filtered: Sendmail Attachment Filter v2.8.1 excore8.hns.com j73FYuiv004721 X-AntiVirus: Sendmail Anti-Virus Filter excore8.hns.com 4.4.00 4549 j73FYuiv004721 X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit I can understand why it is desirable to be able to carry non-IP traffic. But, I would prefer to get a solution for security that supports IP over DVB even if it doesn't support non-IP protocols than to not have a solution. Is there a compelling reason to include securing non-IP traffic in the problem space right now? John From owner-ipdvb@erg.abdn.ac.uk Wed Aug 03 12:06:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0LlZ-0007bJ-7n for ipdvb-archive@megatron.ietf.org; Wed, 03 Aug 2005 12:06:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27641 for ; Wed, 3 Aug 2005 12:06:46 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0MIB-0008B6-Ce for ipdvb-archive@ietf.org; Wed, 03 Aug 2005 12:40:37 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j73FwlkK006091 for ; Wed, 3 Aug 2005 16:58:47 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j73Fwl0J006090 for ipdvb-subscribed-users; Wed, 3 Aug 2005 16:58:47 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from smtpout04-03.prod.mesa1.secureserver.net (smtpout04-03.prod.mesa1.secureserver.net [64.202.165.198]) by erg.abdn.ac.uk (8.13.4/8.13.4) with SMTP id j73FwgrY006075 for ; Wed, 3 Aug 2005 16:58:42 +0100 (BST) Received: (qmail 14693 invoked from network); 3 Aug 2005 15:58:36 -0000 Received: from unknown (HELO webmail11.prod.mesa1.secureserver.net) (64.202.189.48) by smtpout04-03.prod.mesa1.secureserver.net with SMTP; 3 Aug 2005 15:58:36 -0000 Received: (qmail 23481 invoked by uid 99); 3 Aug 2005 15:58:36 -0000 Date: Wed, 3 Aug 2005 08:58:36 -0700 From: Marie-Jose Montpetit Subject: RE: Non-IP Protocol Support To: ipdvb@erg.abdn.ac.uk Message-ID: <20050803085836.ca5566c7162b3cfcb6c200079b757bd6.0c636c67af.wbe@email.email.secureserver.net> 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-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 I totally agree. Knowing that there is a compelling case of an IP solution that would be applicable across technologies (wireless, satellite and cable) I wonder why we should look at non-IP and legacy solution. Also looking in the future if we have an IP solution that works we can then see use cases for the non IP versions. I think it also would send the wrong message to the community. Let's solve IP over DVB here and let the other non-IP standardisation bodies tackle their technologies. /mjm > -------- Original Message -------- > Subject: Non-IP Protocol Support > From: John Border > Date: Wed, August 03, 2005 11:34 am > To: ipdvb@erg.abdn.ac.uk > > I can understand why it is desirable to be able to carry non-IP > traffic. But, I would prefer to get a solution for security that > supports IP over DVB even if it doesn't support non-IP protocols than to > not have a solution. Is there a compelling reason to include securing > non-IP traffic in the problem space right now? > > > John From owner-ipdvb@erg.abdn.ac.uk Wed Aug 03 14:16:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Nmz-0007Qm-R3 for ipdvb-archive@megatron.ietf.org; Wed, 03 Aug 2005 14:16:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04428 for ; Wed, 3 Aug 2005 14:16:24 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0OJi-00057E-9T for ipdvb-archive@ietf.org; Wed, 03 Aug 2005 14:50:15 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j73I6Muo008654 for ; Wed, 3 Aug 2005 19:06:22 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j73I6MR2008653 for ipdvb-subscribed-users; Wed, 3 Aug 2005 19:06:22 +0100 (BST) X-Authentication-Warning: dee.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.13.4/8.13.4) with ESMTP id j73I6GaD008636 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Wed, 3 Aug 2005 19:06:17 +0100 (BST) Received: from ([199.29.3.25]) by maildc2.nab.org with ESMTP id 4028857.6015595; Wed, 03 Aug 2005 14:05:49 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Adding ULE into a network already using MPE... X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 3 Aug 2005 14:05:49 -0400 Message-ID: Thread-Topic: Adding ULE into a network already using MPE... Thread-Index: AcWYQvSPly2ZTxamSdGOMRDTHqRItgAEpkdg From: "Allison, Art" To: 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 j73I6MYv008650 Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 8bit Use of the MRD will enable a device on a MPEG-2 network that does not understand that MRD's signaling/meaning to ignore the new encapsulation. Of course if the existing network just used private data with out signaling what it was, a problem may exist. __________________ Art Allison Director, Advanced Engineering NAB Science & Technology 1771 N St NW, Washington DC 20036 202 429 5418 -----Original Message----- From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] Sent: Wednesday, August 03, 2005 11:32 AM To: ipdvb@erg.abdn.ac.uk Subject: Adding ULE into a network already using MPE... Has anyone looked at the operational problems associated with adding ULE use to a network which has some deployed terminals which only understand MPE? John From owner-ipdvb@erg.abdn.ac.uk Wed Aug 03 14:34:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0O4O-0006SD-W3 for ipdvb-archive@megatron.ietf.org; Wed, 03 Aug 2005 14:34:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05582 for ; Wed, 3 Aug 2005 14:34:23 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0Ob6-0005uN-GX for ipdvb-archive@ietf.org; Wed, 03 Aug 2005 15:08:15 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j73ITlZF009328 for ; Wed, 3 Aug 2005 19:29:47 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j73ITlB6009327 for ipdvb-subscribed-users; Wed, 3 Aug 2005 19:29:47 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from smtpout02-03.prod.mesa1.secureserver.net (smtpout02-03.prod.mesa1.secureserver.net [64.202.165.193]) by erg.abdn.ac.uk (8.13.4/8.13.4) with SMTP id j73ITgZn009312 for ; Wed, 3 Aug 2005 19:29:43 +0100 (BST) Received: (qmail 14924 invoked from network); 3 Aug 2005 18:29:36 -0000 Received: from unknown (HELO webmail13.mesa1.secureserver.net) (64.202.189.54) by smtpout02-03.prod.mesa1.secureserver.net with SMTP; 3 Aug 2005 18:29:36 -0000 Received: (qmail 18488 invoked by uid 99); 3 Aug 2005 18:29:36 -0000 Date: Wed, 3 Aug 2005 11:29:36 -0700 From: Marie-Jose Montpetit Subject: RE: Adding ULE into a network already using MPE... To: ipdvb@erg.abdn.ac.uk cc: ipdvb@erg.abdn.ac.uk Message-ID: <20050803112936.ca5566c7162b3cfcb6c200079b757bd6.3e97673fe2.wbe@email.email.secureserver.net> 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-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 I think this is one thing that could be solved by some of the configuration work that was started where you could associate a PID to an encapsulation. You may not want to ignore the new encapsulation. Marie-Jose > -------- Original Message -------- > Subject: RE: Adding ULE into a network already using MPE... > From: "Allison, Art" > Date: Wed, August 03, 2005 2:05 pm > To: > > Use of the MRD will enable a device on a MPEG-2 network that does not > understand that MRD's signaling/meaning to ignore the new encapsulation. > > > Of course if the existing network just used private data with out > signaling what it was, a problem may exist. > __________________ > Art Allison > Director, Advanced Engineering > NAB Science & Technology > 1771 N St NW, Washington DC 20036 > 202 429 5418 > -----Original Message----- > From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] > Sent: Wednesday, August 03, 2005 11:32 AM > To: ipdvb@erg.abdn.ac.uk > Subject: Adding ULE into a network already using MPE... > > > Has anyone looked at the operational problems associated with adding > ULE use to a network which has some deployed terminals which only > understand MPE? > > > John From owner-ipdvb@erg.abdn.ac.uk Wed Aug 03 14:44:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0ODu-0002D2-Dm for ipdvb-archive@megatron.ietf.org; Wed, 03 Aug 2005 14:44:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05957 for ; Wed, 3 Aug 2005 14:44:13 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0Okd-0006Eb-02 for ipdvb-archive@ietf.org; Wed, 03 Aug 2005 15:18:04 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j73IdecR009624 for ; Wed, 3 Aug 2005 19:39:40 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j73Ide91009623 for ipdvb-subscribed-users; Wed, 3 Aug 2005 19:39:40 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from hnse2.hns.com (hnse2.hns.com [208.236.67.201]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j73IdWHh009605 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Wed, 3 Aug 2005 19:39:33 +0100 (BST) Received: from excore8.hns.com (excore8.hns.com [139.85.52.156]) by hnse2.hns.com (Switch-3.1.7/Switch-3.1.0) with ESMTP id j73IdQbx008766 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 3 Aug 2005 14:39:27 -0400 (EDT) Received: from hns.com (rasnvpn13.hns.com [139.85.221.96]) by excore8.hns.com (Switch-3.1.7/Switch-3.1.0) with ESMTP id j73IdJ5g014135; Wed, 3 Aug 2005 14:39:20 -0400 (EDT) Message-ID: <42F10F52.2040309@hns.com> Date: Wed, 03 Aug 2005 14:39:14 -0400 From: John Border User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: Re: Adding ULE into a network already using MPE... References: <20050803112936.ca5566c7162b3cfcb6c200079b757bd6.3e97673fe2.wbe@email.email.secureserver.net> In-Reply-To: <20050803112936.ca5566c7162b3cfcb6c200079b757bd6.3e97673fe2.wbe@email.email.secureserver.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Filtered: Sendmail Attachment Filter v2.8.1 excore8.hns.com j73IdJ5g014135 X-AntiVirus: Sendmail Anti-Virus Filter excore8.hns.com 4.4.00 4549 j73IdJ5g014135 X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit I was thinking along those lines. The sender associates the encapsulation method with a particular PID and "knows" (via AR) which PID to use to send to a particular receiver. Receivers which only understand MPE only use MPE PIDs. Receivers which understand ULE and MPE determine which method is being used by which PID is being received. (I think the ULE capable receivers will still need to support MPE for multicast traffic that is shared with "older" terminals.) I was wondering if there is a way for the receiver to look at the header and determine if it is ULE or MPE on the fly. I haven't taken a close look at it yet. But, I suspect that it is not reliably possible... John Marie-Jose Montpetit wrote: >I think this is one thing that could be solved by some of the >configuration work that was started where you could associate a PID to >an encapsulation. You may not want to ignore the new encapsulation. > >Marie-Jose > > > >>-------- Original Message -------- >>Subject: RE: Adding ULE into a network already using MPE... >>From: "Allison, Art" >>Date: Wed, August 03, 2005 2:05 pm >>To: >> >>Use of the MRD will enable a device on a MPEG-2 network that does not >>understand that MRD's signaling/meaning to ignore the new encapsulation. >> >> >>Of course if the existing network just used private data with out >>signaling what it was, a problem may exist. >>__________________ >>Art Allison >>Director, Advanced Engineering >>NAB Science & Technology >>1771 N St NW, Washington DC 20036 >>202 429 5418 >>-----Original Message----- >>From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] >>Sent: Wednesday, August 03, 2005 11:32 AM >>To: ipdvb@erg.abdn.ac.uk >>Subject: Adding ULE into a network already using MPE... >> >> >> Has anyone looked at the operational problems associated with adding >>ULE use to a network which has some deployed terminals which only >>understand MPE? >> >> >>John >> >> > > > From owner-ipdvb@erg.abdn.ac.uk Wed Aug 03 15:35:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0P1p-0004Lw-KI for ipdvb-archive@megatron.ietf.org; Wed, 03 Aug 2005 15:35:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09227 for ; Wed, 3 Aug 2005 15:35:47 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0PYY-0008Dx-Kw for ipdvb-archive@ietf.org; Wed, 03 Aug 2005 16:09:40 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j73JTh6F010942 for ; Wed, 3 Aug 2005 20:29:43 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j73JThb8010941 for ipdvb-subscribed-users; Wed, 3 Aug 2005 20:29:43 +0100 (BST) X-Authentication-Warning: dee.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.13.4/8.13.4) with ESMTP id j73JTb3b010926 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Wed, 3 Aug 2005 20:29:38 +0100 (BST) Received: from ([199.29.3.25]) by maildc2.nab.org with ESMTP id 4028857.6016822; Wed, 03 Aug 2005 15:29:18 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Adding ULE into a network already using MPE... X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 3 Aug 2005 15:29:18 -0400 Message-ID: Thread-Topic: Adding ULE into a network already using MPE... Thread-Index: AcWYXNW5H/US76RAQh2fakM625zBkgABD3eg From: "Allison, Art" To: 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 j73JThEw010938 Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 8bit Fixed PID associations constrain multiplexers. I suggest you seek the complexity impact assessment (both OTO and ongoing) from mux vendors to have a 'fixed' or 'well known' PID. MPEG2 systems folks will tell you this is a bad thing to do. __________________ Art Allison Director, Advanced Engineering NAB Science & Technology 1771 N St NW, Washington DC 20036 202 429 5418 -----Original Message----- From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] Sent: Wednesday, August 03, 2005 2:39 PM To: ipdvb@erg.abdn.ac.uk Subject: Re: Adding ULE into a network already using MPE... I was thinking along those lines. The sender associates the encapsulation method with a particular PID and "knows" (via AR) which PID to use to send to a particular receiver. Receivers which only understand MPE only use MPE PIDs. Receivers which understand ULE and MPE determine which method is being used by which PID is being received. (I think the ULE capable receivers will still need to support MPE for multicast traffic that is shared with "older" terminals.) I was wondering if there is a way for the receiver to look at the header and determine if it is ULE or MPE on the fly. I haven't taken a close look at it yet. But, I suspect that it is not reliably possible... John Marie-Jose Montpetit wrote: >I think this is one thing that could be solved by some of the >configuration work that was started where you could associate a PID to >an encapsulation. You may not want to ignore the new encapsulation. > >Marie-Jose > > > >>-------- Original Message -------- >>Subject: RE: Adding ULE into a network already using MPE... >>From: "Allison, Art" >>Date: Wed, August 03, 2005 2:05 pm >>To: >> >>Use of the MRD will enable a device on a MPEG-2 network that does not >>understand that MRD's signaling/meaning to ignore the new encapsulation. >> >> >>Of course if the existing network just used private data with out >>signaling what it was, a problem may exist. >>__________________ >>Art Allison >>Director, Advanced Engineering >>NAB Science & Technology >>1771 N St NW, Washington DC 20036 >>202 429 5418 >>-----Original Message----- >>From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] >>Sent: Wednesday, August 03, 2005 11:32 AM >>To: ipdvb@erg.abdn.ac.uk >>Subject: Adding ULE into a network already using MPE... >> >> >> Has anyone looked at the operational problems associated with >>adding ULE use to a network which has some deployed terminals which >>only understand MPE? >> >> >>John >> >> > > > From owner-ipdvb@erg.abdn.ac.uk Thu Aug 04 03:12:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Ztp-0006j5-Hk for ipdvb-archive@megatron.ietf.org; Thu, 04 Aug 2005 03:12:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06452 for ; Thu, 4 Aug 2005 03:12:16 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0aQe-000118-Q4 for ipdvb-archive@ietf.org; Thu, 04 Aug 2005 03:46:14 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j7476DKl021354 for ; Thu, 4 Aug 2005 08:06:13 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j7476C6E021353 for ipdvb-subscribed-users; Thu, 4 Aug 2005 08:06:12 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from mermoz.ensica.fr (hermes.ensica.fr [192.70.110.90]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j74768Hg021308 for ; Thu, 4 Aug 2005 08:06:09 +0100 (BST) Received: from DrCerebro (localhost [127.0.0.1]) by mermoz.ensica.fr (8.10.2+Sun/jtpda-5.3.1) with SMTP id j7476Hs16120 for ; Thu, 4 Aug 2005 09:06:17 +0200 (MEST) Message-ID: <000101c598c2$f36691b0$877a36c1@DrCerebro> From: "Juan Cantillo" To: References: <20050803085836.ca5566c7162b3cfcb6c200079b757bd6.0c636c67af.wbe@email.email.secureserver.net> Subject: Re: Non-IP Protocol Support Date: Wed, 3 Aug 2005 18:59:04 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.4 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit I agree too with MJM and John. For the "future" applications, since the IP vs non-IP traffic ratio will certainly keep becoming larger, is it insane to consider non-IP traffic encapsulated in IP packets ?... This would solve everything with an IP solution right? Best regards, ----- Original Message ----- From: "Marie-Jose Montpetit" To: Sent: Wednesday, August 03, 2005 5:58 PM Subject: RE: Non-IP Protocol Support >I totally agree. Knowing that there is a compelling case of an IP > solution that would be applicable across technologies (wireless, > satellite and cable) I wonder why we should look at non-IP and legacy > solution. Also looking in the future if we have an IP solution that > works we can then see use cases for the non IP versions. I think it > also would send the wrong message to the community. Let's solve IP over > DVB here and let the other non-IP standardisation bodies tackle their > technologies. > > /mjm > >> -------- Original Message -------- >> Subject: Non-IP Protocol Support >> From: John Border >> Date: Wed, August 03, 2005 11:34 am >> To: ipdvb@erg.abdn.ac.uk >> >> I can understand why it is desirable to be able to carry non-IP >> traffic. But, I would prefer to get a solution for security that >> supports IP over DVB even if it doesn't support non-IP protocols than to >> not have a solution. Is there a compelling reason to include securing >> non-IP traffic in the problem space right now? >> >> >> John > From owner-ipdvb@erg.abdn.ac.uk Thu Aug 04 03:39:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0aKJ-0008MB-VT for ipdvb-archive@megatron.ietf.org; Thu, 04 Aug 2005 03:39:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08472 for ; Thu, 4 Aug 2005 03:39:38 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0arA-0002YN-BM for ipdvb-archive@ietf.org; Thu, 04 Aug 2005 04:13:36 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j747Z3Se022076 for ; Thu, 4 Aug 2005 08:35:03 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j747Z31i022075 for ipdvb-subscribed-users; Thu, 4 Aug 2005 08:35:03 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from [86.255.16.90] (openMeridian-16-90.ietf63.ietf.org [86.255.16.90] (may be forged)) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j747Yi1a022059 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 4 Aug 2005 08:34:52 +0100 (BST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 04 Aug 2005 09:36:33 +0200 Subject: Re: Non-IP Protocol Support From: Gorry Fairhurst To: Message-ID: In-Reply-To: <000101c598c2$f36691b0$877a36c1@DrCerebro> 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-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit In some environments 802.1pQ; Metro Ethernet; LLC-based control packets (such as spanning tree); MPLS, etc are seen as important to provide management and control the L2 network. These and others are all supported by the ULE protocol type, and can be all used for IP network traffic. When we come to talking about security threats and requirements, it would be sensible to examine IPv4 and IPv6 as the most important services. If we can analyse this, we will be doing well. Future work may then also address other non-IP traffic flows (should this seem tractable and useful). One possibility is, I understand, to allow IP-based key management for non-IP flows (with some design trade-offs), but this requires extra work to define how this could happen. Another possibility is not to use alternate key management for these applications. Gorry On 3/8/05 6:59 pm, "Juan Cantillo" wrote: > I agree too with MJM and John. For the "future" applications, since the IP > vs non-IP traffic ratio will certainly keep becoming larger, is it insane > to consider non-IP traffic encapsulated in IP packets ?... This would solve > everything with an IP solution right? > Best regards, > > > > > ----- Original Message ----- > From: "Marie-Jose Montpetit" > To: > Sent: Wednesday, August 03, 2005 5:58 PM > Subject: RE: Non-IP Protocol Support > > >> I totally agree. Knowing that there is a compelling case of an IP >> solution that would be applicable across technologies (wireless, >> satellite and cable) I wonder why we should look at non-IP and legacy >> solution. Also looking in the future if we have an IP solution that >> works we can then see use cases for the non IP versions. I think it >> also would send the wrong message to the community. Let's solve IP over >> DVB here and let the other non-IP standardisation bodies tackle their >> technologies. >> >> /mjm >> >>> -------- Original Message -------- >>> Subject: Non-IP Protocol Support >>> From: John Border >>> Date: Wed, August 03, 2005 11:34 am >>> To: ipdvb@erg.abdn.ac.uk >>> >>> I can understand why it is desirable to be able to carry non-IP >>> traffic. But, I would prefer to get a solution for security that >>> supports IP over DVB even if it doesn't support non-IP protocols than to >>> not have a solution. Is there a compelling reason to include securing >>> non-IP traffic in the problem space right now? >>> >>> >>> John >> > > From owner-ipdvb@erg.abdn.ac.uk Thu Aug 04 03:57:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0ac1-0006Mm-K2 for ipdvb-archive@megatron.ietf.org; Thu, 04 Aug 2005 03:57:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09386 for ; Thu, 4 Aug 2005 03:57:55 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0b8s-0003Js-4h for ipdvb-archive@ietf.org; Thu, 04 Aug 2005 04:31:54 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j747sXYC022744 for ; Thu, 4 Aug 2005 08:54:33 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j747sX6a022743 for ipdvb-subscribed-users; Thu, 4 Aug 2005 08:54:33 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from [139.133.204.42] (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j747sOtv022723 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 4 Aug 2005 08:54:28 +0100 (BST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 04 Aug 2005 09:56:10 +0200 Subject: Re: Adding ULE into a network already using MPE... From: Gorry Fairhurst To: Message-ID: In-Reply-To: <42F10F52.2040309@hns.com> 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-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: 7bit There ways to do this I can think of three, and I think John you are asking about C? A) You could parse the SI/PSI signalling (if any) and extract the information from there. B) You could configure it (out of band) or using IP configuration/resolution, etc. C) I once worked through an "auto-detect mode", where you knew the PID but didn't know the type of encapsulation. ---- The basic rule is only one type of encapsulation is allowed for a single PID. So how can you find out which is used? I note there is a reasonably strong CRC there in the ULE framing, and you can easily extract framing alignment to the TS from the PUSI setting in the TS header: (i) Supposing your receiver starts as unconfigured. (ii) The receiver looks for a PUSI setting and extracts the PP value. (iii) It then tries reassembly of the first section as a ULE packet. If it succeeds with a valid CRC-32 and Length, it is probably safe to assume this is ULE. (iv) If the CRC fails, it tries a DSM-CC section reassembly (being aware the integrity check is interpreted in more than one way in MPE). The MPE start code is also another "hint" that this may not be ULE, but this value *could* appear as the start of a ULE field - (Note one needs to be aware that MPE and ATSC use different start values). (v) You could (probably should!!!) verify the next few SNDUs to increase your confidence, as in any alignment algorithm. It would also be wise to re-initialise the detection if you suffer an alignment failure. This could be a result of a change of mutliplexing policy. Note: This is orthogonal to the generation of SI/PSI tables used to control the TS multiplexing layer itself. If you use a transport stream multiplexor as a part of your L2 MPEG transmission network, this may need the SI/PSI to allow the PID to reach the Receiver. Thoughts? Gorry On 3/8/05 8:39 pm, "John Border" wrote: > > I was thinking along those lines. The sender associates the > encapsulation method with a particular PID and "knows" (via AR) which > PID to use to send to a particular receiver. Receivers which only > understand MPE only use MPE PIDs. Receivers which understand ULE and > MPE determine which method is being used by which PID is being > received. (I think the ULE capable receivers will still need to support > MPE for multicast traffic that is shared with "older" terminals.) > > I was wondering if there is a way for the receiver to look at the > header and determine if it is ULE or MPE on the fly. I haven't taken a > close look at it yet. But, I suspect that it is not reliably possible... > > John > > > Marie-Jose Montpetit wrote: > >> I think this is one thing that could be solved by some of the >> configuration work that was started where you could associate a PID to >> an encapsulation. You may not want to ignore the new encapsulation. >> >> Marie-Jose >> >> >> >>> -------- Original Message -------- >>> Subject: RE: Adding ULE into a network already using MPE... >>> From: "Allison, Art" >>> Date: Wed, August 03, 2005 2:05 pm >>> To: >>> >>> Use of the MRD will enable a device on a MPEG-2 network that does not >>> understand that MRD's signaling/meaning to ignore the new encapsulation. >>> >>> >>> Of course if the existing network just used private data with out >>> signaling what it was, a problem may exist. >>> __________________ >>> Art Allison >>> Director, Advanced Engineering >>> NAB Science & Technology >>> 1771 N St NW, Washington DC 20036 >>> 202 429 5418 >>> -----Original Message----- >>> From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] >>> Sent: Wednesday, August 03, 2005 11:32 AM >>> To: ipdvb@erg.abdn.ac.uk >>> Subject: Adding ULE into a network already using MPE... >>> >>> >>> Has anyone looked at the operational problems associated with adding >>> ULE use to a network which has some deployed terminals which only >>> understand MPE? >>> >>> >>> John >>> >>> >> >> >> > > From owner-ipdvb@erg.abdn.ac.uk Thu Aug 04 05:42:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0cF1-0005Ue-Dd for ipdvb-archive@megatron.ietf.org; Thu, 04 Aug 2005 05:42:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16944 for ; Thu, 4 Aug 2005 05:42:17 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0clX-0000Kh-Rz for ipdvb-archive@ietf.org; Thu, 04 Aug 2005 06:16:17 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j749a5rE025400 for ; Thu, 4 Aug 2005 10:36:05 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j749a5pg025399 for ipdvb-subscribed-users; Thu, 4 Aug 2005 10:36:05 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from rsys001x.roke.co.uk (rsys001x.roke.co.uk [193.118.201.108]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j749Zxib025380 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 4 Aug 2005 10:36:00 +0100 (BST) Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j749ZcFt011453 for ; Thu, 4 Aug 2005 10:35:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Received: from [193.118.193.100] (193.118.193.100 [193.118.193.100]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id PJSG1VNY; Thu, 4 Aug 2005 10:38:20 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C598D8.3FC28E00" Content-class: urn:content-classes:message Subject: Re: Non-IP Protocol Support Date: Thu, 4 Aug 2005 11:40:43 +0100 Message-ID: Thread-Topic: Non-IP Protocol Support Thread-Index: AcWY2EBfVnSUTHfrTpWNJH4AXo0nKg== From: "West, Mark" To: X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: mark.a.west@roke.co.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-Spam-Score: 0.8 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e This is a multi-part message in MIME format. ------_=_NextPart_001_01C598D8.3FC28E00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A further comment on Juan's point (and something that came up in discussion after the ipdvb session, yesterday)... If there is a security mechanism for IP (e.g. IPsec) and you want to = apply that to non-IP flows (e.g. a stream of SNDUs, Ethernet frames, ...) then why not run the non-IP over an emulated pseudo-wire within the IPsec tunnel? Then you only need an IP-based security solution. I honestly don't know whether this is appropriate, but it seemed like an interesting idea at the time! (http://www.ietf.org/internet-drafts/draft-ietf-pwe3-iana-allocation-11.t= xt already has codepoints for Ethernet, etc., but not anything specific to the ipdvb case.) Cheers, Mark. -- Mark A. West, Senior Consultant Engineer Roke Manor Research Ltd., Romsey, Hants. SO51 0ZN Phone +44 (0)1794 833311 Fax +44 (0)1794 833433 ------_=_NextPart_001_01C598D8.3FC28E00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Non-IP Protocol Support

A further comment on Juan's point (and something that = came up in
discussion after the ipdvb session, = yesterday)...

If there is a security mechanism for IP (e.g. IPsec) = and you want to apply
that to non-IP flows (e.g. a stream of SNDUs, = Ethernet frames, ...) then
why not run the non-IP over an emulated pseudo-wire = within the IPsec
tunnel?  Then you only need an IP-based security = solution.

I honestly don't know whether this is appropriate, but = it seemed like an
interesting idea at the time!

(http://www.ietf.org/internet-drafts/draft-ietf-pwe3-iana-alloc= ation-11.txt
already has codepoints for Ethernet, etc., but not = anything specific to
the ipdvb case.)

Cheers,

Mark.

--
Mark A. West, Senior Consultant Engineer
Roke Manor Research Ltd., Romsey, Hants.  SO51 = 0ZN
Phone +44 (0)1794 833311   Fax  +44 = (0)1794 833433

------_=_NextPart_001_01C598D8.3FC28E00-- From owner-ipdvb@erg.abdn.ac.uk Thu Aug 04 06:46:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0dFE-0007fi-D9 for ipdvb-archive@megatron.ietf.org; Thu, 04 Aug 2005 06:46:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25949 for ; Thu, 4 Aug 2005 06:46:33 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0dm4-0003n2-SY for ipdvb-archive@ietf.org; Thu, 04 Aug 2005 07:20:34 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j74AXZZE026831 for ; Thu, 4 Aug 2005 11:33:35 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j74AXZeB026830 for ipdvb-subscribed-users; Thu, 4 Aug 2005 11:33:35 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from [139.133.204.42] (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j74AXVVf026801 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 4 Aug 2005 11:33:31 +0100 (BST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 04 Aug 2005 12:35:19 +0200 Subject: Re: Non-IP Protocol Support From: Gorry Fairhurst To: Message-ID: In-Reply-To: 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-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit The IETF have defined several foo-over-IP methods which could be used, and these should work with ULE (bidirectional IP connectivity may be required). PWE3 is by no means the only option. However, there are situations were this tunnel over IP approach really does not do what may be wanted. ARP for IPv4 is a classic example. If you wanted to use arp to resolve an IP to MAC address, then clearly you can't encapsulate this over IP to send it. Gorry On 4/8/05 12:40 pm, "West, Mark" wrote: > > A further comment on Juan's point (and something that came up in > discussion after the ipdvb session, yesterday)... > > If there is a security mechanism for IP (e.g. IPsec) and you want to apply > that to non-IP flows (e.g. a stream of SNDUs, Ethernet frames, ...) then > why not run the non-IP over an emulated pseudo-wire within the IPsec > tunnel? Then you only need an IP-based security solution. > > I honestly don't know whether this is appropriate, but it seemed like an > interesting idea at the time! > > (http://www.ietf.org/internet-drafts/draft-ietf-pwe3-iana-allocation-11.txt > already has codepoints for Ethernet, etc., but not anything specific to > the ipdvb case.) > > Cheers, > > Mark. > > -- > Mark A. West, Senior Consultant Engineer > Roke Manor Research Ltd., Romsey, Hants. SO51 0ZN > Phone +44 (0)1794 833311 Fax +44 (0)1794 833433 > From owner-ipdvb@erg.abdn.ac.uk Thu Aug 04 08:24:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0emQ-0002Nr-Ll for ipdvb-archive@megatron.ietf.org; Thu, 04 Aug 2005 08:24:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01105 for ; Thu, 4 Aug 2005 08:24:57 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0fJG-0007sT-Kg for ipdvb-archive@ietf.org; Thu, 04 Aug 2005 08:58:58 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j74CJRuZ029762 for ; Thu, 4 Aug 2005 13:19:27 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j74CJRwp029761 for ipdvb-subscribed-users; Thu, 4 Aug 2005 13:19:27 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from rsys001x.roke.co.uk (rsys001x.roke.co.uk [193.118.201.108]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j74CJNY7029745 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 4 Aug 2005 13:19:23 +0100 (BST) Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j74CJ4Ft018948 for ; Thu, 4 Aug 2005 13:19:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Received: from [193.118.193.100] (193.118.193.100 [193.118.193.100]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id PJSG1VPW; Thu, 4 Aug 2005 13:21:49 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C598EF.16612C80" Content-class: urn:content-classes:message Subject: Re: Non-IP Protocol Support Date: Thu, 4 Aug 2005 14:23:56 +0100 Message-ID: Thread-Topic: Non-IP Protocol Support Thread-Index: AcWY7xbpUlTuTF31Spu4l0wPYtsYWQ== From: "West, Mark" To: X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: mark.a.west@roke.co.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-Spam-Score: 0.8 (/) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d This is a multi-part message in MIME format. ------_=_NextPart_001_01C598EF.16612C80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Indeed, RFC 3251 may be worth considering :-) But seriously... ... could I not encapsulate ARP, in that case, over multicast IP? It may be that this conversation is a little premature, in that there = are other questions about security that aren't directly related to this. = But if you can't tunnel stuff over IP to bootstrap, for example, then I'm suspicious of using an IP-based architecture to set-up a non-IP-based security system. (If that makes any sense?!) Cheers, Mark. > > The IETF have defined several foo-over-IP methods which could be used, > and > these should work with ULE (bidirectional IP connectivity may be > required). > PWE3 is by no means the only option. > > However, there are situations were this tunnel over IP approach really > does > not do what may be wanted. ARP for IPv4 is a classic example. If you > wanted > to use arp to resolve an IP to MAC address, then clearly you can't > encapsulate this over IP to send it. > > Gorry > > On 4/8/05 12:40 pm, "West, Mark" wrote: > > > > > A further comment on Juan's point (and something that came up in > > discussion after the ipdvb session, yesterday)... > > > > If there is a security mechanism for IP (e.g. IPsec) and you want to > apply > > that to non-IP flows (e.g. a stream of SNDUs, Ethernet frames, ...) > then > > why not run the non-IP over an emulated pseudo-wire within the IPsec > > tunnel? Then you only need an IP-based security solution. > > > > I honestly don't know whether this is appropriate, but it seemed = like > an > > interesting idea at the time! > > > > > = (http://www.ietf.org/internet-drafts/draft-ietf-pwe3-iana-allocation-11. > txt > > already has codepoints for Ethernet, etc., but not anything specific > to > > the ipdvb case.) > > > > Cheers, > > > > Mark. > > > > -- > > Mark A. West, Senior Consultant Engineer > > Roke Manor Research Ltd., Romsey, Hants. SO51 0ZN > > Phone +44 (0)1794 833311 Fax +44 (0)1794 833433 > > > > > ------_=_NextPart_001_01C598EF.16612C80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Non-IP Protocol Support

Indeed, RFC 3251 may be worth considering :-)

But seriously...

... could I not encapsulate ARP, in that case, over = multicast IP?

It may be that this conversation is a little = premature, in that there are
other questions about security that aren't directly = related to this.  But
if you can't tunnel stuff over IP to bootstrap, for = example, then I'm
suspicious of using an IP-based architecture to = set-up a non-IP-based
security system.  (If that makes any = sense?!)

Cheers,

Mark.


>
> The IETF have defined several foo-over-IP = methods which could be used,
> and
> these should work with ULE (bidirectional IP = connectivity may be
> required).
> PWE3 is by no means the only option.
>
> However, there are situations were this tunnel = over IP approach really
> does
> not do what may be wanted. ARP for IPv4 is a = classic example. If you
> wanted
> to use arp to resolve an IP to MAC address, then = clearly you can't
> encapsulate this over IP to send it.
>
> Gorry
>
> On 4/8/05 12:40 pm, "West, Mark" = <mark.a.west@roke.co.uk> wrote:
>
> >
> > A further comment on Juan's point (and = something that came up in
> > discussion after the ipdvb session, = yesterday)...
> >
> > If there is a security mechanism for IP = (e.g. IPsec) and you want to
> apply
> > that to non-IP flows (e.g. a stream of = SNDUs, Ethernet frames, ...)
> then
> > why not run the non-IP over an emulated = pseudo-wire within the IPsec
> > tunnel?  Then you only need an = IP-based security solution.
> >
> > I honestly don't know whether this is = appropriate, but it seemed like
> an
> > interesting idea at the time!
> >
> >
> (http://www.ietf.org/internet-drafts/draft-ietf-pwe3-iana-allocatio= n-11.
> txt
> > already has codepoints for Ethernet, etc., = but not anything specific
> to
> > the ipdvb case.)
> >
> > Cheers,
> >
> > Mark.
> >
> > --
> > Mark A. West, Senior Consultant = Engineer
> > Roke Manor Research Ltd., Romsey, = Hants.  SO51 0ZN
> > Phone +44 (0)1794 833311   = Fax  +44 (0)1794 833433
> >
>
>
>

------_=_NextPart_001_01C598EF.16612C80-- From owner-ipdvb@erg.abdn.ac.uk Thu Aug 04 11:54:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0i36-0004P5-2X for ipdvb-archive@megatron.ietf.org; Thu, 04 Aug 2005 11:54:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21148 for ; Thu, 4 Aug 2005 11:54:21 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0iZx-00084M-VN for ipdvb-archive@ietf.org; Thu, 04 Aug 2005 12:28:24 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j74Fi1Mt004169 for ; Thu, 4 Aug 2005 16:44:01 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j74Fi1oP004168 for ipdvb-subscribed-users; Thu, 4 Aug 2005 16:44:01 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from sharplabs.com (keymaster.sharplabs.com [216.65.151.107]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j74FhnrC004147 for ; Thu, 4 Aug 2005 16:43:52 +0100 (BST) Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j74Fhg8R016532 for ; Thu, 4 Aug 2005 08:43:42 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Thu, 4 Aug 2005 08:45:08 -0700 Message-ID: <08259490B3BC3140B549DD0907A5644822C552@admsrvnt10.enet.sharplabs.com> From: "Goldberg, Adam" To: ipdvb@erg.abdn.ac.uk Subject: RE: Adding ULE into a network already using MPE... Date: Thu, 4 Aug 2005 08:45:03 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-ERG-MailScanner: Found to be clean, Found to be clean X-MIME-Autoconverted: from quoted-printable to 8bit by erg.abdn.ac.uk id j74Fi0ul004165 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 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by erg.abdn.ac.uk id j74Fi1Mt004169 X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Content-Transfer-Encoding: quoted-printable Sure, you can decide to not use the mechanisms already existent in an MPE= G Transport Stream (B, C), but in doing so you merely cause redesign or purchase of special-purpose "MPEG" processing devices. Make it a Transport Stream. This has very little real overhead, requirin= g only a PAT and PMT. The PMT is very lightweight but yet can easily signa= l which elementary streams (er, "PIDs") are encoded with what protocols. This has many advantages: You don't need to reinvent anything (inband signaling) -- merely an identifying descriptor; you don't have to require multiplexers and other non-IETF MPEG processing devices do anything speci= al (that is to say, you don't require existing MPEG processing devices to al= so process nonstandard IETF things); IETF streams would coexist peacefully w= ith non-IETF streams in a Transport Stream; it's very extensible to other encapsulation formats yet-to-be-defined. Adam Goldberg Director, Television Standards & Policy Development Sharp Laboratories of America 8605 Westwood Center Drive, Suite 206 Vienna, VA=A0 22182 703-556-4406 703-556-4410 fax 571-276-0305 cell =A0 > -----Original Message----- > From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On > Behalf Of Gorry Fairhurst > Sent: Thursday, August 04, 2005 3:56 AM > To: ipdvb@erg.abdn.ac.uk > Subject: Re: Adding ULE into a network already using MPE... >=20 > There ways to do this I can think of three, and I think John you are > asking > about C? >=20 >=20 > A) You could parse the SI/PSI signalling (if any) and extract the > information from there. >=20 > B) You could configure it (out of band) or using IP > configuration/resolution, etc. >=20 > C) I once worked through an "auto-detect mode", where you knew the PID = but > didn't know the type of encapsulation. >=20 > ---- >=20 > The basic rule is only one type of encapsulation is allowed for a singl= e > PID. So how can you find out which is used? >=20 > I note there is a reasonably strong CRC there in the ULE framing, and y= ou > can easily extract framing alignment to the TS from the PUSI setting in > the > TS header: >=20 > (i) Supposing your receiver starts as unconfigured. >=20 > (ii) The receiver looks for a PUSI setting and extracts the PP value. >=20 > (iii) It then tries reassembly of the first section as a ULE packet. If= it > succeeds with a valid CRC-32 and Length, it is probably safe to assume > this > is ULE. >=20 > (iv) If the CRC fails, it tries a DSM-CC section reassembly (being awar= e > the > integrity check is interpreted in more than one way in MPE). The MPE st= art > code is also another "hint" that this may not be ULE, but this value > *could* > appear as the start of a ULE field - (Note one needs to be aware that M= PE > and ATSC use different start values). >=20 > (v) You could (probably should!!!) verify the next few SNDUs to increas= e > your confidence, as in any alignment algorithm. It would also be wise = to > re-initialise the detection if you suffer an alignment failure. This co= uld > be a result of a change of mutliplexing policy. >=20 > Note: This is orthogonal to the generation of SI/PSI tables used to > control > the TS multiplexing layer itself. If you use a transport stream > multiplexor > as a part of your L2 MPEG transmission network, this may need the SI/PS= I > to > allow the PID to reach the Receiver. >=20 > Thoughts? >=20 > Gorry >=20 > On 3/8/05 8:39 pm, "John Border" wrote: > > > > I was thinking along those lines. The sender associates the > > encapsulation method with a particular PID and "knows" (via AR) which > > PID to use to send to a particular receiver. Receivers which only > > understand MPE only use MPE PIDs. Receivers which understand ULE and > > MPE determine which method is being used by which PID is being > > received. (I think the ULE capable receivers will still need to supp= ort > > MPE for multicast traffic that is shared with "older" terminals.) > > > > I was wondering if there is a way for the receiver to look at the > > header and determine if it is ULE or MPE on the fly. I haven't taken= a > > close look at it yet. But, I suspect that it is not reliably possible... > > > > John > > > > > > Marie-Jose Montpetit wrote: > > > >> I think this is one thing that could be solved by some of the > >> configuration work that was started where you could associate a PID = to > >> an encapsulation. You may not want to ignore the new encapsulation. > >> > >> Marie-Jose > >> > >> > >> > >>> -------- Original Message -------- > >>> Subject: RE: Adding ULE into a network already using MPE... > >>> From: "Allison, Art" > >>> Date: Wed, August 03, 2005 2:05 pm > >>> To: > >>> > >>> Use of the MRD will enable a device on a MPEG-2 network that does n= ot > >>> understand that MRD's signaling/meaning to ignore the new > encapsulation. > >>> > >>> > >>> Of course if the existing network just used private data with out > >>> signaling what it was, a problem may exist. > >>> __________________ > >>> Art Allison > >>> Director, Advanced Engineering > >>> NAB Science & Technology > >>> 1771 N St NW, Washington DC 20036 > >>> 202 429 5418 > >>> -----Original Message----- > >>> From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk= ] > >>> Sent: Wednesday, August 03, 2005 11:32 AM > >>> To: ipdvb@erg.abdn.ac.uk > >>> Subject: Adding ULE into a network already using MPE... > >>> > >>> > >>> Has anyone looked at the operational problems associated with > adding > >>> ULE use to a network which has some deployed terminals which only > >>> understand MPE? > >>> > >>> > >>> John > >>> > >>> > >> > >> > >> > > > > From owner-ipdvb@erg.abdn.ac.uk Thu Aug 04 12:10:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0iIC-0008F3-9Q for ipdvb-archive@megatron.ietf.org; Thu, 04 Aug 2005 12:10:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22082 for ; Thu, 4 Aug 2005 12:09:57 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0ip6-00005P-8Q for ipdvb-archive@ietf.org; Thu, 04 Aug 2005 12:44:01 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j74G5bkx004933 for ; Thu, 4 Aug 2005 17:05:37 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j74G5b2r004932 for ipdvb-subscribed-users; Thu, 4 Aug 2005 17:05:37 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from hnse2.hns.com (hnse2.hns.com [208.236.67.202]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j74G5WZv004913 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 4 Aug 2005 17:05:33 +0100 (BST) Received: from excore8.hns.com (excore8.hns.com [139.85.52.156]) by hnse2.hns.com (Switch-3.1.7/Switch-3.1.0) with ESMTP id j74G5NJ9016196 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 4 Aug 2005 12:05:24 -0400 (EDT) Received: from atlas (atlas.hns.com [139.85.177.110]) by excore8.hns.com (Switch-3.1.7/Switch-3.1.0) with ESMTP id j74G58Ol021342; Thu, 4 Aug 2005 12:05:16 -0400 (EDT) To: ipdvb@erg.abdn.ac.uk Cc: ipdvb@erg.abdn.ac.uk, owner-ipdvb@erg.abdn.ac.uk Subject: RE: Adding ULE into a network already using MPE... MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: Satyajit Roy Date: Thu, 4 Aug 2005 12:05:05 -0400 X-MIMETrack: Serialize by Router on Atlas/HNS(Release 6.5.1|January 21, 2004) at 08/04/2005 12:03:15, Serialize complete at 08/04/2005 12:03:15 Content-Type: multipart/alternative; boundary="=_alternative 00585B3185257053_=" X-Filtered: Sendmail Attachment Filter v2.8.1 excore8.hns.com j74G58Ol021342 X-AntiVirus: Sendmail Anti-Virus Filter excore8.hns.com 4.4.00 4549 j74G58Ol021342 X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 3643ee1fccf5d6cf2af25f27d28abb29 This is a multipart message in MIME format. --=_alternative 00585B3185257053_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I also support distinguishing encapsulation protocols via PMT. Satyajit "Goldberg, Adam" Sent by: owner-ipdvb@erg.abdn.ac.uk 08/04/2005 11:45 AM Please respond to ipdvb =20 To: ipdvb@erg.abdn.ac.uk cc:=20 Subject: RE: Adding ULE into a network already using MPE... Sure, you can decide to not use the mechanisms already existent in an MPEG Transport Stream (B, C), but in doing so you merely cause redesign or purchase of special-purpose "MPEG" processing devices. Make it a Transport Stream. This has very little real overhead, requiring only a PAT and PMT. The PMT is very lightweight but yet can easily signal which elementary streams (er, "PIDs") are encoded with what protocols. This has many advantages: You don't need to reinvent anything (inband signaling) -- merely an identifying descriptor; you don't have to require multiplexers and other non-IETF MPEG processing devices do anything=20 special (that is to say, you don't require existing MPEG processing devices to=20 also process nonstandard IETF things); IETF streams would coexist peacefully=20 with non-IETF streams in a Transport Stream; it's very extensible to other encapsulation formats yet-to-be-defined. Adam Goldberg Director, Television Standards & Policy Development Sharp Laboratories of America 8605 Westwood Center Drive, Suite 206 Vienna, VA=A0 22182 703-556-4406 703-556-4410 fax 571-276-0305 cell =A0 > -----Original Message----- > From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On > Behalf Of Gorry Fairhurst > Sent: Thursday, August 04, 2005 3:56 AM > To: ipdvb@erg.abdn.ac.uk > Subject: Re: Adding ULE into a network already using MPE... >=20 > There ways to do this I can think of three, and I think John you are > asking > about C? >=20 >=20 > A) You could parse the SI/PSI signalling (if any) and extract the > information from there. >=20 > B) You could configure it (out of band) or using IP > configuration/resolution, etc. >=20 > C) I once worked through an "auto-detect mode", where you knew the PID=20 but > didn't know the type of encapsulation. >=20 > ---- >=20 > The basic rule is only one type of encapsulation is allowed for a single > PID. So how can you find out which is used? >=20 > I note there is a reasonably strong CRC there in the ULE framing, and=20 you > can easily extract framing alignment to the TS from the PUSI setting in > the > TS header: >=20 > (i) Supposing your receiver starts as unconfigured. >=20 > (ii) The receiver looks for a PUSI setting and extracts the PP value. >=20 > (iii) It then tries reassembly of the first section as a ULE packet. If=20 it > succeeds with a valid CRC-32 and Length, it is probably safe to assume > this > is ULE. >=20 > (iv) If the CRC fails, it tries a DSM-CC section reassembly (being aware > the > integrity check is interpreted in more than one way in MPE). The MPE=20 start > code is also another "hint" that this may not be ULE, but this value > *could* > appear as the start of a ULE field - (Note one needs to be aware that=20 MPE > and ATSC use different start values). >=20 > (v) You could (probably should!!!) verify the next few SNDUs to increase > your confidence, as in any alignment algorithm. It would also be wise=20 to > re-initialise the detection if you suffer an alignment failure. This=20 could > be a result of a change of mutliplexing policy. >=20 > Note: This is orthogonal to the generation of SI/PSI tables used to > control > the TS multiplexing layer itself. If you use a transport stream > multiplexor > as a part of your L2 MPEG transmission network, this may need the SI/PSI > to > allow the PID to reach the Receiver. >=20 > Thoughts? >=20 > Gorry >=20 > On 3/8/05 8:39 pm, "John Border" wrote: > > > > I was thinking along those lines. The sender associates the > > encapsulation method with a particular PID and "knows" (via AR) which > > PID to use to send to a particular receiver. Receivers which only > > understand MPE only use MPE PIDs. Receivers which understand ULE and > > MPE determine which method is being used by which PID is being > > received. (I think the ULE capable receivers will still need to=20 support > > MPE for multicast traffic that is shared with "older" terminals.) > > > > I was wondering if there is a way for the receiver to look at the > > header and determine if it is ULE or MPE on the fly. I haven't taken=20 a > > close look at it yet. But, I suspect that it is not reliably possible... > > > > John > > > > > > Marie-Jose Montpetit wrote: > > > >> I think this is one thing that could be solved by some of the > >> configuration work that was started where you could associate a PID=20 to > >> an encapsulation. You may not want to ignore the new encapsulation. > >> > >> Marie-Jose > >> > >> > >> > >>> -------- Original Message -------- > >>> Subject: RE: Adding ULE into a network already using MPE... > >>> From: "Allison, Art" > >>> Date: Wed, August 03, 2005 2:05 pm > >>> To: > >>> > >>> Use of the MRD will enable a device on a MPEG-2 network that does=20 not > >>> understand that MRD's signaling/meaning to ignore the new > encapsulation. > >>> > >>> > >>> Of course if the existing network just used private data with out > >>> signaling what it was, a problem may exist. > >>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > >>> Art Allison > >>> Director, Advanced Engineering > >>> NAB Science & Technology > >>> 1771 N St NW, Washington DC 20036 > >>> 202 429 5418 > >>> -----Original Message----- > >>> From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] > >>> Sent: Wednesday, August 03, 2005 11:32 AM > >>> To: ipdvb@erg.abdn.ac.uk > >>> Subject: Adding ULE into a network already using MPE... > >>> > >>> > >>> Has anyone looked at the operational problems associated with > adding > >>> ULE use to a network which has some deployed terminals which only > >>> understand MPE? > >>> > >>> > >>> John > >>> > >>> > >> > >> > >> > > > > --=_alternative 00585B3185257053_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I also support distinguishing encaps= ulation protocols via PMT.

Satyajit



"Goldberg, Adam" <ag= oldberg@sharplabs.com>
Sent by: owner-ipdvb@erg.abdn.ac.uk<= /font>

08/04/2005 11:45 AM
Please respond to ipdvb

       
        To: &nbs= p;      ipdvb@erg.abdn.ac.uk
        cc: &nbs= p;      
        Subject:=        RE: Adding ULE into a network already using MPE= ...



Sure, you can decide to not use the= mechanisms already existent in an MPEG
Transport Stream (B, C), but in doing so you merely cause redesign or
purchase of special-purpose "MPEG" processing devices.

Make it a Transport Stream.  This has very little real overhead, requi= ring
only a PAT and PMT.  The PMT is very lightweight but yet can easily si= gnal
which elementary streams (er, "PIDs") are encoded with what proto= cols.

This has many advantages:  You don't need to reinvent anything (inband=
signaling) -- merely an identifying descriptor; you don't have to require multiplexers and other non-IETF MPEG processing devices do anything special=
(that is to say, you don't require existing MPEG processing devices to also=
process nonstandard IETF things); IETF streams would coexist peacefully wit= h
non-IETF streams in a Transport Stream; it's very extensible to other
encapsulation formats yet-to-be-defined.

Adam Goldberg
Director, Television Standards & Policy Development
Sharp Laboratories of America
8605 Westwood Center Drive, Suite 206
Vienna, VA=A0 22182
703-556-4406
703-556-4410 fax
571-276-0305 cell
=A0


> -----Original Message-----
> From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] O= n
> Behalf Of Gorry Fairhurst
> Sent: Thursday, August 04, 2005 3:56 AM
> To: ipdvb@erg.abdn.ac.uk
> Subject: Re: Adding ULE into a network already using MPE...
>
> There ways to do this I can think of three, and I think John you are > asking
> about C?
>
>
> A) You could parse the SI/PSI signalling (if any) and extract the
> information from there.
>
> B) You could configure it (out of band) or using IP
> configuration/resolution, etc.
>
> C) I once worked through an "auto-detect mode", where you kn= ew the PID but
> didn't know the type of encapsulation.
>
> ----
>
> The basic rule is only one type of encapsulation is allowed for a sing= le
> PID. So how can you find out which is used?
>
> I note there is a reasonably strong CRC there in the ULE framing, and = you
> can easily extract framing alignment to the TS from the PUSI setting i= n
> the
> TS header:
>
> (i) Supposing your receiver starts as unconfigured.
>
> (ii) The receiver looks for a PUSI setting and extracts the PP value.<= br> >
> (iii) It then tries reassembly of the first section as a ULE packet. I= f it
> succeeds with a valid CRC-32 and Length, it is probably safe to assume=
> this
> is ULE.
>
> (iv) If the CRC fails, it tries a DSM-CC section reassembly (being awa= re
> the
> integrity check is interpreted in more than one way in MPE). The MPE s= tart
> code is also another "hint" that this may not be ULE, but th= is value
> *could*
> appear as the start of a ULE field - (Note one needs to be aware that = MPE
> and ATSC use different start values).
>
> (v) You could (probably should!!!) verify the next few SNDUs to increa= se
> your confidence, as in any alignment algorithm.  It would also be= wise to
> re-initialise the detection if you suffer an alignment failure. This c= ould
> be a result of a change of mutliplexing policy.
>
> Note: This is orthogonal to the generation of SI/PSI tables used to
> control
> the TS multiplexing layer itself. If you use a transport stream
> multiplexor
> as a part of your L2 MPEG transmission network, this may need the SI/P= SI
> to
> allow the PID to reach the Receiver.
>
> Thoughts?
>
> Gorry
>
> On 3/8/05 8:39 pm, "John Border" <border@hns.com> wrot= e:
> >
> >     I was thinking along those lines.  The sender = associates the
> > encapsulation method with a particular PID and "knows" = (via AR) which
> > PID to use to send to a particular receiver.  Receivers whic= h only
> > understand MPE only use MPE PIDs.  Receivers which understan= d ULE and
> > MPE determine which method is being used by which PID is being
> > received.  (I think the ULE capable receivers will still nee= d to support
> > MPE for multicast traffic that is shared with "older" t= erminals.)
> >
> >     I was wondering if there is a way for the receiver = to look at the
> > header and determine if it is ULE or MPE on the fly.  I have= n't taken a
> > close look at it yet.  But, I suspect that it is not reliabl= y
possible...
> >
> > John
> >
> >
> > Marie-Jose Montpetit wrote:
> >
> >> I think this is one thing that could be solved by some of the=
> >> configuration work that was started where you could associate= a PID to
> >> an encapsulation. You may not want to ignore the new encapsul= ation.
> >>
> >> Marie-Jose
> >>
> >>
> >>
> >>> -------- Original Message --------
> >>> Subject: RE: Adding ULE into a network already using MPE.= ..
> >>> From: "Allison, Art" <AAllison@nab.org> > >>> Date: Wed, August 03, 2005 2:05 pm
> >>> To: <ipdvb@erg.abdn.ac.uk>
> >>>
> >>> Use of the MRD will enable a device on a MPEG-2 network t= hat does not
> >>> understand that MRD's signaling/meaning to ignore the new=
> encapsulation.
> >>>
> >>>
> >>> Of course if the existing network just used private data = with out
> >>> signaling what it was, a problem may exist.
> >>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> >>> Art Allison
> >>> Director, Advanced Engineering
> >>> NAB Science & Technology
> >>> 1771 N St NW, Washington DC 20036
> >>> 202 429 5418
> >>> -----Original Message-----
> >>> From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.= abdn.ac.uk]
> >>> Sent: Wednesday, August 03, 2005 11:32 AM
> >>> To: ipdvb@erg.abdn.ac.uk
> >>> Subject: Adding ULE into a network already using MPE... > >>>
> >>>
> >>>    Has anyone looked at the operational problem= s associated with
> adding
> >>> ULE use to a network which has some deployed terminals wh= ich only
> >>> understand MPE?
> >>>
> >>>
> >>> John
> >>>
> >>>
> >>
> >>
> >>
> >
> >

--=_alternative 00585B3185257053_=-- From owner-ipdvb@erg.abdn.ac.uk Thu Aug 04 13:11:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0jGA-0001bR-J1 for ipdvb-archive@megatron.ietf.org; Thu, 04 Aug 2005 13:11:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25167 for ; Thu, 4 Aug 2005 13:11:55 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0jn5-0001ju-Cf for ipdvb-archive@ietf.org; Thu, 04 Aug 2005 13:46:00 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j74GY5A7005582 for ; Thu, 4 Aug 2005 17:34:05 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j74GY5uG005581 for ipdvb-subscribed-users; Thu, 4 Aug 2005 17:34:05 +0100 (BST) X-Authentication-Warning: dee.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.13.4/8.13.4) with ESMTP id j74GY1gQ005564 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 4 Aug 2005 17:34:01 +0100 (BST) Received: from ([199.29.3.25]) by maildc2.nab.org with ESMTP id 4028857.6027527; Thu, 04 Aug 2005 12:33:46 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: Adding ULE into a network already using MPE... Date: Thu, 4 Aug 2005 12:33:45 -0400 Message-ID: Thread-Topic: Adding ULE into a network already using MPE... Thread-Index: AcWZDpBXp8NGKom4SJmBhjY2+3nT8QAAwrGw From: "Allison, Art" To: X-ERG-MailScanner: Found to be clean, Found to be clean X-MIME-Autoconverted: from quoted-printable to 8bit by erg.abdn.ac.uk id j74GY57U005576 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 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by erg.abdn.ac.uk id j74GY5A7005582 X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Content-Transfer-Encoding: quoted-printable After all this is transport of ULE (which is in MPEG-2 Transport Packets)= ...so being MPEG-2 compliant would tend to extend the utility, and not be= ing MPEG-2 would reduce the utility. But whatever... __________________ Art Allison Director, Advanced Engineering NAB Science & Technology 1771 N St NW, Washington DC 20036 202 429 5418=20 --Original Message----- From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk]=20 Sent: Thursday, August 04, 2005 11:45 AM To: ipdvb@erg.abdn.ac.uk Subject: RE: Adding ULE into a network already using MPE... Sure, you can decide to not use the mechanisms already existent in an MPE= G Transport Stream (B, C), but in doing so you merely cause redesign or p= urchase of special-purpose "MPEG" processing devices. Make it a Transport Stream. This has very little real overhead, requirin= g only a PAT and PMT. The PMT is very lightweight but yet can easily sig= nal which elementary streams (er, "PIDs") are encoded with what protocols. This has many advantages: You don't need to reinvent anything (inband signaling) -- merely an identifying descriptor; you don't have to require= multiplexers and other non-IETF MPEG processing devices do anything spec= ial (that is to say, you don't require existing MPEG processing devices t= o also process nonstandard IETF things); IETF streams would coexist peace= fully with non-IETF streams in a Transport Stream; it's very extensible t= o other encapsulation formats yet-to-be-defined. Adam Goldberg Director, Television Standards & Policy Development Sharp Laboratories of= America 8605 Westwood Center Drive, Suite 206 Vienna, VA=A0 22182 703-556-4406 703-556-4410 fax 571-276-0305 cell =A0 > -----Original Message----- > From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk]=20 > On Behalf Of Gorry Fairhurst > Sent: Thursday, August 04, 2005 3:56 AM > To: ipdvb@erg.abdn.ac.uk > Subject: Re: Adding ULE into a network already using MPE... >=20 > There ways to do this I can think of three, and I think John you are=20 > asking about C? >=20 >=20 > A) You could parse the SI/PSI signalling (if any) and extract the=20 > information from there. >=20 > B) You could configure it (out of band) or using IP=20 > configuration/resolution, etc. >=20 > C) I once worked through an "auto-detect mode", where you knew the PID=20 > but didn't know the type of encapsulation. >=20 > ---- >=20 > The basic rule is only one type of encapsulation is allowed for a=20 > single PID. So how can you find out which is used? >=20 > I note there is a reasonably strong CRC there in the ULE framing, and=20 > you can easily extract framing alignment to the TS from the PUSI=20 > setting in the TS header: >=20 > (i) Supposing your receiver starts as unconfigured. >=20 > (ii) The receiver looks for a PUSI setting and extracts the PP value. >=20 > (iii) It then tries reassembly of the first section as a ULE packet.=20 > If it succeeds with a valid CRC-32 and Length, it is probably safe to=20 > assume this is ULE. >=20 > (iv) If the CRC fails, it tries a DSM-CC section reassembly (being=20 > aware the integrity check is interpreted in more than one way in MPE).=20 > The MPE start code is also another "hint" that this may not be ULE,=20 > but this value > *could* > appear as the start of a ULE field - (Note one needs to be aware that=20 > MPE and ATSC use different start values). >=20 > (v) You could (probably should!!!) verify the next few SNDUs to=20 > increase your confidence, as in any alignment algorithm. It would=20 > also be wise to re-initialise the detection if you suffer an alignment=20 > failure. This could be a result of a change of mutliplexing policy. >=20 > Note: This is orthogonal to the generation of SI/PSI tables used to=20 > control the TS multiplexing layer itself. If you use a transport=20 > stream multiplexor as a part of your L2 MPEG transmission network,=20 > this may need the SI/PSI to allow the PID to reach the Receiver. >=20 > Thoughts? >=20 > Gorry >=20 > On 3/8/05 8:39 pm, "John Border" wrote: > > > > I was thinking along those lines. The sender associates the=20 > > encapsulation method with a particular PID and "knows" (via AR)=20 > > which PID to use to send to a particular receiver. Receivers which=20 > > only understand MPE only use MPE PIDs. Receivers which understand=20 > > ULE and MPE determine which method is being used by which PID is=20 > > being received. (I think the ULE capable receivers will still need=20 > > to support MPE for multicast traffic that is shared with "older"=20 > > terminals.) > > > > I was wondering if there is a way for the receiver to look at=20 > > the header and determine if it is ULE or MPE on the fly. I haven't=20 > > taken a close look at it yet. But, I suspect that it is not=20 > > reliably possible... > > > > John > > > > > > Marie-Jose Montpetit wrote: > > > >> I think this is one thing that could be solved by some of the=20 > >> configuration work that was started where you could associate a PID=20 > >> to an encapsulation. You may not want to ignore the new encapsulatio= n. > >> > >> Marie-Jose > >> > >> > >> > >>> -------- Original Message -------- > >>> Subject: RE: Adding ULE into a network already using MPE... > >>> From: "Allison, Art" > >>> Date: Wed, August 03, 2005 2:05 pm > >>> To: > >>> > >>> Use of the MRD will enable a device on a MPEG-2 network that does=20 > >>> not understand that MRD's signaling/meaning to ignore the new > encapsulation. > >>> > >>> > >>> Of course if the existing network just used private data with out=20 > >>> signaling what it was, a problem may exist. > >>> __________________ > >>> Art Allison > >>> Director, Advanced Engineering > >>> NAB Science & Technology > >>> 1771 N St NW, Washington DC 20036 > >>> 202 429 5418 > >>> -----Original Message----- > >>> From: owner-ipdvb@erg.abdn.ac.uk=20 > >>> [mailto:owner-ipdvb@erg.abdn.ac.uk] > >>> Sent: Wednesday, August 03, 2005 11:32 AM > >>> To: ipdvb@erg.abdn.ac.uk > >>> Subject: Adding ULE into a network already using MPE... > >>> > >>> > >>> Has anyone looked at the operational problems associated with > adding > >>> ULE use to a network which has some deployed terminals which only=20 > >>> understand MPE? > >>> > >>> > >>> John > >>> > >>> > >> > >> > >> > > > > From owner-ipdvb@erg.abdn.ac.uk Thu Aug 04 13:28:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0jVv-0005Ab-Oa for ipdvb-archive@megatron.ietf.org; Thu, 04 Aug 2005 13:28:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25879 for ; Thu, 4 Aug 2005 13:28:12 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0k2q-00029V-QL for ipdvb-archive@ietf.org; Thu, 04 Aug 2005 14:02:17 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j74GreNh005856 for ; Thu, 4 Aug 2005 17:53:40 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j74GreXx005855 for ipdvb-subscribed-users; Thu, 4 Aug 2005 17:53:40 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from [139.133.204.42] (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j74GrZ8U005838 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 4 Aug 2005 17:53:36 +0100 (BST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 04 Aug 2005 18:55:24 +0200 Subject: Re: Adding ULE into a network already using MPE... From: Gorry Fairhurst To: Message-ID: In-Reply-To: <08259490B3BC3140B549DD0907A5644822C552@admsrvnt10.enet.sharplabs.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" X-ERG-MailScanner: Found to be clean, Found to be clean X-MIME-Autoconverted: from quoted-printable to 8bit by erg.abdn.ac.uk id j74GremJ005852 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 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by erg.abdn.ac.uk id j74GreNh005856 X-Spam-Score: 0.0 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Content-Transfer-Encoding: quoted-printable I don't see it this way. On 4/8/05 5:45 pm, "Goldberg, Adam" wrote: > Sure, you can decide to not use the mechanisms already existent in an M= PEG > Transport Stream (B, C), but in doing so you merely cause redesign or > purchase of special-purpose "MPEG" processing devices. Why do you feel auto-detection of the encapsulation ( C ) implies a redes= ign of the MPEG equipment? This is a driver issue only, and orthogonal to supplying SI/PSI signalling. It does not stop a stream sending signalling= as well, or imply it. It provides a way to know that you have got the right encaps. > Make it a Transport Stream. This has very little real overhead, requir= ing > only a PAT and PMT. The PMT is very lightweight but yet can easily sig= nal > which elementary streams (er, "PIDs") are encoded with what protocols. >=20 > This has many advantages: You don't need to reinvent anything (inband > signaling) -- merely an identifying descriptor; you don't have to requi= re > multiplexers and other non-IETF MPEG processing devices do anything spe= cial > (that is to say, you don't require existing MPEG processing devices to = also > process nonstandard IETF things); IETF streams would coexist peacefully= with > non-IETF streams in a Transport Stream; it's very extensible to other > encapsulation formats yet-to-be-defined. I think someone should gather this thread and write one or two paragraphs= to summarise this to include in section 4 of the address resolution document (draft-ietf-ipdvb-ar-00.txt), especially the implications of the PSI/SI o= n the remultiplexing environment. Gorry =20 >=20 > Adam Goldberg > Director, Television Standards & Policy Development > Sharp Laboratories of America > 8605 Westwood Center Drive, Suite 206 > Vienna, VA=A0 22182 > 703-556-4406 > 703-556-4410 fax > 571-276-0305 cell > =A0 >=20 >=20 >> -----Original Message----- >> From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] O= n >> Behalf Of Gorry Fairhurst >> Sent: Thursday, August 04, 2005 3:56 AM >> To: ipdvb@erg.abdn.ac.uk >> Subject: Re: Adding ULE into a network already using MPE... >>=20 >> There ways to do this I can think of three, and I think John you are >> asking >> about C? >>=20 >>=20 >> A) You could parse the SI/PSI signalling (if any) and extract the >> information from there. >>=20 >> B) You could configure it (out of band) or using IP >> configuration/resolution, etc. >>=20 >> C) I once worked through an "auto-detect mode", where you knew the PID= but >> didn't know the type of encapsulation. >>=20 >> ---- >>=20 >> The basic rule is only one type of encapsulation is allowed for a sing= le >> PID. So how can you find out which is used? >>=20 >> I note there is a reasonably strong CRC there in the ULE framing, and = you >> can easily extract framing alignment to the TS from the PUSI setting i= n >> the >> TS header: >>=20 >> (i) Supposing your receiver starts as unconfigured. >>=20 >> (ii) The receiver looks for a PUSI setting and extracts the PP value. >>=20 >> (iii) It then tries reassembly of the first section as a ULE packet. I= f it >> succeeds with a valid CRC-32 and Length, it is probably safe to assume >> this >> is ULE. >>=20 >> (iv) If the CRC fails, it tries a DSM-CC section reassembly (being awa= re >> the >> integrity check is interpreted in more than one way in MPE). The MPE s= tart >> code is also another "hint" that this may not be ULE, but this value >> *could* >> appear as the start of a ULE field - (Note one needs to be aware that = MPE >> and ATSC use different start values). >>=20 >> (v) You could (probably should!!!) verify the next few SNDUs to increa= se >> your confidence, as in any alignment algorithm. It would also be wise= to >> re-initialise the detection if you suffer an alignment failure. This c= ould >> be a result of a change of mutliplexing policy. >>=20 >> Note: This is orthogonal to the generation of SI/PSI tables used to >> control >> the TS multiplexing layer itself. If you use a transport stream >> multiplexor >> as a part of your L2 MPEG transmission network, this may need the SI/P= SI >> to >> allow the PID to reach the Receiver. >>=20 >> Thoughts? >>=20 >> Gorry >>=20 >> On 3/8/05 8:39 pm, "John Border" wrote: >>>=20 >>> I was thinking along those lines. The sender associates the >>> encapsulation method with a particular PID and "knows" (via AR) which >>> PID to use to send to a particular receiver. Receivers which only >>> understand MPE only use MPE PIDs. Receivers which understand ULE and >>> MPE determine which method is being used by which PID is being >>> received. (I think the ULE capable receivers will still need to supp= ort >>> MPE for multicast traffic that is shared with "older" terminals.) >>>=20 >>> I was wondering if there is a way for the receiver to look at the >>> header and determine if it is ULE or MPE on the fly. I haven't taken= a >>> close look at it yet. But, I suspect that it is not reliably > possible... >>>=20 >>> John >>>=20 >>>=20 >>> Marie-Jose Montpetit wrote: >>>=20 >>>> I think this is one thing that could be solved by some of the >>>> configuration work that was started where you could associate a PID = to >>>> an encapsulation. You may not want to ignore the new encapsulation. >>>>=20 >>>> Marie-Jose >>>>=20 >>>>=20 >>>>=20 >>>>> -------- Original Message -------- >>>>> Subject: RE: Adding ULE into a network already using MPE... >>>>> From: "Allison, Art" >>>>> Date: Wed, August 03, 2005 2:05 pm >>>>> To: >>>>>=20 >>>>> Use of the MRD will enable a device on a MPEG-2 network that does n= ot >>>>> understand that MRD's signaling/meaning to ignore the new >> encapsulation. >>>>>=20 >>>>>=20 >>>>> Of course if the existing network just used private data with out >>>>> signaling what it was, a problem may exist. >>>>> __________________ >>>>> Art Allison >>>>> Director, Advanced Engineering >>>>> NAB Science & Technology >>>>> 1771 N St NW, Washington DC 20036 >>>>> 202 429 5418 >>>>> -----Original Message----- >>>>> From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk= ] >>>>> Sent: Wednesday, August 03, 2005 11:32 AM >>>>> To: ipdvb@erg.abdn.ac.uk >>>>> Subject: Adding ULE into a network already using MPE... >>>>>=20 >>>>>=20 >>>>> Has anyone looked at the operational problems associated with >> adding >>>>> ULE use to a network which has some deployed terminals which only >>>>> understand MPE? >>>>>=20 >>>>>=20 >>>>> John >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >=20 >=20 From owner-ipdvb@erg.abdn.ac.uk Thu Aug 04 13:58:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0jyu-0003OP-2V for ipdvb-archive@megatron.ietf.org; Thu, 04 Aug 2005 13:58:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27248 for ; Thu, 4 Aug 2005 13:58:10 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0kVk-0002s0-W2 for ipdvb-archive@ietf.org; Thu, 04 Aug 2005 14:32:14 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j74HmVnZ006962 for ; Thu, 4 Aug 2005 18:48:31 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j74HmVcU006961 for ipdvb-subscribed-users; Thu, 4 Aug 2005 18:48:31 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from smtpout02-03.prod.mesa1.secureserver.net (smtpout02-03.prod.mesa1.secureserver.net [64.202.165.193]) by erg.abdn.ac.uk (8.13.4/8.13.4) with SMTP id j74HmQPh006945 for ; Thu, 4 Aug 2005 18:48:26 +0100 (BST) Received: (qmail 12231 invoked from network); 4 Aug 2005 17:48:19 -0000 Received: from unknown (HELO gem-wbe02.mesa1.secureserver.net) (64.202.189.27) by smtpout02-03.prod.mesa1.secureserver.net with SMTP; 4 Aug 2005 17:48:19 -0000 Received: (qmail 25315 invoked by uid 99); 4 Aug 2005 17:48:19 -0000 Date: Thu, 4 Aug 2005 10:48:19 -0700 From: Marie-Jose Montpetit Subject: RE: Adding ULE into a network already using MPE... To: ipdvb@erg.abdn.ac.uk cc: ipdvb@erg.abdn.ac.uk Message-ID: <20050804104819.ca5566c7162b3cfcb6c200079b757bd6.9d45da7688.wbe@email.email.secureserver.net> 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-Spam-Score: 0.0 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e I agree with Gorry. I think there are many ways of looking at it and there is a trend to design signaling mechanisms that become to certain extent independant of the actual implementation (that can depend on for example if you MPEG steam is DVB, DCII etc) and allow ti include other features (such as QoS) in the auto-detection. But then, I did write a draft on this ;-) /mjm > -------- Original Message -------- > Subject: Re: Adding ULE into a network already using MPE... > From: Gorry Fairhurst > Date: Thu, August 04, 2005 12:55 pm > To: > > I don't see it this way. > > On 4/8/05 5:45 pm, "Goldberg, Adam" wrote: > > > Sure, you can decide to not use the mechanisms already existent in an MPEG > > Transport Stream (B, C), but in doing so you merely cause redesign or > > purchase of special-purpose "MPEG" processing devices. > > Why do you feel auto-detection of the encapsulation ( C ) implies a redesign > of the MPEG equipment? This is a driver issue only, and orthogonal to > supplying SI/PSI signalling. It does not stop a stream sending signalling as > well, or imply it. It provides a way to know that you have got the right > encaps. > > > Make it a Transport Stream. This has very little real overhead, requiring > > only a PAT and PMT. The PMT is very lightweight but yet can easily signal > > which elementary streams (er, "PIDs") are encoded with what protocols. > > > > This has many advantages: You don't need to reinvent anything (inband > > signaling) -- merely an identifying descriptor; you don't have to require > > multiplexers and other non-IETF MPEG processing devices do anything special > > (that is to say, you don't require existing MPEG processing devices to also > > process nonstandard IETF things); IETF streams would coexist peacefully with > > non-IETF streams in a Transport Stream; it's very extensible to other > > encapsulation formats yet-to-be-defined. > > I think someone should gather this thread and write one or two paragraphs to > summarise this to include in section 4 of the address resolution document > (draft-ietf-ipdvb-ar-00.txt), especially the implications of the PSI/SI on > the remultiplexing environment. > > Gorry > > > > > Adam Goldberg > > Director, Television Standards & Policy Development > > Sharp Laboratories of America > > 8605 Westwood Center Drive, Suite 206 > > Vienna, VA 22182 > > 703-556-4406 > > 703-556-4410 fax > > 571-276-0305 cell > > > > > > > >> -----Original Message----- > >> From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On > >> Behalf Of Gorry Fairhurst > >> Sent: Thursday, August 04, 2005 3:56 AM > >> To: ipdvb@erg.abdn.ac.uk > >> Subject: Re: Adding ULE into a network already using MPE... > >> > >> There ways to do this I can think of three, and I think John you are > >> asking > >> about C? > >> > >> > >> A) You could parse the SI/PSI signalling (if any) and extract the > >> information from there. > >> > >> B) You could configure it (out of band) or using IP > >> configuration/resolution, etc. > >> > >> C) I once worked through an "auto-detect mode", where you knew the PID but > >> didn't know the type of encapsulation. > >> > >> ---- > >> > >> The basic rule is only one type of encapsulation is allowed for a single > >> PID. So how can you find out which is used? > >> > >> I note there is a reasonably strong CRC there in the ULE framing, and you > >> can easily extract framing alignment to the TS from the PUSI setting in > >> the > >> TS header: > >> > >> (i) Supposing your receiver starts as unconfigured. > >> > >> (ii) The receiver looks for a PUSI setting and extracts the PP value. > >> > >> (iii) It then tries reassembly of the first section as a ULE packet. If it > >> succeeds with a valid CRC-32 and Length, it is probably safe to assume > >> this > >> is ULE. > >> > >> (iv) If the CRC fails, it tries a DSM-CC section reassembly (being aware > >> the > >> integrity check is interpreted in more than one way in MPE). The MPE start > >> code is also another "hint" that this may not be ULE, but this value > >> *could* > >> appear as the start of a ULE field - (Note one needs to be aware that MPE > >> and ATSC use different start values). > >> > >> (v) You could (probably should!!!) verify the next few SNDUs to increase > >> your confidence, as in any alignment algorithm. It would also be wise to > >> re-initialise the detection if you suffer an alignment failure. This could > >> be a result of a change of mutliplexing policy. > >> > >> Note: This is orthogonal to the generation of SI/PSI tables used to > >> control > >> the TS multiplexing layer itself. If you use a transport stream > >> multiplexor > >> as a part of your L2 MPEG transmission network, this may need the SI/PSI > >> to > >> allow the PID to reach the Receiver. > >> > >> Thoughts? > >> > >> Gorry > >> > >> On 3/8/05 8:39 pm, "John Border" wrote: > >>> > >>> I was thinking along those lines. The sender associates the > >>> encapsulation method with a particular PID and "knows" (via AR) which > >>> PID to use to send to a particular receiver. Receivers which only > >>> understand MPE only use MPE PIDs. Receivers which understand ULE and > >>> MPE determine which method is being used by which PID is being > >>> received. (I think the ULE capable receivers will still need to support > >>> MPE for multicast traffic that is shared with "older" terminals.) > >>> > >>> I was wondering if there is a way for the receiver to look at the > >>> header and determine if it is ULE or MPE on the fly. I haven't taken a > >>> close look at it yet. But, I suspect that it is not reliably > > possible... > >>> > >>> John > >>> > >>> > >>> Marie-Jose Montpetit wrote: > >>> > >>>> I think this is one thing that could be solved by some of the > >>>> configuration work that was started where you could associate a PID to > >>>> an encapsulation. You may not want to ignore the new encapsulation. > >>>> > >>>> Marie-Jose > >>>> > >>>> > >>>> > >>>>> -------- Original Message -------- > >>>>> Subject: RE: Adding ULE into a network already using MPE... > >>>>> From: "Allison, Art" > >>>>> Date: Wed, August 03, 2005 2:05 pm > >>>>> To: > >>>>> > >>>>> Use of the MRD will enable a device on a MPEG-2 network that does not > >>>>> understand that MRD's signaling/meaning to ignore the new > >> encapsulation. > >>>>> > >>>>> > >>>>> Of course if the existing network just used private data with out > >>>>> signaling what it was, a problem may exist. > >>>>> __________________ > >>>>> Art Allison > >>>>> Director, Advanced Engineering > >>>>> NAB Science & Technology > >>>>> 1771 N St NW, Washington DC 20036 > >>>>> 202 429 5418 > >>>>> -----Original Message----- > >>>>> From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] > >>>>> Sent: Wednesday, August 03, 2005 11:32 AM > >>>>> To: ipdvb@erg.abdn.ac.uk > >>>>> Subject: Adding ULE into a network already using MPE... > >>>>> > >>>>> > >>>>> Has anyone looked at the operational problems associated with > >> adding > >>>>> ULE use to a network which has some deployed terminals which only > >>>>> understand MPE? > >>>>> > >>>>> > >>>>> John > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>> > >>> > > > > From owner-ipdvb@erg.abdn.ac.uk Thu Aug 04 14:55:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0ksC-0007dF-Ix for ipdvb-archive@megatron.ietf.org; Thu, 04 Aug 2005 14:55:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29340 for ; Thu, 4 Aug 2005 14:55:18 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0lP7-00043w-Vi for ipdvb-archive@ietf.org; Thu, 04 Aug 2005 15:29:23 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j74Inh0h007978 for ; Thu, 4 Aug 2005 19:49:43 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j74InhEW007977 for ipdvb-subscribed-users; Thu, 4 Aug 2005 19:49:43 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from fmsfmr005.fm.intel.com (fmr15.intel.com [192.55.52.69]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j74InbtS007962 for ; Thu, 4 Aug 2005 19:49:38 +0100 (BST) Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.253.24.20]) by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j74InVZ3001471 for ; Thu, 4 Aug 2005 18:49:31 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j74InVVX010139 for ; Thu, 4 Aug 2005 18:49:31 GMT Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005080411493130841 for ; Thu, 04 Aug 2005 11:49:31 -0700 Received: from fmsmsx404.amr.corp.intel.com ([132.233.42.208]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 Aug 2005 11:49:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Non-IP Protocol Support Date: Thu, 4 Aug 2005 11:49:30 -0700 Content-Type: multipart/signed; boundary="----=_NextPart_000_0028_01C598EA.518F1D30"; micalg=SHA1; protocol="application/x-pkcs7-signature" Message-ID: X-MS-Has-Attach: yes Thread-Topic: Non-IP Protocol Support Thread-Index: AcWY7xbpUlTuTF31Spu4l0wPYtsYWQAM5BbQ From: "Shanbhogue, Vedvyas" To: X-OriginalArrivalTime: 04 Aug 2005 18:49:31.0132 (UTC) FILETIME=[3FB0D3C0:01C59925] X-Scanned-By: MIMEDefang 2.44 X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.9 (/) X-Scan-Signature: 6a817af60e4281a101681ecb646dffff This is a multi-part message in MIME format. ------=_NextPart_000_0028_01C598EA.518F1D30 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0029_01C598EA.518F1D30" ------=_NextPart_001_0029_01C598EA.518F1D30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reading RFC3251 was an electrifying experience :) Since the requirement here is to tunnel a non-IP protocol perhaps there is no need to tunnel ARP over the tunnel. RFC 2784 GRE encapsulation with a few new etherTypes could work. sincerely, Vs -- Vedvyas Shanbhogue SSA, IPD o:(503) 677 - 6409, c:(503) 851 - 2088 _____ From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On Behalf Of West, Mark Sent: Thursday, August 04, 2005 6:24 AM To: ipdvb@erg.abdn.ac.uk Subject: Re: Non-IP Protocol Support Indeed, RFC 3251 may be worth considering :-) But seriously... ... could I not encapsulate ARP, in that case, over multicast IP? It may be that this conversation is a little premature, in that there are other questions about security that aren't directly related to this. But if you can't tunnel stuff over IP to bootstrap, for example, then I'm suspicious of using an IP-based architecture to set-up a non-IP-based security system. (If that makes any sense?!) Cheers, Mark. > > The IETF have defined several foo-over-IP methods which could be used, > and > these should work with ULE (bidirectional IP connectivity may be > required). > PWE3 is by no means the only option. > > However, there are situations were this tunnel over IP approach really > does > not do what may be wanted. ARP for IPv4 is a classic example. If you > wanted > to use arp to resolve an IP to MAC address, then clearly you can't > encapsulate this over IP to send it. > > Gorry > > On 4/8/05 12:40 pm, "West, Mark" wrote: > > > > > A further comment on Juan's point (and something that came up in > > discussion after the ipdvb session, yesterday)... > > > > If there is a security mechanism for IP (e.g. IPsec) and you want to > apply > > that to non-IP flows (e.g. a stream of SNDUs, Ethernet frames, ...) > then > > why not run the non-IP over an emulated pseudo-wire within the IPsec > > tunnel? Then you only need an IP-based security solution. > > > > I honestly don't know whether this is appropriate, but it seemed like > an > > interesting idea at the time! > > > > > (http://www.ietf.org/internet-drafts/draft-ietf-pwe3-iana-allocation-11. > txt > > already has codepoints for Ethernet, etc., but not anything specific > to > > the ipdvb case.) > > > > Cheers, > > > > Mark. > > > > -- > > Mark A. West, Senior Consultant Engineer > > Roke Manor Research Ltd., Romsey, Hants. SO51 0ZN > > Phone +44 (0)1794 833311 Fax +44 (0)1794 833433 > > > > > ------=_NextPart_001_0029_01C598EA.518F1D30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: Non-IP Protocol Support
Reading RFC3251 was an electrifying experience=20 :)
 
Since the requirement here is to tunnel a = non-IP protocol=20 perhaps there is no need to tunnel ARP over the = tunnel.
 
RFC 2784 GRE encapsulation with a few new = etherTypes could=20 work.
 
 

sincerely,
Vs
--
Vedvyas Shanbhogue
SSA,=20 IPD
o:(503) 677 - 6409, c:(503) 851 - 2088

 

From: owner-ipdvb@erg.abdn.ac.uk=20 [mailto:owner-ipdvb@erg.abdn.ac.uk] On Behalf Of West,=20 Mark
Sent: Thursday, August 04, 2005 6:24 AM
To:=20 ipdvb@erg.abdn.ac.uk
Subject: Re: Non-IP Protocol=20 Support


Indeed, RFC 3251 may be worth considering :-) =

But seriously...

... could I not encapsulate ARP, in that case, over = multicast=20 IP?

It may be that this conversation is a little = premature, in that=20 there are
other questions about security that = aren't=20 directly related to this.  But
if you = can't tunnel=20 stuff over IP to bootstrap, for example, then I'm
suspicious of using an IP-based architecture to set-up a=20 non-IP-based
security system.  (If that = makes any=20 sense?!)

Cheers,

Mark.


>
> The IETF have = defined several=20 foo-over-IP methods which could be used,
> = and=20
> these should work with ULE (bidirectional IP = connectivity=20 may be
> required).
> PWE3=20 is by no means the only option.
> =
> However, there are situations were this tunnel over IP = approach=20 really
> does
> not do=20 what may be wanted. ARP for IPv4 is a classic example. If you =
> wanted
> to use arp to = resolve an IP to=20 MAC address, then clearly you can't
> = encapsulate=20 this over IP to send it.
>
> Gorry
>
> On=20 4/8/05 12:40 pm, "West, Mark" <mark.a.west@roke.co.uk> = wrote:=20
>
> > =
> > A further comment on Juan's point (and something that = came up=20 in
> > discussion after the ipdvb = session,=20 yesterday)...
> >
>=20 > If there is a security mechanism for IP (e.g. IPsec) and you want = to=20
> apply
> > that = to non-IP=20 flows (e.g. a stream of SNDUs, Ethernet frames, ...)
> then
> > why not run the = non-IP over=20 an emulated pseudo-wire within the IPsec
> = >=20 tunnel?  Then you only need an IP-based security solution. =
> >
> > I honestly don't = know whether=20 this is appropriate, but it seemed like
> = an=20
> > interesting idea at the time! =
> >
> >
>=20 (http://www.ietf.org/internet-drafts/draft-ietf-pwe3-iana-allocatio= n-11.=20
> txt
> > already = has=20 codepoints for Ethernet, etc., but not anything specific =
> to
> > the ipdvb = case.)=20
> >
> > = Cheers,=20
> >
> > = Mark.=20
> >
> > = --
> > Mark A. West, Senior Consultant Engineer =
> > Roke Manor Research Ltd., Romsey, Hants.  SO51 = 0ZN=20
> > Phone +44 (0)1794 833311   = Fax  +44=20 (0)1794 833433
> >
>
>
>=20

------=_NextPart_001_0029_01C598EA.518F1D30-- ------=_NextPart_000_0028_01C598EA.518F1D30 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIInuzCCB3Qw ggZcoAMCAQICCmEiIAUAAAAAAAgwDQYJKoZIhvcNAQEFBQAwgZ8xHDAaBgkqhkiG9w0BCQEWDXBr aUBpbnRlbC5jb20xCzAJBgNVBAYTAlVTMRAwDgYDVQQIEwdBcml6b25hMREwDwYDVQQHEwhDaGFu ZGxlcjEaMBgGA1UEChMRSW50ZWwgQ29ycG9yYXRpb24xCzAJBgNVBAsTAklUMSQwIgYDVQQDExtJ bnRlbCBFbnRlcnByaXNlIEJhc2ljUENBLTEwHhcNMDIxMjA1MTczMzEwWhcNMDcxMjA1MjAwMzEw WjCB3jEcMBoGCSqGSIb3DQEJARYNcGtpQGludGVsLmNvbTELMAkGA1UEBhMCVVMxCzAJBgNVBAgT AkNBMQ8wDQYDVQQHEwZGb2xzb20xGjAYBgNVBAoTEUludGVsIENvcnBvcmF0aW9uMT0wOwYDVQQL EzRJbmZvcm1hdGlvbiBUZWNobm9sb2d5IEVudGVycHJpc2UgQnVzaW5lc3MgQ29tcHV0aW5nMTgw NgYDVQQDEy9JbnRlbCBDb3Jwb3JhdGlvbiBCYXNpYyBFbnRlcnByaXNlIElzc3VpbmcgQ0EgMTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALRzs//JBB6y7FN9ze2a6ZnEiX+/YfyQ5g6X GgGxwP87tRqPnZU14W2s0L6q8oWfwi7Dc9Xmns5gYZdQweDEklOjYA9C5ixEFZ3joXUxPsuMAYUt PT8BDzyq9zdsee4c6rqQ1kPEnqtiJc/VlU1kK2zpgXahXy4TpjjVsiz2L5zJ8amT5VdGuSHs3Hz4 Ng6+jw9WQGExJnxYcGNDZMYP45e2VAw1gVZK1bXw7xlM/vcrkx0Lu43dZQc2SXImg2GuJ/5R7iuX EpTsaKDOkjIN+Q6JAGHeQ/2a3mpZOwCF+fSD9Nqcj9AS5u5N0xtsfR/UrOazRrWBa1lOWxaD0/Ph FrcCAwEAAaOCA28wggNrMBAGCSsGAQQBgjcVAQQDAgEAMB0GA1UdDgQWBBSoM2ug7tAG6zllMHb7 U4Phawje/jALBgNVHQ8EBAMCAcYwDwYDVR0TAQH/BAUwAwEB/zCB0wYDVR0jBIHLMIHIgBTKIc61 FcEg45pP/hywTm0mQlxHtaGBo6SBoDCBnTEcMBoGCSqGSIb3DQEJARYNcGtpQGludGVsLmNvbTEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0FyaXpvbmExETAPBgNVBAcTCENoYW5kbGVyMRowGAYDVQQK ExFJbnRlbCBDb3Jwb3JhdGlvbjELMAkGA1UECxMCSVQxIjAgBgNVBAMTGUludGVsIEVudGVycHJp c2UgUm9vdENBLTGCCmErj20AAAAAAAQwggEeBgNVHR8EggEVMIIBETCB1qCB06CB0IaBzWxkYXA6 Ly8vQ049SW50ZWwlMjBFbnRlcnByaXNlJTIwQmFzaWNQQ0EtMSxDTj1QQ0EtQkEwMSxDTj1DRFAs Q049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixE Qz1jb3JwLERDPWludGVsLERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2Jq ZWN0Y2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnQwNqA0oDKGMGh0dHA6Ly93d3cuaW50ZWwuY29t L3JlcG9zaXRvcnkvQ1JML1BDQS1CQS0xLmNybDCCASAGCCsGAQUFBwEBBIIBEjCCAQ4wgcQGCCsG AQUFBzAChoG3bGRhcDovLy9DTj1JbnRlbCUyMEVudGVycHJpc2UlMjBCYXNpY1BDQS0xLENOPUFJ QSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9u LERDPWNvcnAsREM9aW50ZWwsREM9Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RjbGFzcz1j ZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MEUGCCsGAQUFBzAChjlodHRwOi8vd3d3LmludGVsLmNvbS9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlcy9QQ0EtQkEtMS5jcnQwDQYJKoZIhvcNAQEFBQADggEBAKo+ KVd0DYrX6k2Tq7dypUOYLKlvfZ/VYYZbseNBEOGVYRbFMARyHYJLnWDe5YP/bGaPTolEh7HgmW9r MLzgq4CJjqN61zYPrkeRWX9krbhD9+4cB1KklxjbGT/LzPxEjPj/e40z06k1gColzPTk0nepKxUK 56P0XYWYSGRvMmprgO0cWQ/eUSG2ax6CyOQbmK4FM73MFuzmXm2yIZLm0TiMJd6kCRgWHGPCWRKZ hFf8uioRbWCV9kUzUT3aGPAqm9vKSM47yGWf17mjthdQ2WhHPjt06sjkyhdVu4V+ni/OaBx2IB6s /WhlhSTJMsp6otUjtO+ne+i1brThVv1bOCYwggetMIIGlaADAgECAgpca44hAAAAACiaMA0GCSqG SIb3DQEBBQUAMIHeMRwwGgYJKoZIhvcNAQkBFg1wa2lAaW50ZWwuY29tMQswCQYDVQQGEwJVUzEL MAkGA1UECBMCQ0ExDzANBgNVBAcTBkZvbHNvbTEaMBgGA1UEChMRSW50ZWwgQ29ycG9yYXRpb24x PTA7BgNVBAsTNEluZm9ybWF0aW9uIFRlY2hub2xvZ3kgRW50ZXJwcmlzZSBCdXNpbmVzcyBDb21w dXRpbmcxODA2BgNVBAMTL0ludGVsIENvcnBvcmF0aW9uIEJhc2ljIEVudGVycHJpc2UgSXNzdWlu ZyBDQSAxMB4XDTA1MDUwNjE5MzgyOVoXDTA2MDUwNjE5MzgyOVowgbQxEzARBgoJkiaJk/IsZAEZ FgNjb20xFTATBgoJkiaJk/IsZAEZFgVpbnRlbDEUMBIGCgmSJomT8ixkARkWBGNvcnAxEzARBgoJ kiaJk/IsZAEZFgNhbXIxEDAOBgNVBAsTB1dvcmtlcnMxHDAaBgNVBAMTE1NoYW5iaG9ndWUsIFZl ZHZ5YXMxKzApBgkqhkiG9w0BCQEWHHZlZHZ5YXMuc2hhbmJob2d1ZUBpbnRlbC5jb20wgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBANI0Asmqf+7mfxBtZfyIWKbPPZNKVDYO7reJkCDThPn6u8E6 GWUVLPJbZHRZPobe27vKQL3YhBDZOHRTimMMzchktSwSBWT1yoFlPEYmp8Y5s2XMMHP832vtOxSJ ukFCUup65dOMKSEHALziB8iy9PqMKOY9oPOfuCDmloVmHNSrAgMBAAGjggQXMIIEEzALBgNVHQ8E BAMCB4AwHQYDVR0OBBYEFHq+OETujYgbtQ2Gfk1fZlgzWDQ3MDwGCSsGAQQBgjcVBwQvMC0GJSsG AQQBgjcVCIbDjHWEmeVRg/2BKIWOn1OCkcAJZ4HevTmV8EMCAWQCAQIwHwYDVR0jBBgwFoAUqDNr oO7QBus5ZTB2+1OD4WsI3v4wggFuBgNVHR8EggFlMIIBYTCCAV2gggFZoIIBVYaB7WxkYXA6Ly8v Q049SW50ZWwlMjBDb3Jwb3JhdGlvbiUyMEJhc2ljJTIwRW50ZXJwcmlzZSUyMElzc3VpbmclMjBD QSUyMDEsQ049UEtJQkFFTlRDQTAxLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWNvcnAsREM9aW50ZWwsREM9Y29tP2NlcnRp ZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2lu dIZjaHR0cDovL3d3dy5pbnRlbC5jb20vcmVwb3NpdG9yeS9DUkwvSW50ZWwlMjBDb3Jwb3JhdGlv biUyMEJhc2ljJTIwRW50ZXJwcmlzZSUyMElzc3VpbmclMjBDQSUyMDEuY3JsMIIBbwYIKwYBBQUH AQEEggFhMIIBXTCB4AYIKwYBBQUHMAKGgdNsZGFwOi8vL0NOPUludGVsJTIwQ29ycG9yYXRpb24l MjBCYXNpYyUyMEVudGVycHJpc2UlMjBJc3N1aW5nJTIwQ0ElMjAxLENOPUFJQSxDTj1QdWJsaWMl MjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWNvcnAsREM9 aW50ZWwsREM9Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9u QXV0aG9yaXR5MHgGCCsGAQUFBzAChmxodHRwOi8vd3d3LmludGVsLmNvbS9yZXBvc2l0b3J5L2Nl cnRpZmljYXRlcy9JbnRlbCUyMENvcnBvcmF0aW9uJTIwQmFzaWMlMjBFbnRlcnByaXNlJTIwSXNz dWluZyUyMENBJTIwMS5jcnQwHwYDVR0lBBgwFgYIKwYBBQUHAwQGCisGAQQBgjcKAwwwKQYJKwYB BAGCNxUKBBwwGjAKBggrBgEFBQcDBDAMBgorBgEEAYI3CgMMMFUGA1UdEQROMEygLAYKKwYBBAGC NxQCA6AeDBx2ZWR2eWFzLnNoYW5iaG9ndWVAaW50ZWwuY29tgRx2ZWR2eWFzLnNoYW5iaG9ndWVA aW50ZWwuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCrmlMRX4tR0QrqicYAamWQ9spAU1PIgD4h3+A8 G8Kjef/70YPtUsychs71jVa/PTXTCMdwt5EuPP5w75oeuc/PLb9HFbdREWxDjJjgZ5A6u2440mnm TwAecoF4Lso2/mKn25SA4CUCwqycKV/y28PXNla0nWN+05YyOOS1aMippyeQqKR04j/40ZafSf3d 2XzGBfITZz2HlJKkWqS7S1+jFvPaojE9VssUXCVUAYkTdq4QJLrpRp0yjnMo8nCFS5KdsJSeN8Q/ ep1/x1E/GZWO9gC8C5LuUJpuj/ZDl3UnGRluOGwDrzVo5YZE46f3dYrigIYzQOnN27zZtOuCc67E MIIH9DCCBtygAwIBAgIKXG1+9AAAAAAomzANBgkqhkiG9w0BAQUFADCB3jEcMBoGCSqGSIb3DQEJ ARYNcGtpQGludGVsLmNvbTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMQ8wDQYDVQQHEwZGb2xz b20xGjAYBgNVBAoTEUludGVsIENvcnBvcmF0aW9uMT0wOwYDVQQLEzRJbmZvcm1hdGlvbiBUZWNo bm9sb2d5IEVudGVycHJpc2UgQnVzaW5lc3MgQ29tcHV0aW5nMTgwNgYDVQQDEy9JbnRlbCBDb3Jw b3JhdGlvbiBCYXNpYyBFbnRlcnByaXNlIElzc3VpbmcgQ0EgMTAeFw0wNTA1MDYxOTQwMzZaFw0w NjA1MDYxOTQwMzZaMIG0MRMwEQYKCZImiZPyLGQBGRYDY29tMRUwEwYKCZImiZPyLGQBGRYFaW50 ZWwxFDASBgoJkiaJk/IsZAEZFgRjb3JwMRMwEQYKCZImiZPyLGQBGRYDYW1yMRAwDgYDVQQLEwdX b3JrZXJzMRwwGgYDVQQDExNTaGFuYmhvZ3VlLCBWZWR2eWFzMSswKQYJKoZIhvcNAQkBFhx2ZWR2 eWFzLnNoYW5iaG9ndWVAaW50ZWwuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCpMw8I td6XeAA6setzNmwhveNm/KDB6x49a9+og/C1s9H240ZGYkw97jjsMDb3mcYAXsiBt1AD+cpW95tb F9YqodK8ELIspJ0Fb8D3rrQR00OR3bddbd1Uf8DbKo/SKFInPEhlALnEGjEtZGhG9grTy6UA1wld mdoAeezX0BF0dQIDAQABo4IEXjCCBFowCwYDVR0PBAQDAgUgMEQGCSqGSIb3DQEJDwQ3MDUwDgYI KoZIhvcNAwICAgCAMA4GCCqGSIb3DQMEAgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNVHQ4E FgQU9hUi1rRJcmVDGbRccLtZ088UEuIwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIhsOMdYSZ 5VGD/YEohY6fU4KRwAlngfTVWYa0gVUCAWQCAQMwHwYDVR0jBBgwFoAUqDNroO7QBus5ZTB2+1OD 4WsI3v4wggFuBgNVHR8EggFlMIIBYTCCAV2gggFZoIIBVYaB7WxkYXA6Ly8vQ049SW50ZWwlMjBD b3Jwb3JhdGlvbiUyMEJhc2ljJTIwRW50ZXJwcmlzZSUyMElzc3VpbmclMjBDQSUyMDEsQ049UEtJ QkFFTlRDQTAxLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxD Tj1Db25maWd1cmF0aW9uLERDPWNvcnAsREM9aW50ZWwsREM9Y29tP2NlcnRpZmljYXRlUmV2b2Nh dGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIZjaHR0cDovL3d3 dy5pbnRlbC5jb20vcmVwb3NpdG9yeS9DUkwvSW50ZWwlMjBDb3Jwb3JhdGlvbiUyMEJhc2ljJTIw RW50ZXJwcmlzZSUyMElzc3VpbmclMjBDQSUyMDEuY3JsMIIBbwYIKwYBBQUHAQEEggFhMIIBXTCB 4AYIKwYBBQUHMAKGgdNsZGFwOi8vL0NOPUludGVsJTIwQ29ycG9yYXRpb24lMjBCYXNpYyUyMEVu dGVycHJpc2UlMjBJc3N1aW5nJTIwQ0ElMjAxLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2 aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWNvcnAsREM9aW50ZWwsREM9Y29t P2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MHgG CCsGAQUFBzAChmxodHRwOi8vd3d3LmludGVsLmNvbS9yZXBvc2l0b3J5L2NlcnRpZmljYXRlcy9J bnRlbCUyMENvcnBvcmF0aW9uJTIwQmFzaWMlMjBFbnRlcnByaXNlJTIwSXNzdWluZyUyMENBJTIw MS5jcnQwHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYIKwYBBQUHAwQwKQYJKwYBBAGCNxUKBBwwGjAM BgorBgEEAYI3CgMEMAoGCCsGAQUFBwMEMFUGA1UdEQROMEygLAYKKwYBBAGCNxQCA6AeDBx2ZWR2 eWFzLnNoYW5iaG9ndWVAaW50ZWwuY29tgRx2ZWR2eWFzLnNoYW5iaG9ndWVAaW50ZWwuY29tMA0G CSqGSIb3DQEBBQUAA4IBAQBBs16Sz9j2TsH6jWJ8L+p4dRno0DlbEdpan+ZreI1DqB+tQLQVUufv 5c9HPXmAcckyw9IA8nHDZDrfA3BgPAgY6cgtrIdJYn1JIFFhw5VutFEji/k+VgznxBAp8PHtUx7F m1gGCNOvB7j8dOOQRNAuuy/wdd8jaf6cFK2a52FUXCBFr40+8wFFBzoLMcKwpVnoT8JIxugcO/z1 zgHiYoKBVWVQsJXiNDXCNsAw41Zlctsi4+3Hh5V/R5RlxD+6N+8Y9IHxi6QwA7AkMMmB2/2lfdlV ZApi1Xzj9R12+iM9j0Ch9QBN+TR1lJW/0Mmj0yaGmowqIdWdAo49HWFrT/54MIIINTCCBh2gAwIB AgIKYSuPbQAAAAAABDANBgkqhkiG9w0BAQUFADCBnTEcMBoGCSqGSIb3DQEJARYNcGtpQGludGVs LmNvbTELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0FyaXpvbmExETAPBgNVBAcTCENoYW5kbGVyMRow GAYDVQQKExFJbnRlbCBDb3Jwb3JhdGlvbjELMAkGA1UECxMCSVQxIjAgBgNVBAMTGUludGVsIEVu dGVycHJpc2UgUm9vdENBLTEwHhcNMDEwOTI4MTcyMTU4WhcNMTEwOTI4MTk1MTU4WjCBnzEcMBoG CSqGSIb3DQEJARYNcGtpQGludGVsLmNvbTELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0FyaXpvbmEx ETAPBgNVBAcTCENoYW5kbGVyMRowGAYDVQQKExFJbnRlbCBDb3Jwb3JhdGlvbjELMAkGA1UECxMC SVQxJDAiBgNVBAMTG0ludGVsIEVudGVycHJpc2UgQmFzaWNQQ0EtMTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAKzESuSWA+XzEfquJYlavTsSNO6k9KX+L9fIlAc0v5xn6f6Ab1Y1R3p1 3Dqz/qW5DzQhEeO7n6GRSgeIGu0c5Q0YTywfs0xJ8r/9U4XyRBVcxJ61NkqYYVveAfOzBIq8Hn0g GeBCFtRVgnV+z86U3F++jltC71NypUlrgOrVJRltVP+C0ZCtZVu7xDV7i/KOs03D90juYnYbL3e6 waGlXfrVUrgdChwTMx0vG6wCN0wd9i8fFo8tZmKzBSZkGttYQ3zIV2DsRB8SgYpnG24saSnNVUpK 0MiLs3v0RckcTWs9H8/SCVPEGNEj4dDWsbrT4imEMKpidsh8yEVdk2i3g6ECAwEAAaOCA3EwggNt MBAGCSsGAQQBgjcVAQQDAgEAMB0GA1UdDgQWBBTKIc61FcEg45pP/hywTm0mQlxHtTALBgNVHQ8E BAMCAcYwDwYDVR0TAQH/BAUwAwEB/zCB2QYDVR0jBIHRMIHOgBQnJSVoUi44RDokLgR1Qrm1i00H nKGBo6SBoDCBnTEcMBoGCSqGSIb3DQEJARYNcGtpQGludGVsLmNvbTELMAkGA1UEBhMCVVMxEDAO BgNVBAgTB0FyaXpvbmExETAPBgNVBAcTCENoYW5kbGVyMRowGAYDVQQKExFJbnRlbCBDb3Jwb3Jh dGlvbjELMAkGA1UECxMCSVQxIjAgBgNVBAMTGUludGVsIEVudGVycHJpc2UgUm9vdENBLTGCEBXw jVP2WJG1Sv7f4GM5hoowggEcBgNVHR8EggETMIIBDzCB1KCB0aCBzoaBy2xkYXA6Ly8vQ049SW50 ZWwlMjBFbnRlcnByaXNlJTIwUm9vdENBLTEsQ049Uk9PVENBMDEsQ049Q0RQLENOPVB1YmxpYyUy MEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9Y29ycCxEQz1p bnRlbCxEQz1jb20/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdGNsYXNzPWNS TERpc3RyaWJ1dGlvblBvaW50MDagNKAyhjBodHRwOi8vd3d3LmludGVsLmNvbS9yZXBvc2l0b3J5 L0NSTC9Sb290Q0EtMS5jcmwwggEeBggrBgEFBQcBAQSCARAwggEMMIHCBggrBgEFBQcwAoaBtWxk YXA6Ly8vQ049SW50ZWwlMjBFbnRlcnByaXNlJTIwUm9vdENBLTEsQ049QUlBLENOPVB1YmxpYyUy MEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9Y29ycCxEQz1p bnRlbCxEQz1jb20/Y0FDZXJ0aWZpY2F0ZT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25B dXRob3JpdHkwRQYIKwYBBQUHMAKGOWh0dHA6Ly93d3cuaW50ZWwuY29tL3JlcG9zaXRvcnkvY2Vy dGlmaWNhdGVzL1Jvb3RDQS0xLmNydDANBgkqhkiG9w0BAQUFAAOCAgEAVhG35QP2HRYNjurURs+D Ybh9+iVHt0d0HZK3LhKjUrGfKrhTmhoWBTM1ofEx6mi+K8eISgrLIOBFDXsdNj9SzgKAMJG8vNhM zmx/8phUEqKJSGJaEEQzM4R29lZq+3y7AlFGGcLUOYkZsUzRH7oJflIF9jj83zAgmkjAjkAVgjY7 fPcTMRJTRzrsHuH10L/btmYcxHJwbaBjUK9D7eZgotZmloQkU42knyWPLAUvJm9cqfEPdNFrvymL ygEk57ZJqrBw7Cmq9E3l8csZxTEgqN5IpsV+MrQDkZ76Uxyl+w9A4nc0JJkymgFBHpA/khpiu7SR 9S1jh4zwuGgZ805LPw/29Wmc2m4fX858bNxPs3HxvK9UeRH/Q4tprt3ciWXQvVplRBrMDLzSMyhB sl5bzncHIAk4soRKznQZldW1FrheSFxGb3OOAIJBKMgBFFsJlz4vt2D8yxBjwPgCDrSPkVXM4Uij j8yDN9iuuHTCSOAs2wZACoZSLrK2QQSTkDOOZRic9b3G4mWrk8vvH0/qjEw4dR+KLGtFRYfPzL7o Zc0DX1y66D6ram1GrN/ik05/nwpfabLU88CdVLHbwwmLXzkIRYLtEGuOhZyhxXiVnF4ScIiiY0kY Cs4wb5pLghgo7PJXtatN5orqWfI9qJ8iqaZCa+AAfkCoSNuvzB6lj7QwgghdMIIGRaADAgECAhAV 8I1T9liRtUr+3+BjOYaKMA0GCSqGSIb3DQEBBQUAMIGdMRwwGgYJKoZIhvcNAQkBFg1wa2lAaW50 ZWwuY29tMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHQXJpem9uYTERMA8GA1UEBxMIQ2hhbmRsZXIx GjAYBgNVBAoTEUludGVsIENvcnBvcmF0aW9uMQswCQYDVQQLEwJJVDEiMCAGA1UEAxMZSW50ZWwg RW50ZXJwcmlzZSBSb290Q0EtMTAeFw0wMTA5MjcxNjM5NDZaFw0yMTA5MjcxNjQ2MDhaMIGdMRww GgYJKoZIhvcNAQkBFg1wa2lAaW50ZWwuY29tMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHQXJpem9u YTERMA8GA1UEBxMIQ2hhbmRsZXIxGjAYBgNVBAoTEUludGVsIENvcnBvcmF0aW9uMQswCQYDVQQL EwJJVDEiMCAGA1UEAxMZSW50ZWwgRW50ZXJwcmlzZSBSb290Q0EtMTCCAiIwDQYJKoZIhvcNAQEB BQADggIPADCCAgoCggIBAN1HNPQsrZrH8RoEv3xCXSaE/FzV3uQy5QvX6JvynkBtviIU0kYXC3zc zjTQISrrklnpDHOeQ8Zr/fW72zSD9J3ZVvuqDtFuFVlv9KQ0MBQARLzqKkxfuykXDdF5FuVDzSAN 7jpaXl9HBlfY5X9AaQXjJQzt6FCY1kVERO3cllueeq9jMI+JrMky/jjRwNKRoWX/L6qbnaKFO+0s AMn/JcSTCD8Vwn+VNlt0LXzFD5neMvW5PS1bSYdYK7tDhj1JLcYJBDAgeObtT/H1bfdDHPlEtu/n hF146DN5AgdKQRlCP4ISeg+YucLRegLr3ohu8FaykscqCdRU0ziP7mwi2n+yYla/Xpujirdcsj0t YwvGAyN3mZTP7U5s12mi1qhPD68mpoQWxwa78XyyVf8CMq1g0ZsJZg1yX+4TfzS6fTEyKqtQ/PWC aRCZ+pJ4lVocVqk2/+ZgmyANacuBaou/K80P9p6X7Ny1La0DI2g0bLz5TrFhVqa4Vi+aQPJ7UYkG DxoB1fiyGpzyfI0hQj1u0MuDb4QYzlvn5KdrQIC0F2mA3UlCoJTgLL55doq0JIJN7TC/XPK1b1Ud 5bjcJA6MV+at3DD1pMhIhFExmXa1JP3Y5X4lWmhb/Hotrls7+ryNS//+t/m1+H0uqsEwOn3EATBA ez4M7hdgOltXH1nmDdUnAgMBAAGjggKVMIICkTALBgNVHQ8EBAMCAcYwDwYDVR0TAQH/BAUwAwEB /zAdBgNVHQ4EFgQUJyUlaFIuOEQ6JC4EdUK5tYtNB5wwggEcBgNVHR8EggETMIIBDzCB1KCB0aCB zoaBy2xkYXA6Ly8vQ049SW50ZWwlMjBFbnRlcnByaXNlJTIwUm9vdENBLTEsQ049Uk9PVENBMDEs Q049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3Vy YXRpb24sREM9Y29ycCxEQz1pbnRlbCxEQz1jb20/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9i YXNlP29iamVjdGNsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MDagNKAyhjBodHRwOi8vd3d3Lmlu dGVsLmNvbS9yZXBvc2l0b3J5L0NSTC9Sb290Q0EtMS5jcmwwEAYJKwYBBAGCNxUBBAMCAQAwggEe BggrBgEFBQcBAQSCARAwggEMMIHCBggrBgEFBQcwAoaBtWxkYXA6Ly8vQ049SW50ZWwlMjBFbnRl cnByaXNlJTIwUm9vdENBLTEsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNl cnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9Y29ycCxEQz1pbnRlbCxEQz1jb20/Y0FDZXJ0aWZp Y2F0ZT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwRQYIKwYBBQUHMAKG OWh0dHA6Ly93d3cuaW50ZWwuY29tL3JlcG9zaXRvcnkvY2VydGlmaWNhdGVzL1Jvb3RDQS0xLmNy dDANBgkqhkiG9w0BAQUFAAOCAgEA1MJmXSwjbtKcLxOCe9Ti3KnxZ9CSd+nkgiWAE8vKgVJCd+U9 jtdhvPdhTje5WAO5+bz3m6HjH5n5QVA79C9mRLlahh3u0BfiGWBJ5qjnUwOdE0OFUObPZDj3vRyJ BF1umuHW7Uj6ypInstgYsNUKFbd/fd4iqCD6Z76ij8gbHi6anv/Bra/bAyEJqL5Bgy8qBnpvPScc zWRSVi5dJgwWQTam1Yn6RpIgjWaar5uOFarQWh3fdcbHuwP2dhxwFaRHY8a0V50WSrC+v3tKrJCI out+6hzShFH9jnBwB0+Cjacb3M/tLl1rdqoclY0bvzwsi9/6XPjCHLvzSqjVjleeiNsTD51AODHH QO7UIDYRpGAIi9hubV+JpbITzr14cf9XQOyf/RAols1LnAK39U+c2HgUUaxWcMGcySzrmvJP49qg KPxmxjH871HMF7VSOjebMx5Gjnd1TIXK/kINY33Smx500U4lgoplzlVHNy9FVRdypNwv0oIjQVHd MhL/Wxi6PYLDY9tCwd/XOXLMn2OE7UH+cwSJ+Ww2NejmkLNzEahc+USw8WWBNcsmhv5oWF3CpBOC Ojgk/HpIZR3K761lKWuWTbgy6L5yH2ihY91dVSSlrZSpju7L3IL78FAEQDMuh6x24bA4K6UClNto hYPRCYNeVA2bGMOuCfqB7CjUdt4xggRjMIIEXwIBATCB7TCB3jEcMBoGCSqGSIb3DQEJARYNcGtp QGludGVsLmNvbTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMQ8wDQYDVQQHEwZGb2xzb20xGjAY BgNVBAoTEUludGVsIENvcnBvcmF0aW9uMT0wOwYDVQQLEzRJbmZvcm1hdGlvbiBUZWNobm9sb2d5 IEVudGVycHJpc2UgQnVzaW5lc3MgQ29tcHV0aW5nMTgwNgYDVQQDEy9JbnRlbCBDb3Jwb3JhdGlv biBCYXNpYyBFbnRlcnByaXNlIElzc3VpbmcgQ0EgMQIKXGuOIQAAAAAomjAJBgUrDgMCGgUAoIIC yzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTA4MDQxODQ3NDBa MCMGCSqGSIb3DQEJBDEWBBQndEuBm0oCUwDuRhSDmByC3RMqEzBnBgkqhkiG9w0BCQ8xWjBYMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCB/gYJKwYBBAGCNxAEMYHwMIHtMIHeMRwwGgYJ KoZIhvcNAQkBFg1wa2lAaW50ZWwuY29tMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExDzANBgNV BAcTBkZvbHNvbTEaMBgGA1UEChMRSW50ZWwgQ29ycG9yYXRpb24xPTA7BgNVBAsTNEluZm9ybWF0 aW9uIFRlY2hub2xvZ3kgRW50ZXJwcmlzZSBCdXNpbmVzcyBDb21wdXRpbmcxODA2BgNVBAMTL0lu dGVsIENvcnBvcmF0aW9uIEJhc2ljIEVudGVycHJpc2UgSXNzdWluZyBDQSAxAgpcbX70AAAAACib MIIBAAYLKoZIhvcNAQkQAgsxgfCgge0wgd4xHDAaBgkqhkiG9w0BCQEWDXBraUBpbnRlbC5jb20x CzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTEPMA0GA1UEBxMGRm9sc29tMRowGAYDVQQKExFJbnRl bCBDb3Jwb3JhdGlvbjE9MDsGA1UECxM0SW5mb3JtYXRpb24gVGVjaG5vbG9neSBFbnRlcnByaXNl IEJ1c2luZXNzIENvbXB1dGluZzE4MDYGA1UEAxMvSW50ZWwgQ29ycG9yYXRpb24gQmFzaWMgRW50 ZXJwcmlzZSBJc3N1aW5nIENBIDECClxtfvQAAAAAKJswDQYJKoZIhvcNAQEBBQAEgYBEL/feGM/w z1eKcDh4vZo8q16WbK9PLFmtOAolIbNh2X+9YiQElEKGxQ1SV5+uWispgMrHm9xK0duY7zt3q5vP pwpR8c1hBzn3PfZiHXDEng+pk14zZDXKL+x8UC3L38RnbUSzre/KKas6ogvGzn0VuHeqKbJEVzyj 228/948UkwAAAAAAAA== ------=_NextPart_000_0028_01C598EA.518F1D30-- From owner-ipdvb@erg.abdn.ac.uk Thu Aug 04 14:57:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0kuI-000868-CB for ipdvb-archive@megatron.ietf.org; Thu, 04 Aug 2005 14:57:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29492 for ; Thu, 4 Aug 2005 14:57:28 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0lRE-00048k-7t for ipdvb-archive@ietf.org; Thu, 04 Aug 2005 15:31:33 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j74IqLfP008059 for ; Thu, 4 Aug 2005 19:52:21 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j74IqLrn008058 for ipdvb-subscribed-users; Thu, 4 Aug 2005 19:52:21 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from sharplabs.com (keymaster.sharplabs.com [216.65.151.107]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j74IpW9g008039 for ; Thu, 4 Aug 2005 19:51:33 +0100 (BST) Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j74IpPmE024674 for ; Thu, 4 Aug 2005 11:51:25 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Thu, 4 Aug 2005 11:52:52 -0700 Message-ID: <08259490B3BC3140B549DD0907A5644822C564@admsrvnt10.enet.sharplabs.com> From: "Goldberg, Adam" To: ipdvb@erg.abdn.ac.uk Subject: RE: Adding ULE into a network already using MPE... Date: Thu, 4 Aug 2005 11:52:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-ERG-MailScanner: Found to be clean, Found to be clean X-MIME-Autoconverted: from quoted-printable to 8bit by erg.abdn.ac.uk id j74IqLx0008055 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 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by erg.abdn.ac.uk id j74IqLfP008059 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3f2cf88677bfbdeff30feb2c80e2257d Content-Transfer-Encoding: quoted-printable I see it rather simply: consider an environment with a mix of non-IETF-aw= are devices (widely available MPEG-transport-processing devices, like multiplexers, remultiplexers, rate shapers, ad insertion equipment, etc e= tc) - call this set "A" - and IETF-aware devices (couldn't name one, but you probably have something in mind) - call this set "B". If you signal the existence of IETF steams in a MPEG Transport Stream compliant manner (that is, via PMT entries), then every device in "A" wil= l autorecognize that those steams exist, and even if they don't know what t= hey are or what to do with them, will pass them through the system. Also, of course, devices in "B" will work, too. If you signal the existence of IETF streams in some other manner, either = by well-known PID values, or "out of band" signaling or some prearrangement = or whatever, then every device in "B" will work ... and a large proportion o= f devices in "A" will IMMEDIATELY DROP ALL OF THOSE PACKETS AND NOT PASS TH= EM THROUGH. Seems a clear choice to me. But feel free to design a private system tha= t requires all entirely new infrastructure hardware. It'll be much less useful. Adam Goldberg Director, Television Standards & Policy Development Sharp Laboratories of America 8605 Westwood Center Drive, Suite 206 Vienna, VA=A0 22182 703-556-4406 703-556-4410 fax 571-276-0305 cell =A0 > -----Original Message----- > From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On > Behalf Of Marie-Jose Montpetit > Sent: Thursday, August 04, 2005 1:48 PM > To: ipdvb@erg.abdn.ac.uk > Cc: ipdvb@erg.abdn.ac.uk > Subject: RE: Adding ULE into a network already using MPE... >=20 > I agree with Gorry. I think there are many ways of looking at it and > there is a trend to design signaling mechanisms that become to certain > extent independant of the actual implementation (that can depend on for > example if you MPEG steam is DVB, DCII etc) and allow ti include other > features (such as QoS) in the auto-detection. >=20 > But then, I did write a draft on this ;-) >=20 > /mjm >=20 > > -------- Original Message -------- > > Subject: Re: Adding ULE into a network already using MPE... > > From: Gorry Fairhurst > > Date: Thu, August 04, 2005 12:55 pm > > To: > > > > I don't see it this way. > > > > On 4/8/05 5:45 pm, "Goldberg, Adam" wrote: > > > > > Sure, you can decide to not use the mechanisms already existent in = an > MPEG > > > Transport Stream (B, C), but in doing so you merely cause redesign = or > > > purchase of special-purpose "MPEG" processing devices. > > > > Why do you feel auto-detection of the encapsulation ( C ) implies a > redesign > > of the MPEG equipment? This is a driver issue only, and orthogonal to > > supplying SI/PSI signalling. It does not stop a stream sending > signalling as > > well, or imply it. It provides a way to know that you have got the ri= ght > > encaps. > > > > > Make it a Transport Stream. This has very little real overhead, > requiring > > > only a PAT and PMT. The PMT is very lightweight but yet can easily > signal > > > which elementary streams (er, "PIDs") are encoded with what protoco= ls. > > > > > > This has many advantages: You don't need to reinvent anything (inb= and > > > signaling) -- merely an identifying descriptor; you don't have to > require > > > multiplexers and other non-IETF MPEG processing devices do anything > special > > > (that is to say, you don't require existing MPEG processing devices= to > also > > > process nonstandard IETF things); IETF streams would coexist > peacefully with > > > non-IETF streams in a Transport Stream; it's very extensible to oth= er > > > encapsulation formats yet-to-be-defined. > > > > I think someone should gather this thread and write one or two > paragraphs to > > summarise this to include in section 4 of the address resolution > document > > (draft-ietf-ipdvb-ar-00.txt), especially the implications of the PSI/= SI > on > > the remultiplexing environment. > > > > Gorry > > > > > > > > Adam Goldberg > > > Director, Television Standards & Policy Development > > > Sharp Laboratories of America > > > 8605 Westwood Center Drive, Suite 206 > > > Vienna, VA 22182 > > > 703-556-4406 > > > 703-556-4410 fax > > > 571-276-0305 cell > > > > > > > > > > > >> -----Original Message----- > > >> From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.u= k] > On > > >> Behalf Of Gorry Fairhurst > > >> Sent: Thursday, August 04, 2005 3:56 AM > > >> To: ipdvb@erg.abdn.ac.uk > > >> Subject: Re: Adding ULE into a network already using MPE... > > >> > > >> There ways to do this I can think of three, and I think John you a= re > > >> asking > > >> about C? > > >> > > >> > > >> A) You could parse the SI/PSI signalling (if any) and extract the > > >> information from there. > > >> > > >> B) You could configure it (out of band) or using IP > > >> configuration/resolution, etc. > > >> > > >> C) I once worked through an "auto-detect mode", where you knew the > PID but > > >> didn't know the type of encapsulation. > > >> > > >> ---- > > >> > > >> The basic rule is only one type of encapsulation is allowed for a > single > > >> PID. So how can you find out which is used? > > >> > > >> I note there is a reasonably strong CRC there in the ULE framing, = and > you > > >> can easily extract framing alignment to the TS from the PUSI setti= ng > in > > >> the > > >> TS header: > > >> > > >> (i) Supposing your receiver starts as unconfigured. > > >> > > >> (ii) The receiver looks for a PUSI setting and extracts the PP val= ue. > > >> > > >> (iii) It then tries reassembly of the first section as a ULE packe= t. > If it > > >> succeeds with a valid CRC-32 and Length, it is probably safe to > assume > > >> this > > >> is ULE. > > >> > > >> (iv) If the CRC fails, it tries a DSM-CC section reassembly (being > aware > > >> the > > >> integrity check is interpreted in more than one way in MPE). The M= PE > start > > >> code is also another "hint" that this may not be ULE, but this val= ue > > >> *could* > > >> appear as the start of a ULE field - (Note one needs to be aware t= hat > MPE > > >> and ATSC use different start values). > > >> > > >> (v) You could (probably should!!!) verify the next few SNDUs to > increase > > >> your confidence, as in any alignment algorithm. It would also be > wise to > > >> re-initialise the detection if you suffer an alignment failure. Th= is > could > > >> be a result of a change of mutliplexing policy. > > >> > > >> Note: This is orthogonal to the generation of SI/PSI tables used t= o > > >> control > > >> the TS multiplexing layer itself. If you use a transport stream > > >> multiplexor > > >> as a part of your L2 MPEG transmission network, this may need the > SI/PSI > > >> to > > >> allow the PID to reach the Receiver. > > >> > > >> Thoughts? > > >> > > >> Gorry > > >> > > >> On 3/8/05 8:39 pm, "John Border" wrote: > > >>> > > >>> I was thinking along those lines. The sender associates the > > >>> encapsulation method with a particular PID and "knows" (via AR) > which > > >>> PID to use to send to a particular receiver. Receivers which onl= y > > >>> understand MPE only use MPE PIDs. Receivers which understand ULE > and > > >>> MPE determine which method is being used by which PID is being > > >>> received. (I think the ULE capable receivers will still need to > support > > >>> MPE for multicast traffic that is shared with "older" terminals.) > > >>> > > >>> I was wondering if there is a way for the receiver to look at > the > > >>> header and determine if it is ULE or MPE on the fly. I haven't > taken a > > >>> close look at it yet. But, I suspect that it is not reliably > > > possible... > > >>> > > >>> John > > >>> > > >>> > > >>> Marie-Jose Montpetit wrote: > > >>> > > >>>> I think this is one thing that could be solved by some of the > > >>>> configuration work that was started where you could associate a = PID > to > > >>>> an encapsulation. You may not want to ignore the new encapsulati= on. > > >>>> > > >>>> Marie-Jose > > >>>> > > >>>> > > >>>> > > >>>>> -------- Original Message -------- > > >>>>> Subject: RE: Adding ULE into a network already using MPE... > > >>>>> From: "Allison, Art" > > >>>>> Date: Wed, August 03, 2005 2:05 pm > > >>>>> To: > > >>>>> > > >>>>> Use of the MRD will enable a device on a MPEG-2 network that do= es > not > > >>>>> understand that MRD's signaling/meaning to ignore the new > > >> encapsulation. > > >>>>> > > >>>>> > > >>>>> Of course if the existing network just used private data with o= ut > > >>>>> signaling what it was, a problem may exist. > > >>>>> __________________ > > >>>>> Art Allison > > >>>>> Director, Advanced Engineering > > >>>>> NAB Science & Technology > > >>>>> 1771 N St NW, Washington DC 20036 > > >>>>> 202 429 5418 > > >>>>> -----Original Message----- > > >>>>> From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner- > ipdvb@erg.abdn.ac.uk] > > >>>>> Sent: Wednesday, August 03, 2005 11:32 AM > > >>>>> To: ipdvb@erg.abdn.ac.uk > > >>>>> Subject: Adding ULE into a network already using MPE... > > >>>>> > > >>>>> > > >>>>> Has anyone looked at the operational problems associated wit= h > > >> adding > > >>>>> ULE use to a network which has some deployed terminals which on= ly > > >>>>> understand MPE? > > >>>>> > > >>>>> > > >>>>> John > > >>>>> > > >>>>> > > >>>> > > >>>> > > >>>> > > >>> > > >>> > > > > > > From owner-ipdvb@erg.abdn.ac.uk Fri Aug 05 04:17:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0xOi-0007Gg-6t for ipdvb-archive@megatron.ietf.org; Fri, 05 Aug 2005 04:17:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24893 for ; Fri, 5 Aug 2005 04:17:42 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0xvk-0007P6-Ub for ipdvb-archive@ietf.org; Fri, 05 Aug 2005 04:51:54 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j75808ul020653 for ; Fri, 5 Aug 2005 09:00:08 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j75808pq020652 for ipdvb-subscribed-users; Fri, 5 Aug 2005 09:00:08 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from [139.133.204.42] (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j75802JI020620 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 5 Aug 2005 09:00:02 +0100 (BST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 05 Aug 2005 10:01:51 +0200 Subject: Re: Non-IP Protocol Support From: Gorry Fairhurst To: Message-ID: In-Reply-To: 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-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Content-Transfer-Encoding: 7bit On 4/8/05 8:49 pm, "Shanbhogue, Vedvyas" wrote: > Reading RFC3251 was an electrifying experience :) > > Since the requirement here is to tunnel a non-IP protocol perhaps there is > no need to tunnel ARP over the tunnel. In a previous IETF, someone looked at the case of UDLR for IPv4, where arp was used to support IPv4 over the MPEG-2 forward link. I was citing this as a an example. We don't have specific use-cases for the "bridging of L2 frames" - what I meant to say was that sometimes L2 frames are used within a L2 infrastructure to support an IP service. Hence, if there is an easy and effective way to support L2 it is valuable. There is also a second case of non-IP network-layer protocols. > RFC 2784 GRE encapsulation with a few new etherTypes could work. > > sincerely, > Vs > -- > Vedvyas Shanbhogue > SSA, IPD > o:(503) 677 - 6409, c:(503) 851 - 2088 > > > > _____ > > From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On > Behalf Of West, Mark > Sent: Thursday, August 04, 2005 6:24 AM > To: ipdvb@erg.abdn.ac.uk > Subject: Re: Non-IP Protocol Support > > > > > Indeed, RFC 3251 may be worth considering :-) > > But seriously... > > ... could I not encapsulate ARP, in that case, over multicast IP? > > It may be that this conversation is a little premature, in that there are > other questions about security that aren't directly related to this. But > if you can't tunnel stuff over IP to bootstrap, for example, then I'm > suspicious of using an IP-based architecture to set-up a non-IP-based > security system. (If that makes any sense?!) > > Cheers, > > Mark. > > >> >> The IETF have defined several foo-over-IP methods which could be used, >> and >> these should work with ULE (bidirectional IP connectivity may be >> required). >> PWE3 is by no means the only option. >> >> However, there are situations were this tunnel over IP approach really >> does >> not do what may be wanted. ARP for IPv4 is a classic example. If you >> wanted >> to use arp to resolve an IP to MAC address, then clearly you can't >> encapsulate this over IP to send it. >> >> Gorry >> >> On 4/8/05 12:40 pm, "West, Mark" wrote: >> >>> >>> A further comment on Juan's point (and something that came up in >>> discussion after the ipdvb session, yesterday)... >>> >>> If there is a security mechanism for IP (e.g. IPsec) and you want to >> apply >>> that to non-IP flows (e.g. a stream of SNDUs, Ethernet frames, ...) >> then >>> why not run the non-IP over an emulated pseudo-wire within the IPsec >>> tunnel? Then you only need an IP-based security solution. >>> >>> I honestly don't know whether this is appropriate, but it seemed like >> an >>> interesting idea at the time! >>> >>> >> (http://www.ietf.org/internet-drafts/draft-ietf-pwe3-iana-allocation-11. >> txt >>> already has codepoints for Ethernet, etc., but not anything specific >> to >>> the ipdvb case.) >>> >>> Cheers, >>> >>> Mark. >>> >>> -- >>> Mark A. West, Senior Consultant Engineer >>> Roke Manor Research Ltd., Romsey, Hants. SO51 0ZN >>> Phone +44 (0)1794 833311 Fax +44 (0)1794 833433 >>> >> >> >> > From owner-ipdvb@erg.abdn.ac.uk Fri Aug 05 04:23:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0xTw-0000KV-Ce for ipdvb-archive@megatron.ietf.org; Fri, 05 Aug 2005 04:23:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25175 for ; Fri, 5 Aug 2005 04:23:06 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0y0z-0007Zz-3v for ipdvb-archive@ietf.org; Fri, 05 Aug 2005 04:57:18 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j7589vNL020871 for ; Fri, 5 Aug 2005 09:09:57 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j7589vdB020870 for ipdvb-subscribed-users; Fri, 5 Aug 2005 09:09:57 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from [139.133.204.42] (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j7589gfR020840 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 5 Aug 2005 09:09:50 +0100 (BST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 05 Aug 2005 09:02:26 +0200 Subject: Re: Non-IP Protocol Support From: Gorry Fairhurst To: Message-ID: In-Reply-To: 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-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: 7bit Do you mean something like this, at the Receiver? decapsulation of L2 over IP /- ****** --\ | | +-|---------+ | | | | | | | | | IP Module | ^ | v | | | | +-|---------+ | (IP Interface) | | | | | | ^ | | Link | | | | | | | O------|-O +-|---------+ (ULE Interface) | | | | | | MPEG-2 TS | | | | | | --|---------- | This architecture is more painful than something like PWE3, where the interface on which the tunnelled L2 frames are presented is usually different to that on which they are received. In this case, you would tunnel over IP to decapsulate, and then post the frame back into the same Link layer below the same IP module interface. There is (of course) overhead here added to L2 amd there are a few details that would need to be worked out: the issue of discovery of the (link-local?) multicast address, etc. Gorry On 4/8/05 3:23 pm, "West, Mark" wrote: > > Indeed, RFC 3251 may be worth considering :-) Hmmmm, not so useful ;-). > But seriously... > > ... could I not encapsulate ARP, in that case, over multicast IP? > > It may be that this conversation is a little premature, in that there are > other questions about security that aren't directly related to this. But > if you can't tunnel stuff over IP to bootstrap, for example, then I'm > suspicious of using an IP-based architecture to set-up a non-IP-based > security system. (If that makes any sense?!) > > Cheers, > > Mark. > > >> >> The IETF have defined several foo-over-IP methods which could be used, >> and >> these should work with ULE (bidirectional IP connectivity may be >> required). >> PWE3 is by no means the only option. >> >> However, there are situations were this tunnel over IP approach really >> does >> not do what may be wanted. ARP for IPv4 is a classic example. If you >> wanted >> to use arp to resolve an IP to MAC address, then clearly you can't >> encapsulate this over IP to send it. >> >> Gorry >> >> On 4/8/05 12:40 pm, "West, Mark" wrote: >> >>> >>> A further comment on Juan's point (and something that came up in >>> discussion after the ipdvb session, yesterday)... >>> >>> If there is a security mechanism for IP (e.g. IPsec) and you want to >> apply >>> that to non-IP flows (e.g. a stream of SNDUs, Ethernet frames, ...) >> then >>> why not run the non-IP over an emulated pseudo-wire within the IPsec >>> tunnel? Then you only need an IP-based security solution. >>> >>> I honestly don't know whether this is appropriate, but it seemed like >> an >>> interesting idea at the time! >>> >>> >> (http://www.ietf.org/internet-drafts/draft-ietf-pwe3-iana-allocation-11. >> txt >>> already has codepoints for Ethernet, etc., but not anything specific >> to >>> the ipdvb case.) >>> >>> Cheers, >>> >>> Mark. >>> >>> -- >>> Mark A. West, Senior Consultant Engineer >>> Roke Manor Research Ltd., Romsey, Hants. SO51 0ZN >>> Phone +44 (0)1794 833311 Fax +44 (0)1794 833433 >>> >> >> >> From owner-ipdvb@erg.abdn.ac.uk Fri Aug 05 05:46:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0yn4-00066L-TA for ipdvb-archive@megatron.ietf.org; Fri, 05 Aug 2005 05:46:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29440 for ; Fri, 5 Aug 2005 05:46:56 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0zK8-0001dZ-1f for ipdvb-archive@ietf.org; Fri, 05 Aug 2005 06:21:09 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j759ZO3N022593 for ; Fri, 5 Aug 2005 10:35:24 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j759ZOQl022592 for ipdvb-subscribed-users; Fri, 5 Aug 2005 10:35:24 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from [139.133.204.42] (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j759ZJMV022576 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 5 Aug 2005 10:35:20 +0100 (BST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 05 Aug 2005 11:37:11 +0200 Subject: Text for: Adding ULE into a network already using MPE... From: Gorry Fairhurst To: Message-ID: In-Reply-To: <08259490B3BC3140B549DD0907A5644822C564@admsrvnt10.enet.sharplabs.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" X-ERG-MailScanner: Found to be clean, Found to be clean X-MIME-Autoconverted: from quoted-printable to 8bit by erg.abdn.ac.uk id j759ZNth022589 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 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by erg.abdn.ac.uk id j759ZO3N022593 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1094b1c84fa6e846d476f39271f5074f Content-Transfer-Encoding: quoted-printable I think the time has come to write this down as a text block for the AR draft=20 This seems a fine start on some text to me. I would like to propose using this as a basis and working through the mail thread to make sure that we also capture all the points earlier in the thread. Let's capture all this= as a set of paragraphs - we could possibly place this at the front of sectio= n 4. Gorry On 4/8/05 8:52 pm, "Goldberg, Adam" wrote: > I see it rather simply: consider an environment with a mix of non-IETF-= aware > devices (widely available MPEG-transport-processing devices, like > multiplexers, remultiplexers, rate shapers, ad insertion equipment, etc= etc) > - call this set "A" - and IETF-aware devices (couldn't name one, but yo= u > probably have something in mind) - call this set "B". >=20 > If you signal the existence of IETF steams in a MPEG Transport Stream > compliant manner (that is, via PMT entries), then every device in "A" w= ill > autorecognize that those steams exist, and even if they don't know what= they > are or what to do with them, will pass them through the system. Also, = of > course, devices in "B" will work, too. >=20 > If you signal the existence of IETF streams in some other manner, eithe= r by > well-known PID values, or "out of band" signaling or some prearrangemen= t or > whatever, then every device in "B" will work ... and a large proportion= of > devices in "A" will IMMEDIATELY DROP ALL OF THOSE PACKETS AND NOT PASS = THEM > THROUGH. >=20 > Seems a clear choice to me. But feel free to design a private system t= hat > requires all entirely new infrastructure hardware. It'll be much less > useful. >=20 >=20 > Adam Goldberg > Director, Television Standards & Policy Development > Sharp Laboratories of America > 8605 Westwood Center Drive, Suite 206 > Vienna, VA=A0 22182 > 703-556-4406 > 703-556-4410 fax > 571-276-0305 cell > =A0 >=20 >=20 >> -----Original Message----- >> From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] O= n >> Behalf Of Marie-Jose Montpetit >> Sent: Thursday, August 04, 2005 1:48 PM >> To: ipdvb@erg.abdn.ac.uk >> Cc: ipdvb@erg.abdn.ac.uk >> Subject: RE: Adding ULE into a network already using MPE... >>=20 >> I agree with Gorry. I think there are many ways of looking at it and >> there is a trend to design signaling mechanisms that become to certain >> extent independant of the actual implementation (that can depend on fo= r >> example if you MPEG steam is DVB, DCII etc) and allow ti include other >> features (such as QoS) in the auto-detection. >>=20 >> But then, I did write a draft on this ;-) >>=20 >> /mjm >>=20 >>> -------- Original Message -------- >>> Subject: Re: Adding ULE into a network already using MPE... >>> From: Gorry Fairhurst >>> Date: Thu, August 04, 2005 12:55 pm >>> To: >>>=20 >>> I don't see it this way. >>>=20 >>> On 4/8/05 5:45 pm, "Goldberg, Adam" wrote: >>>=20 >>>> Sure, you can decide to not use the mechanisms already existent in a= n >> MPEG >>>> Transport Stream (B, C), but in doing so you merely cause redesign o= r >>>> purchase of special-purpose "MPEG" processing devices. >>>=20 >>> Why do you feel auto-detection of the encapsulation ( C ) implies a >> redesign >>> of the MPEG equipment? This is a driver issue only, and orthogonal to >>> supplying SI/PSI signalling. It does not stop a stream sending >> signalling as >>> well, or imply it. It provides a way to know that you have got the ri= ght >>> encaps. >>>=20 >>>> Make it a Transport Stream. This has very little real overhead, >> requiring >>>> only a PAT and PMT. The PMT is very lightweight but yet can easily >> signal >>>> which elementary streams (er, "PIDs") are encoded with what protocol= s. >>>>=20 >>>> This has many advantages: You don't need to reinvent anything (inba= nd >>>> signaling) -- merely an identifying descriptor; you don't have to >> require >>>> multiplexers and other non-IETF MPEG processing devices do anything >> special >>>> (that is to say, you don't require existing MPEG processing devices = to >> also >>>> process nonstandard IETF things); IETF streams would coexist >> peacefully with >>>> non-IETF streams in a Transport Stream; it's very extensible to othe= r >>>> encapsulation formats yet-to-be-defined. >>>=20 >>> I think someone should gather this thread and write one or two >> paragraphs to >>> summarise this to include in section 4 of the address resolution >> document >>> (draft-ietf-ipdvb-ar-00.txt), especially the implications of the PSI/= SI >> on >>> the remultiplexing environment. >>>=20 >>> Gorry >>>=20 >>>>=20 >>>> Adam Goldberg >>>> Director, Television Standards & Policy Development >>>> Sharp Laboratories of America >>>> 8605 Westwood Center Drive, Suite 206 >>>> Vienna, VA 22182 >>>> 703-556-4406 >>>> 703-556-4410 fax >>>> 571-276-0305 cell >>>>=20 >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk= ] >> On >>>>> Behalf Of Gorry Fairhurst >>>>> Sent: Thursday, August 04, 2005 3:56 AM >>>>> To: ipdvb@erg.abdn.ac.uk >>>>> Subject: Re: Adding ULE into a network already using MPE... >>>>>=20 >>>>> There ways to do this I can think of three, and I think John you ar= e >>>>> asking >>>>> about C? >>>>>=20 >>>>>=20 >>>>> A) You could parse the SI/PSI signalling (if any) and extract the >>>>> information from there. >>>>>=20 >>>>> B) You could configure it (out of band) or using IP >>>>> configuration/resolution, etc. >>>>>=20 >>>>> C) I once worked through an "auto-detect mode", where you knew the >> PID but >>>>> didn't know the type of encapsulation. >>>>>=20 >>>>> ---- >>>>>=20 >>>>> The basic rule is only one type of encapsulation is allowed for a >> single >>>>> PID. So how can you find out which is used? >>>>>=20 >>>>> I note there is a reasonably strong CRC there in the ULE framing, a= nd >> you >>>>> can easily extract framing alignment to the TS from the PUSI settin= g >> in >>>>> the >>>>> TS header: >>>>>=20 >>>>> (i) Supposing your receiver starts as unconfigured. >>>>>=20 >>>>> (ii) The receiver looks for a PUSI setting and extracts the PP valu= e. >>>>>=20 >>>>> (iii) It then tries reassembly of the first section as a ULE packet. >> If it >>>>> succeeds with a valid CRC-32 and Length, it is probably safe to >> assume >>>>> this >>>>> is ULE. >>>>>=20 >>>>> (iv) If the CRC fails, it tries a DSM-CC section reassembly (being >> aware >>>>> the >>>>> integrity check is interpreted in more than one way in MPE). The MP= E >> start >>>>> code is also another "hint" that this may not be ULE, but this valu= e >>>>> *could* >>>>> appear as the start of a ULE field - (Note one needs to be aware th= at >> MPE >>>>> and ATSC use different start values). >>>>>=20 >>>>> (v) You could (probably should!!!) verify the next few SNDUs to >> increase >>>>> your confidence, as in any alignment algorithm. It would also be >> wise to >>>>> re-initialise the detection if you suffer an alignment failure. Thi= s >> could >>>>> be a result of a change of mutliplexing policy. >>>>>=20 >>>>> Note: This is orthogonal to the generation of SI/PSI tables used to >>>>> control >>>>> the TS multiplexing layer itself. If you use a transport stream >>>>> multiplexor >>>>> as a part of your L2 MPEG transmission network, this may need the >> SI/PSI >>>>> to >>>>> allow the PID to reach the Receiver. >>>>>=20 >>>>> Thoughts? >>>>>=20 >>>>> Gorry >>>>>=20 >>>>> On 3/8/05 8:39 pm, "John Border" wrote: >>>>>>=20 >>>>>> I was thinking along those lines. The sender associates the >>>>>> encapsulation method with a particular PID and "knows" (via AR) >> which >>>>>> PID to use to send to a particular receiver. Receivers which only >>>>>> understand MPE only use MPE PIDs. Receivers which understand ULE >> and >>>>>> MPE determine which method is being used by which PID is being >>>>>> received. (I think the ULE capable receivers will still need to >> support >>>>>> MPE for multicast traffic that is shared with "older" terminals.) >>>>>>=20 >>>>>> I was wondering if there is a way for the receiver to look at >> the >>>>>> header and determine if it is ULE or MPE on the fly. I haven't >> taken a >>>>>> close look at it yet. But, I suspect that it is not reliably >>>> possible... >>>>>>=20 >>>>>> John >>>>>>=20 >>>>>>=20 >>>>>> Marie-Jose Montpetit wrote: >>>>>>=20 >>>>>>> I think this is one thing that could be solved by some of the >>>>>>> configuration work that was started where you could associate a P= ID >> to >>>>>>> an encapsulation. You may not want to ignore the new encapsulatio= n. >>>>>>>=20 >>>>>>> Marie-Jose >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> -------- Original Message -------- >>>>>>>> Subject: RE: Adding ULE into a network already using MPE... >>>>>>>> From: "Allison, Art" >>>>>>>> Date: Wed, August 03, 2005 2:05 pm >>>>>>>> To: >>>>>>>>=20 >>>>>>>> Use of the MRD will enable a device on a MPEG-2 network that doe= s >> not >>>>>>>> understand that MRD's signaling/meaning to ignore the new >>>>> encapsulation. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Of course if the existing network just used private data with ou= t >>>>>>>> signaling what it was, a problem may exist. >>>>>>>> __________________ >>>>>>>> Art Allison >>>>>>>> Director, Advanced Engineering >>>>>>>> NAB Science & Technology >>>>>>>> 1771 N St NW, Washington DC 20036 >>>>>>>> 202 429 5418 >>>>>>>> -----Original Message----- >>>>>>>> From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner- >> ipdvb@erg.abdn.ac.uk] >>>>>>>> Sent: Wednesday, August 03, 2005 11:32 AM >>>>>>>> To: ipdvb@erg.abdn.ac.uk >>>>>>>> Subject: Adding ULE into a network already using MPE... >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Has anyone looked at the operational problems associated with >>>>> adding >>>>>>>> ULE use to a network which has some deployed terminals which onl= y >>>>>>>> understand MPE? >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> John >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>=20 >>>>=20 >=20 From owner-ipdvb@erg.abdn.ac.uk Mon Aug 08 07:11:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E25Xz-000539-Qy for ipdvb-archive@megatron.ietf.org; Mon, 08 Aug 2005 07:11:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13622 for ; Mon, 8 Aug 2005 07:11:56 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E265e-0004Bs-L7 for ipdvb-archive@ietf.org; Mon, 08 Aug 2005 07:46:49 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j78AnTxY000726 for ; Mon, 8 Aug 2005 11:49:29 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j78AnTAh000725 for ipdvb-subscribed-users; Mon, 8 Aug 2005 11:49:29 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from mailg.surrey.ac.uk (mailg.surrey.ac.uk [131.227.102.21]) by erg.abdn.ac.uk (8.13.4/8.13.4) with SMTP id j78AnLf0000705 for ; Mon, 8 Aug 2005 11:49:21 +0100 (BST) Received: from ads33.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Mon, 8 Aug 2005 11:48:59 +0100 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads33.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Aug 2005 11:48:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Non-IP Protocol Support Date: Mon, 8 Aug 2005 11:48:58 +0100 Message-ID: Thread-Topic: Non-IP Protocol Support Thread-Index: AcWYR43Bl8gLQVonRTycSvZQOXnJfQDvlPZw From: "H.Cruickshank" To: ipdvb X-OriginalArrivalTime: 08 Aug 2005 10:48:58.0824 (UTC) FILETIME=[C7F2C480:01C59C06] X-ERG-MailScanner: Found to be clean, Found to be clean X-ERG-MailScanner-SpamCheck: not spam, SpamAssassin (score=-2.599, required 5, autolearn=not spam, BAYES_00 -2.60), not spam, SpamAssassin (score=-2.599, required 5, autolearn=not spam, BAYES_00 -2.60) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by erg.abdn.ac.uk id j78AnTUn000722 Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 8bit Hi John, Security support to carry non-IP traffic is useful, but there is no compelling reason to make this a priority. So the first step for the security work progress is to focus on the security requirements to carry IP traffic. Haitham -- Dr. Haitham S. Cruickshank Lecturer Communications Centre for Communication Systems Research (CCSR) School of Electronics, Computing and Mathematics University of Surrey, Guildford, Surrey GU2 7XH, UK Tel: +44 1483 686007 (indirect 689844) Fax: +44 1483 686011 e-mail: H.Cruickshank@surrey.ac.uk http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ -----Original Message----- From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On Behalf Of John Border Sent: 03 August 2005 16:35 To: ipdvb@erg.abdn.ac.uk Subject: Non-IP Protocol Support I can understand why it is desirable to be able to carry non-IP traffic. But, I would prefer to get a solution for security that supports IP over DVB even if it doesn't support non-IP protocols than to not have a solution. Is there a compelling reason to include securing non-IP traffic in the problem space right now? John From owner-ipdvb@erg.abdn.ac.uk Mon Aug 08 10:34:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E28he-0005mT-7u for ipdvb-archive@megatron.ietf.org; Mon, 08 Aug 2005 10:34:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25065 for ; Mon, 8 Aug 2005 10:34:08 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E29FK-0001MN-O4 for ipdvb-archive@ietf.org; Mon, 08 Aug 2005 11:09:01 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j78EGhLt006546 for ; Mon, 8 Aug 2005 15:16:43 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j78EGhWj006545 for ipdvb-subscribed-users; Mon, 8 Aug 2005 15:16:43 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from prue.eim.surrey.ac.uk (IDENT:exim@prue.eim.surrey.ac.uk [131.227.76.5]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j78EGY7J006522 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 8 Aug 2005 15:16:34 +0100 (BST) Received: from argos.ee.surrey.ac.uk ([131.227.89.15] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 1E28QS-000541-00 for ipdvb@erg.abdn.ac.uk; Mon, 08 Aug 2005 15:16:24 +0100 Date: Mon, 8 Aug 2005 15:16:22 +0100 (BST) From: Lloyd Wood X-X-Sender: eep1lw@argos.ee.surrey.ac.uk To: ipdvb Subject: RE: Non-IP Protocol Support In-Reply-To: Message-ID: References: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-102.5 required=7.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_PINE,USER_IN_WHITELIST autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Scanner: exiscan *1E28QS-000541-00*mg2WkvG0GW.* (SECM, UniS) X-ERG-MailScanner: Found to be clean, Found to be clean X-ERG-MailScanner-SpamCheck: not spam, SpamAssassin (score=-2.599, required 5, autolearn=not spam, BAYES_00 -2.60), not spam, SpamAssassin (score=-2.599, required 5, BAYES_00 -2.60) Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Do we class IP with an MPLS shim as IP, or non-IP, traffic? L. On Mon, 8 Aug 2005, H.Cruickshank wrote: > Hi John, > > Security support to carry non-IP traffic is useful, but there is no > compelling reason to make this a priority. So the first step for the > security work progress is to focus on the security requirements to carry > IP traffic. > > Haitham > > -- > > Dr. Haitham S. Cruickshank > > Lecturer > > Communications Centre for Communication Systems Research (CCSR) > > School of Electronics, Computing and Mathematics > > University of Surrey, Guildford, Surrey GU2 7XH, UK > > Tel: +44 1483 686007 (indirect 689844) > > Fax: +44 1483 686011 > > e-mail: H.Cruickshank@surrey.ac.uk > > http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ > > > > -----Original Message----- > From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On > Behalf Of John Border > Sent: 03 August 2005 16:35 > To: ipdvb@erg.abdn.ac.uk > Subject: Non-IP Protocol Support > > > > I can understand why it is desirable to be able to carry non-IP > traffic. But, I would prefer to get a solution for security that > supports IP over DVB even if it doesn't support non-IP protocols than to > > not have a solution. Is there a compelling reason to include securing > non-IP traffic in the problem space right now? > > > John > > > > > From owner-ipdvb@erg.abdn.ac.uk Mon Aug 08 12:42:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Ai9-0002ft-Jt for ipdvb-archive@megatron.ietf.org; Mon, 08 Aug 2005 12:42:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01895 for ; Mon, 8 Aug 2005 12:42:46 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2BFp-00058N-Ey for ipdvb-archive@ietf.org; Mon, 08 Aug 2005 13:17:41 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j78GUg8I010237 for ; Mon, 8 Aug 2005 17:30:42 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j78GUg37010236 for ipdvb-subscribed-users; Mon, 8 Aug 2005 17:30:42 +0100 (BST) X-Authentication-Warning: dee.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.13.4/8.13.4) with ESMTP id j78GUG62010217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 8 Aug 2005 17:30:17 +0100 (BST) Message-ID: <42F78898.3090008@erg.abdn.ac.uk> Date: Mon, 08 Aug 2005 17:30:16 +0100 From: Gorry Fairhurst Organization: University 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: Non-IP Protocol Support 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 X-ERG-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-5.899, required 5, autolearn=not spam, ALL_TRUSTED -3.30, BAYES_00 -2.60), not spam, SpamAssassin (score=-5.899, required 5, ALL_TRUSTED -3.30, BAYES_00 -2.60) Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Does this use the IP Ethertype field? Gorry Lloyd Wood wrote: > Do we class IP with an MPLS shim as IP, or non-IP, traffic? > > L. > > On Mon, 8 Aug 2005, H.Cruickshank wrote: > > >>Hi John, >> >>Security support to carry non-IP traffic is useful, but there is no >>compelling reason to make this a priority. So the first step for the >>security work progress is to focus on the security requirements to carry >>IP traffic. >> >>Haitham >> >>-- >> >>Dr. Haitham S. Cruickshank >> >>Lecturer >> >>Communications Centre for Communication Systems Research (CCSR) >> >>School of Electronics, Computing and Mathematics >> >>University of Surrey, Guildford, Surrey GU2 7XH, UK >> >>Tel: +44 1483 686007 (indirect 689844) >> >>Fax: +44 1483 686011 >> >>e-mail: H.Cruickshank@surrey.ac.uk >> >>http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ >> >> >> >>-----Original Message----- >>From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On >>Behalf Of John Border >>Sent: 03 August 2005 16:35 >>To: ipdvb@erg.abdn.ac.uk >>Subject: Non-IP Protocol Support >> >> >> >> I can understand why it is desirable to be able to carry non-IP >>traffic. But, I would prefer to get a solution for security that >>supports IP over DVB even if it doesn't support non-IP protocols than to >> >>not have a solution. Is there a compelling reason to include securing >>non-IP traffic in the problem space right now? >> >> >>John >> >> >> >> >> > > > > > From owner-ipdvb@erg.abdn.ac.uk Mon Aug 22 13:29:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7G7K-00079k-SC for ipdvb-archive@megatron.ietf.org; Mon, 22 Aug 2005 13:29:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29827 for ; Mon, 22 Aug 2005 13:29:47 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7Ghv-0008Oi-H8 for ipdvb-archive@ietf.org; Mon, 22 Aug 2005 14:07:40 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j7MH4wTs027283 for ; Mon, 22 Aug 2005 18:04:58 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j7MH4waP027282 for ipdvb-subscribed-users; Mon, 22 Aug 2005 18:04:58 +0100 (BST) X-Authentication-Warning: dee.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.13.4/8.13.4) with ESMTP id j7MH4Pv4027228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 22 Aug 2005 18:04:25 +0100 (BST) Message-ID: <430A0599.7030901@erg.abdn.ac.uk> Date: Mon, 22 Aug 2005 18:04:25 +0100 From: Gorry Fairhurst Organization: University 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 CC: Juan Cantillo , Bernhard Collini-Nocker Subject: Re: Noticed some possible errors in the ULE draft, ANNEX A References: <001301c5a734$8fee8a40$877a36c1@DrCerebro> In-Reply-To: <001301c5a734$8fee8a40$877a36c1@DrCerebro> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean X-ERG-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-5.899, required 6, autolearn=not spam, ALL_TRUSTED -3.30, BAYES_00 -2.60), not spam, SpamAssassin (score=-5.899, required 6, ALL_TRUSTED -3.30, BAYES_00 -2.60) Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Juan, thanks for the query it's easy to miss mistakes in the informative annexes, and we'd certainly like to get the text correct before this is published as a RFC. Can someone please check this out (I can't at the momment) Gorry Juan Cantillo wrote: > Dear Gorry, > > I am currently working on the "01 version" of our DVB-S2 draft and while > re-reading the ULE-06 draft I came across what might be some > typographic errors in ANNEX A: > > ********************* Page 38, example A2 "Usage of last byte in a TS > packet":*************** > The 4 shown SNDU sizes are 183, 182, 181 and 185 Bytes long, which would > lead to "SNDU Length" fields of 0xB3, 0xB2, 0xB1and 0xB5, resp, since: > 0xB3 = 183 - 4 (in decimal) > 0xB2 = 182 - 4 > 0xB1 = 181 - 4 > 0xB5 = 185 - 4 > (4 bytes are to be substracted to the length of the SNDU since the "SNDU > Length" field DOES NOT count the 4-byte mandatory header of ULE) > Instead, in the diagram we have 0x63, 0x62, 0x61and 0x65... it seems > that the "B" was confused with "6" ?! > > ********************* Page 41, example A5 "three 44B > PDUs":******************************** > The three SNDUS are 52 bytes long, which would lead to "SNDU Length" of > 48 bytes, coded in hexadecimal as 0x30 and NOT as 0x34. > > Please let me know whether those are typographic mistakes, or if it is > me who is wrong... This last hypothesis is highly probable since "the > errors" are similar, so I might be missing something! > > Looking forward to hearing from you soon, > > Juan > > ========================= > Juan CANTILLO > SatComs PhD. Researcher > ENST/TeSA/ENSICA/ASP > +33 6 23 54 59 65 > Toulouse, FR From owner-ipdvb@erg.abdn.ac.uk Tue Aug 23 04:54:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7UYd-0007fb-CS for ipdvb-archive@megatron.ietf.org; Tue, 23 Aug 2005 04:54:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22011 for ; Tue, 23 Aug 2005 04:54:57 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7UYi-0005GQ-Df for ipdvb-archive@ietf.org; Tue, 23 Aug 2005 04:55:04 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j7N8QmYk025682 for ; Tue, 23 Aug 2005 09:26:48 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j7N8QmE9025681 for ipdvb-subscribed-users; Tue, 23 Aug 2005 09:26:48 +0100 (BST) X-Authentication-Warning: dee.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.13.4/8.13.4) with ESMTP id j7N8Qg2F025662 for ; Tue, 23 Aug 2005 09:26:43 +0100 (BST) Received: from [127.0.0.1] (milbe.cosy.sbg.ac.at [141.201.2.21]) by loewe.cosy.sbg.ac.at (8.8.8/8.8.7) with ESMTP id JAA21474 for ; Tue, 23 Aug 2005 09:32:04 +0200 (MET DST) Message-ID: <430AD0D3.2050802@cosy.sbg.ac.at> Date: Tue, 23 Aug 2005 09:31:31 +0200 From: Bernhard Collini-Nocker User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: Re: Noticed some possible errors in the ULE draft, ANNEX A References: <001301c5a734$8fee8a40$877a36c1@DrCerebro> <430A0599.7030901@erg.abdn.ac.uk> In-Reply-To: <430A0599.7030901@erg.abdn.ac.uk> 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 X-ERG-MailScanner-SpamCheck: not spam, SpamAssassin (score=-2.599, required 6, autolearn=not spam, BAYES_00 -2.60), not spam, SpamAssassin (score=-2.599, required 6, BAYES_00 -2.60) Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: 7bit Dear Juan, many thanks for this hints. You are perfectly right, some wrong numbers have made it into the document, which need to be corrected before publication. For curiosity I checked the earlier versions of the drafts and it looks as if the first problem of this kind (calculating the Length field as being length of SNDU including header, so 4 bytes too much) first occurred in the Feb 2004 -02 version, (was actually meant as an improvement for reading: instead of showing the SNDU bytes from 0 to length-1 to also provide the Length field values). In the Oct 2004 -02 version this first calculation error was corrected for the first example, but at the same time the second example was "improved" with completely obscure numbers (6x instead of Bx). Funny enough, in the same -02 version another two examples were correctly improved, yet another one with same kind of +4 calculation. Apart from Yuan, again many thanks for this detailed reading, no one seems to have recalculated or cross checked the numbers again since then. Rethinking this style of reading improvement it does not seem to be such that the examples are easier to understand at all. If one takes for example the first part of Example A.5 (is just the shortest one) I find it not that clear any more that SNDU A having length 52 (4B hdr plus 48B payload) is to be counted from A000 to A051 on one side, but since the SNDU Length field is shown the counting actually has to start with A002 o nthe other side. Any hints for improvement? Example A.5: Three 44B PDUs. SNDU A is 52 bytes (no ULE destination NPA address) SNDU B is 52 bytes (no ULE destination NPA address) SNDU C is 52 bytes (no ULE destination NPA address) The sequence comprises 1 TS Packet: SNDU PP=0 Length +-----+------+------+------+- -+-----+------+-----+- -+-----+- | HDR | 0x00 | 0x80 | 0x30 | ... | A51 |0x80 | 0x30 | ... | B51 | .. +-----+----*-+-*----+------+- -+-----+-*----+-----+- -+-----+- PUSI=1 * * ***** The sequence comprises 1 TS Packet: SNDU PP=0 Length +-----+------+------+------+- -+-----+------+-----+- -+-----+- | HDR | 0x00 | 0x80 | 0x30 | ... | A51 |0x80 | 0x34 | ... | B51 | .. +-----+----*-+-*----+------+- -+-----+-*----+-----+- -+-----+- PUSI=1 * * ***** Regards, Bernhard Gorry Fairhurst wrote: > > Juan, thanks for the query it's easy to miss mistakes in the informative > annexes, and we'd certainly like to get the text correct before this is > published as a RFC. > > Can someone please check this out (I can't at the momment) > > Gorry > > > Juan Cantillo wrote: > >> Dear Gorry, >> >> I am currently working on the "01 version" of our DVB-S2 draft and >> while re-reading the ULE-06 draft I came across what might be some >> typographic errors in ANNEX A: >> >> ********************* Page 38, example A2 "Usage of last byte in a TS >> packet":*************** >> The 4 shown SNDU sizes are 183, 182, 181 and 185 Bytes long, which >> would lead to "SNDU Length" fields of 0xB3, 0xB2, 0xB1and 0xB5, resp, >> since: >> 0xB3 = 183 - 4 (in decimal) >> 0xB2 = 182 - 4 >> 0xB1 = 181 - 4 >> 0xB5 = 185 - 4 >> (4 bytes are to be substracted to the length of the SNDU since the >> "SNDU Length" field DOES NOT count the 4-byte mandatory header of ULE) >> Instead, in the diagram we have 0x63, 0x62, 0x61and 0x65... it seems >> that the "B" was confused with "6" ?! >> >> ********************* Page 41, example A5 "three 44B >> PDUs":******************************** >> The three SNDUS are 52 bytes long, which would lead to "SNDU Length" >> of 48 bytes, coded in hexadecimal as 0x30 and NOT as 0x34. >> >> Please let me know whether those are typographic mistakes, or if it is >> me who is wrong... This last hypothesis is highly probable since "the >> errors" are similar, so I might be missing something! >> >> Looking forward to hearing from you soon, >> >> Juan >> >> ========================= >> Juan CANTILLO >> SatComs PhD. Researcher >> ENST/TeSA/ENSICA/ASP >> +33 6 23 54 59 65 >> Toulouse, FR > > From owner-ipdvb@erg.abdn.ac.uk Tue Aug 23 12:41:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7bqY-0007Cs-Vs for ipdvb-archive@megatron.ietf.org; Tue, 23 Aug 2005 12:41:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13954 for ; Tue, 23 Aug 2005 12:41:56 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7bqh-0001mB-3B for ipdvb-archive@ietf.org; Tue, 23 Aug 2005 12:42:08 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j7NGEQ4H012576 for ; Tue, 23 Aug 2005 17:14:26 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j7NGEQT8012575 for ipdvb-subscribed-users; Tue, 23 Aug 2005 17:14:26 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from mermoz.ensica.fr (loghost.ensica.fr [192.70.110.90]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j7NGEK1v012556 for ; Tue, 23 Aug 2005 17:14:20 +0100 (BST) Received: from DrCerebro (localhost [127.0.0.1]) by mermoz.ensica.fr (8.10.2+Sun/jtpda-5.3.1) with SMTP id j7NGEiH13362 for ; Tue, 23 Aug 2005 18:14:44 +0200 (MEST) Message-ID: <00f301c5a7fd$acd91700$877a36c1@DrCerebro> From: "Juan Cantillo" To: References: <001301c5a734$8fee8a40$877a36c1@DrCerebro> <430A0599.7030901@erg.abdn.ac.uk> <430AD0D3.2050802@cosy.sbg.ac.at> Subject: Re: Noticed some possible errors in the ULE draft, ANNEX A Date: Tue, 23 Aug 2005 18:14:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-ERG-MailScanner: Found to be clean, Found to be clean X-ERG-MailScanner-SpamCheck: not spam, SpamAssassin (score=-2.599, required 6, autolearn=not spam, BAYES_00 -2.60), not spam, SpamAssassin (score=-2.599, required 6, BAYES_00 -2.60) Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Content-Transfer-Encoding: 7bit Dear Bernhard, Thanks for your prompt revision of the ULE draft and reply, I am glad that those typos won't make it to the RFC Editor! On the other hand I totally agree with the fact that the examples are hard to read, and this is due to 2 factors: 1- "SNDU A is n bytes" actually means that the "Length" field of the ULE header carries the value (n-4). However this value is referred in the drawings as "SNDU Length", which was just defined as "n" and not "(n-4)"... this is pretty much confusing indeed. 2- bytes A000, A001, A002 are *NEVER* explicitely drawn, so their position inside the TS packet is not clear. In addition, the fact that the Length Field is shown makes almost think that it does not belong to the SNDU. This might suggest that A000 is maybe the first byte after the Length field... which turns to be in fact A002 (first byte of Type field). IMHO, and for the sake of clarity,something like this could be added to the beginning of Annex A: ==================================================================== When stated that "SNDU A is n bytes", the n bytes of SNDU A are labelled from A000 to A(n-1), where: *Bytes A000 and A001 represent the 16 bits of the D-bit and the Length field. Those 2 bytes are referred in the following diagrams as "SNDU Length", and carry the decimal value: (n-4) if D-bit is 0 (2^15+n-4) if D-bit is 1 written in hexadecimal notation. *Bytes A(n-4), A(n-3), A(n-2) and A(n-1) carry the CRC of SNDU A. =================================================================== What do you think of this suggestion? Best regards, Juan C. ----- Original Message ----- From: "Bernhard Collini-Nocker" To: Sent: Tuesday, August 23, 2005 9:31 AM Subject: Re: Noticed some possible errors in the ULE draft, ANNEX A > Dear Juan, > > many thanks for this hints. You are perfectly right, some wrong numbers > have made it into the document, which need to be corrected before > publication. > > For curiosity I checked the earlier versions of the drafts and it looks as > if the first problem of this kind (calculating the Length field as being > length of SNDU including header, so 4 bytes too much) first occurred in > the Feb 2004 -02 version, (was actually meant as an improvement for > reading: instead of showing the SNDU bytes from 0 to length-1 to also > provide the Length field values). In the Oct 2004 -02 version this first > calculation error was corrected for the first example, but at the same > time the second example was "improved" with completely obscure numbers (6x > instead of Bx). Funny enough, in the same -02 version another two examples > were correctly improved, yet another one with same kind of +4 calculation. > > Apart from Yuan, again many thanks for this detailed reading, no one seems > to have recalculated or cross checked the numbers again since then. > > > Rethinking this style of reading improvement it does not seem to be such > that the examples are easier to understand at all. > If one takes for example the first part of Example A.5 (is just the > shortest one) I find it not that clear any more that SNDU A having length > 52 (4B hdr plus 48B payload) is to be counted from A000 to A051 on one > side, but since the SNDU Length field is shown the counting actually has > to start with A002 o nthe other side. > > Any hints for improvement? > > Example A.5: Three 44B PDUs. > > SNDU A is 52 bytes (no ULE destination NPA address) > SNDU B is 52 bytes (no ULE destination NPA address) > SNDU C is 52 bytes (no ULE destination NPA address) > > The sequence comprises 1 TS Packet: > > SNDU > PP=0 Length > +-----+------+------+------+- -+-----+------+-----+- -+-----+- > | HDR | 0x00 | 0x80 | 0x30 | ... | A51 |0x80 | 0x30 | ... | B51 | .. > +-----+----*-+-*----+------+- -+-----+-*----+-----+- -+-----+- > PUSI=1 * * > ***** > > The sequence comprises 1 TS Packet: > > SNDU > PP=0 Length > +-----+------+------+------+- -+-----+------+-----+- -+-----+- > | HDR | 0x00 | 0x80 | 0x30 | ... | A51 |0x80 | 0x34 | ... | B51 | .. > +-----+----*-+-*----+------+- -+-----+-*----+-----+- -+-----+- > PUSI=1 * * > ***** > > > Regards, > Bernhard > > Gorry Fairhurst wrote: >> >> Juan, thanks for the query it's easy to miss mistakes in the informative >> annexes, and we'd certainly like to get the text correct before this is >> published as a RFC. >> >> Can someone please check this out (I can't at the momment) >> >> Gorry >> >> >> Juan Cantillo wrote: >> >>> Dear Gorry, >>> I am currently working on the "01 version" of our DVB-S2 draft and >>> while re-reading the ULE-06 draft I came across what might be some >>> typographic errors in ANNEX A: >>> ********************* Page 38, example A2 "Usage of last byte in a TS >>> packet":*************** >>> The 4 shown SNDU sizes are 183, 182, 181 and 185 Bytes long, which would >>> lead to "SNDU Length" fields of 0xB3, 0xB2, 0xB1and 0xB5, resp, since: >>> 0xB3 = 183 - 4 (in decimal) >>> 0xB2 = 182 - 4 >>> 0xB1 = 181 - 4 >>> 0xB5 = 185 - 4 >>> (4 bytes are to be substracted to the length of the SNDU since the "SNDU >>> Length" field DOES NOT count the 4-byte mandatory header of ULE) >>> Instead, in the diagram we have 0x63, 0x62, 0x61and 0x65... it seems >>> that the "B" was confused with "6" ?! >>> ********************* Page 41, example A5 "three 44B >>> PDUs":******************************** >>> The three SNDUS are 52 bytes long, which would lead to "SNDU Length" of >>> 48 bytes, coded in hexadecimal as 0x30 and NOT as 0x34. >>> Please let me know whether those are typographic mistakes, or if it is >>> me who is wrong... This last hypothesis is highly probable since "the >>> errors" are similar, so I might be missing something! >>> Looking forward to hearing from you soon, >>> Juan >>> ========================= >>> Juan CANTILLO >>> SatComs PhD. Researcher >>> ENST/TeSA/ENSICA/ASP >>> +33 6 23 54 59 65 >>> Toulouse, FR >> >> > > From owner-ipdvb@erg.abdn.ac.uk Wed Aug 24 12:20:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7xyt-0001Cr-HY for ipdvb-archive@megatron.ietf.org; Wed, 24 Aug 2005 12:20:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02001 for ; Wed, 24 Aug 2005 12:20:01 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7xzE-0006GW-P1 for ipdvb-archive@ietf.org; Wed, 24 Aug 2005 12:20:25 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j7OG1OKv001924 for ; Wed, 24 Aug 2005 17:01:24 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j7OG1OBR001923 for ipdvb-subscribed-users; Wed, 24 Aug 2005 17:01:24 +0100 (BST) X-Authentication-Warning: dee.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.13.4/8.13.4) with ESMTP id j7OG1H2V001905 for ; Wed, 24 Aug 2005 17:01:17 +0100 (BST) Received: from [127.0.0.1] (milbe.cosy.sbg.ac.at [141.201.2.21]) by loewe.cosy.sbg.ac.at (8.8.8/8.8.7) with ESMTP id SAA16849 for ; Wed, 24 Aug 2005 18:01:17 +0200 (MET DST) Message-ID: <430C99A8.60107@cosy.sbg.ac.at> Date: Wed, 24 Aug 2005 18:00:40 +0200 From: Bernhard Collini-Nocker User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: Re: Noticed some possible errors in the ULE draft, ANNEX A References: <001301c5a734$8fee8a40$877a36c1@DrCerebro> <430A0599.7030901@erg.abdn.ac.uk> <430AD0D3.2050802@cosy.sbg.ac.at> <00f301c5a7fd$acd91700$877a36c1@DrCerebro> In-Reply-To: <00f301c5a7fd$acd91700$877a36c1@DrCerebro> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean X-ERG-MailScanner-SpamCheck: not spam, SpamAssassin (score=-2.599, required 6, autolearn=not spam, BAYES_00 -2.60), not spam, SpamAssassin (score=-2.599, required 6, BAYES_00 -2.60) Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Content-Transfer-Encoding: 7bit Dear Juan, Juan Cantillo wrote: > Dear Bernhard, > > Thanks for your prompt revision of the ULE draft and reply, I am glad > that those typos won't make it to the RFC Editor! thanks to you. > On the other hand I totally agree with the fact that the examples are > hard to read, and this is due to 2 factors: > > 1- "SNDU A is n bytes" actually means that the "Length" field of the > ULE header carries the value (n-4). However this value is referred in > the drawings as "SNDU Length", which was just defined as "n" and not > "(n-4)"... this is pretty much confusing indeed. The reason (but maybe more an excuse) for this fact is that the SNDU Length is earlier in the document (quite) well described in 2.4: A 15-bit value that indicates the length, in bytes, of the SNDU counted from the byte following the Type field, up to and including the CRC. Note the special case described in 4.3. I am already discussiong with Gorry whether the "following the Type field" explaination is clear enough, because maybe "following the 4B ULE base header" is cleare. What do you think? > 2- bytes A000, A001, A002 are *NEVER* explicitely drawn, so their > position inside the TS packet is not clear. In addition, the fact that > the Length Field is shown makes almost think that it does not belong to > the SNDU. This might suggest that A000 is maybe the first byte after the > Length field... which turns to be in fact A002 (first byte of Type field). As said, the attempt to include the SNDU Length field value in the examples did not necessarily add to ease of understanding. > IMHO, and for the sake of clarity,something like this could be added to > the beginning of Annex A: > ==================================================================== > When stated that "SNDU A is n bytes", the n bytes of SNDU A are > labelled from A000 to A(n-1), where: > > *Bytes A000 and A001 represent the 16 bits of the D-bit and the Length > field. Those 2 bytes are referred in the following diagrams as "SNDU > Length", and carry the decimal value: > (n-4) if D-bit is 0 > (2^15+n-4) if D-bit is 1 > written in hexadecimal notation. > > *Bytes A(n-4), A(n-3), A(n-2) and A(n-1) carry the CRC of SNDU A. > =================================================================== > > What do you think of this suggestion? Personally I think that is an very good suggestion. What do others think? One could get the impression that after the early adopters/implementers of ULE not many did the exercise again... > Best regards, > Juan C. Kind regards, Bernhard > > ----- Original Message ----- From: "Bernhard Collini-Nocker" > > To: > Sent: Tuesday, August 23, 2005 9:31 AM > Subject: Re: Noticed some possible errors in the ULE draft, ANNEX A > > >> Dear Juan, >> >> many thanks for this hints. You are perfectly right, some wrong >> numbers have made it into the document, which need to be corrected >> before publication. >> >> For curiosity I checked the earlier versions of the drafts and it >> looks as if the first problem of this kind (calculating the Length >> field as being length of SNDU including header, so 4 bytes too much) >> first occurred in the Feb 2004 -02 version, (was actually meant as an >> improvement for reading: instead of showing the SNDU bytes from 0 to >> length-1 to also provide the Length field values). In the Oct 2004 -02 >> version this first calculation error was corrected for the first >> example, but at the same time the second example was "improved" with >> completely obscure numbers (6x instead of Bx). Funny enough, in the >> same -02 version another two examples were correctly improved, yet >> another one with same kind of +4 calculation. >> >> Apart from Yuan, again many thanks for this detailed reading, no one >> seems to have recalculated or cross checked the numbers again since then. >> >> >> Rethinking this style of reading improvement it does not seem to be >> such that the examples are easier to understand at all. >> If one takes for example the first part of Example A.5 (is just the >> shortest one) I find it not that clear any more that SNDU A having >> length 52 (4B hdr plus 48B payload) is to be counted from A000 to A051 >> on one side, but since the SNDU Length field is shown the counting >> actually has to start with A002 o nthe other side. >> >> Any hints for improvement? >> >> Example A.5: Three 44B PDUs. >> >> SNDU A is 52 bytes (no ULE destination NPA address) >> SNDU B is 52 bytes (no ULE destination NPA address) >> SNDU C is 52 bytes (no ULE destination NPA address) >> >> The sequence comprises 1 TS Packet: >> >> SNDU >> PP=0 Length >> +-----+------+------+------+- -+-----+------+-----+- -+-----+- >> | HDR | 0x00 | 0x80 | 0x30 | ... | A51 |0x80 | 0x30 | ... | B51 | .. >> +-----+----*-+-*----+------+- -+-----+-*----+-----+- -+-----+- >> PUSI=1 * * >> ***** >> >> The sequence comprises 1 TS Packet: >> >> SNDU >> PP=0 Length >> +-----+------+------+------+- -+-----+------+-----+- -+-----+- >> | HDR | 0x00 | 0x80 | 0x30 | ... | A51 |0x80 | 0x34 | ... | B51 | .. >> +-----+----*-+-*----+------+- -+-----+-*----+-----+- -+-----+- >> PUSI=1 * * >> ***** >> >> >> Regards, >> Bernhard >> >> Gorry Fairhurst wrote: >> >>> >>> Juan, thanks for the query it's easy to miss mistakes in the >>> informative annexes, and we'd certainly like to get the text correct >>> before this is published as a RFC. >>> >>> Can someone please check this out (I can't at the momment) >>> >>> Gorry >>> >>> >>> Juan Cantillo wrote: >>> >>>> Dear Gorry, >>>> I am currently working on the "01 version" of our DVB-S2 draft and >>>> while re-reading the ULE-06 draft I came across what might be some >>>> typographic errors in ANNEX A: >>>> ********************* Page 38, example A2 "Usage of last byte in a >>>> TS packet":*************** >>>> The 4 shown SNDU sizes are 183, 182, 181 and 185 Bytes long, which >>>> would lead to "SNDU Length" fields of 0xB3, 0xB2, 0xB1and 0xB5, >>>> resp, since: >>>> 0xB3 = 183 - 4 (in decimal) >>>> 0xB2 = 182 - 4 >>>> 0xB1 = 181 - 4 >>>> 0xB5 = 185 - 4 >>>> (4 bytes are to be substracted to the length of the SNDU since the >>>> "SNDU Length" field DOES NOT count the 4-byte mandatory header of ULE) >>>> Instead, in the diagram we have 0x63, 0x62, 0x61and 0x65... it seems >>>> that the "B" was confused with "6" ?! >>>> ********************* Page 41, example A5 "three 44B >>>> PDUs":******************************** >>>> The three SNDUS are 52 bytes long, which would lead to "SNDU Length" >>>> of 48 bytes, coded in hexadecimal as 0x30 and NOT as 0x34. >>>> Please let me know whether those are typographic mistakes, or if it >>>> is me who is wrong... This last hypothesis is highly probable since >>>> "the errors" are similar, so I might be missing something! >>>> Looking forward to hearing from you soon, >>>> Juan >>>> ========================= >>>> Juan CANTILLO >>>> SatComs PhD. Researcher >>>> ENST/TeSA/ENSICA/ASP >>>> +33 6 23 54 59 65 >>>> Toulouse, FR >>> >>> >>> >> >> > > From owner-ipdvb@erg.abdn.ac.uk Mon Aug 29 05:20:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9foh-0007kr-6o for ipdvb-archive@megatron.ietf.org; Mon, 29 Aug 2005 05:20:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26213 for ; Mon, 29 Aug 2005 05:20:33 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9fpx-0000ga-HI for ipdvb-archive@ietf.org; Mon, 29 Aug 2005 05:21:56 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j7T979Pa021340 for ; Mon, 29 Aug 2005 10:07:09 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j7T979Rq021339 for ipdvb-subscribed-users; Mon, 29 Aug 2005 10:07:09 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from mermoz.ensica.fr (loghost.ensica.fr [192.70.110.90]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j7T970JD021316 for ; Mon, 29 Aug 2005 10:07:01 +0100 (BST) Received: from DrCerebro (localhost [127.0.0.1]) by mermoz.ensica.fr (8.10.2+Sun/jtpda-5.3.1) with SMTP id j7T97PR05592 for ; Mon, 29 Aug 2005 11:07:25 +0200 (MEST) Message-ID: <006901c5ac78$f888b910$877a36c1@DrCerebro> From: "Juan Cantillo" To: References: <001301c5a734$8fee8a40$877a36c1@DrCerebro> <430A0599.7030901@erg.abdn.ac.uk> <430AD0D3.2050802@cosy.sbg.ac.at> <00f301c5a7fd$acd91700$877a36c1@DrCerebro> <430C99A8.60107@cosy.sbg.ac.at> Subject: Re: Noticed some possible errors in the ULE draft, ANNEX A Date: Mon, 29 Aug 2005 11:06:41 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0066_01C5AC89.BBD172D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-ERG-MailScanner: Found to be clean, Found to be clean X-ERG-MailScanner-SpamCheck: not spam, SpamAssassin (score=-2.577, required 6, autolearn=not spam, BAYES_00 -2.60, HTML_30_40 0.02, HTML_MESSAGE 0.00), not spam, SpamAssassin (score=-2.577, required 6, BAYES_00 -2.60, HTML_30_40 0.02, HTML_MESSAGE 0.00) Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.6 (/) X-Scan-Signature: 1fb4c76a9d88e8fb8b791f63f8d1b07f This is a multi-part message in MIME format. ------=_NextPart_000_0066_01C5AC89.BBD172D0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Dear Bernhard, When I first read the draft, the explanation: " A 15-bit value that indicates the length, in bytes, of the SNDU counted from the byte following the Type field, up to and including the CRC. Note the special case described in 4.3." was quite clear to me (and it still is), so in my opinion this shouldn't = be modified.=20 The confusion came only when reading the examples, for the reasons (and = the errors) mentionned in the previous mails, and that is why I consider = that something should be done in order to improve their readability. The = addition of the lines I proposed might address this issue... but of = course, we hope there will be some other proposals and/or feedback from = the list on this subject. Best regards, Juan C.=20 ----- Original Message -----=20 From: Bernhard Collini-Nocker=20 To: ipdvb@erg.abdn.ac.uk=20 Sent: Wednesday, August 24, 2005 6:00 PM Subject: Re: Noticed some possible errors in the ULE draft, ANNEX A Dear Juan, Juan Cantillo wrote: > Dear Bernhard, >=20 > Thanks for your prompt revision of the ULE draft and reply, I am = glad=20 > that those typos won't make it to the RFC Editor! thanks to you. > On the other hand I totally agree with the fact that the examples = are=20 > hard to read, and this is due to 2 factors: >=20 > 1- "SNDU A is n bytes" actually means that the "Length" field of = the=20 > ULE header carries the value (n-4). However this value is referred = in=20 > the drawings as "SNDU Length", which was just defined as "n" and not = > "(n-4)"... this is pretty much confusing indeed. The reason (but maybe more an excuse) for this fact is that the SNDU=20 Length is earlier in the document (quite) well described in 2.4: A 15-bit value that indicates the length, in bytes, of the SNDU counted from the byte following the Type field, up to and = including the CRC. Note the special case described in 4.3. I am already discussiong with Gorry whether the "following the Type=20 field" explaination is clear enough, because maybe "following the 4B = ULE=20 base header" is cleare. What do you think? > 2- bytes A000, A001, A002 are *NEVER* explicitely drawn, so their=20 > position inside the TS packet is not clear. In addition, the fact = that=20 > the Length Field is shown makes almost think that it does not belong = to=20 > the SNDU. This might suggest that A000 is maybe the first byte after = the=20 > Length field... which turns to be in fact A002 (first byte of Type = field). As said, the attempt to include the SNDU Length field value in the=20 examples did not necessarily add to ease of understanding. > IMHO, and for the sake of clarity,something like this could be added = to=20 > the beginning of Annex A: > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > When stated that "SNDU A is n bytes", the n bytes of SNDU A are > labelled from A000 to A(n-1), where: >=20 > *Bytes A000 and A001 represent the 16 bits of the D-bit and the = Length > field. Those 2 bytes are referred in the following diagrams as "SNDU > Length", and carry the decimal value: > (n-4) if D-bit is 0 > (2^15+n-4) if D-bit is 1 > written in hexadecimal notation. >=20 > *Bytes A(n-4), A(n-3), A(n-2) and A(n-1) carry the CRC of SNDU A. > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > What do you think of this suggestion? Personally I think that is an very good suggestion. What do others = think? One could get the impression that after the early = adopters/implementers=20 of ULE not many did the exercise again... > Best regards, > Juan C. Kind regards, Bernhard >=20 > ----- Original Message ----- From: "Bernhard Collini-Nocker"=20 > > To: > Sent: Tuesday, August 23, 2005 9:31 AM > Subject: Re: Noticed some possible errors in the ULE draft, ANNEX A >=20 >=20 >> Dear Juan, >> >> many thanks for this hints. You are perfectly right, some wrong=20 >> numbers have made it into the document, which need to be corrected=20 >> before publication. >> >> For curiosity I checked the earlier versions of the drafts and it=20 >> looks as if the first problem of this kind (calculating the Length=20 >> field as being length of SNDU including header, so 4 bytes too = much)=20 >> first occurred in the Feb 2004 -02 version, (was actually meant as = an=20 >> improvement for reading: instead of showing the SNDU bytes from 0 = to=20 >> length-1 to also provide the Length field values). In the Oct 2004 = -02=20 >> version this first calculation error was corrected for the first=20 >> example, but at the same time the second example was "improved" = with=20 >> completely obscure numbers (6x instead of Bx). Funny enough, in the = >> same -02 version another two examples were correctly improved, yet=20 >> another one with same kind of +4 calculation. >> >> Apart from Yuan, again many thanks for this detailed reading, no = one=20 >> seems to have recalculated or cross checked the numbers again since = then. >> >> >> Rethinking this style of reading improvement it does not seem to be = >> such that the examples are easier to understand at all. >> If one takes for example the first part of Example A.5 (is just the = >> shortest one) I find it not that clear any more that SNDU A having=20 >> length 52 (4B hdr plus 48B payload) is to be counted from A000 to = A051=20 >> on one side, but since the SNDU Length field is shown the counting=20 >> actually has to start with A002 o nthe other side. >> >> Any hints for improvement? >> >> Example A.5: Three 44B PDUs. >> >> SNDU A is 52 bytes (no ULE destination NPA address) >> SNDU B is 52 bytes (no ULE destination NPA address) >> SNDU C is 52 bytes (no ULE destination NPA address) >> >> The sequence comprises 1 TS Packet: >> >> SNDU >> PP=3D0 Length >> +-----+------+------+------+- -+-----+------+-----+- = -+-----+- >> | HDR | 0x00 | 0x80 | 0x30 | ... | A51 |0x80 | 0x30 | ... | B51 = | .. >> +-----+----*-+-*----+------+- -+-----+-*----+-----+- = -+-----+- >> PUSI=3D1 * * >> ***** >> >> The sequence comprises 1 TS Packet: >> >> SNDU >> PP=3D0 Length >> +-----+------+------+------+- -+-----+------+-----+- = -+-----+- >> | HDR | 0x00 | 0x80 | 0x30 | ... | A51 |0x80 | 0x34 | ... | B51 = | .. >> +-----+----*-+-*----+------+- -+-----+-*----+-----+- = -+-----+- >> PUSI=3D1 * * >> ***** >> >> >> Regards, >> Bernhard >> >> Gorry Fairhurst wrote: >> >>> >>> Juan, thanks for the query it's easy to miss mistakes in the=20 >>> informative annexes, and we'd certainly like to get the text = correct=20 >>> before this is published as a RFC. >>> >>> Can someone please check this out (I can't at the momment) >>> >>> Gorry >>> >>> >>> Juan Cantillo wrote: >>> >>>> Dear Gorry, >>>> I am currently working on the "01 version" of our DVB-S2 draft = and=20 >>>> while re-reading the ULE-06 draft I came across what might be = some=20 >>>> typographic errors in ANNEX A: >>>> ********************* Page 38, example A2 "Usage of last byte in = a=20 >>>> TS packet":*************** >>>> The 4 shown SNDU sizes are 183, 182, 181 and 185 Bytes long, = which=20 >>>> would lead to "SNDU Length" fields of 0xB3, 0xB2, 0xB1and 0xB5,=20 >>>> resp, since: >>>> 0xB3 =3D 183 - 4 (in decimal) >>>> 0xB2 =3D 182 - 4 >>>> 0xB1 =3D 181 - 4 >>>> 0xB5 =3D 185 - 4 >>>> (4 bytes are to be substracted to the length of the SNDU since = the=20 >>>> "SNDU Length" field DOES NOT count the 4-byte mandatory header of = ULE) >>>> Instead, in the diagram we have 0x63, 0x62, 0x61and 0x65... it = seems=20 >>>> that the "B" was confused with "6" ?! >>>> ********************* Page 41, example A5 "three 44B=20 >>>> PDUs":******************************** >>>> The three SNDUS are 52 bytes long, which would lead to "SNDU = Length"=20 >>>> of 48 bytes, coded in hexadecimal as 0x30 and NOT as 0x34. >>>> Please let me know whether those are typographic mistakes, or if = it=20 >>>> is me who is wrong... This last hypothesis is highly probable = since=20 >>>> "the errors" are similar, so I might be missing something! >>>> Looking forward to hearing from you soon, >>>> Juan >>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >>>> Juan CANTILLO >>>> SatComs PhD. Researcher >>>> ENST/TeSA/ENSICA/ASP >>>> +33 6 23 54 59 65 >>>> Toulouse, FR >>> >>> >>> >> >> >=20 >=20 ------=_NextPart_000_0066_01C5AC89.BBD172D0 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable
Dear Bernhard,
 
When I first read the draft, the=20 explanation:
 
" A 15-bit value = that=20 indicates the length, in bytes, of the SNDU
    = counted from=20 the byte following the Type field, up to and = including
    the=20 CRC. Note the special case described in 4.3."
 
was quite clear to = me (and it=20 still is), so in my opinion this shouldn't be modified. =
 
The confusion came = only when=20 reading the examples, for the reasons (and the errors) mentionned = in the=20 previous mails, and that=20 is why I consider that something should be done in order to improve = their=20 readability. The addition=20 of the lines I proposed might address this issue... but of course, we = hope there=20 will be some other proposals and/or feedback=20 from the list on this subject.
 
Best regards,
 
Juan C. 
 
----- Original Message -----
From:=20 Bernhard=20 Collini-Nocker
Sent: Wednesday, August 24, = 2005 6:00=20 PM
Subject: Re: Noticed some = possible errors=20 in the ULE draft, ANNEX A

Dear Juan,

Juan Cantillo wrote:
> Dear=20 Bernhard,
>
> Thanks for your prompt revision of the ULE = draft=20 and reply, I am glad
> that those typos won't make it to the = RFC=20 Editor!

thanks to you.

> On the other hand I totally = agree=20 with the fact that the examples are
> hard to read, and this is = due to=20 2 factors:
>
>  1- "SNDU A is n bytes" actually = means that=20 the "Length" field of the
> ULE header carries the value (n-4). = However=20 this value is referred in
> the drawings as "SNDU Length", = which was=20 just defined as "n" and not
> "(n-4)"... this is pretty much = confusing=20 indeed.

The reason (but maybe more an excuse) for this fact is = that the=20 SNDU
Length is earlier in the document (quite) well described in=20 2.4:

    A 15-bit value that indicates the = length, in=20 bytes, of the SNDU
    counted from the byte = following the=20 Type field, up to and including
    the CRC. Note = the=20 special case described in 4.3.

I am already discussiong with = Gorry=20 whether the "following the Type
field" explaination is clear = enough,=20 because maybe "following the 4B ULE
base header" is cleare. What = do you=20 think?

>  2- bytes A000, A001, A002 are *NEVER* = explicitely=20 drawn, so their
> position inside the TS packet is not clear. = In=20 addition, the fact that
> the Length Field is shown makes = almost think=20 that it does not belong to
> the SNDU. This might suggest that = A000 is=20 maybe the first byte after the
> Length field... which turns to = be in=20 fact A002 (first byte of Type field).

As said, the attempt to = include=20 the SNDU Length field value in the
examples did not necessarily = add to=20 ease of understanding.

> IMHO, and for the sake of = clarity,something=20 like this could be added to
> the beginning of Annex A:
> = = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20 When stated that "SNDU A is n bytes", the n bytes of SNDU A = are
>=20 labelled from A000 to A(n-1), where:
>
> *Bytes A000 and = A001=20 represent the 16 bits of the D-bit and the Length
> field. Those = 2 bytes=20 are referred in the following diagrams as "SNDU
> Length", and = carry the=20 decimal value:
>         = (n-4)      if D-bit is=20 0
>         (2^15+n-4) = if D-bit=20 is 1
> written in hexadecimal notation.
>
> *Bytes = A(n-4),=20 A(n-3), A(n-2) and A(n-1) carry the CRC of SNDU A.
>=20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> What do you think of this suggestion?

Personally I = think that=20 is an very good suggestion. What do others think?
One could get the = impression that after the early adopters/implementers
of ULE not = many did=20 the exercise again...

> Best regards,
> Juan=20 C.


Kind regards,
Bernhard

>
> ----- = Original=20 Message ----- From: "Bernhard Collini-Nocker"
> <bnocker@cosy.sbg.ac.at>
= >=20 To: <ipdvb@erg.abdn.ac.uk>
>= Sent:=20 Tuesday, August 23, 2005 9:31 AM
> Subject: Re: Noticed some = possible=20 errors in the ULE draft, ANNEX A
>
>
>> Dear=20 Juan,
>>
>> many thanks for this hints. You are = perfectly=20 right, some wrong
>> numbers have made it into the document, = which=20 need to be corrected
>> before = publication.
>>
>>=20 For curiosity I checked the earlier versions of the drafts and it =
>>=20 looks as if the first problem of this kind (calculating the Length=20
>> field as being length of SNDU including header, so 4 = bytes too=20 much)
>> first occurred in the Feb 2004 -02 version, (was = actually=20 meant as an
>> improvement for reading: instead of showing = the SNDU=20 bytes from 0 to
>> length-1 to also provide the Length field = values). In the Oct 2004 -02
>> version this first = calculation error=20 was corrected for the first
>> example, but at the same time = the=20 second example was "improved" with
>> completely obscure = numbers (6x=20 instead of Bx). Funny enough, in the
>> same -02 version = another two=20 examples were correctly improved, yet
>> another one with = same kind=20 of +4 calculation.
>>
>> Apart from Yuan, again many = thanks=20 for this detailed reading, no one
>> seems to have = recalculated or=20 cross checked the numbers again since=20 then.
>>
>>
>> Rethinking this style of = reading=20 improvement it does not seem to be
>> such that the examples = are=20 easier to understand at all.
>> If one takes for example the = first=20 part of Example A.5 (is just the
>> shortest one) I find it = not that=20 clear any more that SNDU A having
>> length 52 (4B hdr plus = 48B=20 payload) is to be counted from A000 to A051
>> on one side, = but=20 since the SNDU Length field is shown the counting
>> = actually has to=20 start with A002 o nthe other side.
>>
>> Any hints = for=20 improvement?
>>
>>    Example A.5: = Three 44B=20 PDUs.
>>
>>      SNDU A is = 52 bytes=20 (no ULE destination NPA = address)
>>     =20 SNDU B is 52 bytes (no ULE destination NPA=20 address)
>>      SNDU C is 52 bytes = (no ULE=20 destination NPA address)
>>
>>    The = sequence comprises 1 TS=20 = Packet:
>>
>>       =             &= nbsp;  =20 = SNDU
>>         &nb= sp; =20 PP=3D0      = Length
>>   =20 +-----+------+------+------+-   = -+-----+------+-----+-  =20 -+-----+-
>>    | HDR | 0x00 | 0x80 | 0x30 | = ... | A51=20 |0x80 | 0x30 | ... | B51 | ..
>>   =20 +-----+----*-+-*----+------+-   = -+-----+-*----+-----+-  =20 -+-----+-
>>    = PUSI=3D1    =20 *  =20 = *
>>          =     =20 *****
>>
>>    The sequence comprises = 1 TS=20 = Packet:
>>
>>       =             &= nbsp;  =20 = SNDU
>>         &nb= sp; =20 PP=3D0      = Length
>>   =20 +-----+------+------+------+-   = -+-----+------+-----+-  =20 -+-----+-
>>    | HDR | 0x00 | 0x80 | 0x30 | = ... | A51=20 |0x80 | 0x34 | ... | B51 | ..
>>   =20 +-----+----*-+-*----+------+-   = -+-----+-*----+-----+-  =20 -+-----+-
>>    = PUSI=3D1    =20 *  =20 = *
>>          =     =20 *****
>>
>>
>> Regards,
>>=20 Bernhard
>>
>> Gorry Fairhurst=20 wrote:
>>
>>>
>>> Juan, thanks for = the query=20 it's easy to miss mistakes in the
>>> informative = annexes, and=20 we'd certainly like to get the text correct
>>> before = this is=20 published as a RFC.
>>>
>>> Can someone please = check=20 this out (I can't at the momment)
>>>
>>>=20 Gorry
>>>
>>>
>>> Juan Cantillo=20 wrote:
>>>
>>>> Dear=20 Gorry,
>>>>  I am currently working on the "01 = version" of=20 our DVB-S2 draft and
>>>> while re-reading the ULE-06 = draft I=20 came across what might be some
>>>> typographic errors = in=20 ANNEX A:
>>>>  ********************* Page 38, = example A2=20 "Usage of last byte in a
>>>> TS=20 packet":***************
>>>> The 4 shown SNDU sizes are = 183,=20 182, 181 and 185 Bytes long, which
>>>> would lead to = "SNDU=20 Length" fields of 0xB3, 0xB2, 0xB1and 0xB5,
>>>> resp, = since:
>>>> 0xB3 =3D 183 - 4 (in = decimal)
>>>>=20 0xB2 =3D 182 - 4
>>>> 0xB1 =3D 181 - = 4
>>>> 0xB5 =3D=20 185 - 4
>>>> (4 bytes are to be substracted to the = length of=20 the SNDU since the
>>>> "SNDU Length" field DOES NOT = count the=20 4-byte mandatory header of ULE)
>>>> Instead, in the = diagram we=20 have 0x63, 0x62, 0x61and 0x65... it seems
>>>> that = the "B"=20 was confused with "6" ?!
>>>>  = ********************* Page=20 41, example A5 "three 44B
>>>>=20 PDUs":********************************
>>>> The three = SNDUS are=20 52 bytes long, which would lead to "SNDU Length"
>>>> = of 48=20 bytes, coded in hexadecimal as 0x30 and NOT as = 0x34.
>>>> =20 Please let me know whether those are typographic mistakes, or if it=20
>>>> is me who is wrong... This last hypothesis is = highly=20 probable since
>>>> "the errors" are similar, so I = might be=20 missing something!
>>>>  Looking forward to = hearing from=20 you soon,
>>>>  Juan
>>>> =20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
>>>> Juan=20 CANTILLO
>>>> SatComs PhD. = Researcher
>>>>=20 ENST/TeSA/ENSICA/ASP
>>>> +33 6 23 54 59 = 65
>>>>=20 Toulouse,=20 = FR
>>>
>>>
>>>
>>
>>= ;
>=20
>

------=_NextPart_000_0066_01C5AC89.BBD172D0-- From owner-ipdvb@erg.abdn.ac.uk Mon Aug 29 11:28:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9lYR-0000I9-2I for ipdvb-archive@megatron.ietf.org; Mon, 29 Aug 2005 11:28:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16615 for ; Mon, 29 Aug 2005 11:28:05 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9lZi-0003QY-7H for ipdvb-archive@ietf.org; Mon, 29 Aug 2005 11:29:31 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j7TFKRAH003924 for ; Mon, 29 Aug 2005 16:20:27 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j7TFKRTf003923 for ipdvb-subscribed-users; Mon, 29 Aug 2005 16:20:27 +0100 (BST) X-Authentication-Warning: dee.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.13.4/8.13.4) with ESMTP id j7TFKBt1003904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 29 Aug 2005 16:20:11 +0100 (BST) Message-ID: <431327AD.8000601@erg.abdn.ac.uk> Date: Mon, 29 Aug 2005 16:20:13 +0100 From: Gorry Fairhurst Organization: University 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 CC: Haitham Cruickshank , jo@netlab.hut.fi, stiemerling@netlab.nec.de Subject: Draft Minutes for ipdvb at IETF-63, Paris. Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-ERG-MailScanner: Found to be clean, Found to be clean X-ERG-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-5.899, required 6, autolearn=not spam, ALL_TRUSTED -3.30, BAYES_00 -2.60), not spam, SpamAssassin (score=-5.899, required 6, ALL_TRUSTED -3.30, BAYES_00 -2.60) 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 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by erg.abdn.ac.uk id j7TFKRAH003924 X-Spam-Score: 0.0 (/) X-Scan-Signature: d49da3f50144c227c0d2fac65d3953e6 Content-Transfer-Encoding: quoted-printable Draft copies of the minutes. As ever, thanks to Joerg for doing a draft copy! This year, we didn't have the audio archive - and so my edit and updates = are=20 therefore also inserted from handwritten notes, rather than a recording. Please do check and see if there are any mistakes. Let have any correctio= ns asap! Best wishes, Gorry -- Minutes of IP over Digital Video Broadcast WG (ipdvb) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D CHAIR: Gorry Fairhurst Minutes reported by J=F6rg Ott . The IPDVB WG met once at the 63rd IETF (3 August 2005, 1030-1230). The me= eting=20 was chaired by Gorry Fairhurst. The proposed agenda was accepted, no=20 additions were made. A tentatively scheduled presentation from Fraunhofe= r=20 Gesellschaft (draft-miloucheva-udlr-mipv6-00.txt ) was cancelled, becaus= e no=20 presenter was available. Document Status --------------- The chair reported on the document status: Two documents are in the RFC e= ditor=20 queue: draft-ietf-ipdvb-ule-06 (for Proposed Standard) and=20 draft-ietf-ipdvb-arch-04 (for Informational). No other documents are in t= he=20 IETF process beyond discussion in the WG. There is one active WG draft, draft-ietf-ipdvb-ar-00.txt which had supers= eded=20 draft-fair-ipdvb-ar-03.txt. Further drafts to be discussed at the meeting include draft-stiemerling-ipdvb-config-01.txt draft-cruickshank-ipdvb-sec-00.txt, draft-cantillo-ipdvb-s2encaps-00.txt, and draft-bormann-rohc-over-802-01.txt. On the ROHC draft, Carsten Bormann noted that only one minor problem stil= l=20 remains to be solved for the Ethernet case: to get a number assigned. Th= en=20 one can define a protocol to negotiate the context. A future draft could=20 potentially address both ULE and Ethernet, and for ULE this could piggyba= ck on=20 whatever config approach IPDVB will take. The present draft -01 will rem= ain=20 active. Volunteers are required to progress the address resolution protocol and=20 perhaps to to revive draft-montpetit-ipdvb-config-00.txt, expired. Gorry reviewed the WG milestones noting a new WG draft on AR process, bu= t=20 that there was currently no WG document for address resolution protocol (= was=20 supposed to be available as -00 in Feb 2005). The deadline has been post= poned=20 with agreement from the Area Director. Uni-directional Lightweight Encapsulation ----------------------------------------- draft-ietf-ipdvb-ule-06.txt Gorry Fairhurst present a brief update on the ULE spec. Revision -05 was= =20 submitted to the IESG. Revision -06, that was published recently, has the= =20 comments of the IESG review folded in. Refer to the slides for a detaile= d=20 list of changes. Gorry pointed out a substantial change regarding the IA= NA=20 registration procedures. He also pointed at the new document title: it=20 changed from "Ultra-Lightweight Encapsulation" to "Uni-directional Lightw= eight=20 Encapsulation". A comment was made that ULE should also applicable to DV= B-RCS=20 and is thus not limited to uni-directional communications. There were=20 suggestions on finding a better expansion of the letter "U" in the spec's= =20 title, but this is not felt to be serious and the new name was accepted. Gorry noted also that until recently, ULE had not defined a=20 "format_identifier" that would be needed in the context of an MPEG TS=20 multiplex to identify the ULE stream in the SI signalling. The value=20 0x554C4531 has now been assigned for use with ULE by SMPTE (the ISO regi= stry=20 for SI values). Similar registration requests could be made for a "Stream_Type" where registries are maintained by DVB, and ATSC= .=20 It was also possible to consider allocating a "Data_broadcast_ID", althou= gh=20 this was normally used with table sections, and therefore was necessarily= =20 appropriate to ULE. If there is a strong desire for a "Data_broadcast_I= D",=20 this should be taken to the list. Finally, Gorry provided an update on ULE implementations: various commerc= ial=20 and open source receivers are available at this point but only commercial= =20 gateways (i.e., senders). Some at the meeting noted that the European I= ST=20 project Daidalos is developing an implementation with the work carried ou= t by=20 Fraunhofer Gesellschaft; however, Gorry was unable to say whether or not = the=20 result will be open source. Information about known implementations can= be=20 found at http://www.erg.abdn.ac.uk/ipdvb/ipdvb-impl.html and implementers are=20 encouraged to provide additional/updated information regarding this page. Address Resolution ------------------ draft-ietf-ipdvb-ar-00.txt Gorry briefly reported behalf of Marie-Jos=E9 Montpetit. Address resolut= ion is=20 about associating IPv4/IPv6 addresses with an MPEG-2 TS.The draft was ado= pted=20 as a WG document and recent changes reflect much previous input from the = UDLR=20 WG, various nits, and a major reorganisation of the the sections. Furth= er=20 details are in the slides. Gorry strongly encouraged input from the group on a number of intended fu= ture=20 changes (also listed in the slides). IP Address Configuration for ipdvb ---------------------------------- draft-stiemerling-ipdvb-config-01.txt Martin Stiemerling gave a short intro to the draft's history and then=20 proceeded to summarise the changes to the draft (see slides). He rehashe= d the=20 problem space as well as the network and configuration scenarios (already= =20 introduced at the last IETF). Agreement within the group is needed on th= ese=20 issues and so he solicits feedback in order to proceed. One question fro= m the=20 audience was raised: why not simply use IPv6 autoconfig? Martin responde= d=20 that there is a potential stability issue as IPDVB may be faced with 10s = of=20 thousands of receivers, and that other parameters (not currently specifie= d by=20 the NDP) may be required. Martin concluded, stating that a new draft wil= l be=20 available in the Sep/Oct timeframe. ULE Security Extension ---------------------- draft-cruickshank-ipdvb-sec-00.txt Haitham Cruikshank presented some proposed security extensions for ULE, a= =20 subject that was already raised at the last IETF, but no feedback was=20 received on the list afterwards. He noted that there had been a parallel= =20 presentation in the MSEC WG (which could provide appropriate review for t= he=20 key-management functions). He briefly reviewed the comments received on = this=20 matter at the last IETF meeting (see slides and minutes from the 62nd IET= F)=20 and gave an overview of the changes. He proceeded with a motivation for = ULE=20 security and requirements for IP over MPEG-2 TS (see slides 3 and 4). In= =20 particular, he stated that the ULE security shall not be a replacement fo= r=20 security at other layers and shall help to maintain transparency with=20 Performance Enhancing Proxies (PEPs). Haitham went ahead to discuss the=20 proposed approach (see slides 5--8) and then suggested future plans for t= he=20 next revision (slide 9). There was discussion about the number of keys that would need to be manag= ed,=20 and Haitham was asked if all entities shared a single key? - Haitham note= d=20 that the proposal could live with a only single key at each receiver for = all=20 unicast flows sent to a receiver, and perhaps one key per flow (as in mse= c)=20 for multicast flows. There was discussion about whether one key for all=20 receivers was possible, which provoked doubt in the audience that this was really advantageous. Looking at the proposed packet format and the presentation, Steve Bellovi= n=20 noted that authentication of the source of data was essential. In practi= ce,=20 this required at least a sequence number and a crypto integrity check. H= e=20 affirmed that using only a single key for all the network traffic was a=20 mistake as this would make attacks on confidentiality much easier. With reference to the sample ULE packet format a question was raised which part of it would be encrypted. Haitham responded that this is the "SNDU payload", potentially including arbitrary inner extension heade= rs. Haitham pointed out that the approach chosen allows also non-IP packets t= o be=20 secured by ULE. A comment from the MSEC WG was made whether or not IP-ba= sed=20 key management could also be used for non-IP packets -- which Haitham=20 confirmed: this was explicitly included in the current requirements. Steve Bellovin asked if there was a method defined that would allow the = SID=20 to be applied to non-IP traffic, because current IPsec relies on port num= bers,=20 etc to define the flows within the Security Policy Database (SPD). New=20 entries/methods would be required if layer 2 frames were be to encrypted.= He=20 also urged caution regarding multicast traffic. In particular, he argued= that=20 a good justification is needed for doing non-IP traffic security in the I= ETF,=20 and that this would need input and review from the Security Area. Any modifications to the SPD and its use shouldn't be done in an=20 Internet Area working group. He went on to state that the ULE security designers should not make=20 simplifying assumptions about capabilities of attackers (hinting at the=20 missing HMACs). He further noted that HMACs are pretty much free (in ter= ms of=20 processing, but not protocol overhead) at data rates around 100 Mbit/s. Joerg Ott raised concerns that the case for the inclusion of security at = the=20 ULE layer is still not really motivated. He noted that TCP PEPs could we= ll=20 work with IPsec (if just applied at the right point which also applied to= ULE=20 security). He encouraged the authors to perform at least a detailed anal= ysis=20 of why IPsec cannot/should not be used. During the discussion, it was noted that two things can be bought by L2=20 encryption: some degree of medium access control and prevention of traffi= c=20 analysis (the latter only partially, however, since there is other inform= ation=20 available). Margaret Wasserman stated that she was concerned that if the non-IP traff= ic=20 required a new infrastructure, then this may not be appropriate work for= the=20 group. If the group decided to go with IP traffic only, IPsec key manage= ment=20 may be appropriate. She also noted that the authors seemed to be looking= for=20 something in between - were bridging and IP traffic equally important? A= t the=20 moment, she is not sure whether there is something to work on. People are encouraged to look into this problem since it requires a broad= =20 analysis, and a separate requirements document (as an I-D) would be the b= est=20 way forward, so that the WG can understand the issues to be addressed. Th= is=20 also will allow the ADs to understand the motivation/needs/objectives. St= eve=20 volunteered to help understand the threat analysis and would send some=20 references as a starting point to the authors. IP Encapsulation for DVB-S.2 ---------------------------- draft-cantillo-ipdvb-s2encaps-00.txt J=E9rome Lacan presented some requirements for transmission of IP datagra= ms over=20 DVB-S2 (see slides). He gave a quick overview of DVB-S2 and particularly= the=20 available framing formats. Besides MPEG TS, DVB-S2 will also allow for=20 "generic streams" that are IP friendly and do no longer require fixed-siz= e=20 frames. While, for IP encapsulation, IP over ULE/PPoE via MPEG TS over D= VB-S2=20 is possible, no choice had been made for adaptation layer using the Gene= ric=20 Stream. Moreover, the capabilities of generic streams suggest the develo= pment=20 of a new adaptation layer. J=E9rome presents some basic ideas and issues= to=20 that end (see slides). Joerg Ott remarks that TU Braunschweig is working on an all-IP encapsulat= ion=20 (without ULE/PPoE) for DVB. Gorry said a number of other people had also= =20 voiced interest and on-going projects in this area to the ipdvb list. Rod= =20 Walsh pointed out that the definition of such an adaptation layer could b= e=20 completely out of scope. Instead of pursuing this work in the IETF, it ma= y=20 also be possible to provide input to DVB. Gorry Fairhurst said that he was aware of the parallel work within DVB-GB= S,=20 and the work in an ad-hoc WG on the design of a new encapsulation. There = was a=20 good liaison with this group. He said this work had proved more difficult= than=20 first envisaged, and that there were complex dependencies between the phy= sical=20 layer needs and the IP network functions. These were not yet well unders= tood,=20 and a clear definition of the requirements would be good for all. The ad-= hoc=20 group responsible for this work were aware of this draft, and of the=20 discussions within the ipdvb list. Gorry Fairhurst asked whether a DVB-S2 mechanism should be something=20 completely different or some adaptation of ULE? J=E9rome does not see a=20 necessity for a completely different approach, but also indicates that UL= E is=20 not directly applicable for cases with no MPEG-2 TS, as in DVB-S2. An inquiry from the chair showed that few in the room had read (or was aw= are)=20 of the draft. So, he urged the group to read and comment on it. The dra= ft=20 will be updated in September. Review of Milestones -------------------- Finally, Gorry Fairhurst returned to the status of the milestones (see ab= ove)=20 and strongly urged the group to provide input on the address resolution a= s=20 this is now the most pressing work item. From owner-ipdvb@erg.abdn.ac.uk Mon Aug 29 13:46:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9niB-00028e-4M for ipdvb-archive@megatron.ietf.org; Mon, 29 Aug 2005 13:46:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23274 for ; Mon, 29 Aug 2005 13:46:22 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9njT-0007OA-LB for ipdvb-archive@ietf.org; Mon, 29 Aug 2005 13:47:46 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j7THgDuI008849 for ; Mon, 29 Aug 2005 18:42:13 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j7THgDmk008848 for ipdvb-subscribed-users; Mon, 29 Aug 2005 18:42:13 +0100 (BST) X-Authentication-Warning: dee.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.13.4/8.13.4) with ESMTP id j7THg7nZ008830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 29 Aug 2005 18:42:07 +0100 (BST) Message-ID: <431348EF.90900@erg.abdn.ac.uk> Date: Mon, 29 Aug 2005 18:42:07 +0100 From: Gorry Fairhurst Organization: University 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: juan.cantillo@supaero.org CC: ipdvb@erg.abdn.ac.uk Subject: Re: Some typos on the minutes! (continued) References: <20050829162719.33036.qmail@web26508.mail.ukl.yahoo.com> In-Reply-To: <20050829162719.33036.qmail@web26508.mail.ukl.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-ERG-MailScanner: Found to be clean, Found to be clean X-ERG-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-5.899, required 6, autolearn=not spam, ALL_TRUSTED -3.30, BAYES_00 -2.60), not spam, SpamAssassin (score=-5.899, required 6, ALL_TRUSTED -3.30, BAYES_00 -2.60) 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 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by erg.abdn.ac.uk id j7THgDuI008849 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Juan Cantillo wrote: > Dear Gorry, > =20 > It looks that this was my week for spotting errors in the documents=20 > addressed to the list :-) > In the minutes done by Joerg, there are 2 small things to review in our= =20 > opinion: > =20 > 1- It was me (Juan Cantillo) and not Jerome Lacan who presented the=20 > draft during the meeting, even though Jerome is one of the authors of=20 > the document. > =20 OK - I'll get that corrected. > 2- Jerome and I don't remember that the DVB-S2 draft was ever qualified= =20 > as beeing "completely out of scope"... Instead, Rod Walsh pointed out=20 > that it might be "politically risky" to continue in this direction=20 > without DVB, as an IETF standardisation initiative now might lead to=20 > conflicts between DVB and IETF. > =20 How about - "Rod Walsh pointed out that the definition of such an adaptat= ion=20 layer would require coordination with DVB to avoid conflicts in the futur= e." > That's all I think. Thanks to Joerg! > =20 > Juan C. > Jerome L. >=20 > -----------------------------------------------------------------------= - > Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messen= ger > T=E9l=E9chargez le ici !=20 > =20 >=20 From owner-ipdvb@erg.abdn.ac.uk Mon Aug 29 16:08:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9pvE-0000pp-4a for ipdvb-archive@megatron.ietf.org; Mon, 29 Aug 2005 16:08:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03700 for ; Mon, 29 Aug 2005 16:07:58 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9pwb-0003ks-4e for ipdvb-archive@ietf.org; Mon, 29 Aug 2005 16:09:27 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j7TK2H9k014078 for ; Mon, 29 Aug 2005 21:02:17 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j7TK2HaW014077 for ipdvb-subscribed-users; Mon, 29 Aug 2005 21:02:17 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from bonnie.ses-astra.com (bonnie.ses-astra.com [213.169.104.54]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j7TK2B6u014058 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 29 Aug 2005 21:02:11 +0100 (BST) Received: from marge.gen.btz.aia.lu (marge.gen.btz.aia.lu [193.168.96.8]) by bonnie.ses-astra.com (8.12.10/8.12.10) with ESMTP id j7TK29Q9027461 for ; Mon, 29 Aug 2005 22:02:10 +0200 (CEST) Subject: Joel Grotz is out of office. From: Joel.Grotz@ses-astra.com To: ipdvb@erg.abdn.ac.uk Message-ID: Date: Mon, 29 Aug 2005 22:02:08 +0200 X-MIMETrack: Serialize by Router on marge/BTZ(Release 6.5.4|March 27, 2005) at 29/08/2005 22:02:10 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-ERG-MailScanner: Found to be clean, Found to be clean X-ERG-MailScanner-SpamCheck: not spam, SpamAssassin (score=-2.593, required 6, BAYES_00 -2.60, NO_REAL_NAME 0.01, SPF_HELO_PASS -0.00), not spam, SpamAssassin (score=-2.593, required 6, BAYES_00 -2.60, NO_REAL_NAME 0.01, SPF_HELO_PASS -0.00) Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.3 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 I will be out of the office starting 24/08/2005 and will not return until 19/09/2005. If required, I will respond to your message when I return to office. For urgent matters, please contact either: Jens.Krause@ses-astra.com or Jean-Pierre.Choffray@ses-astra.com Best Regards, Joel Grotz SES ASTRA -- DISCLAIMER: This e-mail contains proprietary information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail. If you are not the intended recipient you must not use, disclose, distribute, copy, print, or rely on this e-mail.