From owner-ip-dvb@erg.abdn.ac.uk Mon Feb 2 14:20:41 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i12EK4sf020130 for ; Mon, 2 Feb 2004 14:20:04 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i12EK4x6020129 for ip-dvb-subscribed-users; Mon, 2 Feb 2004 14:20:04 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from tokyo.ccrle.nec.de (tokyo.netlab.nec.de [195.37.70.2]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i12EJOLn020083 for ; Mon, 2 Feb 2004 14:19:25 GMT Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i12EJFN8021233 for ; Mon, 2 Feb 2004 15:19:17 +0100 (CET) Received: from yamato.ccrle.nec.de (jupiter.office [10.1.1.3]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with SMTP id AFA2CFFD49; Mon, 2 Feb 2004 15:19:14 +0100 (CET) Received: from 10.1.1.83 (SquirrelMail authenticated user martin) by yamato.ccrle.nec.de with HTTP; Mon, 2 Feb 2004 15:19:15 +0100 (CET) Message-ID: <4860.10.1.1.83.1075731555.squirrel@yamato.ccrle.nec.de> In-Reply-To: <40044DFC.9090400@erg.abdn.ac.uk> References: <2BF0AD29BC31FE46B7887732114404310357E83F@trebe003.europe.nokia.com> <40042954.E7D60601@hns.com> <40044DFC.9090400@erg.abdn.ac.uk> Date: Mon, 2 Feb 2004 15:19:15 +0100 (CET) Subject: Re: Seoul From: "Martin Stiemerling" To: ip-dvb@erg.abdn.ac.uk Cc: ip-dvb@erg.abdn.ac.uk User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Scanned-By: MIMEDefang 2.35 X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Hi Gorry, it would be great to have a WG session or at least some face-to-face discussions at the next IETF meeting in Seoul. I have some comments on the requirement documents and will post them within the next days (currently busy). Regards, Martin > John, > > We are still not an IETF working group, but there has been progress > behind the scenes. > > A proposed charter for this WG was circulated by the IESG to the IETF > and Internet Area Chairs before the last Minneapolis IETF meeting. > There was some feedback that we have been working to address resulting > in the latest version of our proposed charter text below. We're still > working to tune the milestones, etc. but I am expecting that this > charter will be submited to the IESG for consideration at their next > meeting on 22-Jan. > > We've had BoFs at the previous two IETFs. I am undecided about the need > to call a meeting in Seoul (so if *anyone* has views, please do tell the > list). It seems we are making progress with the ULE Spec, and that the > requirements document is now in a position where the WG could offer > comments and suggestions. > > If there is a need to meet, I'd be very willing to ask for a meeting > slot, but obviously not all groups can meet at every IETF (there simply > wouldn't be space), so the question is I guess, are there issues that > need to be discussed, agenda items, or new inputs that we can expect in > the next month? > > Gorry > > ------- > > > IP over MPEG-2/DVB (ipdvb) > > Chair(s): > Gorry Fairhurst > > Responsible Area Director: > Margaret Wasserman > > Mailing Lists: > General Discussion: ip-dvb@erg.abdn.ac.uk > To subscribe: subscribe ip-dvb at majordomo@erg.abdn.ac.uk > Archive: http://www.erg.abdn.ac.uk/ip-dvb/archive/ > > Description of Working Group: > The WG will develop new protocols and architectures to enable better > deployment of IP over MPEG-2 transport and provide easier interworking > with IP networks. Specific properties of this subnetwork technology > include link-layer support for unicast and multicast, large numbers > of down-stream receivers, and efficiency of transmission. These > properties resemble those in some other wireless networks. The specific > ndards: DVB-RCS; DVB-S and DVB-T and related ATSC Specifications) in > protocols on the existing generation of networks. > > The WG will endeavour to reuse existing open standard technologies, > giving guidance on usage in IP networks, whenever they are able to > fulfil requirements. For instance, it acknowledges the existing > Multiprotocol Encapsulation (MPE) [ATSC A/90;ETSI EN 301192] and that > this will continue to be deployed in the future to develop new markets. > Any alternative encapsulation would need to co-exist with MPE. > > Appropriate standards will be defined to support transmission of IPv4 > and IPv6 datagrams between IP networks connected using MPEG-2 transport > subnetworks. This includes options for encapsulation, dynamic unicast > address resolution for IPv4/IPv6, and the mechanisms needed to map > routed IP multicast traffic to the MPEG-2 transport subnetwork. The > standards will be appropriate to both MPE and any alternative > encapsulation method developed. The developed protocols may also be > applicable to other multicast enabled subnetwork technologies supporting > large numbers of directly connected systems. > > The current list of work items is: > Specify the requirements and architecture for supporting IPv4/IPv6 via > MPEG-2 transmission networks. Such requirements should consider the range > of platforms currently (or anticipated to be) in use. This draft will be > an Informational RFC. > > Define a standards-track RFC defining an efficient encapsulation method. > The design will consider the need for MAC addresses, the potential need > for synchronisation between streams, support for a wide range of IPv4/IPv6 > and multicast traffic. > > Provide an Informational RFC describing a framework for unicast and > multicast address resolution over MPEG-2 transmission networks. The > document will describe options for the address resolution process, > relating these to appropriate usage scenarios and suggesting appropriate > protocol mechanisms for both the existing Multi-Protocol Encapsulation > (MPE) and the efficient encapsulation (2). Consideration will be paid to > existing standards, and the cases for IPv6 and IPv4 will be described. > > Define standards-track RFC(s) to specify procedures for dynamic address > resolution for IPv4/IPv6. This will describe the protocol and syntax of > the information exchanged to bind unicast and multicast flows to the > MPEG-2 > TS Logical Channels. This will include specific optimisations > appropriate for > networks reaching large numbers of down-stream systems. > > Goals and Milestones: > > JAN 04 Draft of a WG Architecture ID describing usage of MPEG-2 > transport for IP transmission. > MAR 04 Draft of a WG ID on the new Encapsulation. > JUL 04 Draft of a WG ID on the AR Framework, specifying mechanisms > to perform address resolution. > JUL 04 Submit Architecture to IESG > OCT 04 Draft of a WG ID or the AR Protocol, defining a protocol to > perform IP address resolution. > OCT 04 Submit Encapsulation to IESG > APR 05 Submit AR Framework to IESG > AUG 05 Submit AR Protocol to IESG > AUG 05 Progress the Encapsulation RFC along the IETF standards track. > > >> >> > > From owner-ip-dvb@erg.abdn.ac.uk Mon Feb 2 18:26:46 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i12IPaaV029423 for ; Mon, 2 Feb 2004 18:25:36 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i12IPaR7029422 for ip-dvb-subscribed-users; Mon, 2 Feb 2004 18:25:36 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley-ipv6.erg.abdn.ac.uk [IPv6:2001:630:241:1:20a:95ff:fe7d:5f0c]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i12IOr16029396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 2 Feb 2004 18:24:54 GMT Message-ID: <401E95F7.70100@erg.abdn.ac.uk> Date: Mon, 02 Feb 2004 18:24:55 +0000 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Re: comment on ULE draft (bridging mode) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Tarif.Zein-Alabedeen@space.alcatel.fr wrote: >This concerns §4.7.5 : bridged frame SNDU encapsulation ( fiugres 8 and 9) >: >The type field value in the figures is set to 0x0001. > Yes > This indicates that >the payload is an ethernet frame > Yes >with preserved FCS > The Ethernet frame should be sent using ULE *without* an Ethernet-level FCS as described in: "The Encapsulator MUST check the LAN-FCS value of all frames received, prior to further processing. Frames received with an invalid LAN FCS MUST be discarded. After checking, the LAN FCS is then removed (i.e., it is NOT forwarded in the bridged SNDU)." http://www.ietf.org/internet-drafts/draft-fair-ipdvb-ule-02.txt Is this the sort of behaviour that you desire? >This leads to a redundant CRC : that of the Ethernet frame and that of the >SNDU > >In Eth/AAL5, it is useual to remove the FCS field from the Eth frame before >encapsulating it in AAL5 PDU since AAL5 makes its own checksum >This may also be a good thing for ULE. > >The coding for the type field when the FCS is not preserved is 0x0007 >(instead of 0x0001) > What do you mean? >regards > > >ALCATEL SPACE >DRT/RST -- Ingénieur Systèmes >Tel : 0534356918 / Fax : 0534355560 >Porte : W.220 > > > Best wishes, Gorry Fairhurst. From owner-ip-dvb@erg.abdn.ac.uk Tue Feb 3 12:33:43 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i13CVkWV008860 for ; Tue, 3 Feb 2004 12:31:46 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i13CVj5v008859 for ip-dvb-subscribed-users; Tue, 3 Feb 2004 12:31:46 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley-ipv6.erg.abdn.ac.uk [IPv6:2001:630:241:1:20a:95ff:fe7d:5f0c]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i13CUN0d008786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 3 Feb 2004 12:30:25 GMT Message-ID: <401F945F.6010908@erg.abdn.ac.uk> Date: Tue, 03 Feb 2004 12:30:23 +0000 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: IETF Working Group Status for ipdvb (Feb 2004) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Welcome everyone! You may have noted the (triple!) posting from the IESG, announcing that this is now an official IETF mailing list in the Internet Area: http://www.erg.abdn.ac.uk/ip-dvb/archive/msg00509.html This announcement has several implications, including: (i) You ARE ALREADY subscribed to this mailing list, and we are pleased to have you on-board. If you do wish to be a member of the IETF ipdvb WG, you must now UNSUBSCRIBE from the list by sending an email to major-domo@erg.abdn.ac.uk with the following in the body of the message: unsubscribe ip-dvb. (ii) I am obliged to remind you that you MUST comply with the IETF note-well governing disclosure and IPR, as stated at: http://www.ietf.org/overview.html (iii This WG is now permitted to request a meeting slot at an IETF meeting, although of course the IETF primarily functions through its mailing lists, and (unlike many other organisations) meetings are NOT required to approve documents. (iv) We have NOT requested a meeting for ipdvb at the Seoul IETF (later this month). There are several reasons for this: - I am also keen to avoid calling a meeting with the same Agenda as the last two BoF meetings (several authors were also unable to make it) - I believe we can make significant progress for the following IETF (August 1-6, San Diego) and I do recommend you put this date in your diary straight away!! http://www.ietf.org/meetings/0mtg-sites.txt (v) We need to revive the work on our charter items: - In the first place this will mean consideration of the ULE Internet Draft for adoption as a working group item, for those unfamiliar, I will explain this process later in the week. - We also have a number of implementations of ULE, we shall be opening a new part of the web site to document the progress of these implementations. - We need to review/update/modify the requirements document to reflect the needs of this WG. Best wishes, Gorry Fairhurst (ipdvb chair) P.S. Some people may have noted that the IETF web page for the ipdvb WG displays a shortened form of the original proposed WG name (that simply expands the acronym). I am checking with the AD to see if the original name is still allowed, and will tell you progress. http://www.ietf.org/html.charters/wg-dir.html From owner-ip-dvb@erg.abdn.ac.uk Tue Feb 3 13:38:36 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i13DbGrG011454 for ; Tue, 3 Feb 2004 13:37:16 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i13DbF6M011453 for ip-dvb-subscribed-users; Tue, 3 Feb 2004 13:37:15 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from smail3.alcatel.fr (colt-na7.alcatel.fr [62.23.212.7]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i13DZtQc011391 for ; Tue, 3 Feb 2004 13:35:55 GMT Received: from vzmta01.netfr.alcatel.fr (vzmta01.netfr.alcatel.fr [155.132.182.220]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id i13DZfQM030773 for ; Tue, 3 Feb 2004 14:35:41 +0100 Importance: Low Sensitivity: Subject: =?iso-8859-1?Q?R=E9f=2E_=3A_Re=3A_comment_on_ULE_draft_=28bridging_mode?= =?us-ascii?Q?=29?= To: ip-dvb@erg.abdn.ac.uk From: Tarif.Zein-Alabedeen@space.alcatel.fr Date: Tue, 3 Feb 2004 14:22:48 +0100 Message-ID: X-MIMETrack: Serialize by Router on VZMTA01/ALCANET/ALCATEL-SPACE(Release 5.0.12 |February 13, 2003) at 03/02/2004 14:35:41 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 X-Alcanet-MTA-scanned-and-authorized: yes 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 i13DbCSo011449 Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Hi Gorry, Sorry if I have not been clear enough.... What I wanted to say is that I think the value for the TYPE field when the FCS of the Ethernet frame is removed before it is encapsulated within the SNDU (which is the case in the draft) should be 0x0007 and not 0x0001 (you can check this in RFC 2684) In fact both values indicate that the transported PDU is Ethernet. However 0x0001 indicates that the FCS is preserved and 0x0007 indicates that it is removed. This is the case for each bridged protocol and not only Ethernet. What is needed is just to correct the type field in the indicated figures of the draft Best regards Tarif ZEIN Gorry Fairhurst @erg.abdn.ac.uk on 02/02/2004 19:24:55 Veuillez répondre à ip-dvb@erg.abdn.ac.uk Envoyé par : owner-ip-dvb@erg.abdn.ac.uk Pour : ip-dvb@erg.abdn.ac.uk cc : Objet : Re: comment on ULE draft (bridging mode) Tarif.Zein-Alabedeen@space.alcatel.fr wrote: >This concerns §4.7.5 : bridged frame SNDU encapsulation ( fiugres 8 and 9) >: >The type field value in the figures is set to 0x0001. > Yes > This indicates that >the payload is an ethernet frame > Yes >with preserved FCS > The Ethernet frame should be sent using ULE *without* an Ethernet-level FCS as described in: "The Encapsulator MUST check the LAN-FCS value of all frames received, prior to further processing. Frames received with an invalid LAN FCS MUST be discarded. After checking, the LAN FCS is then removed (i.e., it is NOT forwarded in the bridged SNDU)." http://www.ietf.org/internet-drafts/draft-fair-ipdvb-ule-02.txt Is this the sort of behaviour that you desire? >This leads to a redundant CRC : that of the Ethernet frame and that of the >SNDU > >In Eth/AAL5, it is useual to remove the FCS field from the Eth frame before >encapsulating it in AAL5 PDU since AAL5 makes its own checksum >This may also be a good thing for ULE. > >The coding for the type field when the FCS is not preserved is 0x0007 >(instead of 0x0001) > What do you mean? >regards > > >ALCATEL SPACE >DRT/RST -- Ingénieur Systèmes >Tel : 0534356918 / Fax : 0534355560 >Porte : W.220 > > > Best wishes, Gorry Fairhurst. ALCATEL SPACE DRT/RST -- Ingénieur Systèmes Tel : 0534356918 / Fax : 0534355560 Porte : W.220 From owner-ip-dvb@erg.abdn.ac.uk Tue Feb 3 13:44:20 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i13DhcFb011743 for ; Tue, 3 Feb 2004 13:43:38 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i13DhcZp011742 for ip-dvb-subscribed-users; Tue, 3 Feb 2004 13:43:38 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from smail3.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i13Dgxgn011704 for ; Tue, 3 Feb 2004 13:42:59 GMT Received: from vzmta01.netfr.alcatel.fr (vzmta01.netfr.alcatel.fr [155.132.182.220]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id i13DeHQi002570 for ; Tue, 3 Feb 2004 14:42:52 +0100 Importance: Low Sensitivity: Subject: =?iso-8859-1?Q?R=E9f=2E_=3A_Re=3A_comment_on_ULE_draft_=28bridging_mode?= =?us-ascii?Q?=29?= To: ip-dvb@erg.abdn.ac.uk From: Tarif.Zein-Alabedeen@space.alcatel.fr Date: Tue, 3 Feb 2004 14:22:48 +0100 Message-ID: X-MIMETrack: Serialize by Router on VZMTA01/ALCANET/ALCATEL-SPACE(Release 5.0.12 |February 13, 2003) at 03/02/2004 14:42:52 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 X-Alcanet-MTA-scanned-and-authorized: yes 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 i13DhbBJ011738 Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Hi Gorry, Sorry if I have not been clear enough.... What I wanted to say is that I think the value for the TYPE field when the FCS of the Ethernet frame is removed before it is encapsulated within the SNDU (which is the case in the draft) should be 0x0007 and not 0x0001 (you can check this in RFC 2684) In fact both values indicate that the transported PDU is Ethernet. However 0x0001 indicates that the FCS is preserved and 0x0007 indicates that it is removed. This is the case for each bridged protocol and not only Ethernet. What is needed is just to correct the type field in the indicated figures of the draft Best regards Tarif ZEIN Gorry Fairhurst @erg.abdn.ac.uk on 02/02/2004 19:24:55 Veuillez répondre à ip-dvb@erg.abdn.ac.uk Envoyé par : owner-ip-dvb@erg.abdn.ac.uk Pour : ip-dvb@erg.abdn.ac.uk cc : Objet : Re: comment on ULE draft (bridging mode) Tarif.Zein-Alabedeen@space.alcatel.fr wrote: >This concerns §4.7.5 : bridged frame SNDU encapsulation ( fiugres 8 and 9) >: >The type field value in the figures is set to 0x0001. > Yes > This indicates that >the payload is an ethernet frame > Yes >with preserved FCS > The Ethernet frame should be sent using ULE *without* an Ethernet-level FCS as described in: "The Encapsulator MUST check the LAN-FCS value of all frames received, prior to further processing. Frames received with an invalid LAN FCS MUST be discarded. After checking, the LAN FCS is then removed (i.e., it is NOT forwarded in the bridged SNDU)." http://www.ietf.org/internet-drafts/draft-fair-ipdvb-ule-02.txt Is this the sort of behaviour that you desire? >This leads to a redundant CRC : that of the Ethernet frame and that of the >SNDU > >In Eth/AAL5, it is useual to remove the FCS field from the Eth frame before >encapsulating it in AAL5 PDU since AAL5 makes its own checksum >This may also be a good thing for ULE. > >The coding for the type field when the FCS is not preserved is 0x0007 >(instead of 0x0001) > What do you mean? >regards > > >ALCATEL SPACE >DRT/RST -- Ingénieur Systèmes >Tel : 0534356918 / Fax : 0534355560 >Porte : W.220 > > > Best wishes, Gorry Fairhurst. ALCATEL SPACE DRT/RST -- Ingénieur Systèmes Tel : 0534356918 / Fax : 0534355560 Porte : W.220 From owner-ip-dvb@erg.abdn.ac.uk Mon Feb 09 14:43:46 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i19CH18w010223 for ; Mon, 9 Feb 2004 12:17:01 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i19CH15o010222 for ip-dvb-subscribed-users; Mon, 9 Feb 2004 12:17:01 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from proxy.6wind.com (proxy.ipv6.6wind.com [194.250.197.211]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i19CFS2a010158 for ; Mon, 9 Feb 2004 12:15:28 GMT Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id 63B5F7BC for ; Mon, 9 Feb 2004 13:15:28 +0100 (CET) Received: from 6wind.com (vouvray.dev.6wind.com [10.16.0.135]) by intranet.6wind.com (Postfix) with ESMTP id 49D646AF; Mon, 9 Feb 2004 13:15:28 +0100 (CET) Message-ID: <40277AD2.9010101@6wind.com> Date: Mon, 09 Feb 2004 13:19:30 +0100 From: Alain RITOUX 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: ip-dvb@erg.abdn.ac.uk Subject: Re: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02. References: <402767AE.3020709@erg.abdn.ac.uk> In-Reply-To: <402767AE.3020709@erg.abdn.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk X-UIDL: E0[!!Y);!!m"k!!%+P!! Gorry Fairhurst wrote: > As WG chair, I request the ipdvb list to consider whether the WG is > ready to ... > > Title : Ultra Lightweight Encapsulation (ULE) for > transmission of IP datagrams over > MPEG-2/DVB networks > Author(s) : G. Fairhurst, B. Collini-Nocker > Filename : draft-fair-ipdvb-ule-02.txt > Pages : 32 > Date : 2003-11-24 I DO support the adoption of this draft as a WG item. Regards. Alain. -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com From owner-ip-dvb@erg.abdn.ac.uk Mon Feb 09 14:43:46 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i19EJmbJ015143 for ; Mon, 9 Feb 2004 14:19:48 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i19EJm2O015142 for ip-dvb-subscribed-users; Mon, 9 Feb 2004 14:19:48 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from gateway.hns.com (gateway.hns.com [208.236.67.13]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i19EIXV1015084 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 9 Feb 2004 14:18:34 GMT Received: from excore8.hns.com (excore8.hns.com [139.85.52.156]) by gateway.hns.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i19EIUac003254 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 9 Feb 2004 09:18:31 -0500 (EST) Received: from hns.com (altasun9.md.hnsnet [10.48.51.25]) by excore8.hns.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id i19EIMVY006668 for ; Mon, 9 Feb 2004 09:18:22 -0500 (EST) Message-ID: <402796AE.E43C83B4@hns.com> Date: Mon, 09 Feb 2004 09:18:22 -0500 From: John Border X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Re: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02. References: <402767AE.3020709@erg.abdn.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk X-UIDL: > As WG chair, I request the ipdvb list to consider whether the WG is > ready to support adoption of the following individual Internet Draft > (ID) as a WG ID. By adopting an individual ID as a working group ID, > this WG indicates that it intends to be develop this into an RFC, > according to the WG charter. > > WG documents should no longer be regarded as the property of the > individuals who originally authored them - the working group as a > whole must decide how they are shaped, and to see the document to a > successful conclusion. If adopted, the Internet Draft will be renamed > to start with the filename draft-ietf-ipdvb..., and will be listed on > the IETF web page for this WG. > > --- > > Title : Ultra Lightweight Encapsulation (ULE) for > transmission of IP datagrams over > MPEG-2/DVB networks > Author(s) : G. Fairhurst, B. Collini-Nocker > Filename : draft-fair-ipdvb-ule-02.txt > Pages : 32 > Date : 2003-11-24 > > The MPEG-2 TS has been widely accepted not only for providing digital > TV services, but also as a subnetwork technology for building IP > networks. This document describes an Ultra Lightweight Encapsulation > (ULE) mechanism for the transport of IPv4 and IPv6 Datagrams and other > network protocol packets directly over ISO MPEG- 2 Transport Streams > (TS) as TS Private Data. > > --- > > You are encouraged to send email to this WG, to help make the decision > for adoption. Possible recommendations are: > > 1) Support for adoption as a working group draft under our Charter - > i.e. Recommend this Internet Draft SHOULD be used as the basis for > developing an RFC by the ipdvb WG. > > 2) Request for non-adoption > i.e. That there is (or could be) alternative approaches to > the problem, and that the current draft is not sufficiently > developed / or correctly designed ipdvb WG > > 3) Out of scope > i.e. you believe the document to be beyond the scope of the > approved ipdvb WG charter. > > Emails on this topic should be sent to the ipdvb mailing list before > 23rd February 2004. > > Note that an ID does not need to be complete to be adopted. It would > also be most useful to collect as many comments/criticisms as possible > from those reading this ID. Looking through the archived mailing > list, a first list of issues to be addressed is included at the end of > this email. > > Please do help to identify any more known (or potential) issues that > should be addressed/discussed. > > Best wishes, > > Gorry Fairhurst > (ipdvb WG Chair) > > --- > > Known issues with draft-fair-ipdvb-ule-02.txt > ============================================= > > 1) Refinement of the text on CRC generation to be unambiguous > (explicitly talk about the polynomial as a forward CRC-32 and THEN > explicitly about the computation process) > - Text to be rewritten. > > 2) Query about the code point value for an Ethernet Bridging SNDU - > should the ULE type-field be 0x0001 ; 0x0007 as in ATM/AAL5 (as in > RFC2684); or should the IEEE Ethertype for bridging (0x6558) be used > instead? > - Discuss on list. > > 3) Need to check the SNDU Packing/Padding examples in the informative > appendix of the ID for correctness (including the length of the last > packet of example A.4) > --- any volunteers? > > 4) Suggestion to add an appendix to the next rev of the ID, with a > hexadecimal example of an SNDU, to assist implementors in validating > the operation of the CRC. The following example has been proposed: > > >> Ping6 > >> from 2001:660:3008:1789::5 to 2001:660:3008:1789::6, with the > >> associated DVB MAC addr being 01:02:03:04:05:06. It gives the > >> following SNDU : > >> > >> 0000: 00 3f 86 dd 01 02 03 04 05 06 60 00 00 00 00 0d > >> .?........`..... > >> 0010: 3a 40 20 01 06 60 30 08 17 89 00 00 00 00 00 00 :@ ..`0......... > >> 0020: 00 05 20 01 06 60 30 08 17 89 00 00 00 00 00 00 .. ..`0......... > >> 0030: 00 06 80 00 9c 58 07 70 00 00 00 00 00 00 00 02 .....X.p........ > >> 0040: 72 c9 c2 r.. > >> > - The exact decode of this needs to be done and verified > > 5) ??? From owner-ip-dvb@erg.abdn.ac.uk Mon Feb 09 14:43:46 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i19Etg5d016580 for ; Mon, 9 Feb 2004 14:55:42 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i19EtgTI016579 for ip-dvb-subscribed-users; Mon, 9 Feb 2004 14:55:42 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from mailer.ing.unirc.it ([192.167.50.202]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i19Et8Lp016515 for ; Mon, 9 Feb 2004 14:55:09 GMT Received: from mailer.ing.unirc.it (localhost [127.0.0.1]) by mailer.ing.unirc.it (8.12.10+Sun/8.12.5) with ESMTP id i19ExPmX004032 for ; Mon, 9 Feb 2004 15:59:25 +0100 (CET) Received: (from nobody@localhost) by mailer.ing.unirc.it (8.12.10+Sun/8.12.5/Submit) id i19ExPGH004031 for ip-dvb@erg.abdn.ac.uk; Mon, 9 Feb 2004 15:59:25 +0100 (CET) X-Authentication-Warning: mailer.ing.unirc.it: nobody set sender to pulitano@ing.unirc.it using -f Received: from aulamultirc.ing.unirc.it (aulamultirc.ing.unirc.it [192.167.50.235]) by mailer.ing.unirc.it (IMP) with HTTP for ; Mon, 9 Feb 2004 15:59:25 +0100 Message-ID: <1076338765.4027a04d44c13@mailer.ing.unirc.it> Date: Mon, 9 Feb 2004 15:59:25 +0100 From: pulitano@ing.unirc.it To: ip-dvb@erg.abdn.ac.uk Subject: Re: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02. References: <402767AE.3020709@erg.abdn.ac.uk> <402796AE.E43C83B4@hns.com> In-Reply-To: <402796AE.E43C83B4@hns.com> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 192.167.50.235 X-yoursite-MailScanner-Information: Please contact the ISP for more information X-yoursite-MailScanner: Found to be clean X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk X-UIDL: F>f!!lO~"!X+V"!cD>"! I think that such a draft can be adopted as a WG draft. From owner-ip-dvb@erg.abdn.ac.uk Mon Feb 09 15:43:46 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i19FKbdM017508 for ; Mon, 9 Feb 2004 15:20:37 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i19FKbni017507 for ip-dvb-subscribed-users; Mon, 9 Feb 2004 15:20:37 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from mail1.iabg.de (mail1.iabg.de [194.139.245.9]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i19FJZxw017449 for ; Mon, 9 Feb 2004 15:19:35 GMT Received: from mail1.iabg.de (localhost [127.0.0.1]) by localhost (Mailserver IABG) with ESMTP id 8B043F505 for ; Mon, 9 Feb 2004 16:19:30 +0100 (CET) Received: from exchange03.iabg.de (exchange03.iabg.de [10.128.200.37]) by mail1.iabg.de (Mailserver IABG) with ESMTP id 48125F4EE for ; Mon, 9 Feb 2004 16:19:30 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: AW: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02. Date: Mon, 9 Feb 2004 16:19:30 +0100 Message-ID: <69A5E767EC979846826F566C7932A3F2074DAC@exchange03.iabg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02. Thread-Index: AcPvASkflYpUNpsCRaGzZHBhTczYTQAHt1zA From: "Fritsche Wolfgang" 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 i19FKZQm017504 Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk X-UIDL: K4j!!S'2!!BjN!!V=6"! I do support the adoption of the ULE draft as a WG draft. Cheers, Wolfgang > -----Ursprüngliche Nachricht----- > Von: owner-ip-dvb@erg.abdn.ac.uk > [mailto:owner-ip-dvb@erg.abdn.ac.uk] Im Auftrag von Gorry Fairhurst > Gesendet: Montag, 9. Februar 2004 11:58 > An: ipdvb@erg.abdn.ac.uk > Betreff: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02. > > > As WG chair, I request the ipdvb list to consider whether the > WG is ready to support adoption of the following individual > Internet Draft (ID) as a WG ID. > By adopting an individual ID as a working group ID, this WG > indicates that > it intends to be develop this into an RFC, according to the > WG charter. > > WG documents should no longer be regarded as the property of the > individuals who originally authored them - the working group > as a whole > must decide how they are shaped, and to see the document to > a successful conclusion. If adopted, the Internet Draft will > be renamed to start with the filename draft-ietf-ipdvb..., > and will be listed on the IETF web page for this WG. > > --- > > Title : Ultra Lightweight Encapsulation (ULE) for > transmission of IP datagrams over > MPEG-2/DVB networks > Author(s) : G. Fairhurst, B. Collini-Nocker > Filename : draft-fair-ipdvb-ule-02.txt > Pages : 32 > Date : 2003-11-24 > > The MPEG-2 TS has been widely accepted not only for providing > digital TV services, but also as a subnetwork technology for > building IP networks. This document describes an Ultra > Lightweight Encapsulation (ULE) mechanism for the transport > of IPv4 and IPv6 Datagrams and other network protocol packets > directly over ISO MPEG- 2 Transport Streams (TS) as TS Private Data. > > --- > > You are encouraged to send email to this WG, to help make the > decision for adoption. Possible recommendations are: > > 1) Support for adoption as a working group draft under > our Charter - > i.e. Recommend this Internet Draft SHOULD be used as > the basis for > developing an RFC by the ipdvb WG. > > 2) Request for non-adoption > i.e. That there is (or could be) alternative approaches to > the problem, and that the current draft is not sufficiently > developed / or correctly designed ipdvb WG > > 3) Out of scope > i.e. you believe the document to be beyond the scope of the > approved ipdvb WG charter. > > Emails on this topic should be sent to the ipdvb mailing list > before 23rd February 2004. > > Note that an ID does not need to be complete to be adopted. > It would also be most useful to collect as many > comments/criticisms as possible from those reading this ID. > Looking through the archived mailing list, a first list of > issues to be addressed is included at the end of this email. > > Please do help to identify any more known (or potential) > issues that should be addressed/discussed. > > Best wishes, > > Gorry Fairhurst > (ipdvb WG Chair) > > > --- > > > Known issues with draft-fair-ipdvb-ule-02.txt > ============================================= > > 1) Refinement of the text on CRC generation to be unambiguous > (explicitly talk about the polynomial as a forward CRC-32 > and THEN explicitly about the computation process) > - Text to be rewritten. > > 2) Query about the code point value for an Ethernet Bridging > SNDU - should the ULE type-field be 0x0001 ; 0x0007 as in > ATM/AAL5 (as in RFC2684); > or should the IEEE Ethertype for bridging (0x6558) be used instead? > - Discuss on list. > > 3) Need to check the SNDU Packing/Padding examples in the > informative appendix of the ID for correctness (including the > length of the last > packet of example A.4) > --- any volunteers? > > 4) Suggestion to add an appendix to the next rev of the ID, > with a hexadecimal example of an SNDU, to assist implementors > in validating the operation of the CRC. The following example > has been proposed: > > >> Ping6 > >> from 2001:660:3008:1789::5 to 2001:660:3008:1789::6, with the > >> associated DVB MAC addr being 01:02:03:04:05:06. It gives the > >> following SNDU : > >> > >> 0000: 00 3f 86 dd 01 02 03 04 05 06 60 00 00 00 00 0d > >> .?........`..... > >> 0010: 3a 40 20 01 06 60 30 08 17 89 00 00 00 00 00 00 :@ > ..`0......... > >> 0020: 00 05 20 01 06 60 30 08 17 89 00 00 00 00 00 00 .. > ..`0......... > >> 0030: 00 06 80 00 9c 58 07 70 00 00 00 00 00 00 00 02 > .....X.p........ > >> 0040: 72 c9 c2 r.. > >> > - The exact decode of this needs to be done and verified > > > 5) ??? > > > From owner-ip-dvb@erg.abdn.ac.uk Mon Feb 09 15:43:46 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i19FREH7017785 for ; Mon, 9 Feb 2004 15:27:14 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i19FRDpN017784 for ip-dvb-subscribed-users; Mon, 9 Feb 2004 15:27:13 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from mail1.iabg.de (mail1.iabg.de [194.139.245.9]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i19FQ9XG017736; Mon, 9 Feb 2004 15:26:10 GMT Received: from mail1.iabg.de (localhost [127.0.0.1]) by localhost (Mailserver IABG) with ESMTP id 3788DF505; Mon, 9 Feb 2004 16:26:05 +0100 (CET) Received: from exchange03.iabg.de (exchange03.iabg.de [10.128.200.37]) by mail1.iabg.de (Mailserver IABG) with ESMTP id BE49CF4EE; Mon, 9 Feb 2004 16:26:04 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: AW: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02. Date: Mon, 9 Feb 2004 16:26:04 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02. Thread-Index: AcPvASkTn8rJZo3kQYCMCVCwGplxGgAHy8Wg From: "Mayer Karl" 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 i19FR9mx017780 Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk X-UIDL: pP/"!fA6!!So0"!S2B"! I support the adoption of the ULE draft as WG ID. Karl > -----Ursprüngliche Nachricht----- > Von: owner-ip-dvb@erg.abdn.ac.uk [mailto:owner-ip-dvb@erg.abdn.ac.uk] > Im Auftrag von Gorry Fairhurst > Gesendet: Montag, 9. Februar 2004 11:58 > An: ipdvb@erg.abdn.ac.uk > Betreff: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02. > > As WG chair, I request the ipdvb list to consider whether the WG is > ready to support adoption of the following individual Internet Draft > (ID) as a WG ID. > By adopting an individual ID as a working group ID, this WG indicates that > it intends to be develop this into an RFC, according to the WG charter. > > WG documents should no longer be regarded as the property of the > individuals who originally authored them - the working group as a > whole must decide how they are shaped, and to see the document to a > successful conclusion. If adopted, the Internet Draft will be renamed > to start with the filename draft-ietf-ipdvb..., and will be listed on > the IETF web page for this WG. > > --- > > Title : Ultra Lightweight Encapsulation (ULE) for > transmission of IP datagrams over > MPEG-2/DVB networks > Author(s) : G. Fairhurst, B. Collini-Nocker > Filename : draft-fair-ipdvb-ule-02.txt > Pages : 32 > Date : 2003-11-24 > > The MPEG-2 TS has been widely accepted not only for providing digital > TV services, but also as a subnetwork technology for building IP > networks. This document describes an Ultra Lightweight Encapsulation > (ULE) mechanism for the transport of IPv4 and IPv6 Datagrams and other > network protocol packets directly over ISO MPEG- 2 Transport Streams > (TS) as TS Private Data. > > --- > > You are encouraged to send email to this WG, to help make the decision > for adoption. Possible recommendations are: > > 1) Support for adoption as a working group draft under our Charter - > i.e. Recommend this Internet Draft SHOULD be used as the basis for > developing an RFC by the ipdvb WG. > > 2) Request for non-adoption > i.e. That there is (or could be) alternative approaches to > the problem, and that the current draft is not sufficiently > developed / or correctly designed ipdvb WG > > 3) Out of scope > i.e. you believe the document to be beyond the scope of the > approved ipdvb WG charter. > > Emails on this topic should be sent to the ipdvb mailing list before > 23rd February 2004. > > Note that an ID does not need to be complete to be adopted. It would > also be most useful to collect as many comments/criticisms as possible > from those reading this ID. Looking through the archived mailing > list, a first list of issues to be addressed is included at the end of > this email. > > Please do help to identify any more known (or potential) issues that > should be addressed/discussed. > > Best wishes, > > Gorry Fairhurst > (ipdvb WG Chair) > > > --- > > > Known issues with draft-fair-ipdvb-ule-02.txt > ============================================= > > 1) Refinement of the text on CRC generation to be unambiguous > (explicitly talk about the polynomial as a forward CRC-32 and THEN > explicitly about the computation process) > - Text to be rewritten. > > 2) Query about the code point value for an Ethernet Bridging SNDU - > should the ULE type-field be 0x0001 ; 0x0007 as in ATM/AAL5 (as in > RFC2684); or should the IEEE Ethertype for bridging (0x6558) be used > instead? > - Discuss on list. > > 3) Need to check the SNDU Packing/Padding examples in the informative > appendix of the ID for correctness (including the length of the last > packet of example A.4) > --- any volunteers? > > 4) Suggestion to add an appendix to the next rev of the ID, with a > hexadecimal example of an SNDU, to assist implementors in validating > the operation of the CRC. The following example has been proposed: > > >> Ping6 > >> from 2001:660:3008:1789::5 to 2001:660:3008:1789::6, with the > associated > >> DVB MAC addr being 01:02:03:04:05:06. It gives the following SNDU : > >> > >> 0000: 00 3f 86 dd 01 02 03 04 05 06 60 00 00 00 00 0d > .?........`..... > >> 0010: 3a 40 20 01 06 60 30 08 17 89 00 00 00 00 00 00 :@ > ..`0......... > >> 0020: 00 05 20 01 06 60 30 08 17 89 00 00 00 00 00 00 .. > ..`0......... > >> 0030: 00 06 80 00 9c 58 07 70 00 00 00 00 00 00 00 02 > .....X.p........ > >> 0040: 72 c9 c2 r.. > >> > - The exact decode of this needs to be done and verified > > > 5) ??? > From owner-ip-dvb@erg.abdn.ac.uk Mon Feb 09 16:43:46 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i19GBtp3019562 for ; Mon, 9 Feb 2004 16:11:55 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i19GBtoQ019560 for ip-dvb-subscribed-users; Mon, 9 Feb 2004 16:11:55 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from mail1.iabg.de (mail1.iabg.de [194.139.245.9]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i19GALHe019501 for ; Mon, 9 Feb 2004 16:10:21 GMT Received: from mail1.iabg.de (localhost [127.0.0.1]) by localhost (Mailserver IABG) with ESMTP id C7C11F523 for ; Mon, 9 Feb 2004 17:10:16 +0100 (CET) Received: from exchange03.iabg.de (exchange03.iabg.de [10.128.200.37]) by mail1.iabg.de (Mailserver IABG) with ESMTP id 6D553F520 for ; Mon, 9 Feb 2004 17:10:16 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02. Date: Mon, 9 Feb 2004 17:10:16 +0100 Message-ID: <69A5E767EC979846826F566C7932A3F213566D@exchange03.iabg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02. Thread-Index: AcPvASkflYpUNpsCRaGzZHBhTczYTQAJfXJA From: "Gessler Gerhard" 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 i19GBqGK019557 Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk X-UIDL: (;j!!>n'"!+&Z"!LjS!! I do support the adoption of this draft as a WG item. -------------------------------------------- Gerhard Geßler Communication Networks, IABG mbH Einsteinstr. 20 85521 Ottobrunn, Germany Telefon: +49 89 6088 - 2021 Fax: +49 89 6088 - 2845 E-Mail: gessler@iabg.de > -----Original Message----- > From: owner-ip-dvb@erg.abdn.ac.uk > [mailto:owner-ip-dvb@erg.abdn.ac.uk] On Behalf Of Gorry Fairhurst > Sent: Monday, February 09, 2004 11:58 AM > To: ipdvb@erg.abdn.ac.uk > Subject: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02. > > > As WG chair, I request the ipdvb list to consider whether > the WG is ready to > support adoption of the following individual Internet Draft > (ID) as a WG ID. > By adopting an individual ID as a working group ID, this WG > indicates that > it intends to be develop this into an RFC, according to the > WG charter. > > WG documents should no longer be regarded as the property of the > individuals who originally authored them - the working > group as a whole > must decide how they are shaped, and to see the document to > a successful conclusion. If adopted, the Internet Draft > will be renamed to > start with the filename draft-ietf-ipdvb..., and will be > listed on the IETF > web page for this WG. > > --- > > Title : Ultra Lightweight Encapsulation (ULE) for > transmission of IP datagrams over > MPEG-2/DVB networks > Author(s) : G. Fairhurst, B. Collini-Nocker > Filename : draft-fair-ipdvb-ule-02.txt > Pages : 32 > Date : 2003-11-24 > > The MPEG-2 TS has been widely accepted not only for providing > digital TV services, but also as a subnetwork technology for > building IP networks. This document describes an Ultra Lightweight > Encapsulation (ULE) mechanism for the transport of IPv4 and IPv6 > Datagrams and other network protocol packets directly over ISO MPEG- > 2 Transport Streams (TS) as TS Private Data. > > --- > > You are encouraged to send email to this WG, to help make > the decision for > adoption. Possible recommendations are: > > 1) Support for adoption as a working group draft > under our Charter - > i.e. Recommend this Internet Draft SHOULD be used as > the basis for > developing an RFC by the ipdvb WG. > > 2) Request for non-adoption > i.e. That there is (or could be) alternative approaches to > the problem, and that the current draft is not sufficiently > developed / or correctly designed ipdvb WG > > 3) Out of scope > i.e. you believe the document to be beyond the scope of the > approved ipdvb WG charter. > > Emails on this topic should be sent to the ipdvb mailing list before > 23rd February 2004. > > Note that an ID does not need to be complete to be adopted. It would > also be most useful to collect as many comments/criticisms > as possible from > those reading this ID. Looking through the archived mailing list, a > first list of issues to be addressed is included at the end > of this email. > > Please do help to identify any more known (or potential) > issues that should > be addressed/discussed. > > Best wishes, > > Gorry Fairhurst > (ipdvb WG Chair) > > > --- > > > Known issues with draft-fair-ipdvb-ule-02.txt > ============================================= > > 1) Refinement of the text on CRC generation to be unambiguous > (explicitly talk about the polynomial as a forward CRC-32 > and THEN explicitly about the computation process) > - Text to be rewritten. > > 2) Query about the code point value for an Ethernet > Bridging SNDU - should > the ULE type-field be 0x0001 ; 0x0007 as in ATM/AAL5 (as in > RFC2684); > or should the IEEE Ethertype for bridging (0x6558) be used instead? > - Discuss on list. > > 3) Need to check the SNDU Packing/Padding examples in the > informative > appendix of the ID for correctness (including the length of > the last > packet of example A.4) > --- any volunteers? > > 4) Suggestion to add an appendix to the next rev of the ID, with a > hexadecimal example of an SNDU, to assist implementors in > validating the > operation of the CRC. The following example has been proposed: > > >> Ping6 > >> from 2001:660:3008:1789::5 to 2001:660:3008:1789::6, > with the associated > >> DVB MAC addr being 01:02:03:04:05:06. It gives the > following SNDU : > >> > >> 0000: 00 3f 86 dd 01 02 03 04 05 06 60 00 00 00 00 0d > .?........`..... > >> 0010: 3a 40 20 01 06 60 30 08 17 89 00 00 00 00 00 00 > :@ ..`0......... > >> 0020: 00 05 20 01 06 60 30 08 17 89 00 00 00 00 00 00 > .. ..`0......... > >> 0030: 00 06 80 00 9c 58 07 70 00 00 00 00 00 00 00 02 > .....X.p........ > >> 0040: 72 c9 c2 r.. > >> > - The exact decode of this needs to be done and verified > > > 5) ??? > > > From owner-ip-dvb@erg.abdn.ac.uk Mon Feb 09 17:43:46 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i19HXNFH022564 for ; Mon, 9 Feb 2004 17:33:23 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i19HXMHS022563 for ip-dvb-subscribed-users; Mon, 9 Feb 2004 17:33:22 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from demokritos1.cytanet.com.cy (demokritos1.cytanet.com.cy [195.14.130.225]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i19HWj4u022534; Mon, 9 Feb 2004 17:32:45 GMT Received: from userwoveggfsck (fm-3-05.cytanet.com.cy [195.14.135.133]) by demokritos1.cytanet.com.cy (Postfix) with ESMTP id E1AC68B3C2; Mon, 9 Feb 2004 19:32:38 +0200 (EET) From: "Pete, Bec and Ethan" To: , Subject: RE: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02. Date: Mon, 9 Feb 2004 19:32:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <402767AE.3020709@erg.abdn.ac.uk> Thread-Index: AcPvAJCCnbMcapiEQNC/4iGG1dze/AAMbbwQ Message-Id: <20040209173238.E1AC68B3C2@demokritos1.cytanet.com.cy> X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk X-UIDL: hZ1!!cmm"!-g6!!bh!"! I support the adoption of the ULE draft as a WG item. Pete -----Original Message----- From: owner-ip-dvb@erg.abdn.ac.uk [mailto:owner-ip-dvb@erg.abdn.ac.uk] On Behalf Of Gorry Fairhurst Sent: Monday, February 09, 2004 12:58 PM To: ipdvb@erg.abdn.ac.uk Subject: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02. As WG chair, I request the ipdvb list to consider whether the WG is ready to support adoption of the following individual Internet Draft (ID) as a WG ID. By adopting an individual ID as a working group ID, this WG indicates that it intends to be develop this into an RFC, according to the WG charter. WG documents should no longer be regarded as the property of the individuals who originally authored them - the working group as a whole must decide how they are shaped, and to see the document to a successful conclusion. If adopted, the Internet Draft will be renamed to start with the filename draft-ietf-ipdvb..., and will be listed on the IETF web page for this WG. --- Title : Ultra Lightweight Encapsulation (ULE) for transmission of IP datagrams over MPEG-2/DVB networks Author(s) : G. Fairhurst, B. Collini-Nocker Filename : draft-fair-ipdvb-ule-02.txt Pages : 32 Date : 2003-11-24 The MPEG-2 TS has been widely accepted not only for providing digital TV services, but also as a subnetwork technology for building IP networks. This document describes an Ultra Lightweight Encapsulation (ULE) mechanism for the transport of IPv4 and IPv6 Datagrams and other network protocol packets directly over ISO MPEG- 2 Transport Streams (TS) as TS Private Data. --- You are encouraged to send email to this WG, to help make the decision for adoption. Possible recommendations are: 1) Support for adoption as a working group draft under our Charter - i.e. Recommend this Internet Draft SHOULD be used as the basis for developing an RFC by the ipdvb WG. 2) Request for non-adoption i.e. That there is (or could be) alternative approaches to the problem, and that the current draft is not sufficiently developed / or correctly designed ipdvb WG 3) Out of scope i.e. you believe the document to be beyond the scope of the approved ipdvb WG charter. Emails on this topic should be sent to the ipdvb mailing list before 23rd February 2004. Note that an ID does not need to be complete to be adopted. It would also be most useful to collect as many comments/criticisms as possible from those reading this ID. Looking through the archived mailing list, a first list of issues to be addressed is included at the end of this email. Please do help to identify any more known (or potential) issues that should be addressed/discussed. Best wishes, Gorry Fairhurst (ipdvb WG Chair) --- Known issues with draft-fair-ipdvb-ule-02.txt ============================================= 1) Refinement of the text on CRC generation to be unambiguous (explicitly talk about the polynomial as a forward CRC-32 and THEN explicitly about the computation process) - Text to be rewritten. 2) Query about the code point value for an Ethernet Bridging SNDU - should the ULE type-field be 0x0001 ; 0x0007 as in ATM/AAL5 (as in RFC2684); or should the IEEE Ethertype for bridging (0x6558) be used instead? - Discuss on list. 3) Need to check the SNDU Packing/Padding examples in the informative appendix of the ID for correctness (including the length of the last packet of example A.4) --- any volunteers? 4) Suggestion to add an appendix to the next rev of the ID, with a hexadecimal example of an SNDU, to assist implementors in validating the operation of the CRC. The following example has been proposed: >> Ping6 >> from 2001:660:3008:1789::5 to 2001:660:3008:1789::6, with the >> associated DVB MAC addr being 01:02:03:04:05:06. It gives the >> following SNDU : >> >> 0000: 00 3f 86 dd 01 02 03 04 05 06 60 00 00 00 00 0d >> .?........`..... >> 0010: 3a 40 20 01 06 60 30 08 17 89 00 00 00 00 00 00 :@ ..`0......... >> 0020: 00 05 20 01 06 60 30 08 17 89 00 00 00 00 00 00 .. ..`0......... >> 0030: 00 06 80 00 9c 58 07 70 00 00 00 00 00 00 00 02 .....X.p........ >> 0040: 72 c9 c2 r.. >> - The exact decode of this needs to be done and verified 5) ??? --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.547 / Virus Database: 340 - Release Date: 02/12/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.547 / Virus Database: 340 - Release Date: 02/12/2003 From owner-ip-dvb@erg.abdn.ac.uk Mon Feb 09 17:54:46 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i19HsHH3023417 for ; Mon, 9 Feb 2004 17:54:17 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i19HsHgc023416 for ip-dvb-subscribed-users; Mon, 9 Feb 2004 17:54:17 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i19HqORH023328 for ; Mon, 9 Feb 2004 17:52:24 GMT Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1]) by shiva.jussieu.fr (8.12.10/jtpda-5.4) with ESMTP id i19HqKkK033750 for ; Mon, 9 Feb 2004 18:52:22 +0100 (CET) X-Ids: 168 Received: from prism8382ujqp2 (richelieu.prism.uvsq.fr [193.51.25.105]) by guillotin.prism.uvsq.fr (8.11.4/jtpda-5.3.2) with ESMTP id i19HqQp23717 for ; Mon, 9 Feb 2004 18:52:26 +0100 (MET) Message-Id: <200402091752.i19HqQp23717@guillotin.prism.uvsq.fr> From: "Abdelhamid Nafaa" To: Subject: RE: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02. Date: Mon, 9 Feb 2004 18:55:33 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <20040209173238.E1AC68B3C2@demokritos1.cytanet.com.cy> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcPvAJCCnbMcapiEQNC/4iGG1dze/AAMbbwQAADHkjA= X-Miltered: at shiva.jussieu.fr with ID 4027C8D4.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Antivirus: scanned by sophie at shiva.jussieu.fr X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk X-UIDL: +;>"!an4!!`nj!!gL&#! I support the adoption of the ULE draft as a WG item and starting point for a proposed IETF standard. Abdelhamid ---------------- Abdelhamid NAFAA | Tel: +33 1 39 25 40 59 PRiSM-CNRS Lab. | Web: http://www.prism.uvsq.fr/~anaf/ University of Versailles 45, Av. Des Etats Unis, 78035 - Versailles, France. -----Original Message----- From: owner-ip-dvb@erg.abdn.ac.uk [mailto:owner-ip-dvb@erg.abdn.ac.uk] On Behalf Of Gorry Fairhurst Sent: Monday, February 09, 2004 12:58 PM To: ipdvb@erg.abdn.ac.uk Subject: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02. As WG chair, I request the ipdvb list to consider whether the WG is ready to support adoption of the following individual Internet Draft (ID) as a WG ID. By adopting an individual ID as a working group ID, this WG indicates that it intends to be develop this into an RFC, according to the WG charter. WG documents should no longer be regarded as the property of the individuals who originally authored them - the working group as a whole must decide how they are shaped, and to see the document to a successful conclusion. If adopted, the Internet Draft will be renamed to start with the filename draft-ietf-ipdvb..., and will be listed on the IETF web page for this WG. --- Title : Ultra Lightweight Encapsulation (ULE) for transmission of IP datagrams over MPEG-2/DVB networks Author(s) : G. Fairhurst, B. Collini-Nocker Filename : draft-fair-ipdvb-ule-02.txt Pages : 32 Date : 2003-11-24 The MPEG-2 TS has been widely accepted not only for providing digital TV services, but also as a subnetwork technology for building IP networks. This document describes an Ultra Lightweight Encapsulation (ULE) mechanism for the transport of IPv4 and IPv6 Datagrams and other network protocol packets directly over ISO MPEG- 2 Transport Streams (TS) as TS Private Data. --- You are encouraged to send email to this WG, to help make the decision for adoption. Possible recommendations are: 1) Support for adoption as a working group draft under our Charter - i.e. Recommend this Internet Draft SHOULD be used as the basis for developing an RFC by the ipdvb WG. 2) Request for non-adoption i.e. That there is (or could be) alternative approaches to the problem, and that the current draft is not sufficiently developed / or correctly designed ipdvb WG 3) Out of scope i.e. you believe the document to be beyond the scope of the approved ipdvb WG charter. Emails on this topic should be sent to the ipdvb mailing list before 23rd February 2004. Note that an ID does not need to be complete to be adopted. It would also be most useful to collect as many comments/criticisms as possible from those reading this ID. Looking through the archived mailing list, a first list of issues to be addressed is included at the end of this email. Please do help to identify any more known (or potential) issues that should be addressed/discussed. Best wishes, Gorry Fairhurst (ipdvb WG Chair) --- Known issues with draft-fair-ipdvb-ule-02.txt ============================================= 1) Refinement of the text on CRC generation to be unambiguous (explicitly talk about the polynomial as a forward CRC-32 and THEN explicitly about the computation process) - Text to be rewritten. 2) Query about the code point value for an Ethernet Bridging SNDU - should the ULE type-field be 0x0001 ; 0x0007 as in ATM/AAL5 (as in RFC2684); or should the IEEE Ethertype for bridging (0x6558) be used instead? - Discuss on list. 3) Need to check the SNDU Packing/Padding examples in the informative appendix of the ID for correctness (including the length of the last packet of example A.4) --- any volunteers? 4) Suggestion to add an appendix to the next rev of the ID, with a hexadecimal example of an SNDU, to assist implementors in validating the operation of the CRC. The following example has been proposed: >> Ping6 >> from 2001:660:3008:1789::5 to 2001:660:3008:1789::6, with the >> associated DVB MAC addr being 01:02:03:04:05:06. It gives the >> following SNDU : >> >> 0000: 00 3f 86 dd 01 02 03 04 05 06 60 00 00 00 00 0d >> .?........`..... >> 0010: 3a 40 20 01 06 60 30 08 17 89 00 00 00 00 00 00 :@ ..`0......... >> 0020: 00 05 20 01 06 60 30 08 17 89 00 00 00 00 00 00 .. ..`0......... >> 0030: 00 06 80 00 9c 58 07 70 00 00 00 00 00 00 00 02 .....X.p........ >> 0040: 72 c9 c2 r.. >> - The exact decode of this needs to be done and verified 5) ??? --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.547 / Virus Database: 340 - Release Date: 02/12/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.547 / Virus Database: 340 - Release Date: 02/12/2003 From owner-ip-dvb@erg.abdn.ac.uk Mon Feb 09 18:43:46 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i19IdJUW025101 for ; Mon, 9 Feb 2004 18:39:19 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i19IdJJj025100 for ip-dvb-subscribed-users; Mon, 9 Feb 2004 18:39:19 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from out009.verizon.net (out009pub.verizon.net [206.46.170.131]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i19IbjdG025013 for ; Mon, 9 Feb 2004 18:37:46 GMT Received: from copernicus ([68.163.186.227]) by out009.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040209183745.EMY11926.out009.verizon.net@copernicus> for ; Mon, 9 Feb 2004 12:37:45 -0600 Message-ID: <015e01c3ef3b$f70cdc70$b402a8c0@copernicus> From: "Marie-Jose Montpetit" To: References: <402767AE.3020709@erg.abdn.ac.uk> Subject: Re: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02. Date: Mon, 9 Feb 2004 13:36:30 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authentication-Info: Submitted using SMTP AUTH at out009.verizon.net from [68.163.186.227] at Mon, 9 Feb 2004 12:37:45 -0600 X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk X-UIDL: U,h"!/i To: Sent: Monday, February 09, 2004 5:57 AM Subject: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02. > As WG chair, I request the ipdvb list to consider whether the WG is > ready to > support adoption of the following individual Internet Draft (ID) as a > WG ID. > By adopting an individual ID as a working group ID, this WG indicates > that it intends to be develop this into an RFC, according to the WG > charter. > > WG documents should no longer be regarded as the property of the > individuals who originally authored them - the working group as a > whole must decide how they are shaped, and to see the document to a > successful conclusion. If adopted, the Internet Draft will be renamed > to start with the filename draft-ietf-ipdvb..., and will be listed on > the IETF > web page for this WG. > > --- > > Title : Ultra Lightweight Encapsulation (ULE) for > transmission of IP datagrams over > MPEG-2/DVB networks > Author(s) : G. Fairhurst, B. Collini-Nocker > Filename : draft-fair-ipdvb-ule-02.txt > Pages : 32 > Date : 2003-11-24 > > The MPEG-2 TS has been widely accepted not only for providing digital > TV services, but also as a subnetwork technology for building IP > networks. This document describes an Ultra Lightweight Encapsulation > (ULE) mechanism for the transport of IPv4 and IPv6 Datagrams and other > network protocol packets directly over ISO MPEG- 2 Transport Streams > (TS) as TS Private Data. > > --- > > You are encouraged to send email to this WG, to help make the decision > for adoption. Possible recommendations are: > > 1) Support for adoption as a working group draft under our Charter - > i.e. Recommend this Internet Draft SHOULD be used as the basis for > developing an RFC by the ipdvb WG. > > 2) Request for non-adoption > i.e. That there is (or could be) alternative approaches to > the problem, and that the current draft is not sufficiently > developed / or correctly designed ipdvb WG > > 3) Out of scope > i.e. you believe the document to be beyond the scope of the > approved ipdvb WG charter. > > Emails on this topic should be sent to the ipdvb mailing list before > 23rd February 2004. > > Note that an ID does not need to be complete to be adopted. It would > also be most useful to collect as many comments/criticisms as possible from > those reading this ID. Looking through the archived mailing list, a > first list of issues to be addressed is included at the end of this > email. > > Please do help to identify any more known (or potential) issues that should > be addressed/discussed. > > Best wishes, > > Gorry Fairhurst > (ipdvb WG Chair) > > > --- > > > Known issues with draft-fair-ipdvb-ule-02.txt > ============================================= > > 1) Refinement of the text on CRC generation to be unambiguous > (explicitly talk about the polynomial as a forward CRC-32 and THEN > explicitly about the computation process) > - Text to be rewritten. > > 2) Query about the code point value for an Ethernet Bridging SNDU - > should the ULE type-field be 0x0001 ; 0x0007 as in ATM/AAL5 (as in > RFC2684); or should the IEEE Ethertype for bridging (0x6558) be used > instead? > - Discuss on list. > > 3) Need to check the SNDU Packing/Padding examples in the informative > appendix of the ID for correctness (including the length of the last > packet of example A.4) > --- any volunteers? > > 4) Suggestion to add an appendix to the next rev of the ID, with a > hexadecimal example of an SNDU, to assist implementors in validating > the operation of the CRC. The following example has been proposed: > > >> Ping6 > >> from 2001:660:3008:1789::5 to 2001:660:3008:1789::6, with the associated > >> DVB MAC addr being 01:02:03:04:05:06. It gives the following SNDU : > >> > >> 0000: 00 3f 86 dd 01 02 03 04 05 06 60 00 00 00 00 0d .?........`..... > >> 0010: 3a 40 20 01 06 60 30 08 17 89 00 00 00 00 00 00 :@ ..`0......... > >> 0020: 00 05 20 01 06 60 30 08 17 89 00 00 00 00 00 00 .. ..`0......... > >> 0030: 00 06 80 00 9c 58 07 70 00 00 00 00 00 00 00 02 .....X.p........ > >> 0040: 72 c9 c2 r.. > >> > - The exact decode of this needs to be done and verified > > > 5) ??? > > > From owner-ip-dvb@erg.abdn.ac.uk Tue Feb 10 06:23:46 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1A6JXY6020332 for ; Tue, 10 Feb 2004 06:19:33 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1A6JWqJ020331 for ip-dvb-subscribed-users; Tue, 10 Feb 2004 06:19:32 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from esacom57-int.estec.esa.int (esacom57-ext.estec.esa.int [131.176.107.4]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1A6IuLE020282 for ; Tue, 10 Feb 2004 06:18:56 GMT Received: from esacom52.estec.esa.int (esacom52.estec.esa.int [131.176.7.7]) by esacom57-int.estec.esa.int (8.12.10/8.12.10/ESA-External-v3.2) with ESMTP id i1A6IoGP022172 for ; Tue, 10 Feb 2004 07:18:50 +0100 (MET) Received: from estecmta1.estec.esa.int (estecmta1.estec.esa.int [131.176.1.131]) by esacom52.estec.esa.int (8.12.10/8.12.10/ESA-Internal-v3.2) with ESMTP id i1A6IoCT018545 for ; Tue, 10 Feb 2004 07:18:50 +0100 (MET) Subject: Re: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02. To: ip-dvb@erg.abdn.ac.uk X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: Frank.Zeppenfeldt@esa.int Date: Tue, 10 Feb 2004 07:18:49 +0100 X-MIMETrack: Serialize by Router on estecmta1/estec/ESA(Release 5.0.11 |July 24, 2002) at 10-02-2004 07:18:50 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk X-UIDL: R+?!!)6l!!8/M!!+bk!! Status: RO X-Status: X-Keywords: X-UID: 7485 I support the adoption of the ID draft-fair-ipdvb-ule-02.txt as a WG ID. Frank.Zeppenfeldt@esa.int http://telecom.esa.int/ ESA/ESTEC (European Space & Technology Centre) Keplerlaan 1 Postbus 299 2200 AG Noordwijk (The Netherlands) From owner-ip-dvb@erg.abdn.ac.uk Tue Feb 10 08:22:46 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1A8MD5U024551 for ; Tue, 10 Feb 2004 08:22:13 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1A8MCIH024550 for ip-dvb-subscribed-users; Tue, 10 Feb 2004 08:22:12 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from proxy.6wind.com (proxy.ipv6.6wind.com [194.250.197.211]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1A8LWTh024516 for ; Tue, 10 Feb 2004 08:21:32 GMT Received: from eagle.6wind.com (givenchy.6wind.com [212.234.238.114]) by proxy.6wind.com (Postfix) with ESMTP id 91630754 for ; Tue, 10 Feb 2004 09:21:31 +0100 (CET) Received: from 6wind.com (unknown [10.16.0.135]) by eagle.6wind.com (Postfix) with ESMTP id 70143465; Tue, 10 Feb 2004 09:21:31 +0100 (CET) Message-ID: <4028957D.803@6wind.com> Date: Tue, 10 Feb 2004 09:25:33 +0100 From: alain.ritoux@6wind.com 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: ip-dvb@erg.abdn.ac.uk Subject: ULE extension headers References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk X-UIDL: p\&#!+F5"!=H?!!ILA!! Status: O X-Status: X-Keywords: X-UID: 7494 Marie-Jose Montpetit wrote: > I support the adoption of the ID as WG document. I also suggest for > point 5) extension headers in ULE for future services. > I agree with an extension header for future services. I would propose to do it in an IPv6-style, using some values in the 1-1500 part of next header, to signal the extention header(s). Such headers could then have a fixed and well known begining : +---+---+---+--// ..... // ----+ | NH | L | extension value | +---+---+---+--// ..... // ----+ NH : 2 bytes, defines the type of next field which could then be, a classical ULE payload (0x800 for IPv4 ...) or even another extension header. L : length in bytes of the header. Even some values range could be reseved for that purpose, that would allow implementation to be compatible with still not known extensions. And even that would indicate the behaviour if extension is not known. exemple : 1280 <= type field < 1304 : optional extension, if not known, just skip and process next 1304 <= type field < 1408 : critical extension, if not known, stop processing, drop ULE SNDU, and possibly report an error to emitter (if possible, but how ??, usefull ??, ..) I chose those values as exemple because - they are in the 1-500 range - they have a nice bit pattern and can be checked with a single AND Still about the type field : I think it would be good to reseve a certain range of these values, for experimental uses, which would garanty that (if respected ;-))) there would be no conflict with due reserved values. 1408 <= type field < 1472 : reseved for experimental purpose, In operational use, such SNDU MUST be silently dropped. All this is very little implementation and keeps the door opened for any future services. Your thoughts about this ? Regards. Alain. -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com From owner-ip-dvb@erg.abdn.ac.uk Tue Feb 10 10:43:46 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1AAPa3D029271 for ; Tue, 10 Feb 2004 10:25:36 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1AAPaPn029270 for ip-dvb-subscribed-users; Tue, 10 Feb 2004 10:25:36 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from proxy.6wind.com (proxy.ipv6.6wind.com [194.250.197.211]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1AAP9iV029242 for ; Tue, 10 Feb 2004 10:25:09 GMT Received: from eagle.6wind.com (givenchy.6wind.com [212.234.238.114]) by proxy.6wind.com (Postfix) with ESMTP id 6F863725 for ; Tue, 10 Feb 2004 11:25:09 +0100 (CET) Received: from 6wind.com (unknown [10.16.0.135]) by eagle.6wind.com (Postfix) with ESMTP id 4EB63F1; Tue, 10 Feb 2004 11:25:09 +0100 (CET) Message-ID: <4028B277.80407@6wind.com> Date: Tue, 10 Feb 2004 11:29:11 +0100 From: alain.ritoux@6wind.com 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 Subject: ULE : SNDU Packing/Padding examples References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk X-UIDL: 0B3"!IoN"!i@'#!n'B"! Status: RO X-Status: X-Keywords: X-UID: 7521 Gorry Fairhurst wrote: > As WG chair, I request the ipdvb list to consider whether the WG is > ... > 3) Need to check the SNDU Packing/Padding examples in the informative > appendix of the ID for correctness (including the length of the last > packet of example A.4) --- any volunteers? I do ;-) In all examples, we assume the SNDU size includes the whole SNDU (header, body, trailer), hence, the field length is this size minus 4 Exemple A.1, first TS cell ============================ Error in length: actually 0x00 0xC8 should be 0x00 0xC4 Exemple A.1, second TS cell ============================ Error in length: actually 0x00 0xC0 should be 0x00 0xC4 Error in Payload Pointer value actually 0x10 / PP=16 should be 0x11 / PP=17 Exemple A.3, 5th TS cell ========================== Error in last byte numbering actually B186 should be B185 Exemple A.3, 6th TS cell ========================== Error in first byte numbering actually B187 should be B186 The others examples/TS-cells seem fine for me. Cheers. Alain. -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com From owner-ip-dvb@erg.abdn.ac.uk Tue Feb 11 11:43:46 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1AB4CL0001859 for ; Tue, 10 Feb 2004 11:04:13 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1AB4C6E001858 for ip-dvb-subscribed-users; Tue, 10 Feb 2004 11:04:12 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from out011.verizon.net (out011pub.verizon.net [206.46.170.135]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1AB2KWE001616 for ; Tue, 10 Feb 2004 11:02:20 GMT Received: from copernicus ([68.163.254.15]) by out011.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040210110217.PZDB17235.out011.verizon.net@copernicus> for ; Tue, 10 Feb 2004 05:02:17 -0600 Message-ID: <003301c3efc5$80edf4e0$b402a8c0@copernicus> From: "Marie-Jose Montpetit" To: References: <4028957D.803@6wind.com> Subject: Re: ULE extension headers Date: Tue, 10 Feb 2004 06:03:21 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authentication-Info: Submitted using SMTP AUTH at out011.verizon.net from [68.163.254.15] at Tue, 10 Feb 2004 05:02:16 -0600 X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk X-UIDL: SiQ!!~Jj!!1 To: Sent: Tuesday, February 10, 2004 3:25 AM Subject: ULE extension headers > > > Marie-Jose Montpetit wrote: > > > I support the adoption of the ID as WG document. I also suggest for point 5) > > extension headers in ULE for future services. > > > > I agree with an extension header for future services. > > I would propose to do it in an IPv6-style, using some values in the > 1-1500 part of next header, to signal the extention header(s). Such > headers could then have a fixed and well known begining : > +---+---+---+--// ..... // ----+ > | NH | L | extension value | > +---+---+---+--// ..... // ----+ > > NH : 2 bytes, defines the type of next field which could then be, > a classical ULE payload (0x800 for IPv4 ...) or even another > extension header. > L : length in bytes of the header. > > Even some values range could be reseved for that purpose, that would > allow implementation to be compatible with still not known extensions. > And even that would indicate the behaviour if extension is not known. > > exemple : > 1280 <= type field < 1304 : optional extension, if not known, > just skip and process next 1304 <= > type field < 1408 : critical extension, if not known, stop > processing, drop ULE SNDU, and possibly > report an error to emitter > (if possible, but how ??, usefull ??, > ..) > > I chose those values as exemple because > - they are in the 1-500 range > - they have a nice bit pattern and can be checked with a single AND > > > Still about the type field : > I think it would be good to reseve a certain range of these values, > for experimental uses, which would garanty that (if respected ;-))) > there would be no conflict with due reserved values. 1408 <= type > field < 1472 : reseved for experimental purpose, In > operational use, such SNDU MUST be > silently dropped. > > All this is very little implementation and keeps the door opened for > any future services. > > Your thoughts about this ? > > Regards. > Alain. > -- > Alain RITOUX > Tel +33-1-39-30-92-32 > Fax +33-1-39-30-92-11 > visit our web http://www.6wind.com > > From owner-ip-dvb@erg.abdn.ac.uk Wed Feb 11 08:43:46 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1B8rLJE020173 for ; Wed, 11 Feb 2004 08:53:21 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1B8rL78020172 for ip-dvb-subscribed-users; Wed, 11 Feb 2004 08:53:21 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from tokyo.ccrle.nec.de (tokyo.netlab.nec.de [195.37.70.2]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1B8qbkv020140 for ; Wed, 11 Feb 2004 08:52:37 GMT Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i1B8qWZU074650 for ; Wed, 11 Feb 2004 09:52:32 +0100 (CET) Received: from [10.1.1.109] (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 5294910588E for ; Wed, 11 Feb 2004 09:52:31 +0100 (CET) Date: Wed, 11 Feb 2004 09:52:45 +0100 From: Martin Stiemerling To: ip-dvb@erg.abdn.ac.uk Subject: Re: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02. Message-ID: <2147483647.1076493165@[10.1.1.109]> In-Reply-To: <402767AE.3020709@erg.abdn.ac.uk> References: <402767AE.3020709@erg.abdn.ac.uk> X-Mailer: Mulberry/3.1.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk X-UIDL: e^j"!lES!!1<(#!9B0!! Hi, I support to accept ULE as WG document. Martin --On Montag, 9. Februar 2004 10:57 Uhr +0000 Gorry Fairhurst wrote: | As WG chair, I request the ipdvb list to consider whether the WG is | ready to support adoption of the following individual Internet Draft | (ID) as a WG ID. By adopting an individual ID as a working group ID, | this WG indicates that it intends to be develop this into an RFC, | according to the WG charter. | WG documents should no longer be regarded as the property of the | individuals who originally authored them - the working group as a whole | must decide how they are shaped, and to see the document to | a successful conclusion. If adopted, the Internet Draft will be renamed to | start with the filename draft-ietf-ipdvb..., and will be listed on the | IETF | web page for this WG. | | --- | | Title : Ultra Lightweight Encapsulation (ULE) for | transmission of IP datagrams over | MPEG-2/DVB networks | Author(s) : G. Fairhurst, B. Collini-Nocker | Filename : draft-fair-ipdvb-ule-02.txt | Pages : 32 | Date : 2003-11-24 | The MPEG-2 TS has been widely accepted not only for providing | digital TV services, but also as a subnetwork technology for building | IP networks. This document describes an Ultra Lightweight | Encapsulation (ULE) mechanism for the transport of IPv4 and IPv6 | Datagrams and other network protocol packets directly over ISO MPEG- 2 | Transport Streams (TS) as TS Private Data. | | --- | | You are encouraged to send email to this WG, to help make the decision | for adoption. Possible recommendations are: | | 1) Support for adoption as a working group draft under our Charter - | i.e. Recommend this Internet Draft SHOULD be used as the basis for | developing an RFC by the ipdvb WG. | | 2) Request for non-adoption | i.e. That there is (or could be) alternative approaches to | the problem, and that the current draft is not sufficiently | developed / or correctly designed ipdvb WG | | 3) Out of scope | i.e. you believe the document to be beyond the scope of the | approved ipdvb WG charter. | | Emails on this topic should be sent to the ipdvb mailing list before | 23rd February 2004. | | Note that an ID does not need to be complete to be adopted. It would | also be most useful to collect as many comments/criticisms as possible | from those reading this ID. Looking through the archived mailing | list, a first list of issues to be addressed is included at the end of | this email. | | Please do help to identify any more known (or potential) issues that | should be addressed/discussed. | | Best wishes, | | Gorry Fairhurst | (ipdvb WG Chair) | | | --- | | | Known issues with draft-fair-ipdvb-ule-02.txt | ============================================= | | 1) Refinement of the text on CRC generation to be unambiguous | (explicitly talk about the polynomial as a forward CRC-32 and THEN | explicitly about the computation process) | - Text to be rewritten. | | 2) Query about the code point value for an Ethernet Bridging SNDU - | should the ULE type-field be 0x0001 ; 0x0007 as in ATM/AAL5 (as in | RFC2684); or should the IEEE Ethertype for bridging (0x6558) be used | instead? | - Discuss on list. | | 3) Need to check the SNDU Packing/Padding examples in the informative | appendix of the ID for correctness (including the length of the last | packet of example A.4) --- any volunteers? | | 4) Suggestion to add an appendix to the next rev of the ID, with a | hexadecimal example of an SNDU, to assist implementors in validating | the operation of the CRC. The following example has been proposed: | |>> Ping6 |>> from 2001:660:3008:1789::5 to 2001:660:3008:1789::6, with the |>> associated DVB MAC addr being 01:02:03:04:05:06. It gives the |>> following SNDU : |>> |>> 0000: 00 3f 86 dd 01 02 03 04 05 06 60 00 00 00 00 0d |>> .?........`..... |>> 0010: 3a 40 20 01 06 60 30 08 17 89 00 00 00 00 00 00 :@ ..`0......... |>> 0020: 00 05 20 01 06 60 30 08 17 89 00 00 00 00 00 00 .. ..`0......... |>> 0030: 00 06 80 00 9c 58 07 70 00 00 00 00 00 00 00 02 .....X.p........ |>> 0040: 72 c9 c2 r.. |>> | - The exact decode of this needs to be done and verified | | | 5) ??? | | From owner-ip-dvb@erg.abdn.ac.uk Wed Feb 11 09:31:46 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1B9Uq32021617 for ; Wed, 11 Feb 2004 09:30:52 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1B9UpFM021616 for ip-dvb-subscribed-users; Wed, 11 Feb 2004 09:30:51 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from GWOUT.thalesgroup.com (gwout.thalesgroup.com [195.101.39.227]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1B9Sir4021500 for ; Wed, 11 Feb 2004 09:28:44 GMT Received: from thalescan.corp.thales (200.3.2.3) by GWOUT.thalesgroup.com (NPlex 6.5.026) id 4024E3CE00056F4D for ip-dvb@erg.abdn.ac.uk; Wed, 11 Feb 2004 10:28:48 +0100 Received: from lowplex.mut.thales ([10.33.37.2]) by thalescan with InterScan Messaging Security Suite; Wed, 11 Feb 2004 10:27:50 +0100 Received: from cnfplex.thomcast.thomson-csf.com (178.1.4.1) by lowplex.mut.thales (NPlex 6.5.026) id 401E14AF000D80B7 for ip-dvb@erg.abdn.ac.uk; Wed, 11 Feb 2004 10:27:50 +0100 Received: from zethos.thomcast.thomson-csf.com (178.3.2.15) by cnfplex.thomcast.thomson-csf.com (NPlex 6.5.026) id 402714AA000024EB for ip-dvb@erg.abdn.ac.uk; Wed, 11 Feb 2004 10:27:50 +0100 Received: from andromede (178.3.1.43) by zethos.thomcast.thomson-csf.com (NPlex 6.5.026) id 40164E0800007A57 for ip-dvb@erg.abdn.ac.uk; Wed, 11 Feb 2004 10:30:41 +0100 From: "Benoit Oger" To: Subject: RE: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02. Date: Wed, 11 Feb 2004 10:24:17 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <2147483647.1076493165@[10.1.1.109]> X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk X-UIDL: P?Q!!&XO!!-92"!nW;"! Hello, I support the adoption of the ULE draft as a WG draft. Benoit > --On Montag, 9. Februar 2004 10:57 Uhr +0000 Gorry Fairhurst > wrote: > > | As WG chair, I request the ipdvb list to consider whether the > WG is ready > | to > | support adoption of the following individual Internet Draft (ID) as > | a WG ID. By adopting an individual ID as a working group ID, this WG > indicates > | that it intends to be develop this into an RFC, according to the WG > | charter. WG documents should no longer be regarded as the property > | of the individuals who originally authored them - the working group > | as a whole must decide how they are shaped, and to see the document > | to a successful conclusion. If adopted, the Internet Draft will be > renamed to > | start with the filename draft-ietf-ipdvb..., and will be listed on > | the IETF web page for this WG. > | > | --- > | > | Title : Ultra Lightweight Encapsulation (ULE) for > | transmission of IP datagrams over > | MPEG-2/DVB networks > | Author(s) : G. Fairhurst, B. Collini-Nocker > | Filename : draft-fair-ipdvb-ule-02.txt > | Pages : 32 > | Date : 2003-11-24 > | The MPEG-2 TS has been widely accepted not only for > | providing digital TV services, but also as a subnetwork technology > | for building IP networks. This document describes an Ultra > | Lightweight Encapsulation (ULE) mechanism for the transport of IPv4 > | and IPv6 Datagrams and other network protocol packets directly over > | ISO MPEG- 2 Transport Streams (TS) as TS Private Data. > | > | --- > | > | You are encouraged to send email to this WG, to help make the > decision for > | adoption. Possible recommendations are: > | > | 1) Support for adoption as a working group draft under > our Charter - > | i.e. Recommend this Internet Draft SHOULD be used as the basis for > | developing an RFC by the ipdvb WG. > | > | 2) Request for non-adoption > | i.e. That there is (or could be) alternative approaches to > | the problem, and that the current draft is not sufficiently > | developed / or correctly designed ipdvb WG > | > | 3) Out of scope > | i.e. you believe the document to be beyond the scope of the > | approved ipdvb WG charter. > | > | Emails on this topic should be sent to the ipdvb mailing list before > | 23rd February 2004. > | > | Note that an ID does not need to be complete to be adopted. It would > | also be most useful to collect as many comments/criticisms as > | possible from those reading this ID. Looking through the archived > | mailing list, a first list of issues to be addressed is included at > | the end of > this email. > | > | Please do help to identify any more known (or potential) issues that > | should be addressed/discussed. > | > | Best wishes, > | > | Gorry Fairhurst > | (ipdvb WG Chair) > | > | > | --- > | > | > | Known issues with draft-fair-ipdvb-ule-02.txt > | ============================================= > | > | 1) Refinement of the text on CRC generation to be unambiguous > (explicitly > | talk about the polynomial as a forward CRC-32 > | and THEN explicitly about the computation process) > | - Text to be rewritten. > | > | 2) Query about the code point value for an Ethernet Bridging > SNDU - should > | the ULE type-field be 0x0001 ; 0x0007 as in ATM/AAL5 (as in > | RFC2684); or should the IEEE Ethertype for bridging (0x6558) be used > | instead? > | - Discuss on list. > | > | 3) Need to check the SNDU Packing/Padding examples in the > | informative appendix of the ID for correctness (including the length > | of the last packet of example A.4) --- any volunteers? > | > | 4) Suggestion to add an appendix to the next rev of the ID, with a > | hexadecimal example of an SNDU, to assist implementors in validating > | the operation of the CRC. The following example has been proposed: > | > |>> Ping6 > |>> from 2001:660:3008:1789::5 to 2001:660:3008:1789::6, with the > associated > |>> DVB MAC addr being 01:02:03:04:05:06. It gives the following SNDU > |>> : > |>> > |>> 0000: 00 3f 86 dd 01 02 03 04 05 06 60 00 00 00 00 0d > .?........`..... > |>> 0010: 3a 40 20 01 06 60 30 08 17 89 00 00 00 00 00 00 :@ > ..`0......... > |>> 0020: 00 05 20 01 06 60 30 08 17 89 00 00 00 00 00 00 .. > ..`0......... > |>> 0030: 00 06 80 00 9c 58 07 70 00 00 00 00 00 00 00 02 > .....X.p........ > |>> 0040: 72 c9 c2 r.. > |>> > | - The exact decode of this needs to be done and verified > | > | > | 5) ??? > | > | > > From owner-ip-dvb@erg.abdn.ac.uk Thu Feb 12 08:43:46 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1C8Ixbm012245 for ; Thu, 12 Feb 2004 08:18:59 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1C8Ixnt012244 for ip-dvb-subscribed-users; Thu, 12 Feb 2004 08:18:59 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1C8IHZu012218 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 12 Feb 2004 08:18:18 GMT Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1C8Hpv12334; Thu, 12 Feb 2004 10:17:52 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 12 Feb 2004 10:16:04 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 12 Feb 2004 10:16:03 +0200 Received: from esebe024.NOE.Nokia.com ([172.21.138.125]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 12 Feb 2004 10:16:04 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe024.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 12 Feb 2004 10:16:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02. Date: Thu, 12 Feb 2004 10:16:03 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02. Thread-Index: AcPu/0s+qU5OJf1iQSKhIbGr2LbWqACQLyfg From: To: , X-OriginalArrivalTime: 12 Feb 2004 08:16:03.0580 (UTC) FILETIME=[74C563C0:01C3F140] 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 i1C8Iv0R012240 Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk X-UIDL: SVe!!nC)!!`CA!!$3H!! Hi Gorry & WG I also support ULE adoption as a WG draft. Please spell out the proposed timeframe as this has a big effect on the quality of the final document developed. BTW, the "option (2)" is rather confusing "That there is (or could be) alternative approaches to the problem, and that the current draft is not sufficiently developed", since there is an existing solution (MPE) and there certainly are alternatives (even ipdvb started with 2 :). Also, the point of chartering into a WG is to develop the work-in-progress draft with the aim of publishing as an RFC - not just rubber stamp the individual draft with an RFC number. Is this just imprecise wording, or have I misunderstood? - please clarify. (I'll be in Korea, so would be happy to share a couple of round with anyone interested in a bar-WG - not a bar-bof anymore :) Cheers, Rod. -----Original Message----- From: owner-ip-dvb@erg.abdn.ac.uk [mailto:owner-ip-dvb@erg.abdn.ac.uk]On Behalf Of ext Gorry Fairhurst Sent: Monday, February 09, 2004 12:58 PM To: ipdvb@erg.abdn.ac.uk Subject: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02. As WG chair, I request the ipdvb list to consider whether the WG is ready to support adoption of the following individual Internet Draft (ID) as a WG ID. By adopting an individual ID as a working group ID, this WG indicates that it intends to be develop this into an RFC, according to the WG charter. WG documents should no longer be regarded as the property of the individuals who originally authored them - the working group as a whole must decide how they are shaped, and to see the document to a successful conclusion. If adopted, the Internet Draft will be renamed to start with the filename draft-ietf-ipdvb..., and will be listed on the IETF web page for this WG. --- Title : Ultra Lightweight Encapsulation (ULE) for transmission of IP datagrams over MPEG-2/DVB networks Author(s) : G. Fairhurst, B. Collini-Nocker Filename : draft-fair-ipdvb-ule-02.txt Pages : 32 Date : 2003-11-24 The MPEG-2 TS has been widely accepted not only for providing digital TV services, but also as a subnetwork technology for building IP networks. This document describes an Ultra Lightweight Encapsulation (ULE) mechanism for the transport of IPv4 and IPv6 Datagrams and other network protocol packets directly over ISO MPEG- 2 Transport Streams (TS) as TS Private Data. --- You are encouraged to send email to this WG, to help make the decision for adoption. Possible recommendations are: 1) Support for adoption as a working group draft under our Charter - i.e. Recommend this Internet Draft SHOULD be used as the basis for developing an RFC by the ipdvb WG. 2) Request for non-adoption i.e. That there is (or could be) alternative approaches to the problem, and that the current draft is not sufficiently developed / or correctly designed ipdvb WG 3) Out of scope i.e. you believe the document to be beyond the scope of the approved ipdvb WG charter. Emails on this topic should be sent to the ipdvb mailing list before 23rd February 2004. Note that an ID does not need to be complete to be adopted. It would also be most useful to collect as many comments/criticisms as possible from those reading this ID. Looking through the archived mailing list, a first list of issues to be addressed is included at the end of this email. Please do help to identify any more known (or potential) issues that should be addressed/discussed. Best wishes, Gorry Fairhurst (ipdvb WG Chair) --- Known issues with draft-fair-ipdvb-ule-02.txt ============================================= 1) Refinement of the text on CRC generation to be unambiguous (explicitly talk about the polynomial as a forward CRC-32 and THEN explicitly about the computation process) - Text to be rewritten. 2) Query about the code point value for an Ethernet Bridging SNDU - should the ULE type-field be 0x0001 ; 0x0007 as in ATM/AAL5 (as in RFC2684); or should the IEEE Ethertype for bridging (0x6558) be used instead? - Discuss on list. 3) Need to check the SNDU Packing/Padding examples in the informative appendix of the ID for correctness (including the length of the last packet of example A.4) --- any volunteers? 4) Suggestion to add an appendix to the next rev of the ID, with a hexadecimal example of an SNDU, to assist implementors in validating the operation of the CRC. The following example has been proposed: >> Ping6 >> from 2001:660:3008:1789::5 to 2001:660:3008:1789::6, with the >> associated DVB MAC addr being 01:02:03:04:05:06. It gives the >> following SNDU : >> >> 0000: 00 3f 86 dd 01 02 03 04 05 06 60 00 00 00 00 0d >> .?........`..... >> 0010: 3a 40 20 01 06 60 30 08 17 89 00 00 00 00 00 00 :@ ..`0......... >> 0020: 00 05 20 01 06 60 30 08 17 89 00 00 00 00 00 00 .. ..`0......... >> 0030: 00 06 80 00 9c 58 07 70 00 00 00 00 00 00 00 02 .....X.p........ >> 0040: 72 c9 c2 r.. >> - The exact decode of this needs to be done and verified 5) ??? From owner-ip-dvb@erg.abdn.ac.uk Thu Feb 12 20:37:46 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1CKbOC8007539 for ; Thu, 12 Feb 2004 20:37:24 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1CKbOLo007538 for ip-dvb-subscribed-users; Thu, 12 Feb 2004 20:37:24 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from mx.laposte.net (mx.laposte.net [81.255.54.11]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1CKaAxT007489 for ; Thu, 12 Feb 2004 20:36:12 GMT Received: from thales-bm.com (213.36.129.48) by mx.laposte.net (7.0.024) (authenticated as richardo.lhermitte) id 40225CF200365029 for ip-dvb@erg.abdn.ac.uk; Thu, 12 Feb 2004 21:36:06 +0100 Message-ID: <402B8AD9.840AB752@thales-bm.com> Date: Thu, 12 Feb 2004 15:16:57 +0100 From: Richard Lhermitte Organization: Thales Broadcast & Multimedia X-Mailer: Mozilla 4.78 [fr] (Windows NT 5.0; U) X-Accept-Language: fr MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Re: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02. References: <402767AE.3020709@erg.abdn.ac.uk> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk X-UIDL: 6VF"!Q53!!?e1!!_kK!! I support the adoption of the ULE draft as a WG item. Richard Gorry Fairhurst a écrit : > As WG chair, I request the ipdvb list to consider whether the WG is > ready to support adoption of the following individual Internet Draft > (ID) as a WG ID. By adopting an individual ID as a working group ID, > this WG indicates that it intends to be develop this into an RFC, > according to the WG charter. > > WG documents should no longer be regarded as the property of the > individuals who originally authored them - the working group as a > whole must decide how they are shaped, and to see the document to a > successful conclusion. If adopted, the Internet Draft will be renamed > to start with the filename draft-ietf-ipdvb..., and will be listed on > the IETF web page for this WG. > > --- > > Title : Ultra Lightweight Encapsulation (ULE) for > transmission of IP datagrams over > MPEG-2/DVB networks > Author(s) : G. Fairhurst, B. Collini-Nocker > Filename : draft-fair-ipdvb-ule-02.txt > Pages : 32 > Date : 2003-11-24 > > The MPEG-2 TS has been widely accepted not only for providing digital > TV services, but also as a subnetwork technology for building IP > networks. This document describes an Ultra Lightweight Encapsulation > (ULE) mechanism for the transport of IPv4 and IPv6 Datagrams and other > network protocol packets directly over ISO MPEG- 2 Transport Streams > (TS) as TS Private Data. > > --- > > You are encouraged to send email to this WG, to help make the decision > for adoption. Possible recommendations are: > > 1) Support for adoption as a working group draft under our Charter - > i.e. Recommend this Internet Draft SHOULD be used as the basis for > developing an RFC by the ipdvb WG. > > 2) Request for non-adoption > i.e. That there is (or could be) alternative approaches to > the problem, and that the current draft is not sufficiently > developed / or correctly designed ipdvb WG > > 3) Out of scope > i.e. you believe the document to be beyond the scope of the > approved ipdvb WG charter. > > Emails on this topic should be sent to the ipdvb mailing list before > 23rd February 2004. > > Note that an ID does not need to be complete to be adopted. It would > also be most useful to collect as many comments/criticisms as possible > from those reading this ID. Looking through the archived mailing > list, a first list of issues to be addressed is included at the end of > this email. > > Please do help to identify any more known (or potential) issues that > should be addressed/discussed. > > Best wishes, > > Gorry Fairhurst > (ipdvb WG Chair) > > --- > > Known issues with draft-fair-ipdvb-ule-02.txt > ============================================= > > 1) Refinement of the text on CRC generation to be unambiguous > (explicitly talk about the polynomial as a forward CRC-32 and THEN > explicitly about the computation process) > - Text to be rewritten. > > 2) Query about the code point value for an Ethernet Bridging SNDU - > should the ULE type-field be 0x0001 ; 0x0007 as in ATM/AAL5 (as in > RFC2684); or should the IEEE Ethertype for bridging (0x6558) be used > instead? > - Discuss on list. > > 3) Need to check the SNDU Packing/Padding examples in the informative > appendix of the ID for correctness (including the length of the last > packet of example A.4) > --- any volunteers? > > 4) Suggestion to add an appendix to the next rev of the ID, with a > hexadecimal example of an SNDU, to assist implementors in validating > the operation of the CRC. The following example has been proposed: > > >> Ping6 > >> from 2001:660:3008:1789::5 to 2001:660:3008:1789::6, with the > >> associated DVB MAC addr being 01:02:03:04:05:06. It gives the > >> following SNDU : > >> > >> 0000: 00 3f 86 dd 01 02 03 04 05 06 60 00 00 00 00 0d > >> .?........`..... > >> 0010: 3a 40 20 01 06 60 30 08 17 89 00 00 00 00 00 00 :@ ..`0......... > >> 0020: 00 05 20 01 06 60 30 08 17 89 00 00 00 00 00 00 .. ..`0......... > >> 0030: 00 06 80 00 9c 58 07 70 00 00 00 00 00 00 00 02 .....X.p........ > >> 0040: 72 c9 c2 r.. > >> > - The exact decode of this needs to be done and verified > > 5) ??? From owner-ip-dvb@erg.abdn.ac.uk Fri Feb 13 14:07:46 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1DE7KjY011825 for ; Fri, 13 Feb 2004 14:07:20 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1DE7Jbo011824 for ip-dvb-subscribed-users; Fri, 13 Feb 2004 14:07:19 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from smail3.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1DE6Ems011794 for ; Fri, 13 Feb 2004 14:06:15 GMT Received: from vzmta01.netfr.alcatel.fr (vzmta01.netfr.alcatel.fr [155.132.182.220]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id i1DE5bIH005947 for ; Fri, 13 Feb 2004 15:06:04 +0100 Importance: Low Sensitivity: Subject: Question on Continuity Counter field To: ip-dvb@erg.abdn.ac.uk From: Tarif.Zein-Alabedeen@space.alcatel.fr Date: Fri, 13 Feb 2004 15:04:30 +0100 Message-ID: X-MIMETrack: Serialize by Router on VZMTA01/ALCANET/ALCATEL-SPACE(Release 5.0.12 |February 13, 2003) at 13/02/2004 15:06:04 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk X-UIDL: "O]!!=Cg!!hPU!!4,g!! Hi, I have a question about the continuity counter field in the TS packet header. May be someone in this group has the right answer : what heppens if an MPEG receiver receives an out of order TS packet? that is, for the same PID, the CC field value of a received packet not equal to CC field value of precedent TS packet + 1 Is there one standard behavior or is it implmenetation dependent? can CC check as the receiver be disabled? (oups, this makes 3 questions already) thank's and best regards T. Zein ALCATEL SPACE DRT/RST From owner-ip-dvb@erg.abdn.ac.uk Fri Feb 13 21:00:46 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1DKxZNf025609 for ; Fri, 13 Feb 2004 20:59:35 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1DKxXjm025606 for ip-dvb-subscribed-users; Fri, 13 Feb 2004 20:59:33 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from esacom57-int.estec.esa.int (esacom57-ext.estec.esa.int [131.176.107.4]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1DKwDtU025558 for ; Fri, 13 Feb 2004 20:58:14 GMT Received: from esacom52.estec.esa.int (esacom52.estec.esa.int [131.176.7.7]) by esacom57-int.estec.esa.int (8.12.10/8.12.10/ESA-External-v3.2) with ESMTP id i1DKw9VT012950 for ; Fri, 13 Feb 2004 21:58:09 +0100 (MET) Received: from estecmta1.estec.esa.int (estecmta1.estec.esa.int [131.176.1.131]) by esacom52.estec.esa.int (8.12.10/8.12.10/ESA-Internal-v3.2) with ESMTP id i1DKw8IH024380 for ; Fri, 13 Feb 2004 21:58:08 +0100 (MET) MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk From: Frank.Zeppenfeldt@esa.int Subject: Final Presentation of ESA study on ip-over-dvb: 5 March 2004 10.00h at ESTEC Date: Fri, 13 Feb 2004 21:58:02 +0100 Message-ID: X-MIMETrack: Serialize by Router on estecmta1/estec/ESA(Release 5.0.11 |July 24, 2002) at 13/02/2004 09:58:08 PM Content-type: multipart/mixed; Boundary="0__=CEBBE4AADFE0AD088f9e8a93df938690918cCEBBE4AADFE0AD08" Content-Disposition: inline X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk X-UIDL: *HS"!BW!"!HP;"!edQ!! You are cordially invited to attend a presentation that will take place in ESTEC (European Space and Technology Centre) in Noordwijk, the Netherlands, on 5 March 2004, 10.00h-13.00h in room Da 026 on the subject of ip-over-dvb. This a final presentation of one of two parallel studies initiated and funded by the European Space Agency (ESA) to support ongoing work within the ip-over-dvb community. The presentation will be made by by Joanneum Research (A), in partnership with University of Salzburg (A), GCS (A), EMS (C) and the University of Aberdeen (UK). Information on these studies as been announced previously on this list in http://www.erg.abdn.ac.uk/ip-dvb/archive/msg00291.html http://www.erg.abdn.ac.uk/ip-dvb/archive/msg00463.html Please find attached an invitation and a summary abstract; feel free to pass this invitation to other interested persons. The presentation is open to all, but registration is required for external visitors. More information may also be found on: http://telecom.esa.int/telecom/www/object/index.cfm?fobjectid=11405 http://telecom.esa.int/telecom/www/object/index.cfm?fobjectid=11850 Best regards, Frank Zeppenfeldt +31 71 565 4376 From owner-ip-dvb@erg.abdn.ac.uk Fri Feb 13 21:07:46 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1DLGigK026230 for ; Fri, 13 Feb 2004 21:16:44 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1DLGiYe026229 for ip-dvb-subscribed-users; Fri, 13 Feb 2004 21:16:44 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from smtp.exodus.net (smtp.exodus.net [66.35.230.236]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1DLFOVB026174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 Feb 2004 21:15:25 GMT Received: from ms101.mail1.com (ms101.mail1.com [209.1.5.174]) by smtp.exodus.net (8.12.8/8.12.8) with ESMTP id i1DMs4w3017130; Fri, 13 Feb 2004 14:54:05 -0800 Received: from ala-mrwtemp.thingmagic.com (unverified [24.61.30.237]) by accounting.espmail.com (Rockliffe SMTPRA 5.2.5) with ESMTP id ; Fri, 13 Feb 2004 13:15:18 -0800 Message-Id: <5.1.0.14.2.20040213161153.0447bb70@ms101.mail1.com> X-Sender: margaret@thingmagic.com@ms101.mail1.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 13 Feb 2004 16:13:38 -0500 To: ip-dvb@erg.abdn.ac.uk From: Margaret Wasserman Subject: RE: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02. Cc: Gorry Fairhurst In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk X-UIDL: 3MQ!!o%)"!d9+"!1Sp"! Hi Rod, >(I'll be in Korea, so would be happy to share a couple of round with >anyone interested in a bar-WG - not a bar-bof anymore :) If you don't mind, I'll take you up on this! I don't want to distract the WG from its chartered work, but I would like to better understand the current state of standardization in the field and how our work in IPDVB will fit in. It would be great if Gorry can join us, and anyone else who wants to come, of course. Margaret From owner-ip-dvb@erg.abdn.ac.uk Mon Feb 16 13:24:46 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1GDOIQU001218 for ; Mon, 16 Feb 2004 13:24:18 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1GDOId7001217 for ip-dvb-subscribed-users; Mon, 16 Feb 2004 13:24:18 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from bonnie.ses-astra.com (bonnie.ses-astra.com [194.154.219.59]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1GDNFSc001173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 16 Feb 2004 13:23:20 GMT 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 i1GDN9Ig008627 for ; Mon, 16 Feb 2004 14:23:09 +0100 (CET) Subject: Re: Final Presentation of ESA study on ip-over-dvb: 5 March 2004 10.00h at ESTEC To: ip-dvb@erg.abdn.ac.uk X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: Jens.Krause@ses-astra.com Date: Mon, 16 Feb 2004 14:23:07 +0100 X-MIMETrack: Serialize by Router on marge/BTZ(Release 5.0.12 |February 13, 2003) at 16/02/2004 14:23:09 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk X-UIDL: C%W"!4bU!!eGa"![Ha!! I would like to attend the IP over DVB presentation on March 5th. As requested in the invitation, I herewith confirm my attendance. I will also participate in the ETSI BSM meeting the days before this presentation. --------------------------------------------------------------------------- Dr. Jens Krause Sr Mgr, Communications Systems Engineering Technical Department SES ASTRA Address: L-6815 Chateau de Betzdorf Luxembourg Tel.: +352-710 725 447 Fax: +352-710 725 482 E-mail: Jens.Krause@ses-astra.com Our web site: http://www.ses-astra.com --------------------------------------------------------------------------- -- 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. From owner-ip-dvb@erg.abdn.ac.uk Mon Feb 16 14:43:46 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1GEuRjE004483 for ; Mon, 16 Feb 2004 14:56:27 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1GEuQSh004482 for ip-dvb-subscribed-users; Mon, 16 Feb 2004 14:56:26 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from bonnie.ses-astra.com (bonnie.ses-astra.com [194.154.219.59]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1GEtkLK004448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 16 Feb 2004 14:55:48 GMT 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 i1GEtfIg009982 for ; Mon, 16 Feb 2004 15:55:42 +0100 (CET) Subject: Re: Final Presentation of ESA study on ip-over-dvb: 5 March 2004 10.00h at ESTEC To: ip-dvb@erg.abdn.ac.uk X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: Jens.Krause@ses-astra.com Date: Mon, 16 Feb 2004 15:55:41 +0100 X-MIMETrack: Serialize by Router on marge/BTZ(Release 5.0.12 |February 13, 2003) at 16/02/2004 15:55:42 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk X-UIDL: o=d"!c&j"!HPU"!bpZ!! Please disregard the e-mail below. I wanted to send it to Frank Zeppenfeld from ESA, but sent it to this reflector by mistake. Sorry for the inconvenience and confusion. ----- Forwarded by Jens Krause/BTZ on 16/02/2004 15:50 ----- Jens Krause To: ip-dvb@erg.abdn.ac.uk 16/02/2004 14:23 cc: Subject: Re: Final Presentation of ESA study on ip-over-dvb: 5 March 2004 10.00h at ESTEC(Document link: Jens Krause) I would like to attend the IP over DVB presentation on March 5th. As requested in the invitation, I herewith confirm my attendance. I will also participate in the ETSI BSM meeting the days before this presentation. --------------------------------------------------------------------------- Dr. Jens Krause Sr Mgr, Communications Systems Engineering Technical Department SES ASTRA Address: L-6815 Chateau de Betzdorf Luxembourg Tel.: +352-710 725 447 Fax: +352-710 725 482 E-mail: Jens.Krause@ses-astra.com Our web site: http://www.ses-astra.com --------------------------------------------------------------------------- -- 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. From owner-ip-dvb@erg.abdn.ac.uk Tues Feb 17 14:56:46 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1HJl0QP004991 for ; Tue, 17 Feb 2004 19:47:00 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1HJl0BY004990 for ip-dvb-subscribed-users; Tue, 17 Feb 2004 19:47:00 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from [209.116.240.194] (foxtrot.nab.org [209.116.240.194]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1HJjcme004940 for ; Tue, 17 Feb 2004 19:45:39 GMT Received: from mail.nab.org by [209.116.240.194] via smtpd (for mavis.erg.abdn.ac.uk [139.133.204.77]) with ESMTP; Tue, 17 Feb 2004 14:45:40 -0500 Received: (private information removed) Message-ID: <5A659834E1607E4EBD72FCE2FE5C9CF102FEBEDB@mail.NAB.ORG> From: "Allison, Art" To: "'ip-dvb@erg.abdn.ac.uk'" Subject: RE: Question on Continuity Counter field Date: Tue, 17 Feb 2004 14:45:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk X-UIDL: &*0"!g'$"!M2n!!nlS"! IMHO, if a MPEG-2 TS parser was presented with out of order packets identified by the same PID, a receiver failure is to be expected as the stream would be non-conformant. However, the continuity_counter can be the same in sequential packets (which are then required to be the same except for the PCR). Also, this count may be discontinuous when that is indicated by the discontinuity_indicator. So it is not always a monotonically incrementing field. Given the rules for this 4-bit continuity_counter, it is not apparent that it is possible to use it to reorder packets at the MPEG-2 level. Therefore, IMHO, any lower level communication protocol must not reorder MPEG-2 transport stream packets that are identified by the same PID. If it has a potential to do so, then either constraints or an explicit method for restoring the order must be defined. Art ::{)> Art Allison Director Advanced Engineering NAB 1771 N St NW Washington DC 20036 202 429 5418 -----Original Message----- From: Tarif.Zein-Alabedeen@space.alcatel.fr [mailto:Tarif.Zein-Alabedeen@space.alcatel.fr] Sent: Friday, February 13, 2004 9:05 AM To: ip-dvb@erg.abdn.ac.uk Subject: Question on Continuity Counter field Importance: Low Hi, I have a question about the continuity counter field in the TS packet header. May be someone in this group has the right answer : what heppens if an MPEG receiver receives an out of order TS packet? that is, for the same PID, the CC field value of a received packet not equal to CC field value of precedent TS packet + 1 Is there one standard behavior or is it implmenetation dependent? can CC check as the receiver be disabled? (oups, this makes 3 questions already) thank's and best regards T. Zein ALCATEL SPACE DRT/RST From owner-ip-dvb@erg.abdn.ac.uk Wed Feb 18 13:43:46 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1I55DNB023750 for ; Wed, 18 Feb 2004 05:05:13 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1I55DwP023749 for ip-dvb-subscribed-users; Wed, 18 Feb 2004 05:05:13 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from rediffmail.com (webmail33.rediffmail.com [203.199.83.245] (may be forged)) by erg.abdn.ac.uk (8.12.11/8.12.11) with SMTP id i1I54f3T023729 for ; Wed, 18 Feb 2004 05:04:43 GMT Received: (qmail 16063 invoked by uid 510); 18 Feb 2004 05:04:38 -0000 Date: 18 Feb 2004 05:04:38 -0000 Message-ID: <20040218050438.16049.qmail@mailweb33.rediffmail.com> Received: from unknown (203.197.138.199) by rediffmail.com via HTTP; 18 feb 2004 05:04:38 -0000 MIME-Version: 1.0 From: "William StanisLaus" To: "'ip-dvb@erg.abdn.ac.uk'" Cc: "Allison,Art" Subject: Re: RE: Question on Continuity Counter field Content-type: multipart/alternative; boundary="Next_1077080678---0-203.199.83.245-16024" X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk X-UIDL: @e@"!TBa"!HO/"!ljd!! Hi, Please refer..ISO/IEC 13818-1 2.4.3.3 Semantic definition of fields in Transport Stream packet layer, Page 44 for countinuty_counter and Page 46 for discontinuity_indicator Well its again an implementation decision to consider or mask countinuty check based on the PID. Best Regards, William StanisLaus | Design Engineer - FS, Nera Dept email: williams@future.futsoft.com | Telephone: +91 44 24330550 Extn: 282 Mobile: +91 98411 57902 www.futsoft.com On Wed, 18 Feb 2004 Allison, Art wrote : >IMHO, if a MPEG-2 TS parser was presented with out of order packets >identified by the same PID, a receiver failure is to be expected as the >stream would be non-conformant. > >However, the continuity_counter can be the same in sequential packets (which >are then required to be the same except for the PCR). Also, this count may >be discontinuous when that is indicated by the discontinuity_indicator. So >it is not always a monotonically incrementing field. Given the rules for >this 4-bit continuity_counter, it is not apparent that it is possible to use >it to reorder packets at the MPEG-2 level. > >Therefore, IMHO, any lower level communication protocol must not reorder >MPEG-2 transport stream packets that are identified by the same PID. If it >has a potential to do so, then either constraints or an explicit method for >restoring the order must be defined. > >Art >::{)> >Art Allison >Director Advanced Engineering >NAB >1771 N St NW >Washington DC 20036 >202 429 5418 > > >-----Original Message----- > From: Tarif.Zein-Alabedeen@space.alcatel.fr >[mailto:Tarif.Zein-Alabedeen@space.alcatel.fr] >Sent: Friday, February 13, 2004 9:05 AM >To: ip-dvb@erg.abdn.ac.uk >Subject: Question on Continuity Counter field >Importance: Low > > > > >Hi, >I have a question about the continuity counter field in the TS packet >header. May be someone in this group has the right answer : >what heppens if an MPEG receiver receives an out of order TS packet? >that is, for the same PID, the CC field value of a received packet not >equal to CC field value of precedent TS packet + 1 > >Is there one standard behavior or is it implmenetation dependent? >can CC check as the receiver be disabled? > >(oups, this makes 3 questions already) > >thank's and best regards > > >T. Zein >ALCATEL SPACE >DRT/RST > From owner-ip-dvb@erg.abdn.ac.uk Wed Feb 18 13:43:46 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1ICQOuR008640 for ; Wed, 18 Feb 2004 12:26:24 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1ICQONe008639 for ip-dvb-subscribed-users; Wed, 18 Feb 2004 12:26:24 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1ICPeP8008603 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Wed, 18 Feb 2004 12:25:41 GMT Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1ICPfK05157 for ; Wed, 18 Feb 2004 14:25:41 +0200 (EET) X-Scanned: Wed, 18 Feb 2004 14:24:54 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i1ICOs0s021047 for ; Wed, 18 Feb 2004 14:24:54 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 004CuWeC; Wed, 18 Feb 2004 14:24:54 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1ICOr721235 for ; Wed, 18 Feb 2004 14:24:53 +0200 (EET) Received: from esebe024.NOE.Nokia.com ([172.21.138.125]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 18 Feb 2004 14:24:53 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe024.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 18 Feb 2004 14:24:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Question on Continuity Counter field Date: Wed, 18 Feb 2004 14:24:53 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question on Continuity Counter field Thread-Index: AcPyQYf2P/U5vL86S46tGGELb0+74QD2GyYQ From: To: X-OriginalArrivalTime: 18 Feb 2004 12:24:53.0012 (UTC) FILETIME=[35E26D40:01C3F61A] 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 i1ICQMpx008635 Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk X-UIDL: O?="!hUF"!+_S"!RoW!! Hi It is implementation dependent. Most likely a receiver would assume it has missed some packet(s). The spec doesn't specify the behaviour of a receiver. The spec only specifies how required parameters (incl. the continuity_counter) are coded. Cheers, Rod. -----Original Message----- From: owner-ip-dvb@erg.abdn.ac.uk [mailto:owner-ip-dvb@erg.abdn.ac.uk]On Behalf Of ext Tarif.Zein-Alabedeen@space.alcatel.fr Sent: Friday, February 13, 2004 4:05 PM To: ip-dvb@erg.abdn.ac.uk Subject: Question on Continuity Counter field Importance: Low Hi, I have a question about the continuity counter field in the TS packet header. May be someone in this group has the right answer : what heppens if an MPEG receiver receives an out of order TS packet? that is, for the same PID, the CC field value of a received packet not equal to CC field value of precedent TS packet + 1 Is there one standard behavior or is it implmenetation dependent? can CC check as the receiver be disabled? (oups, this makes 3 questions already) thank's and best regards T. Zein ALCATEL SPACE DRT/RST From owner-ip-dvb@erg.abdn.ac.uk Wed Feb 18 12:52:46 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1ICqDYu009611 for ; Wed, 18 Feb 2004 12:52:13 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1ICqDTU009610 for ip-dvb-subscribed-users; Wed, 18 Feb 2004 12:52:13 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from smail3.alcatel.fr (na5.alcatel.fr [194.133.58.5]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1ICpdJu009585 for ; Wed, 18 Feb 2004 12:51:40 GMT Received: from vzmta01.netfr.alcatel.fr (vzmta01.netfr.alcatel.fr [155.132.182.220]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id i1ICpXID001371 for ; Wed, 18 Feb 2004 13:51:33 +0100 Importance: Low Sensitivity: Subject: =?iso-8859-1?Q?R=E9f=2E_=3A_RE=3A_Question_on_Continuity_Counter_field?= To: ip-dvb@erg.abdn.ac.uk From: Tarif.Zein-Alabedeen@space.alcatel.fr Date: Wed, 18 Feb 2004 13:48:51 +0100 Message-ID: X-MIMETrack: Serialize by Router on VZMTA01/ALCANET/ALCATEL-SPACE(Release 5.0.12 |February 13, 2003) at 18/02/2004 13:51:33 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 X-Alcanet-MTA-scanned-and-authorized: yes 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 i1ICqACT009606 Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk X-UIDL: ?$U"!nD##!+bS"!6So!! Thank you Art and william for your answers... William says that consider or mask CC check for a given PID is implementation dependent.. is someone aware of the general rule for current IP/MPE/MPEG implementations? Considering our ULE encapsulation, I think it would be wise to provision an option allowing to disactivate CC check for specified PIDs in the receiver. This may be helpful if, at some point in the future, we need ULE/MPEG to operate correctly in a mesh or multi star scenarios (PID shared among several transmiters). what is your opinion about that? best regards Traif ZEIN "Allison, Art" @erg.abdn.ac.uk on 17/02/2004 20:45:38 Veuillez répondre à ip-dvb@erg.abdn.ac.uk Envoyé par : owner-ip-dvb@erg.abdn.ac.uk Pour : "'ip-dvb@erg.abdn.ac.uk'" cc : Objet : RE: Question on Continuity Counter field IMHO, if a MPEG-2 TS parser was presented with out of order packets identified by the same PID, a receiver failure is to be expected as the stream would be non-conformant. However, the continuity_counter can be the same in sequential packets (which are then required to be the same except for the PCR). Also, this count may be discontinuous when that is indicated by the discontinuity_indicator. So it is not always a monotonically incrementing field. Given the rules for this 4-bit continuity_counter, it is not apparent that it is possible to use it to reorder packets at the MPEG-2 level. Therefore, IMHO, any lower level communication protocol must not reorder MPEG-2 transport stream packets that are identified by the same PID. If it has a potential to do so, then either constraints or an explicit method for restoring the order must be defined. Art ::{)> Art Allison Director Advanced Engineering NAB 1771 N St NW Washington DC 20036 202 429 5418 -----Original Message----- From: Tarif.Zein-Alabedeen@space.alcatel.fr [mailto:Tarif.Zein-Alabedeen@space.alcatel.fr] Sent: Friday, February 13, 2004 9:05 AM To: ip-dvb@erg.abdn.ac.uk Subject: Question on Continuity Counter field Importance: Low Hi, I have a question about the continuity counter field in the TS packet header. May be someone in this group has the right answer : what heppens if an MPEG receiver receives an out of order TS packet? that is, for the same PID, the CC field value of a received packet not equal to CC field value of precedent TS packet + 1 Is there one standard behavior or is it implmenetation dependent? can CC check as the receiver be disabled? (oups, this makes 3 questions already) thank's and best regards From owner-ip-dvb@erg.abdn.ac.uk Wed Feb 18 13:43:46 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1IDhSMO011459 for ; Wed, 18 Feb 2004 13:43:29 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1IDhS6x011458 for ip-dvb-subscribed-users; Wed, 18 Feb 2004 13:43:28 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from [10.0.1.94] (maxp25.abdn.ac.uk [139.133.7.184]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1IDe0xa011318 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 18 Feb 2004 13:40:18 GMT User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Wed, 18 Feb 2004 13:38:13 +0000 Subject: Re: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02. 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-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk X-UIDL: I-_"!;74!!"U0"!#=@!! On 12/2/04 8:16 am, "Rod.Walsh@nokia.com" wrote: > Hi Gorry & WG > > I also support ULE adoption as a WG draft. > > Please spell out the proposed timeframe as this has a big effect on > the quality of the final document developed. There are now several early implementations being developed, so I'm keen to progress this, in parallel with this. The milestones for ULE are on the ipdvb Charter page at: http://ietf.org/ > BTW, the "option (2)" is rather confusing Sorry, it was just a general form of words for adopting a WG item. The aim is to allow people to tell the WG, if there is another (competing) ID on the way, or some alternative approach that also would address the charter, and hence they have concerns about adopting the WG item. > "That there is (or could be) > alternative approaches to the problem, and that the current draft is > not sufficiently developed", since there is an existing solution (MPE) > and there certainly are alternatives (even ipdvb started with 2 :). Indeed MPE exists - and is acknowledged in the WG Charter. The UNISAL encapsulation is not (as far as I am aware) being resubmitted to this WG as a competitor to ULE. > Also, the point of > chartering into a WG is to develop the work-in-progress draft with the > aim of publishing as an RFC - not just rubber stamp the individual > draft with an RFC number. Exactly, the WG is now looking for any inputs and/or potential concerns. > Is this just imprecise wording, or have I misunderstood? - please > clarify. The wording of (2) was loose, to allow scope to respond - thanks for asking. > > (I'll be in Korea, so would be happy to share a couple of round with > anyone interested in a bar-WG - not a bar-bof anymore :) > > Cheers, Rod. > > > -----Original Message----- > From: owner-ip-dvb@erg.abdn.ac.uk > [mailto:owner-ip-dvb@erg.abdn.ac.uk]On > Behalf Of ext Gorry Fairhurst > Sent: Monday, February 09, 2004 12:58 PM > To: ipdvb@erg.abdn.ac.uk > Subject: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02. > > > As WG chair, I request the ipdvb list to consider whether the WG is > ready to support adoption of the following individual Internet Draft > (ID) as a WG ID. By adopting an individual ID as a working group ID, > this WG indicates that it intends to be develop this into an RFC, > according to the WG charter. > > WG documents should no longer be regarded as the property of the > individuals who originally authored them - the working group as a > whole must decide how they are shaped, and to see the document to a > successful conclusion. If adopted, the Internet Draft will be renamed > to start with the filename draft-ietf-ipdvb..., and will be listed on > the IETF web page for this WG. > > --- > > Title : Ultra Lightweight Encapsulation (ULE) for > transmission of IP datagrams over > MPEG-2/DVB networks > Author(s) : G. Fairhurst, B. Collini-Nocker > Filename : draft-fair-ipdvb-ule-02.txt > Pages : 32 > Date : 2003-11-24 > > The MPEG-2 TS has been widely accepted not only for providing digital > TV services, but also as a subnetwork technology for building IP > networks. This document describes an Ultra Lightweight Encapsulation > (ULE) mechanism for the transport of IPv4 and IPv6 Datagrams and other > network protocol packets directly over ISO MPEG- 2 Transport Streams > (TS) as TS Private Data. > > --- > > You are encouraged to send email to this WG, to help make the decision > for adoption. Possible recommendations are: > > 1) Support for adoption as a working group draft under our Charter - > i.e. Recommend this Internet Draft SHOULD be used as the basis for > developing an RFC by the ipdvb WG. > > 2) Request for non-adoption > i.e. That there is (or could be) alternative approaches to > the problem, and that the current draft is not sufficiently > developed / or correctly designed ipdvb WG > > 3) Out of scope > i.e. you believe the document to be beyond the scope of the > approved ipdvb WG charter. > > Emails on this topic should be sent to the ipdvb mailing list before > 23rd February 2004. > > Note that an ID does not need to be complete to be adopted. It would > also be most useful to collect as many comments/criticisms as possible > from those reading this ID. Looking through the archived mailing > list, a first list of issues to be addressed is included at the end of > this email. > > Please do help to identify any more known (or potential) issues that > should be addressed/discussed. > > Best wishes, > > Gorry Fairhurst > (ipdvb WG Chair) > > > --- > > > Known issues with draft-fair-ipdvb-ule-02.txt > ============================================= > > 1) Refinement of the text on CRC generation to be unambiguous > (explicitly talk about the polynomial as a forward CRC-32 and THEN > explicitly about the computation process) > - Text to be rewritten. > > 2) Query about the code point value for an Ethernet Bridging SNDU - > should the ULE type-field be 0x0001 ; 0x0007 as in ATM/AAL5 (as in > RFC2684); or should the IEEE Ethertype for bridging (0x6558) be used > instead? > - Discuss on list. > > 3) Need to check the SNDU Packing/Padding examples in the informative > appendix of the ID for correctness (including the length of the last > packet of example A.4) > --- any volunteers? > > 4) Suggestion to add an appendix to the next rev of the ID, with a > hexadecimal example of an SNDU, to assist implementors in validating > the operation of the CRC. The following example has been proposed: > >>> Ping6 >>> from 2001:660:3008:1789::5 to 2001:660:3008:1789::6, with the >>> associated DVB MAC addr being 01:02:03:04:05:06. It gives the >>> following SNDU : >>> >>> 0000: 00 3f 86 dd 01 02 03 04 05 06 60 00 00 00 00 0d >>> .?........`..... >>> 0010: 3a 40 20 01 06 60 30 08 17 89 00 00 00 00 00 00 :@ ..`0......... >>> 0020: 00 05 20 01 06 60 30 08 17 89 00 00 00 00 00 00 .. ..`0......... >>> 0030: 00 06 80 00 9c 58 07 70 00 00 00 00 00 00 00 02 .....X.p........ >>> 0040: 72 c9 c2 r.. >>> > - The exact decode of this needs to be done and verified > > > 5) ??? > > 5= Consideration of the proposed ULE Extension Header > From owner-ip-dvb@erg.abdn.ac.uk Wed Feb 18 13:50:46 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1IDna7H011716 for ; Wed, 18 Feb 2004 13:49:36 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1IDna82011715 for ip-dvb-subscribed-users; Wed, 18 Feb 2004 13:49:36 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from proxy.6wind.com (proxy.ipv6.6wind.com [194.250.197.211]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1IDmwAB011670 for ; Wed, 18 Feb 2004 13:49:00 GMT Received: from eagle.6wind.com (givenchy.6wind.com [212.234.238.114]) by proxy.6wind.com (Postfix) with ESMTP id 9369972C for ; Wed, 18 Feb 2004 14:48:53 +0100 (CET) Received: from 6wind.com (unknown [10.16.0.135]) by eagle.6wind.com (Postfix) with ESMTP id 77E82EE for ; Wed, 18 Feb 2004 14:48:53 +0100 (CET) Message-ID: <40336E39.3050203@6wind.com> Date: Wed, 18 Feb 2004 14:52:57 +0100 From: alain.ritoux@6wind.com 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 Subject: Re: =?ISO-8859-1?Q?R=E9f=2E_=3A_RE=3A_Question_on_Cont?= =?ISO-8859-1?Q?inuity_Counter_field?= References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk X-UIDL: :]Z"!YNn"!Wkk"!?b)!! Tarif.Zein-Alabedeen@space.alcatel.fr wrote: > > Thank you Art and william for your answers... > > William says that consider or mask CC check for a given PID is > implementation dependent.. is someone aware of the general rule for > current IP/MPE/MPEG implementations? > > Considering our ULE encapsulation, I think it would be wise to > provision an option allowing to disactivate CC check for specified > PIDs in the receiver. I'm not that sure, because the countinuity counter shows some TS cells loss, which can be meesy wrt ULE re-assembly, so ignoring it may lead to strange packets (unless detetected by sizes issues). Of course such packets have very little chance to pass the CRC32 test, but an earlier drop prevents CPU usage for nothing. > This may be helpful if, at some point in the future, we need ULE/MPEG > to operate correctly in a mesh or multi star scenarios (PID shared > among several transmiters). The way ULE is designed doesn't seem to work with several independant transmitters, because reassembly of ULE SNDU is led only by PID, and if 2 SNDU ares sent by 2 transmitters, each splitting over many TS cells, the reciever, won't be able to tell whose fragment belongs to who, and hence won't be able to reconstruct any of the SNDUs. my 2 cents. Cheers. Alain -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com From owner-ip-dvb@erg.abdn.ac.uk Wed Feb 18 14:33:46 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1IEXJjQ013219 for ; Wed, 18 Feb 2004 14:33:19 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1IEXIj3013218 for ip-dvb-subscribed-users; Wed, 18 Feb 2004 14:33:19 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from loewe.cosy.sbg.ac.at (loewe.cosy.sbg.ac.at [141.201.2.12]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1IEVfDN013153 for ; Wed, 18 Feb 2004 14:31:41 GMT Received: from milbe (milbe.cosy.sbg.ac.at [141.201.2.21]) by loewe.cosy.sbg.ac.at (8.8.8/8.8.7) with SMTP id PAA13012 for ; Wed, 18 Feb 2004 15:31:41 +0100 (MET) From: "Bernhard Collini-Nocker" To: Subject: =?iso-8859-1?Q?RE:_R=E9f._:_RE:_Question_on_Continuity_Counter_field?= Date: Wed, 18 Feb 2004 15:31:41 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Importance: Normal X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk X-UIDL: -----Original Message----- > From: owner-ip-dvb@erg.abdn.ac.uk > [mailto:owner-ip-dvb@erg.abdn.ac.uk]On > Behalf Of Tarif.Zein-Alabedeen@space.alcatel.fr > Sent: Mittwoch, 18. Februar 2004 13:49 > To: ip-dvb@erg.abdn.ac.uk > Subject: Réf. : RE: Question on Continuity Counter field > Importance: Low > > > > > Thank you Art and william for your answers... > > William says that consider or mask CC check for a given PID is > implementation dependent.. is someone aware of the general rule for > current IP/MPE/MPEG implementations? > > Considering our ULE encapsulation, I think it would be wise to > provision an option allowing to disactivate CC check for specified > PIDs in the receiver. > This may be helpful if, at some point in the future, we need ULE/MPEG to > operate correctly in a mesh or multi star scenarios (PID shared among > several transmiters). > what is your opinion about that? > > best regards > Traif ZEIN > > > > > > > > > "Allison, Art" @erg.abdn.ac.uk on 17/02/2004 > 20:45:38 > > Veuillez répondre à ip-dvb@erg.abdn.ac.uk > > Envoyé par : owner-ip-dvb@erg.abdn.ac.uk > > > Pour : "'ip-dvb@erg.abdn.ac.uk'" > cc : > Objet : RE: Question on Continuity Counter field > > > IMHO, if a MPEG-2 TS parser was presented with out of order packets > identified by the same PID, a receiver failure is to be expected as > the stream would be non-conformant. > > However, the continuity_counter can be the same in sequential packets > (which are then required to be the same except for the PCR). Also, > this count may > be discontinuous when that is indicated by the > discontinuity_indicator. So > it is not always a monotonically incrementing field. Given the rules for > this 4-bit continuity_counter, it is not apparent that it is possible to > use > it to reorder packets at the MPEG-2 level. > > Therefore, IMHO, any lower level communication protocol must not > reorder MPEG-2 transport stream packets that are identified by the > same PID. If it has a potential to do so, then either constraints or > an explicit method for restoring the order must be defined. > > Art > ::{)> > Art Allison > Director Advanced Engineering > NAB > 1771 N St NW > Washington DC 20036 > 202 429 5418 > > > -----Original Message----- > From: Tarif.Zein-Alabedeen@space.alcatel.fr > [mailto:Tarif.Zein-Alabedeen@space.alcatel.fr] > Sent: Friday, February 13, 2004 9:05 AM > To: ip-dvb@erg.abdn.ac.uk > Subject: Question on Continuity Counter field > Importance: Low > > > > > Hi, > I have a question about the continuity counter field in the TS packet > header. May be someone in this group has the right answer : what > heppens if an MPEG receiver receives an out of order TS packet? that > is, for the same PID, the CC field value of a received packet not > equal to CC field value of precedent TS packet + 1 > > Is there one standard behavior or is it implmenetation dependent? can > CC check as the receiver be disabled? > > (oups, this makes 3 questions already) > > thank's and best regards > > > > > From owner-ip-dvb@erg.abdn.ac.uk Wed Feb 18 16:03:32 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1IG1tZ0016715 for ; Wed, 18 Feb 2004 16:01:55 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1IG1soW016714 for ip-dvb-subscribed-users; Wed, 18 Feb 2004 16:01:54 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from rediffmail.com (webmail34.rediffmail.com [203.199.83.247] (may be forged)) by erg.abdn.ac.uk (8.12.11/8.12.11) with SMTP id i1IG07hb016650 for ; Wed, 18 Feb 2004 16:00:08 GMT Received: (qmail 26070 invoked by uid 510); 18 Feb 2004 16:00:05 -0000 Date: 18 Feb 2004 16:00:05 -0000 Message-ID: <20040218160005.26069.qmail@mailweb34.rediffmail.com> Received: from unknown (203.197.138.199) by rediffmail.com via HTTP; 18 feb 2004 16:00:05 -0000 MIME-Version: 1.0 From: "William StanisLaus" To: ip-dvb@erg.abdn.ac.uk Cc: "Bernhard Collini-Nocker" Subject: =?iso-8859-1?Q?Re:_RE:_R=E9f=2E_:_RE:_Question_on_Continuity_Counter_fie?= =?iso-8859-1?Q?ld?= Content-type: multipart/alternative; boundary="Next_1077120005---0-203.199.83.247-26063" X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk This is a multipart mime message --Next_1077120005---0-203.199.83.247-26063 Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

=0ADear all,
=0A  I fully agree on Bernhard's comment, CC is th= e only means of validating any payload belonging to same TS packets for tha= t PID. In case if any intermediate TS packets are lost, RX state moves to o= ut of sync and flushes the buffer.
=0A  But masking of CC is used = on propriety PIDs and Real Time protocol PIDs,  where loss of TS packe= ts are merely eliminated, mostly single ip packet is filled in one TS packe= t and  which is taken care by higher layer protocol.
=0A
=0ABest= Regards,
=0AWilliam.
=0A
=0A
=0AOn Wed, 18 Feb 2004 Bernhard C= ollini-Nocker wrote :
=0A>Dear all,
=0A>
=0A>I do not agr= ee with the conclusion that considering or masking CC check for
=0A>a= given PID is implementation dependent. According to ISO/IEC 13818-1 the CC=
=0A>is a 4 bit field incrementing with each Transport Stream packet = with the
=0A>same PID. It wraps around to 0 after its maxmimum value.= Only in case when
=0A>the adaptation_filed_control bits indicate &qu= ot;reserved" or "no payload" the CC
=0A>shall not be i= ncremented.
=0A>For the receiver the CC is the only means (despite of= a CRC/checksum of the
=0A>reassembled payload) to check for TS packe= ts belonging to the same "payload"
=0A>on the same PID. Whe= n the CC of a subsequent packet is not incremented by
=0A>one (or wra= pped) then the receiver must assume that it has lost one or more
=0A>= TS packets and must wait for the next PUSI to resynchronize. It must flush<= BR>=0A>its buffer if an end of a payload has not been reached yet.
= =0A>Disabling CC check on the receiver probably makes only sense if each= payload
=0A>fits into one TS packet, hence, all TS packets carry a P= USI and
=0A>discontinuity does not introduce problems.
=0A>
= =0A>Finally PID sharing among different transmitters must follow the sam= e rules.
=0A>If there is no onboard functionality that resolves disco= ntinuties in
=0A>buffering complete payloads (sections or elementary = stream packets or even
=0A>ULE protocol data units) and playout with = incremental CCs per payload
=0A>receivers would screw up completely.<= BR>=0A>
=0A>Kind regards,
=0A>Bernhard
=0A>
=0A>= Dr. Bernhard Collini-Nocker
=0A>Institute for Computer Sciences
= =0A>Salzburg University
=0A>J. Haringerstr. 2
=0A>A-5020 Sal= zburg
=0A>Tel: +43 662 8044 6316
=0A>Fax: +43 662 8044 611
= =0A>
=0A>
=0A>
=0A> > -----Original Message-----=0A> > From: owner-ip-dvb@erg.abdn.ac.uk [mailto:owner-ip-dvb@erg.ab= dn.ac.uk]On
=0A> > Behalf Of Tarif.Zein-Alabedeen@space.alcatel.fr=
=0A> > Sent: Mittwoch, 18. Februar 2004 13:49
=0A> > To:= ip-dvb@erg.abdn.ac.uk
=0A> > Subject: R=E9f. : RE: Question on Co= ntinuity Counter field
=0A> > Importance: Low
=0A> >
= =0A> >
=0A> >
=0A> >
=0A> > Thank you Art = and william for your answers...
=0A> >
=0A> > William say= s that consider or mask CC check for a given PID is
=0A> > impleme= ntation dependent..
=0A> > is someone aware of the general rule fo= r current IP/MPE/MPEG
=0A> > implementations?
=0A> >
= =0A> > Considering our ULE encapsulation, I think it would be wise to=
=0A> > provision an
=0A> > option allowing to disactivat= e CC check for specified PIDs in the
=0A> > receiver.
=0A> &= gt; This may be helpful if, at some point in the future, we need ULE/MPEG t= o
=0A> > operate correctly in a mesh or multi star scenarios (PID = shared among
=0A> > several transmiters).
=0A> > what is = your opinion about that?
=0A> >
=0A> > best regards
= =0A> > Traif ZEIN
=0A> >
=0A> >
=0A> >
= =0A> >
=0A> >
=0A> >
=0A> >
=0A> >= ;
=0A> > "Allison, Art" <AAllison@nab.org>@erg.abd= n.ac.uk on 17/02/2004 20:45:38
=0A> >
=0A> > Veuillez r= =E9pondre =E0 ip-dvb@erg.abdn.ac.uk
=0A> >
=0A> > Envoy= =E9 par :      owner-ip-dvb@erg.abdn.ac.uk
=0A> >=0A> >
=0A> > Pour : "'ip-dvb@erg.abdn.ac.uk'" &= lt;ip-dvb@erg.abdn.ac.uk>
=0A> > cc :
=0A> > Objet :&n= bsp;   RE: Question on Continuity Counter field
=0A> >
= =0A> >
=0A> > IMHO, if a MPEG-2 TS parser was presented with= out of order packets
=0A> > identified by the same PID, a receive= r failure is to be expected as the
=0A> > stream would be non-conf= ormant.
=0A> >
=0A> > However, the continuity_counter can= be the same in sequential packets
=0A> > (which
=0A> > a= re then required to be the same except for the PCR).  Also, this
= =0A> > count may
=0A> > be discontinuous when that is indica= ted by the
=0A> > discontinuity_indicator.  So
=0A> >= ; it is not always a monotonically incrementing field.  Given the rule= s for
=0A> > this 4-bit continuity_counter, it is not apparent tha= t it is possible to
=0A> > use
=0A> > it to reorder packe= ts at the MPEG-2 level.
=0A> >
=0A> > Therefore, IMHO, an= y lower level communication protocol must not reorder
=0A> > MPEG-= 2 transport stream packets that are identified by the same PID. If it
= =0A> > has a potential to do so, then either constraints or an explic= it
=0A> > method for
=0A> > restoring the order must be d= efined.
=0A> >
=0A> > Art
=0A> > ::{)>
=0A= > > Art Allison
=0A> > Director Advanced Engineering
=0A&= gt; > NAB
=0A> > 1771 N St NW
=0A> > Washington DC 200= 36
=0A> > 202 429 5418
=0A> >
=0A> >
=0A> = > -----Original Message-----
=0A> > From: Tarif.Zein-Alabedeen@= space.alcatel.fr
=0A> > [mailto:Tarif.Zein-Alabedeen@space.alcatel= .fr]
=0A> > Sent: Friday, February 13, 2004 9:05 AM
=0A> >= ; To: ip-dvb@erg.abdn.ac.uk
=0A> > Subject: Question on Continuity= Counter field
=0A> > Importance: Low
=0A> >
=0A> &= gt;
=0A> >
=0A> >
=0A> > Hi,
=0A> > I h= ave a question about the continuity counter field in the TS packet
=0A&g= t; > header. May be someone in this group has the right answer :
=0A&= gt; > what heppens if an MPEG receiver receives an out of order TS packe= t?
=0A> > that is, for the same PID, the CC field value of a recei= ved packet not
=0A> > equal to CC field value of precedent TS pack= et + 1
=0A> >
=0A> > Is there one standard behavior or is= it implmenetation dependent?
=0A> > can CC check as the receiver = be disabled?
=0A> >
=0A> > (oups, this makes 3 questions = already)
=0A> >
=0A> > thank's and best regards
=0A>= ; >
=0A> >
=0A> >
=0A> >
=0A> >
= =0A>
=0A=0A

=0A

=0A=0A --Next_1077120005---0-203.199.83.247-26063 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Dear all,=0A I fully agree on Bernhard's comment, CC is the only means of= validating any payload belonging to same TS packets for that PID. In case = if any intermediate TS packets are lost, RX state moves to out of sync and = flushes the buffer.=0A But masking of CC is used on propriety PIDs and Re= al Time protocol PIDs, where loss of TS packets are merely eliminated, mos= tly single ip packet is filled in one TS packet and which is taken care by= higher layer protocol.=0A=0ABest Regards,=0AWilliam.=0A=0A=0AOn Wed, 18 Fe= b 2004 Bernhard Collini-Nocker wrote :=0A>Dear all,=0A>=0A>I do not agree w= ith the conclusion that considering or masking CC check for=0A>a given PID = is implementation dependent. According to ISO/IEC 13818-1 the CC=0A>is a 4 = bit field incrementing with each Transport Stream packet with the=0A>same P= ID. It wraps around to 0 after its maxmimum value. Only in case when=0A>the= adaptation_filed_control bits indicate "reserved" or "no payload" the CC= =0A>shall not be incremented.=0A>For the receiver the CC is the only means = (despite of a CRC/checksum of the=0A>reassembled payload) to check for TS p= ackets belonging to the same "payload"=0A>on the same PID. When the CC of a= subsequent packet is not incremented by=0A>one (or wrapped) then the recei= ver must assume that it has lost one or more=0A>TS packets and must wait fo= r the next PUSI to resynchronize. It must flush=0A>its buffer if an end of = a payload has not been reached yet.=0A>Disabling CC check on the receiver p= robably makes only sense if each payload=0A>fits into one TS packet, hence,= all TS packets carry a PUSI and=0A>discontinuity does not introduce proble= ms.=0A>=0A>Finally PID sharing among different transmitters must follow the= same rules.=0A>If there is no onboard functionality that resolves disconti= nuties in=0A>buffering complete payloads (sections or elementary stream pac= kets or even=0A>ULE protocol data units) and playout with incremental CCs p= er payload=0A>receivers would screw up completely.=0A>=0A>Kind regards,=0A>= Bernhard=0A>=0A>Dr. Bernhard Collini-Nocker=0A>Institute for Computer Scien= ces=0A>Salzburg University=0A>J. Haringerstr. 2=0A>A-5020 Salzburg=0A>Tel: = +43 662 8044 6316=0A>Fax: +43 662 8044 611=0A>=0A>=0A>=0A> > -----Original = Message-----=0A> > From: owner-ip-dvb@erg.abdn.ac.uk [mailto:owner-ip-dvb@e= rg.abdn.ac.uk]On=0A> > Behalf Of Tarif.Zein-Alabedeen@space.alcatel.fr=0A> = > Sent: Mittwoch, 18. Februar 2004 13:49=0A> > To: ip-dvb@erg.abdn.ac.uk=0A= > > Subject: R=E9f. : RE: Question on Continuity Counter field=0A> > Import= ance: Low=0A> >=0A> >=0A> >=0A> >=0A> > Thank you Art and william for your = answers...=0A> >=0A> > William says that consider or mask CC check for a gi= ven PID is=0A> > implementation dependent..=0A> > is someone aware of the g= eneral rule for current IP/MPE/MPEG=0A> > implementations?=0A> >=0A> > Cons= idering our ULE encapsulation, I think it would be wise to=0A> > provision = an=0A> > option allowing to disactivate CC check for specified PIDs in the= =0A> > receiver.=0A> > This may be helpful if, at some point in the future,= we need ULE/MPEG to=0A> > operate correctly in a mesh or multi star scenar= ios (PID shared among=0A> > several transmiters).=0A> > what is your opinio= n about that?=0A> >=0A> > best regards=0A> > Traif ZEIN=0A> >=0A> >=0A> >= =0A> >=0A> >=0A> >=0A> >=0A> >=0A> > "Allison, Art" @erg.= abdn.ac.uk on 17/02/2004 20:45:38=0A> >=0A> > Veuillez r=E9pondre =E0 ip-dv= b@erg.abdn.ac.uk=0A> >=0A> > Envoy=E9 par : owner-ip-dvb@erg.abdn.ac.u= k=0A> >=0A> >=0A> > Pour : "'ip-dvb@erg.abdn.ac.uk'" =0A> > cc :=0A> > Objet : RE: Question on Continuity Counter field=0A>= >=0A> >=0A> > IMHO, if a MPEG-2 TS parser was presented with out of order = packets=0A> > identified by the same PID, a receiver failure is to be expec= ted as the=0A> > stream would be non-conformant.=0A> >=0A> > However, the c= ontinuity_counter can be the same in sequential packets=0A> > (which=0A> > = are then required to be the same except for the PCR). Also, this=0A> > cou= nt may=0A> > be discontinuous when that is indicated by the=0A> > discontin= uity_indicator. So=0A> > it is not always a monotonically incrementing fie= ld. Given the rules for=0A> > this 4-bit continuity_counter, it is not app= arent that it is possible to=0A> > use=0A> > it to reorder packets at the M= PEG-2 level.=0A> >=0A> > Therefore, IMHO, any lower level communication pro= tocol must not reorder=0A> > MPEG-2 transport stream packets that are ident= ified by the same PID. If it=0A> > has a potential to do so, then either co= nstraints or an explicit=0A> > method for=0A> > restoring the order must be= defined.=0A> >=0A> > Art=0A> > ::{)>=0A> > Art Allison=0A> > Director Adva= nced Engineering=0A> > NAB=0A> > 1771 N St NW=0A> > Washington DC 20036=0A>= > 202 429 5418=0A> >=0A> >=0A> > -----Original Message-----=0A> > From: Ta= rif.Zein-Alabedeen@space.alcatel.fr=0A> > [mailto:Tarif.Zein-Alabedeen@spac= e.alcatel.fr]=0A> > Sent: Friday, February 13, 2004 9:05 AM=0A> > To: ip-dv= b@erg.abdn.ac.uk=0A> > Subject: Question on Continuity Counter field=0A> > = Importance: Low=0A> >=0A> >=0A> >=0A> >=0A> > Hi,=0A> > I have a question a= bout the continuity counter field in the TS packet=0A> > header. May be som= eone in this group has the right answer :=0A> > what heppens if an MPEG rec= eiver receives an out of order TS packet?=0A> > that is, for the same PID, = the CC field value of a received packet not=0A> > equal to CC field value o= f precedent TS packet + 1=0A> >=0A> > Is there one standard behavior or is = it implmenetation dependent?=0A> > can CC check as the receiver be disabled= ?=0A> >=0A> > (oups, this makes 3 questions already)=0A> >=0A> > thank's an= d best regards=0A> >=0A> >=0A> >=0A> >=0A> >=0A>=0A --Next_1077120005---0-203.199.83.247-26063-- From owner-ip-dvb@erg.abdn.ac.uk Wed Feb 18 18:00:23 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1IHwqmd021206 for ; Wed, 18 Feb 2004 17:58:52 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1IHwqdb021205 for ip-dvb-subscribed-users; Wed, 18 Feb 2004 17:58:52 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from [209.116.240.194] (foxtrot.nab.org [209.116.240.194]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1IHwBJd021175 for ; Wed, 18 Feb 2004 17:58:11 GMT Received: from mail.nab.org by [209.116.240.194] via smtpd (for mavis.erg.abdn.ac.uk [139.133.204.77]) with ESMTP; Wed, 18 Feb 2004 12:58:12 -0500 Received: (private information removed) Message-ID: <5A659834E1607E4EBD72FCE2FE5C9CF102FEBEE9@mail.NAB.ORG> From: "Allison, Art" To: "'ip-dvb@erg.abdn.ac.uk'" Subject: =?iso-8859-1?Q?RE=3A_R=E9f=2E_=3A_RE=3A_Question_on_Continuity?= =?iso-8859-1?Q?_Counter_field?= Date: Wed, 18 Feb 2004 12:58:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-ERG-MailScanner: Found to be clean, Found to be clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by erg.abdn.ac.uk id i1IHwpsD021202 Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Please note that the Continuity Counter need not increment in the special case where the TS packet contents are duplicated, see same ref as below (and my previous post). (So I take this small exception to Bernhard's post below). But I agree with the thrust of his post. Stated simply, if TS packets get out of order then one does not have a valid MPEG-2 stream any longer and a receiver cannot be expected to work. The question is about how to handle this failure mode seems a futile and non-productive exercise. Don't enable it. Art ::{)> Art Allison Director Advanced Engineering NAB 1771 N St NW Washington DC 20036 202 429 5418 -----Original Message----- From: Bernhard Collini-Nocker [mailto:bnocker@cosy.sbg.ac.at] Sent: Wednesday, February 18, 2004 9:32 AM To: ip-dvb@erg.abdn.ac.uk Subject: RE: Réf. : RE: Question on Continuity Counter field Dear all, I do not agree with the conclusion that considering or masking CC check for a given PID is implementation dependent. According to ISO/IEC 13818-1 the CC is a 4 bit field incrementing with each Transport Stream packet with the same PID. It wraps around to 0 after its maxmimum value. Only in case when the adaptation_filed_control bits indicate "reserved" or "no payload" the CC shall not be incremented. For the receiver the CC is the only means (despite of a CRC/checksum of the reassembled payload) to check for TS packets belonging to the same "payload" on the same PID. When the CC of a subsequent packet is not incremented by one (or wrapped) then the receiver must assume that it has lost one or more TS packets and must wait for the next PUSI to resynchronize. It must flush its buffer if an end of a payload has not been reached yet. Disabling CC check on the receiver probably makes only sense if each payload fits into one TS packet, hence, all TS packets carry a PUSI and discontinuity does not introduce problems. Finally PID sharing among different transmitters must follow the same rules. If there is no onboard functionality that resolves discontinuties in buffering complete payloads (sections or elementary stream packets or even ULE protocol data units) and playout with incremental CCs per payload receivers would screw up completely. Kind regards, Bernhard Dr. Bernhard Collini-Nocker Institute for Computer Sciences Salzburg University J. Haringerstr. 2 A-5020 Salzburg Tel: +43 662 8044 6316 Fax: +43 662 8044 611 > -----Original Message----- > From: owner-ip-dvb@erg.abdn.ac.uk [mailto:owner-ip-dvb@erg.abdn.ac.uk]On > Behalf Of Tarif.Zein-Alabedeen@space.alcatel.fr > Sent: Mittwoch, 18. Februar 2004 13:49 > To: ip-dvb@erg.abdn.ac.uk > Subject: Réf. : RE: Question on Continuity Counter field > Importance: Low > > > > > Thank you Art and william for your answers... > > William says that consider or mask CC check for a given PID is > implementation dependent.. > is someone aware of the general rule for current IP/MPE/MPEG > implementations? > > Considering our ULE encapsulation, I think it would be wise to > provision an > option allowing to disactivate CC check for specified PIDs in the > receiver. > This may be helpful if, at some point in the future, we need ULE/MPEG to > operate correctly in a mesh or multi star scenarios (PID shared among > several transmiters). > what is your opinion about that? > > best regards > Traif ZEIN > > > > > > > > > "Allison, Art" @erg.abdn.ac.uk on 17/02/2004 20:45:38 > > Veuillez répondre à ip-dvb@erg.abdn.ac.uk > > Envoyé par : owner-ip-dvb@erg.abdn.ac.uk > > > Pour : "'ip-dvb@erg.abdn.ac.uk'" > cc : > Objet : RE: Question on Continuity Counter field > > > IMHO, if a MPEG-2 TS parser was presented with out of order packets > identified by the same PID, a receiver failure is to be expected as the > stream would be non-conformant. > > However, the continuity_counter can be the same in sequential packets > (which > are then required to be the same except for the PCR). Also, this > count may > be discontinuous when that is indicated by the > discontinuity_indicator. So > it is not always a monotonically incrementing field. Given the rules for > this 4-bit continuity_counter, it is not apparent that it is possible to > use > it to reorder packets at the MPEG-2 level. > > Therefore, IMHO, any lower level communication protocol must not reorder > MPEG-2 transport stream packets that are identified by the same PID. If it > has a potential to do so, then either constraints or an explicit > method for > restoring the order must be defined. > > Art > ::{)> > Art Allison > Director Advanced Engineering > NAB > 1771 N St NW > Washington DC 20036 > 202 429 5418 > > > -----Original Message----- > From: Tarif.Zein-Alabedeen@space.alcatel.fr > [mailto:Tarif.Zein-Alabedeen@space.alcatel.fr] > Sent: Friday, February 13, 2004 9:05 AM > To: ip-dvb@erg.abdn.ac.uk > Subject: Question on Continuity Counter field > Importance: Low > > > > > Hi, > I have a question about the continuity counter field in the TS packet > header. May be someone in this group has the right answer : > what heppens if an MPEG receiver receives an out of order TS packet? > that is, for the same PID, the CC field value of a received packet not > equal to CC field value of precedent TS packet + 1 > > Is there one standard behavior or is it implmenetation dependent? > can CC check as the receiver be disabled? > > (oups, this makes 3 questions already) > > thank's and best regards > > > > > From owner-ip-dvb@erg.abdn.ac.uk Wed Feb 18 22:16:25 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1IMFWqT000295 for ; Wed, 18 Feb 2004 22:15:32 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1IMFWax000294 for ip-dvb-subscribed-users; Wed, 18 Feb 2004 22:15:32 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from [10.0.1.95] (maxp8.abdn.ac.uk [139.133.7.167]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1IMDncJ000202 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 18 Feb 2004 22:13:55 GMT User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Wed, 18 Feb 2004 13:55:21 +0000 Subject: Re: R=?ISO-8859-1?B?6Q==?=f. : RE: Question on Continuity Counter field From: Gorry Fairhurst To: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" 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 i1IMFTAa000288 Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk So.... On transmission ULE currently says: "The Encapsulation MUST ensure that all TS Packets set the MPEG-2 Continuity Counter carried in the TS Packet header. This value MUST be incremented by one (using modulo arithmetic) for each TS Packet sent using a TS Logical Channel [ISO-MPEG]." This simply says the encapsulator must be compliant for what it sends. At the receiver: "The Receiver MAY also check the MPEG-2 Continuity Counter carried in the TS Packet header. If the Receiver does perform Continuity Counter checking and the received value does not increment by one for successive TS Packets (modulo 16), the Receiver has detected a continuity error. Any partially received SNDU MUST be discarded. A continuity counter error event SHOULD be recorded. The Receiver then enters the Idle State." The case for ULE reception seems much less clear, and I'd be interested to re-assess the correct behaviour. I wonder what is the implication of simply ignoring the CC field? - This has no impact as far as I can see on ULE payload data integrity OR framing, since in ULE these are primarily protected by the CRC-32. Does anyone think we should change the recommendation to "SHOULD NOT" check or "MUST" ignore the CC field? Gorry On 18/2/04 12:48 pm, "Tarif.Zein-Alabedeen@space.alcatel.fr" wrote: > > > Thank you Art and william for your answers... > > William says that consider or mask CC check for a given PID is > implementation dependent.. > is someone aware of the general rule for current IP/MPE/MPEG > implementations? > > Considering our ULE encapsulation, I think it would be wise to provision an > option allowing to disactivate CC check for specified PIDs in the receiver. > This may be helpful if, at some point in the future, we need ULE/MPEG to > operate correctly in a mesh or multi star scenarios (PID shared among > several transmiters). > what is your opinion about that? > > best regards > Traif ZEIN > > > > > > > > > "Allison, Art" @erg.abdn.ac.uk on 17/02/2004 20:45:38 > > Veuillez répondre à ip-dvb@erg.abdn.ac.uk > > Envoyé par : owner-ip-dvb@erg.abdn.ac.uk > > > Pour : "'ip-dvb@erg.abdn.ac.uk'" > cc : > Objet : RE: Question on Continuity Counter field > > > IMHO, if a MPEG-2 TS parser was presented with out of order packets > identified by the same PID, a receiver failure is to be expected as the > stream would be non-conformant. > > However, the continuity_counter can be the same in sequential packets > (which > are then required to be the same except for the PCR). Also, this count may > be discontinuous when that is indicated by the discontinuity_indicator. So > it is not always a monotonically incrementing field. Given the rules for > this 4-bit continuity_counter, it is not apparent that it is possible to > use > it to reorder packets at the MPEG-2 level. > > Therefore, IMHO, any lower level communication protocol must not reorder > MPEG-2 transport stream packets that are identified by the same PID. If it > has a potential to do so, then either constraints or an explicit method for > restoring the order must be defined. > > Art > ::{)> > Art Allison > Director Advanced Engineering > NAB > 1771 N St NW > Washington DC 20036 > 202 429 5418 > > > -----Original Message----- > From: Tarif.Zein-Alabedeen@space.alcatel.fr > [mailto:Tarif.Zein-Alabedeen@space.alcatel.fr] > Sent: Friday, February 13, 2004 9:05 AM > To: ip-dvb@erg.abdn.ac.uk > Subject: Question on Continuity Counter field > Importance: Low > > > > > Hi, > I have a question about the continuity counter field in the TS packet > header. May be someone in this group has the right answer : > what heppens if an MPEG receiver receives an out of order TS packet? > that is, for the same PID, the CC field value of a received packet not > equal to CC field value of precedent TS packet + 1 > > Is there one standard behavior or is it implmenetation dependent? > can CC check as the receiver be disabled? > > (oups, this makes 3 questions already) > > thank's and best regards > > > > > From owner-ip-dvb@erg.abdn.ac.uk Wed Feb 18 22:54:48 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1IMrFQo001614 for ; Wed, 18 Feb 2004 22:53:15 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1IMrFtX001613 for ip-dvb-subscribed-users; Wed, 18 Feb 2004 22:53:15 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from [209.116.240.194] (foxtrot.nab.org [209.116.240.194]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1IMq8C6001580 for ; Wed, 18 Feb 2004 22:52:08 GMT Received: from mail.nab.org by [209.116.240.194] via smtpd (for mavis.erg.abdn.ac.uk [139.133.204.77]) with ESMTP; Wed, 18 Feb 2004 17:52:09 -0500 Received: (private information removed) Message-ID: <5A659834E1607E4EBD72FCE2FE5C9CF102FEBEEB@mail.NAB.ORG> From: "Allison, Art" To: "'ip-dvb@erg.abdn.ac.uk'" Subject: =?iso-8859-1?Q?RE=3A_R=E9f=2E_=3A_RE=3A_Question_on_Continuity?= =?iso-8859-1?Q?_Counter_field?= Date: Wed, 18 Feb 2004 17:52:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-ERG-MailScanner: Found to be clean, Found to be clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by erg.abdn.ac.uk id i1IMrChN001610 Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk So... what if the source MPEG-2 Transport stream has two packets that are identified by the same PID which do not increment the CC (because the content did not change)? This language would seem to require the CC to be incremented, which would result in the duplicated data being presented to the parser as if it is the next data in sequence. The resulting stream would no longer meet 13818-1:2000 and receiver behavior is unpredictable. Note that the packet could be a table section, where error concealment is not an option. Also see my earlier post for other conditions where this payload counter should not be incremented.. Further, requiring the ULE layer to touch this payload value seems like a cross between layers and therefore a questionable design... Art ::{)> Art Allison Director Advanced Engineering NAB 1771 N St NW Washington DC 20036 202 429 5418 -----Original Message----- From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk] Sent: Wednesday, February 18, 2004 8:55 AM To: ip-dvb@erg.abdn.ac.uk Subject: Re: Réf. : RE: Question on Continuity Counter field So.... On transmission ULE currently says: "The Encapsulation MUST ensure that all TS Packets set the MPEG-2 Continuity Counter carried in the TS Packet header. This value MUST be incremented by one (using modulo arithmetic) for each TS Packet sent using a TS Logical Channel [ISO-MPEG]." This simply says the encapsulator must be compliant for what it sends. At the receiver: "The Receiver MAY also check the MPEG-2 Continuity Counter carried in the TS Packet header. If the Receiver does perform Continuity Counter checking and the received value does not increment by one for successive TS Packets (modulo 16), the Receiver has detected a continuity error. Any partially received SNDU MUST be discarded. A continuity counter error event SHOULD be recorded. The Receiver then enters the Idle State." The case for ULE reception seems much less clear, and I'd be interested to re-assess the correct behaviour. I wonder what is the implication of simply ignoring the CC field? - This has no impact as far as I can see on ULE payload data integrity OR framing, since in ULE these are primarily protected by the CRC-32. Does anyone think we should change the recommendation to "SHOULD NOT" check or "MUST" ignore the CC field? Gorry On 18/2/04 12:48 pm, "Tarif.Zein-Alabedeen@space.alcatel.fr" wrote: > > > Thank you Art and william for your answers... > > William says that consider or mask CC check for a given PID is > implementation dependent.. > is someone aware of the general rule for current IP/MPE/MPEG > implementations? > > Considering our ULE encapsulation, I think it would be wise to provision an > option allowing to disactivate CC check for specified PIDs in the receiver. > This may be helpful if, at some point in the future, we need ULE/MPEG to > operate correctly in a mesh or multi star scenarios (PID shared among > several transmiters). > what is your opinion about that? > > best regards > Traif ZEIN > > > > > > > > > "Allison, Art" @erg.abdn.ac.uk on 17/02/2004 20:45:38 > > Veuillez répondre à ip-dvb@erg.abdn.ac.uk > > Envoyé par : owner-ip-dvb@erg.abdn.ac.uk > > > Pour : "'ip-dvb@erg.abdn.ac.uk'" > cc : > Objet : RE: Question on Continuity Counter field > > > IMHO, if a MPEG-2 TS parser was presented with out of order packets > identified by the same PID, a receiver failure is to be expected as the > stream would be non-conformant. > > However, the continuity_counter can be the same in sequential packets > (which > are then required to be the same except for the PCR). Also, this count may > be discontinuous when that is indicated by the discontinuity_indicator. So > it is not always a monotonically incrementing field. Given the rules for > this 4-bit continuity_counter, it is not apparent that it is possible to > use > it to reorder packets at the MPEG-2 level. > > Therefore, IMHO, any lower level communication protocol must not reorder > MPEG-2 transport stream packets that are identified by the same PID. If it > has a potential to do so, then either constraints or an explicit method for > restoring the order must be defined. > > Art > ::{)> > Art Allison > Director Advanced Engineering > NAB > 1771 N St NW > Washington DC 20036 > 202 429 5418 > > > -----Original Message----- > From: Tarif.Zein-Alabedeen@space.alcatel.fr > [mailto:Tarif.Zein-Alabedeen@space.alcatel.fr] > Sent: Friday, February 13, 2004 9:05 AM > To: ip-dvb@erg.abdn.ac.uk > Subject: Question on Continuity Counter field > Importance: Low > > > > > Hi, > I have a question about the continuity counter field in the TS packet > header. May be someone in this group has the right answer : > what heppens if an MPEG receiver receives an out of order TS packet? > that is, for the same PID, the CC field value of a received packet not > equal to CC field value of precedent TS packet + 1 > > Is there one standard behavior or is it implmenetation dependent? > can CC check as the receiver be disabled? > > (oups, this makes 3 questions already) > > thank's and best regards > > > > > From owner-ip-dvb@erg.abdn.ac.uk Thu Feb 19 15:11:35 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1JFAQhu019797 for ; Thu, 19 Feb 2004 15:10:26 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1JFAQEL019796 for ip-dvb-subscribed-users; Thu, 19 Feb 2004 15:10:26 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley-ipv6.erg.abdn.ac.uk [IPv6:2001:630:241:1:20a:95ff:fe7d:5f0c]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1JF9TpZ019733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 19 Feb 2004 15:09:30 GMT Message-ID: <4034D1AC.8030807@erg.abdn.ac.uk> Date: Thu, 19 Feb 2004 15:09:32 +0000 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Re: =?ISO-8859-1?Q?R=E9f=2E_=3A_RE=3A_Question_on_Cont?= =?ISO-8859-1?Q?inuity_Counter_field?= References: <5A659834E1607E4EBD72FCE2FE5C9CF102FEBEEB@mail.NAB.ORG> In-Reply-To: <5A659834E1607E4EBD72FCE2FE5C9CF102FEBEEB@mail.NAB.ORG> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Before we look at any new ideas for potentially easing use of ULE over regenerative satellites, I'd like to clearly understand the points raised below, specifically the correct sender/receiver behaviour as required by MPEG-2: Allison, Art wrote: >So... what if the source MPEG-2 Transport stream has two packets that are >identified by the same PID which do not increment the CC (because the >content did not change)? > So is this where the sender (encapsulator) intentionaly replicates exactly the last TS-Packet? >This language would seem to require the CC to be incremented, which would >result in the duplicated data being presented to the parser as if it is the >next data in sequence. The resulting stream would no longer meet >13818-1:2000 and receiver behavior is unpredictable. Note that the packet >could be a table section, where error concealment is not an option. > If you're saying duplication is a valid technique to conceal loss, then the appropriate response should be to discard any duplicates (with identical CC). This is not what the current ID text says. ~If at all possible, ULE should be designed to fully conform to ISO MPEG-2 TS, that is a stated goal. Some new text is now definitely required. > >Also see my earlier post for other conditions where this payload counter >should not be incremented.. > >Further, requiring the ULE layer to touch this payload value seems like a >cross between layers and therefore a questionable design... > The current text did NOT require acceess to the CC field. The actual text, only permitted this: "The Receiver MAY also check"... There are alos other ways of verifying framing and integrity in ULE. Best wishes, Gorry > >Art >::{)> >Art Allison >Director Advanced Engineering >NAB >1771 N St NW >Washington DC 20036 >202 429 5418 > > >-----Original Message----- >From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk] >Sent: Wednesday, February 18, 2004 8:55 AM >To: ip-dvb@erg.abdn.ac.uk >Subject: Re: Réf. : RE: Question on Continuity Counter field > > >So.... > >On transmission ULE currently says: > "The Encapsulation MUST ensure that all TS Packets set the MPEG-2 > Continuity Counter carried in the TS Packet header. This value MUST > be incremented by one (using modulo arithmetic) for each TS Packet > sent using a TS Logical Channel [ISO-MPEG]." > >This simply says the encapsulator must be compliant for what it sends. > >At the receiver: > "The Receiver MAY also check the MPEG-2 Continuity Counter carried in > the TS Packet header. If the Receiver does perform Continuity > Counter checking and the received value does not increment by one > for successive TS Packets (modulo 16), the Receiver has detected a > continuity error. Any partially received SNDU MUST be discarded. A > continuity counter error event SHOULD be recorded. The Receiver then > enters the Idle State." > > >The case for ULE reception seems much less clear, and I'd be interested to >re-assess the correct behaviour. > >I wonder what is the implication of simply ignoring the CC field? >- This has no impact as far as I can see on ULE payload data integrity OR >framing, since in ULE these are primarily protected by the CRC-32. > >Does anyone think we should change the recommendation to "SHOULD NOT" check >or "MUST" ignore the CC field? > >Gorry > > >On 18/2/04 12:48 pm, "Tarif.Zein-Alabedeen@space.alcatel.fr" > wrote: > > > >>Thank you Art and william for your answers... >> >>William says that consider or mask CC check for a given PID is >>implementation dependent.. >>is someone aware of the general rule for current IP/MPE/MPEG >>implementations? >> >>Considering our ULE encapsulation, I think it would be wise to provision >> >> >an > > >>option allowing to disactivate CC check for specified PIDs in the >> >> >receiver. > > >>This may be helpful if, at some point in the future, we need ULE/MPEG to >>operate correctly in a mesh or multi star scenarios (PID shared among >>several transmiters). >>what is your opinion about that? >> >>best regards >>Traif ZEIN >> >> >> >> >> >> >> >> >>"Allison, Art" @erg.abdn.ac.uk on 17/02/2004 20:45:38 >> >>Veuillez répondre à ip-dvb@erg.abdn.ac.uk >> >>Envoyé par : owner-ip-dvb@erg.abdn.ac.uk >> >> >>Pour : "'ip-dvb@erg.abdn.ac.uk'" >>cc : >>Objet : RE: Question on Continuity Counter field >> >> >>IMHO, if a MPEG-2 TS parser was presented with out of order packets >>identified by the same PID, a receiver failure is to be expected as the >>stream would be non-conformant. >> >>However, the continuity_counter can be the same in sequential packets >>(which >>are then required to be the same except for the PCR). Also, this count >> >> >may > > >>be discontinuous when that is indicated by the discontinuity_indicator. >> >> >So > > >>it is not always a monotonically incrementing field. Given the rules for >>this 4-bit continuity_counter, it is not apparent that it is possible to >>use >>it to reorder packets at the MPEG-2 level. >> >>Therefore, IMHO, any lower level communication protocol must not reorder >>MPEG-2 transport stream packets that are identified by the same PID. If it >>has a potential to do so, then either constraints or an explicit method >> >> >for > > >>restoring the order must be defined. >> >>Art >>::{)> >>Art Allison >>Director Advanced Engineering >>NAB >>1771 N St NW >>Washington DC 20036 >>202 429 5418 >> >> >>-----Original Message----- >>From: Tarif.Zein-Alabedeen@space.alcatel.fr >>[mailto:Tarif.Zein-Alabedeen@space.alcatel.fr] >>Sent: Friday, February 13, 2004 9:05 AM >>To: ip-dvb@erg.abdn.ac.uk >>Subject: Question on Continuity Counter field >>Importance: Low >> >> >> >> >>Hi, >>I have a question about the continuity counter field in the TS packet >>header. May be someone in this group has the right answer : >>what heppens if an MPEG receiver receives an out of order TS packet? >>that is, for the same PID, the CC field value of a received packet not >>equal to CC field value of precedent TS packet + 1 >> >>Is there one standard behavior or is it implmenetation dependent? >>can CC check as the receiver be disabled? >> >>(oups, this makes 3 questions already) >> >>thank's and best regards >> >> >> >> >> >> >> > > > > > From owner-ip-dvb@erg.abdn.ac.uk Thu Feb 19 17:36:01 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1JHZGUU024938 for ; Thu, 19 Feb 2004 17:35:16 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1JHZGk4024937 for ip-dvb-subscribed-users; Thu, 19 Feb 2004 17:35:16 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from smail3.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1JHXh6C024857 for ; Thu, 19 Feb 2004 17:33:43 GMT Received: from vzmta01.netfr.alcatel.fr (vzmta01.netfr.alcatel.fr [155.132.182.220]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id i1J8tTo5005628 for ; Thu, 19 Feb 2004 18:33:27 +0100 Importance: Low Sensitivity: Subject: =?iso-8859-1?Q?R=E9f=2E_=3A_Re=3A_R=E9f=2E_=3A_RE=3A_Question_on?= Continuity Counter field To: ip-dvb@erg.abdn.ac.uk From: Tarif.Zein-Alabedeen@space.alcatel.fr Date: Thu, 19 Feb 2004 17:41:18 +0100 Message-ID: X-MIMETrack: Serialize by Router on VZMTA01/ALCANET/ALCATEL-SPACE(Release 5.0.12 |February 13, 2003) at 19/02/2004 18:33:27 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 X-Alcanet-MTA-scanned-and-authorized: yes 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 i1JHZDnO024934 Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk About your first question, yes, it seems that a sender can intentionaly replicates TS packets (only one replicate is allowed I think). This is to conceal packet losses It does not seem however that replication is obligatory. It is up to the sender to decide this (is that correct Allison?).... So, the question now is (and before rewriting the ID) : do we need replication in our ULE/MPEG mode? My first feeling is that we don't (but this is still a feeling). For this, let me bring the following argumentation : The only reason I see for a packet bieng lost (at least on transparent satellite channel) is that an error occured in its PID field (PIDx became PIDy). Is that correct?! (another reason would be buffer overflow at the sender but in that case replication is not applicable..) Packet duplications is surely efficient for these losses. However, for a given bit error ratio, the probability of erros occuring within the 184 bytes payload should be much higher than the probability of errors occuring in the 13 bits PID field. In other terms, packet loss probability should be much smaller than packet error probability which leads anyway to SNDU being droped after CRC check... So, resolving packet loss would not improve significantly the SNDU loss/drop ratio and finally the PDU delivery robustness. May be someone is aware of studies or simulations having been done on this issue and quantifying the improvment of replication on the SNDU loss/drop ratio regards Gorry Fairhurst @erg.abdn.ac.uk on 19/02/2004 16:09:32 Veuillez répondre à ip-dvb@erg.abdn.ac.uk Envoyé par : owner-ip-dvb@erg.abdn.ac.uk Pour : ip-dvb@erg.abdn.ac.uk cc : Objet : Re: Réf. : RE: Question on Continuity Counter field Before we look at any new ideas for potentially easing use of ULE over regenerative satellites, I'd like to clearly understand the points raised below, specifically the correct sender/receiver behaviour as required by MPEG-2: Allison, Art wrote: >So... what if the source MPEG-2 Transport stream has two packets that are >identified by the same PID which do not increment the CC (because the >content did not change)? > So is this where the sender (encapsulator) intentionaly replicates exactly the last TS-Packet? >This language would seem to require the CC to be incremented, which would >result in the duplicated data being presented to the parser as if it is the >next data in sequence. The resulting stream would no longer meet >13818-1:2000 and receiver behavior is unpredictable. Note that the packet >could be a table section, where error concealment is not an option. > If you're saying duplication is a valid technique to conceal loss, then the appropriate response should be to discard any duplicates (with identical CC). This is not what the current ID text says. ~If at all possible, ULE should be designed to fully conform to ISO MPEG-2 TS, that is a stated goal. Some new text is now definitely required. > >Also see my earlier post for other conditions where this payload counter >should not be incremented.. > >Further, requiring the ULE layer to touch this payload value seems like a >cross between layers and therefore a questionable design... > The current text did NOT require acceess to the CC field. The actual text, only permitted this: "The Receiver MAY also check"... There are alos other ways of verifying framing and integrity in ULE. Best wishes, Gorry > >Art >::{)> >Art Allison >Director Advanced Engineering >NAB >1771 N St NW >Washington DC 20036 >202 429 5418 > > >-----Original Message----- >From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk] >Sent: Wednesday, February 18, 2004 8:55 AM >To: ip-dvb@erg.abdn.ac.uk >Subject: Re: Réf. : RE: Question on Continuity Counter field > > >So.... > >On transmission ULE currently says: > "The Encapsulation MUST ensure that all TS Packets set the MPEG-2 > Continuity Counter carried in the TS Packet header. This value MUST > be incremented by one (using modulo arithmetic) for each TS Packet > sent using a TS Logical Channel [ISO-MPEG]." > >This simply says the encapsulator must be compliant for what it sends. > >At the receiver: > "The Receiver MAY also check the MPEG-2 Continuity Counter carried in > the TS Packet header. If the Receiver does perform Continuity > Counter checking and the received value does not increment by one > for successive TS Packets (modulo 16), the Receiver has detected a > continuity error. Any partially received SNDU MUST be discarded. A > continuity counter error event SHOULD be recorded. The Receiver then > enters the Idle State." > > >The case for ULE reception seems much less clear, and I'd be interested to >re-assess the correct behaviour. > >I wonder what is the implication of simply ignoring the CC field? >- This has no impact as far as I can see on ULE payload data integrity OR >framing, since in ULE these are primarily protected by the CRC-32. > >Does anyone think we should change the recommendation to "SHOULD NOT" check >or "MUST" ignore the CC field? > >Gorry > > >On 18/2/04 12:48 pm, "Tarif.Zein-Alabedeen@space.alcatel.fr" > wrote: > > > >>Thank you Art and william for your answers... >> >>William says that consider or mask CC check for a given PID is >>implementation dependent.. >>is someone aware of the general rule for current IP/MPE/MPEG >>implementations? >> >>Considering our ULE encapsulation, I think it would be wise to provision >> >> >an > > >>option allowing to disactivate CC check for specified PIDs in the >> >> >receiver. > > >>This may be helpful if, at some point in the future, we need ULE/MPEG to >>operate correctly in a mesh or multi star scenarios (PID shared among >>several transmiters). >>what is your opinion about that? >> >>best regards >>Traif ZEIN >> >> >> >> >> >> >> >> >>"Allison, Art" @erg.abdn.ac.uk on 17/02/2004 20:45:38 >> >>Veuillez répondre à ip-dvb@erg.abdn.ac.uk >> >>Envoyé par : owner-ip-dvb@erg.abdn.ac.uk >> >> >>Pour : "'ip-dvb@erg.abdn.ac.uk'" >>cc : >>Objet : RE: Question on Continuity Counter field >> >> >>IMHO, if a MPEG-2 TS parser was presented with out of order packets >>identified by the same PID, a receiver failure is to be expected as the >>stream would be non-conformant. >> >>However, the continuity_counter can be the same in sequential packets >>(which >>are then required to be the same except for the PCR). Also, this count >> >> >may > > >>be discontinuous when that is indicated by the discontinuity_indicator. >> >> >So > > >>it is not always a monotonically incrementing field. Given the rules for >>this 4-bit continuity_counter, it is not apparent that it is possible to >>use >>it to reorder packets at the MPEG-2 level. >> >>Therefore, IMHO, any lower level communication protocol must not reorder >>MPEG-2 transport stream packets that are identified by the same PID. If it >>has a potential to do so, then either constraints or an explicit method >> >> >for > > >>restoring the order must be defined. >> >>Art >>::{)> >>Art Allison >>Director Advanced Engineering >>NAB >>1771 N St NW >>Washington DC 20036 >>202 429 5418 >> >> >>-----Original Message----- >>From: Tarif.Zein-Alabedeen@space.alcatel.fr >>[mailto:Tarif.Zein-Alabedeen@space.alcatel.fr] >>Sent: Friday, February 13, 2004 9:05 AM >>To: ip-dvb@erg.abdn.ac.uk >>Subject: Question on Continuity Counter field >>Importance: Low >> >> >> >> >>Hi, >>I have a question about the continuity counter field in the TS packet >>header. May be someone in this group has the right answer : >>what heppens if an MPEG receiver receives an out of order TS packet? >>that is, for the same PID, the CC field value of a received packet not >>equal to CC field value of precedent TS packet + 1 >> >>Is there one standard behavior or is it implmenetation dependent? >>can CC check as the receiver be disabled? >> >>(oups, this makes 3 questions already) >> >>thank's and best regards >> >> >> >> >> >> >> > > > > > T. Zein ALCATEL SPACE DRT/RST -- Ingénieur Systèmes Tel : 0534356918 / Fax : 0534355560 Porte : W.220 From owner-ip-dvb@erg.abdn.ac.uk Thu Feb 19 23:34:12 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1JNXLOr007397 for ; Thu, 19 Feb 2004 23:33:21 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1JNXLpR007396 for ip-dvb-subscribed-users; Thu, 19 Feb 2004 23:33:21 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from [209.116.240.194] (foxtrot.nab.org [209.116.240.194]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1JNWWQq007364 for ; Thu, 19 Feb 2004 23:32:32 GMT Received: from mail.nab.org by [209.116.240.194] via smtpd (for mavis.erg.abdn.ac.uk [139.133.204.77]) with ESMTP; Thu, 19 Feb 2004 18:32:35 -0500 Received: (private information removed) Message-ID: <5A659834E1607E4EBD72FCE2FE5C9CF102FEBEF2@mail.NAB.ORG> From: "Allison, Art" To: "'ip-dvb@erg.abdn.ac.uk'" Subject: =?iso-8859-1?Q?RE=3A_R=E9f=2E_=3A_Re=3A_R=E9f=2E_=3A_RE=3A_Que?= =?iso-8859-1?Q?stion_onContinuity_Counter_field?= Date: Thu, 19 Feb 2004 18:32:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-ERG-MailScanner: Found to be clean, Found to be clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by erg.abdn.ac.uk id i1JNXIox007393 Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk See embedded.. sorry, but in meetings all day today and tomorrow.. I responded to this response and to the note before it in this one message...as the day is gone. Art ::{)> Art Allison Director Advanced Engineering NAB 1771 N St NW Washington DC 20036 202 429 5418 -----Original Message----- From: Tarif.Zein-Alabedeen@space.alcatel.fr [mailto:Tarif.Zein-Alabedeen@space.alcatel.fr] Sent: Thursday, February 19, 2004 11:41 AM To: ip-dvb@erg.abdn.ac.uk Subject: Réf. : Re: Réf. : RE: Question onContinuity Counter field Importance: Low About your first question, yes, it seems that a sender can intentionaly replicates TS packets (only one replicate is allowed I think). This is to conceal packet losses It does not seem however that replication is obligatory. It is up to the sender to decide this (is that correct Allison?).... AA> Correct, it is a sender option. So, the question now is (and before rewriting the ID) : do we need replication in our ULE/MPEG mode? My first feeling is that we don't (but this is still a feeling). AA> I don't see the need for replication. For this, let me bring the following argumentation : The only reason I see for a packet bieng lost (at least on transparent satellite channel) is that an error occured in its PID field (PIDx became PIDy). Is that correct?! AA>I don't know the OFDM error detection/protection coding and its relationship to MPEG-2 packets. For QAM per SCTE and 8VSB per ATSC, a defective packet is considered a lost packet. If physical layer error processing coding/method is not enough for proper reconstruction of bits damaged in a packet, then determining which bit is bad may not be possible. Even if the system can determine which bit is not correct, there is only one bit for signaling at the Transport Stream layer. Therefore which bit(s) is(are) bad is not available at the MPEG-2 transport stream layer. (another reason would be buffer overflow at the sender but in that case replication is not applicable..) AA> Yes, if buffer overflow the TS is broken already and not this RFC's job to try to fix. Packet duplications is surely efficient for these losses. However, for a given bit error ratio, the probability of erros occuring within the 184 bytes payload should be much higher than the probability of errors occuring in the 13 bits PID field. In other terms, packet loss probability should be much smaller than packet error probability which leads anyway to SNDU being droped after CRC check... So, resolving packet loss would not improve significantly the SNDU loss/drop ratio and finally the PDU delivery robustness. AA>Is it possible you are mixing PES layer with MPEG2 transport stream layer? While a table can be in a packet (and therefore have a CRC in that packet), they and PES packets cross packet boundaries. AA> For some transports the entire packet is coded with Reed Solomon for error detection and recovery, and if this fails the entire packet is usually tossed.. The hit chance a function of bit count would only apply to the transport error indicator bit being hit, a very remote chance. May be someone is aware of studies or simulations having been done on this issue and quantifying the improvment of replication on the SNDU loss/drop ratio regards Gorry Fairhurst @erg.abdn.ac.uk on 19/02/2004 16:09:32 Veuillez répondre à ip-dvb@erg.abdn.ac.uk Envoyé par : owner-ip-dvb@erg.abdn.ac.uk Pour : ip-dvb@erg.abdn.ac.uk cc : Objet : Re: Réf. : RE: Question on Continuity Counter field Before we look at any new ideas for potentially easing use of ULE over regenerative satellites, I'd like to clearly understand the points raised below, specifically the correct sender/receiver behaviour as required by MPEG-2: Allison, Art wrote: >So... what if the source MPEG-2 Transport stream has two packets that are >identified by the same PID which do not increment the CC (because the >content did not change)? > So is this where the sender (encapsulator) intentionaly replicates exactly the last TS-Packet? AA> Yes. >This language would seem to require the CC to be incremented, which would >result in the duplicated data being presented to the parser as if it is the >next data in sequence. The resulting stream would no longer meet >13818-1:2000 and receiver behavior is unpredictable. Note that the packet >could be a table section, where error concealment is not an option. > If you're saying duplication is a valid technique to conceal loss, then the appropriate response should be to discard any duplicates (with identical CC). This is not what the current ID text says. AA> Discarding of duplicates seems like an alternative. However, if this ULE were used as part of a distribution chain perhaps thinking if forces a re-generation and insertion of duplicate packets. Also the rules are more complex than discard duplicates as they involve the state of the discontinuity_indicator. ~If at all possible, ULE should be designed to fully conform to ISO MPEG-2 TS, that is a stated goal. Some new text is now definitely required. > >Also see my earlier post for other conditions where this payload counter >should not be incremented.. > >Further, requiring the ULE layer to touch this payload value seems like a >cross between layers and therefore a questionable design... > The current text did NOT require acceess to the CC field. The actual text, only permitted this: "The Receiver MAY also check"... There are alos other ways of verifying framing and integrity in ULE. AA> I read an encapsulator MUST requirement (and cross over) not a receiver requirement.. Best wishes, Gorry > >Art >::{)> >Art Allison >Director Advanced Engineering >NAB >1771 N St NW >Washington DC 20036 >202 429 5418 > > >-----Original Message----- >From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk] >Sent: Wednesday, February 18, 2004 8:55 AM >To: ip-dvb@erg.abdn.ac.uk >Subject: Re: Réf. : RE: Question on Continuity Counter field > > >So.... > >On transmission ULE currently says: > "The Encapsulation MUST ensure that all TS Packets set the MPEG-2 > Continuity Counter carried in the TS Packet header. This value MUST > be incremented by one (using modulo arithmetic) for each TS Packet > sent using a TS Logical Channel [ISO-MPEG]." > >This simply says the encapsulator must be compliant for what it sends. > >At the receiver: > "The Receiver MAY also check the MPEG-2 Continuity Counter carried in > the TS Packet header. If the Receiver does perform Continuity > Counter checking and the received value does not increment by one > for successive TS Packets (modulo 16), the Receiver has detected a > continuity error. Any partially received SNDU MUST be discarded. A > continuity counter error event SHOULD be recorded. The Receiver then > enters the Idle State." > > >The case for ULE reception seems much less clear, and I'd be interested to >re-assess the correct behaviour. > >I wonder what is the implication of simply ignoring the CC field? >- This has no impact as far as I can see on ULE payload data integrity OR >framing, since in ULE these are primarily protected by the CRC-32. > >Does anyone think we should change the recommendation to "SHOULD NOT" check >or "MUST" ignore the CC field? > >Gorry > > >On 18/2/04 12:48 pm, "Tarif.Zein-Alabedeen@space.alcatel.fr" > wrote: > > > >>Thank you Art and william for your answers... >> >>William says that consider or mask CC check for a given PID is >>implementation dependent.. >>is someone aware of the general rule for current IP/MPE/MPEG >>implementations? >> >>Considering our ULE encapsulation, I think it would be wise to provision >> >> >an > > >>option allowing to disactivate CC check for specified PIDs in the >> >> >receiver. > > >>This may be helpful if, at some point in the future, we need ULE/MPEG to >>operate correctly in a mesh or multi star scenarios (PID shared among >>several transmiters). >>what is your opinion about that? >> >>best regards >>Traif ZEIN >> >> >> >> >> >> >> >> >>"Allison, Art" @erg.abdn.ac.uk on 17/02/2004 20:45:38 >> >>Veuillez répondre à ip-dvb@erg.abdn.ac.uk >> >>Envoyé par : owner-ip-dvb@erg.abdn.ac.uk >> >> >>Pour : "'ip-dvb@erg.abdn.ac.uk'" >>cc : >>Objet : RE: Question on Continuity Counter field >> >> >>IMHO, if a MPEG-2 TS parser was presented with out of order packets >>identified by the same PID, a receiver failure is to be expected as the >>stream would be non-conformant. >> >>However, the continuity_counter can be the same in sequential packets >>(which >>are then required to be the same except for the PCR). Also, this count >> >> >may > > >>be discontinuous when that is indicated by the discontinuity_indicator. >> >> >So > > >>it is not always a monotonically incrementing field. Given the rules for >>this 4-bit continuity_counter, it is not apparent that it is possible to >>use >>it to reorder packets at the MPEG-2 level. >> >>Therefore, IMHO, any lower level communication protocol must not reorder >>MPEG-2 transport stream packets that are identified by the same PID. If it >>has a potential to do so, then either constraints or an explicit method >> >> >for > > >>restoring the order must be defined. >> >>Art >>::{)> >>Art Allison >>Director Advanced Engineering >>NAB >>1771 N St NW >>Washington DC 20036 >>202 429 5418 >> >> >>-----Original Message----- >>From: Tarif.Zein-Alabedeen@space.alcatel.fr >>[mailto:Tarif.Zein-Alabedeen@space.alcatel.fr] >>Sent: Friday, February 13, 2004 9:05 AM >>To: ip-dvb@erg.abdn.ac.uk >>Subject: Question on Continuity Counter field >>Importance: Low >> >> >> >> >>Hi, >>I have a question about the continuity counter field in the TS packet >>header. May be someone in this group has the right answer : >>what heppens if an MPEG receiver receives an out of order TS packet? >>that is, for the same PID, the CC field value of a received packet not >>equal to CC field value of precedent TS packet + 1 >> >>Is there one standard behavior or is it implmenetation dependent? >>can CC check as the receiver be disabled? >> >>(oups, this makes 3 questions already) >> >>thank's and best regards >> >> >> >> >> >> >> > > > > > T. Zein ALCATEL SPACE DRT/RST -- Ingénieur Systèmes Tel : 0534356918 / Fax : 0534355560 Porte : W.220 From owner-ip-dvb@erg.abdn.ac.uk Mon Feb 23 12:09:55 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1NC9Ia3022929 for ; Mon, 23 Feb 2004 12:09:18 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1NC9IUA022928 for ip-dvb-subscribed-users; Mon, 23 Feb 2004 12:09:18 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from rediffmail.com (webmail26.rediffmail.com [203.199.83.148] (may be forged)) by erg.abdn.ac.uk (8.12.11/8.12.11) with SMTP id i1NC8W7D022885 for ; Mon, 23 Feb 2004 12:08:32 GMT Received: (qmail 30077 invoked by uid 510); 23 Feb 2004 12:08:30 -0000 Date: 23 Feb 2004 12:08:30 -0000 Message-ID: <20040223120830.30076.qmail@webmail26.rediffmail.com> Received: from unknown (203.197.138.199) by rediffmail.com via HTTP; 23 feb 2004 12:08:30 -0000 MIME-Version: 1.0 From: "William StanisLaus" To: "'ip-dvb@erg.abdn.ac.uk'" Subject: UnderStanding ULE Content-type: multipart/alternative; boundary="Next_1077538110---0-203.199.83.148-30068" X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk This is a multipart mime message --Next_1077538110---0-203.199.83.148-30068 Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

=0ADear all,
=0A
=0AMight be I=92m a bit late on ULE discussion, t= hough I have few quick questions hit my mind, hope anyone can help me
= =0A
=0A1)     Is there any document available already to = differentiate DSMCC and ULE, advantages and disadvantages, why we use ULE i= nstead of DSMCC. If not already available, I=92ll volunteer to prepare one = from my understanding of both the MPE types.
=0A
=0ADoubts on ULE Dra= ft
=0A-------------------------------
=0A1.     Sectio= n 4.2 Maximum size of SNDU should be defined, according to draft it says 15= bits, means 32K. If it has to be 0x7FFF it is an End Indicator. Hence plea= se define Max Size for SNDU used for any payload.
=0A2.    &nb= sp;Destination Address field: Section 4.5, Well to provide MAC level filter= ing as similar to DSMCC, we have this support. But nowhere it is mentioned = as MAC Destination Address. Might be misleading to IP addressing since Ipv6= is 6 byte addressing.
=0A3.     Scenarios for Bridged SN= DU Encapsulation. For example, we have DVB-RCS terminal with one Ethernet I= nterface and one DVB interface(TX and RX). When a packet has to be routed f= rom Ethernet Interface to DVB interface, here in Bridged SNDU Encapsulation= comes into picture when the DVB-RCS terminal is configured as L2 SWITCH. D= id we mean that in this case, or when we are using GRE and receive an L2 pa= yload for GRE, which decapsulates the IP & GRE  header and forward= s the payload directly into DVB interface with ULE encapsulation.
=0A=0AThanks and Best Regards,
=0AWilliam=0A

=0A

=0A=0A --Next_1077538110---0-203.199.83.148-30068 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Dear all,=0A=0AMight be I=92m a bit late on ULE discussion, though I have f= ew quick questions hit my mind, hope anyone can help me=0A=0A1) Is there an= y document available already to differentiate DSMCC and ULE, advantages and= disadvantages, why we use ULE instead of DSMCC. If not already available, = I=92ll volunteer to prepare one from my understanding of both the MPE types= .=0A=0ADoubts on ULE Draft=0A-------------------------------=0A1. Section 4= .2 Maximum size of SNDU should be defined, according to draft it says 15 bi= ts, means 32K. If it has to be 0x7FFF it is an End Indicator. Hence please = define Max Size for SNDU used for any payload.=0A2. Destination Address fie= ld: Section 4.5, Well to provide MAC level filtering as similar to DSMCC, w= e have this support. But nowhere it is mentioned as MAC Destination Address= . Might be misleading to IP addressing since Ipv6 is 6 byte addressing.=0A3= . Scenarios for Bridged SNDU Encapsulation. For example, we have DVB-RCS te= rminal with one Ethernet Interface and one DVB interface(TX and RX). When a= packet has to be routed from Ethernet Interface to DVB interface, here in = Bridged SNDU Encapsulation comes into picture when the DVB-RCS terminal is = configured as L2 SWITCH. Did we mean that in this case, or when we are usin= g GRE and receive an L2 payload for GRE, which decapsulates the IP & GRE h= eader and forwards the payload directly into DVB interface with ULE encapsu= lation.=0A=0AThanks and Best Regards,=0AWilliam --Next_1077538110---0-203.199.83.148-30068-- From owner-ip-dvb@erg.abdn.ac.uk Mon Feb 23 12:11:30 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1NCAupb023010 for ; Mon, 23 Feb 2004 12:10:56 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1NCAucJ023009 for ip-dvb-subscribed-users; Mon, 23 Feb 2004 12:10:56 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from rediffmail.com (webmail34.rediffmail.com [203.199.83.247] (may be forged)) by erg.abdn.ac.uk (8.12.11/8.12.11) with SMTP id i1NCAJU0022993 for ; Mon, 23 Feb 2004 12:10:20 GMT Received: (qmail 30793 invoked by uid 510); 23 Feb 2004 12:10:16 -0000 Date: 23 Feb 2004 12:10:16 -0000 Message-ID: <20040223121016.30792.qmail@mailweb34.rediffmail.com> Received: from unknown (203.197.138.199) by rediffmail.com via HTTP; 23 feb 2004 12:10:16 -0000 MIME-Version: 1.0 From: "William StanisLaus" To: "'ip-dvb@erg.abdn.ac.uk'" Subject: UnderStanding ULE Content-type: multipart/alternative; boundary="Next_1077538216---0-203.199.83.247-30233" X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk This is a multipart mime message --Next_1077538216---0-203.199.83.247-30233 Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

=0ADear all,
=0A
=0AMight be I=92m a bit late on ULE discussion, t= hough I have few quick questions hit my mind, hope anyone can help me
= =0A
=0A1)     Is there any document available already to = differentiate DSMCC and ULE, advantages and disadvantages, why we use ULE i= nstead of DSMCC. If not already available, I=92ll volunteer to prepare one = from my understanding of both the MPE types.
=0A
=0ADoubts on ULE Dra= ft
=0A-------------------------------
=0A1.     Sectio= n 4.2 Maximum size of SNDU should be defined, according to draft it says 15= bits, means 32K. If it has to be 0x7FFF it is an End Indicator. Hence plea= se define Max Size for SNDU used for any payload.
=0A2.    &nb= sp;Destination Address field: Section 4.5, Well to provide MAC level filter= ing as similar to DSMCC, we have this support. But nowhere it is mentioned = as MAC Destination Address. Might be misleading to IP addressing since Ipv6= is 6 byte addressing.
=0A3.     Scenarios for Bridged SN= DU Encapsulation. For example, we have DVB-RCS terminal with one Ethernet I= nterface and one DVB interface(TX and RX). When a packet has to be routed f= rom Ethernet Interface to DVB interface, here in Bridged SNDU Encapsulation= comes into picture when the DVB-RCS terminal is configured as L2 SWITCH. D= id we mean that in this case, or when we are using GRE and receive an L2 pa= yload for GRE, which decapsulates the IP & GRE  header and forward= s the payload directly into DVB interface with ULE encapsulation.
=0A=0AThanks and Best Regards,
=0AWilliam=0A

=0A

=0A=0A --Next_1077538216---0-203.199.83.247-30233 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Dear all,=0A=0AMight be I=92m a bit late on ULE discussion, though I have f= ew quick questions hit my mind, hope anyone can help me=0A=0A1) Is there an= y document available already to differentiate DSMCC and ULE, advantages and= disadvantages, why we use ULE instead of DSMCC. If not already available, = I=92ll volunteer to prepare one from my understanding of both the MPE types= .=0A=0ADoubts on ULE Draft=0A-------------------------------=0A1. Section 4= .2 Maximum size of SNDU should be defined, according to draft it says 15 bi= ts, means 32K. If it has to be 0x7FFF it is an End Indicator. Hence please = define Max Size for SNDU used for any payload.=0A2. Destination Address fie= ld: Section 4.5, Well to provide MAC level filtering as similar to DSMCC, w= e have this support. But nowhere it is mentioned as MAC Destination Address= . Might be misleading to IP addressing since Ipv6 is 6 byte addressing.=0A3= . Scenarios for Bridged SNDU Encapsulation. For example, we have DVB-RCS te= rminal with one Ethernet Interface and one DVB interface(TX and RX). When a= packet has to be routed from Ethernet Interface to DVB interface, here in = Bridged SNDU Encapsulation comes into picture when the DVB-RCS terminal is = configured as L2 SWITCH. Did we mean that in this case, or when we are usin= g GRE and receive an L2 payload for GRE, which decapsulates the IP & GRE h= eader and forwards the payload directly into DVB interface with ULE encapsu= lation.=0A=0AThanks and Best Regards,=0AWilliam --Next_1077538216---0-203.199.83.247-30233-- From owner-ip-dvb@erg.abdn.ac.uk Mon Feb 23 12:35:41 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1NCYvYo023989 for ; Mon, 23 Feb 2004 12:34:57 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1NCYvtx023988 for ip-dvb-subscribed-users; Mon, 23 Feb 2004 12:34:57 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from out005.verizon.net (out005pub.verizon.net [206.46.170.143]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1NCXnRq023917 for ; Mon, 23 Feb 2004 12:33:49 GMT Received: from copernicus ([68.163.243.66]) by out005.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040223123346.WMI2677.out005.verizon.net@copernicus> for ; Mon, 23 Feb 2004 06:33:46 -0600 Message-ID: <05e501c3fa09$5280faa0$b402a8c0@copernicus> From: "Marie-Jose Montpetit" To: References: <20040223121016.30792.qmail@mailweb34.rediffmail.com> Subject: Re: UnderStanding ULE Date: Mon, 23 Feb 2004 07:34:00 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_05E1_01C3F9DF.673EFBB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authentication-Info: Submitted using SMTP AUTH at out005.verizon.net from [68.163.243.66] at Mon, 23 Feb 2004 06:33:45 -0600 X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk This is a multi-part message in MIME format. ------=_NextPart_000_05E1_01C3F9DF.673EFBB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Actually part of the study we did with ESTEC was to look at those = differences/advantages; the FP for the study is end of next week so = we're busy writing those differences. We will have both hardware = advantage/disadvantages and protocol level differences. I'm ready to = help also write the document if that is considered helpful by the group. Marie-Jose ----- Original Message -----=20 From: William StanisLaus=20 To: 'ip-dvb@erg.abdn.ac.uk'=20 Sent: Monday, February 23, 2004 7:10 AM Subject: UnderStanding ULE Dear all, Might be I'm a bit late on ULE discussion, though I have few quick = questions hit my mind, hope anyone can help me 1) Is there any document available already to differentiate DSMCC = and ULE, advantages and disadvantages, why we use ULE instead of DSMCC. = If not already available, I'll volunteer to prepare one from my = understanding of both the MPE types. Doubts on ULE Draft ------------------------------- 1. Section 4.2 Maximum size of SNDU should be defined, according = to draft it says 15 bits, means 32K. If it has to be 0x7FFF it is an End = Indicator. Hence please define Max Size for SNDU used for any payload. 2. Destination Address field: Section 4.5, Well to provide MAC = level filtering as similar to DSMCC, we have this support. But nowhere = it is mentioned as MAC Destination Address. Might be misleading to IP = addressing since Ipv6 is 6 byte addressing. 3. Scenarios for Bridged SNDU Encapsulation. For example, we have = DVB-RCS terminal with one Ethernet Interface and one DVB interface(TX = and RX). When a packet has to be routed from Ethernet Interface to DVB = interface, here in Bridged SNDU Encapsulation comes into picture when = the DVB-RCS terminal is configured as L2 SWITCH. Did we mean that in = this case, or when we are using GRE and receive an L2 payload for GRE, = which decapsulates the IP & GRE header and forwards the payload = directly into DVB interface with ULE encapsulation. Thanks and Best Regards, William=20 ------=_NextPart_000_05E1_01C3F9DF.673EFBB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Actually part of the study we did with = ESTEC was to=20 look at those differences/advantages; the FP for the study is end of = next week=20 so we're busy writing those differences. We will have both hardware=20 advantage/disadvantages and protocol level differences. I'm ready to = help also=20 write the document if that is considered helpful by the = group.
 
Marie-Jose
----- Original Message -----
From:=20 William StanisLaus =
Sent: Monday, February 23, 2004 = 7:10=20 AM
Subject: UnderStanding = ULE

Dear all,

Might be I=92m a bit late on ULE discussion, = though I have=20 few quick questions hit my mind, hope anyone can help = me

1) =20    Is there any document available already to differentiate = DSMCC=20 and ULE, advantages and disadvantages, why we use ULE instead of = DSMCC. If not=20 already available, I=92ll volunteer to prepare one from my = understanding of both=20 the MPE types.

Doubts on ULE=20 Draft
-------------------------------
1.    =  Section 4.2=20 Maximum size of SNDU should be defined, according to draft it says 15 = bits,=20 means 32K. If it has to be 0x7FFF it is an End Indicator. Hence please = define=20 Max Size for SNDU used for any payload.
2.    =  Destination=20 Address field: Section 4.5, Well to provide MAC level filtering as = similar to=20 DSMCC, we have this support. But nowhere it is mentioned as MAC = Destination=20 Address. Might be misleading to IP addressing since Ipv6 is 6 byte=20 addressing.
3.     Scenarios for Bridged SNDU = Encapsulation.=20 For example, we have DVB-RCS terminal with one Ethernet Interface and = one DVB=20 interface(TX and RX). When a packet has to be routed from Ethernet = Interface=20 to DVB interface, here in Bridged SNDU Encapsulation comes into = picture when=20 the DVB-RCS terminal is configured as L2 SWITCH. Did we mean that in = this=20 case, or when we are using GRE and receive an L2 payload for GRE, = which=20 decapsulates the IP & GRE  header and forwards the payload = directly=20 into DVB interface with ULE encapsulation.

Thanks and Best=20 Regards,
William



------=_NextPart_000_05E1_01C3F9DF.673EFBB0-- From owner-ip-dvb@erg.abdn.ac.uk Mon Feb 23 13:45:06 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1NDhwe9026478 for ; Mon, 23 Feb 2004 13:43:58 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1NDhvqa026477 for ip-dvb-subscribed-users; Mon, 23 Feb 2004 13:43:57 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1NDh4pN026446 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 23 Feb 2004 13:43:05 GMT Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1NDh4T01282; Mon, 23 Feb 2004 15:43:04 +0200 (EET) X-Scanned: Mon, 23 Feb 2004 15:42:49 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i1NDgnMC020691; Mon, 23 Feb 2004 15:42:49 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 0027fFCV; Mon, 23 Feb 2004 15:42:48 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1NDgm708840; Mon, 23 Feb 2004 15:42:48 +0200 (EET) Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 23 Feb 2004 15:42:48 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 23 Feb 2004 15:42:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02. Date: Mon, 23 Feb 2004 15:42:46 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02. Thread-Index: AcPyeOxOXaPlmgOPRzO/3cR2tZ/eLQCmjwFQAT/ERJA= From: To: , Cc: X-OriginalArrivalTime: 23 Feb 2004 13:42:47.0482 (UTC) FILETIME=[EC26B1A0:01C3FA12] 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 i1NDhs02026471 Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Hi Margaret et al. (Sorry about the dekay - just waiting to see if anyone else flagged interest in a "bar-WG" in Korea - none yet) I'd be happy to make time for this. Anyone else interested? (If there's only the two of us the drinks are on me, otherwise we'll see :) How about Tuesday 1130-1500 or 1515-1545? Cheers, Rod. -----Original Message----- From: owner-ip-dvb@erg.abdn.ac.uk [mailto:owner-ip-dvb@erg.abdn.ac.uk]On Behalf Of ext Margaret Wasserman Sent: Friday, February 13, 2004 11:14 PM To: ip-dvb@erg.abdn.ac.uk Cc: Gorry Fairhurst Subject: RE: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02. Hi Rod, >(I'll be in Korea, so would be happy to share a couple of round with >anyone interested in a bar-WG - not a bar-bof anymore :) If you don't mind, I'll take you up on this! I don't want to distract the WG from its chartered work, but I would like to better understand the current state of standardization in the field and how our work in IPDVB will fit in. It would be great if Gorry can join us, and anyone else who wants to come, of course. Margaret From owner-ip-dvb@erg.abdn.ac.uk Tue Feb 24 00:03:52 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1O03LTi017763 for ; Tue, 24 Feb 2004 00:03:21 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1O03LRw017762 for ip-dvb-subscribed-users; Tue, 24 Feb 2004 00:03:21 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from clyde.ses-astra.com (clyde.ses-astra.com [194.154.219.60]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1O01J86017693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 24 Feb 2004 00:01:20 GMT Received: from marge.gen.btz.aia.lu (marge.gen.btz.aia.lu [193.168.96.8]) by clyde.ses-astra.com (8.12.10/8.12.10) with ESMTP id i1O01EEu002710 for ; Tue, 24 Feb 2004 01:01:15 +0100 (CET) Subject: Joel Grotz is out of office. From: Joel.Grotz@ses-astra.com To: ip-dvb@erg.abdn.ac.uk Message-ID: Date: Tue, 24 Feb 2004 01:01:14 +0100 X-MIMETrack: Serialize by Router on marge/BTZ(Release 5.0.12 |February 13, 2003) at 24/02/2004 01:01:15 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk I will be out of the office starting 02/23/2004 and will not return until 02/25/2004. If required, I will respond to your message when I return to office. Best Regards, Joel Grotz PS: Use joel.grotz@gmx.net for urgent matters. -- 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. From owner-ip-dvb@erg.abdn.ac.uk Tue Feb 24 17:32:21 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1OHVfIT022454 for ; Tue, 24 Feb 2004 17:31:41 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1OHVeYE022453 for ip-dvb-subscribed-users; Tue, 24 Feb 2004 17:31:40 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from smail3.alcatel.fr (colt-na7.alcatel.fr [62.23.212.7]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1OHU7UZ022379 for ; Tue, 24 Feb 2004 17:30:09 GMT Received: from vzmta01.netfr.alcatel.fr (vzmta01.netfr.alcatel.fr [155.132.182.220]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id i1OHTuIH030776 for ; Tue, 24 Feb 2004 18:30:02 +0100 Importance: Low Sensitivity: Subject: Encryption control of SNDU To: ip-dvb@erg.abdn.ac.uk From: Tarif.Zein-Alabedeen@space.alcatel.fr Date: Tue, 24 Feb 2004 18:27:28 +0100 Message-ID: X-MIMETrack: Serialize by Router on VZMTA01/ALCANET/ALCATEL-SPACE(Release 5.0.12 |February 13, 2003) at 24/02/2004 18:30:02 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 X-Alcanet-MTA-scanned-and-authorized: yes 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 i1OHVc58022448 Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Hi every body The current ULE draft does not address the issue of SNDU encryption which we think is important. In fact, a requirement has been identified in IP/MPE/MPEG to allow, when necessary, data encryption at MPE level. Some IP/MPE/MPEG products already implement this capability (e.g. Alcatel 9780) Encryption is controlled using the 'payload scrambling control' field (2 bits) in the MPE header. Consequently, it would be necessary to provision an "encryption-control" field (2 bits) in the SNDU header. This could also facilitate the transition from MPE to ULE Here is a proposal for its definition : bit 1 : indicates if the SNDU is encrypted or not bit 2 : indicating the type of encryption (when active) odd/even (to allow key shift on the fly) Adding 2 bits would require to add a complete byte to the SNDU header in order that the header still an integer number of bytes. If this is not acceptable from a performance point of view, we can envisage to shorten the 'length' field from 15 bits down to 13 bits (note that in MPE, the length field is 12 bits). waiting for your feedback regards T. Zein ALCATEL SPACE DRT/RST -- Ingénieur Systèmes Tel : 0534356918 / Fax : 0534355560 Porte : W.220 From owner-ip-dvb@erg.abdn.ac.uk Tue Feb 24 20:27:04 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1OKQ77C028643 for ; Tue, 24 Feb 2004 20:26:07 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1OKQ65F028642 for ip-dvb-subscribed-users; Tue, 24 Feb 2004 20:26:07 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from dobermann.cosy.sbg.ac.at (dobermann.cosy.sbg.ac.at [141.201.2.56]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1OKPHb6028597 for ; Tue, 24 Feb 2004 20:25:17 GMT Received: by dobermann.cosy.sbg.ac.at (Postfix, from userid 102) id 67592F9014; Tue, 24 Feb 2004 21:25:18 +0100 (CET) Received: from lama.cosy.sbg.ac.at (lama.cosy.sbg.ac.at [141.201.2.5]) by dobermann.cosy.sbg.ac.at (Postfix) with ESMTP id 51FCEF8D03 for ; Tue, 24 Feb 2004 21:25:16 +0100 (CET) Received: by lama.cosy.sbg.ac.at (Postfix, from userid 1004) id E83C76EFC1; Tue, 24 Feb 2004 21:25:15 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by lama.cosy.sbg.ac.at (Postfix) with ESMTP id C66FA2E98F for ; Tue, 24 Feb 2004 21:25:15 +0100 (MET) Date: Tue, 24 Feb 2004 21:25:15 +0100 (MET) From: Bernhard Nocker To: Subject: Re: Encryption control of SNDU In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-15 Content-Transfer-Encoding: 8BIT X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on dobermann.cosy.sbg.ac.at X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Hi, if it is really required to notify a receiver about scrambled SNDUs I would prefer to use another type field value for that purpose instead of adding new header fields. But it might be as appropriate to start a S-ULE (secure ULE) draft just for that purpose?! Another alternative would be to announce the scrambled ULE in the PSI/SI instead of the encapsulation header fields. Kind regards, Bernhard On Tue, 24 Feb 2004 Tarif.Zein-Alabedeen@space.alcatel.fr wrote: > > > Hi every body > > The current ULE draft does not address the issue of SNDU encryption which > we think is important. > In fact, a requirement has been identified in IP/MPE/MPEG to allow, when > necessary, data encryption at MPE level. Some IP/MPE/MPEG products already > implement this capability (e.g. Alcatel 9780) > Encryption is controlled using the 'payload scrambling control' field (2 > bits) in the MPE header. > > Consequently, it would be necessary to provision an "encryption-control" > field (2 bits) in the SNDU header. > This could also facilitate the transition from MPE to ULE > Here is a proposal for its definition : > bit 1 : indicates if the SNDU is encrypted or not > bit 2 : indicating the type of encryption (when active) odd/even (to > allow key shift on the fly) > > Adding 2 bits would require to add a complete byte to the SNDU header in > order that the header still an integer number of bytes. If this is not > acceptable from a performance point of view, we can envisage to shorten the > 'length' field from 15 bits down to 13 bits (note that in MPE, the length > field is 12 bits). > > waiting for your feedback > regards > > T. Zein > > ALCATEL SPACE > DRT/RST -- Ingénieur Systèmes > Tel : 0534356918 / Fax : 0534355560 > Porte : W.220 > > > From owner-ip-dvb@erg.abdn.ac.uk Wed Feb 25 09:35:15 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1P9Xijs025572 for ; Wed, 25 Feb 2004 09:33:44 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1P9XiPb025570 for ip-dvb-subscribed-users; Wed, 25 Feb 2004 09:33:44 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from proxy.6wind.com (proxy.ipv6.6wind.com [194.250.197.211]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1P9WPc6025511 for ; Wed, 25 Feb 2004 09:32:26 GMT Received: from eagle.6wind.com (givenchy.6wind.com [212.234.238.114]) by proxy.6wind.com (Postfix) with ESMTP id E2F5E73F for ; Wed, 25 Feb 2004 10:32:25 +0100 (CET) Received: from 6wind.com (unknown [10.16.0.135]) by eagle.6wind.com (Postfix) with ESMTP id C53B854F for ; Wed, 25 Feb 2004 10:32:25 +0100 (CET) Message-ID: <403C6CA1.6050708@6wind.com> Date: Wed, 25 Feb 2004 10:36:33 +0100 From: alain.ritoux@6wind.com 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 Subject: Re: Encryption control of SNDU References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Tarif.Zein-Alabedeen@space.alcatel.fr wrote: > > Hi every body > > The current ULE draft does not address the issue of SNDU encryption which > we think is important. > In fact, a requirement has been identified in IP/MPE/MPEG to allow, when > necessary, data encryption at MPE level. Some IP/MPE/MPEG products already > implement this capability (e.g. Alcatel 9780) > Encryption is controlled using the 'payload scrambling control' field (2 > bits) in the MPE header. I fail to see why we would need an L2 encryption to carry IP/IPv6 traffic, when IPsec/IKE is already defined including encryption, authentication, key distribution and all that kind of stuff. Would it not be re-inventing the (rather complex) wheel ? Regards. Alain. -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com From owner-ip-dvb@erg.abdn.ac.uk Wed Feb 25 09:43:53 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1P9hCF1025962 for ; Wed, 25 Feb 2004 09:43:12 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1P9hBng025961 for ip-dvb-subscribed-users; Wed, 25 Feb 2004 09:43:11 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from GWOUT.thalesgroup.com (gwout.thalesgroup.com [195.101.39.227]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1P9gOJW025925 for ; Wed, 25 Feb 2004 09:42:24 GMT Received: from thalescan.corp.thales (200.3.2.3) by GWOUT.thalesgroup.com (NPlex 6.5.026) id 403C027C00007903 for ip-dvb@erg.abdn.ac.uk; Wed, 25 Feb 2004 10:42:12 +0100 Received: from lowplex.mut.thales ([10.33.37.2]) by thalescan with InterScan Messaging Security Suite; Wed, 25 Feb 2004 10:41:54 +0100 Received: from cnfplex.thomcast.thomson-csf.com (178.1.4.1) by lowplex.mut.thales (NPlex 6.5.026) id 4032367000068157 for ip-dvb@erg.abdn.ac.uk; Wed, 25 Feb 2004 10:41:54 +0100 Received: from zethos.thomcast.thomson-csf.com (178.3.2.15) by cnfplex.thomcast.thomson-csf.com (NPlex 6.5.026) id 4039B985000027C4 for ip-dvb@erg.abdn.ac.uk; Wed, 25 Feb 2004 10:41:53 +0100 Received: from andromede (178.3.1.43) by zethos.thomcast.thomson-csf.com (NPlex 6.5.026) id 402D052300005EAA for ip-dvb@erg.abdn.ac.uk; Wed, 25 Feb 2004 10:44:55 +0100 From: "Benoit Oger" To: Subject: ULE and FEC Date: Wed, 25 Feb 2004 10:38:09 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Hello, as new subjects are raised, like encryption, I was thinking it could be interessant for ULE to propose a FEC system (Forward Error Correction). ULE is aimed for a wide range of physical media, more or less exposed to noise and error; therefore an error correction ability could be useful. Actually, we could be inspired by the DVB-H draft that provide MPE with such a system, called MPE-FEC. DVB-H derive from DVB-T standard, it deals with optimisation for wireless communication like the reduction of the average power consumption for mobile or a better resistance to noise. MPE-FEC simply combine datagrams interleaving and a Reed-Solomon code. It is designed in such a way that it will be transparent for a receiver not supporting MPE-FEC. Datagrams are encapsulated and sent as usual. Reed-Solomon parity bytes are transmitted on the same Pid but with a different section type , for ULE it migth be a different type. Your thoughts about that. Benoit Oger Thales Broadcast & Multimedia From owner-ip-dvb@erg.abdn.ac.uk Wed Feb 25 10:05:31 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1PA3uEa026750 for ; Wed, 25 Feb 2004 10:03:56 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1PA3utO026749 for ip-dvb-subscribed-users; Wed, 25 Feb 2004 10:03:56 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from [10.0.1.104] (maxp2.abdn.ac.uk [139.133.7.161]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1PA2Opb026696 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 25 Feb 2004 10:02:27 GMT User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Wed, 25 Feb 2004 10:02:54 +0000 Subject: ipdvb: draft-fair-ipdvb-ule-02.txt progression to WG draft From: Gorry Fairhurst To: 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-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk I am pleased to announce the adoption of the following draft as a Working Group work item. This draft will be re-issued as draft-ietf-ipdvb-ule-00, following re-opening of the Internet Draft Archives after the Seoul meeting. A list of known issues will be posted soon by the authors and inputs will be appreciated to address as many of these issues as possible in the next revision. Title : Ultra Lightweight Encapsulation (ULE) for transmission of IP datagrams over MPEG-2/DVB networks Author(s) : G. Fairhurst, B. Collini-Nocker Filename : draft-fair-ipdvb-ule-02.txt Pages : 32 Date : 2003-11-24 Gorry Fairhurst Ipdvb WG chair From owner-ip-dvb@erg.abdn.ac.uk Wed Feb 25 10:49:37 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1PAm5At028417 for ; Wed, 25 Feb 2004 10:48:05 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1PAm5Mw028416 for ip-dvb-subscribed-users; Wed, 25 Feb 2004 10:48:05 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from loewe.cosy.sbg.ac.at (loewe.cosy.sbg.ac.at [141.201.2.12]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1PAkvaf028364 for ; Wed, 25 Feb 2004 10:46:57 GMT Received: from milbe (milbe.cosy.sbg.ac.at [141.201.2.21]) by loewe.cosy.sbg.ac.at (8.8.8/8.8.7) with SMTP id LAA15311 for ; Wed, 25 Feb 2004 11:46:57 +0100 (MET) From: "Bernhard Collini-Nocker" To: Subject: RE: Encryption control of SNDU Date: Wed, 25 Feb 2004 11:46:57 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <403C6CA1.6050708@6wind.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Hello, I do see reasons for scrambling e.g. for the case to prevent from traffic analysis. Whether this or other reasons are taking into account is in my view a question of community demand. But again, I am not in favour of new header fields/flags. Scrambling has too little to do with encapsulation. One other issue, which has not been discussed yet, is how to announce ULE streams in PSI/SI at all. Does someone have a preferred strategy on how to proceed with this issue? It is certainly a side-issue, but without having a god-idea (in advance or by stream analysis) what stream type (encapsulation) is used on a specific PID receivers are somehow left in the dark. Best regards, Bernhard > -----Original Message----- > From: owner-ip-dvb@erg.abdn.ac.uk [mailto:owner-ip-dvb@erg.abdn.ac.uk]On > Behalf Of alain.ritoux@6wind.com > Sent: Mittwoch, 25. Februar 2004 10:37 > To: IPDVB > Subject: Re: Encryption control of SNDU > > > > > Tarif.Zein-Alabedeen@space.alcatel.fr wrote: > > > > > Hi every body > > > > The current ULE draft does not address the issue of SNDU > encryption which > > we think is important. > > In fact, a requirement has been identified in IP/MPE/MPEG to allow, when > > necessary, data encryption at MPE level. Some IP/MPE/MPEG > products already > > implement this capability (e.g. Alcatel 9780) > > Encryption is controlled using the 'payload scrambling control' field (2 > > bits) in the MPE header. > > I fail to see why we would need an L2 encryption to carry IP/IPv6 > traffic, when IPsec/IKE is already defined including encryption, > authentication, key distribution and all that kind of stuff. > Would it not be re-inventing the (rather complex) wheel ? > > Regards. > Alain. > -- > Alain RITOUX > Tel +33-1-39-30-92-32 > Fax +33-1-39-30-92-11 > visit our web http://www.6wind.com > From owner-ip-dvb@erg.abdn.ac.uk Wed Feb 25 10:47:24 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1PAkUwJ028349 for ; Wed, 25 Feb 2004 10:46:30 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1PAkTrP028348 for ip-dvb-subscribed-users; Wed, 25 Feb 2004 10:46:29 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from proxy.6wind.com (proxy.ipv6.6wind.com [194.250.197.211]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1PAjo3F028312 for ; Wed, 25 Feb 2004 10:45:50 GMT Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id 987A6790 for ; Wed, 25 Feb 2004 11:45:50 +0100 (CET) Received: from 6wind.com (vouvray.dev.6wind.com [10.16.0.135]) by intranet.6wind.com (Postfix) with ESMTP id 891666C7; Wed, 25 Feb 2004 11:45:50 +0100 (CET) Message-ID: <403C7DD6.2080402@6wind.com> Date: Wed, 25 Feb 2004 11:49:58 +0100 From: Alain RITOUX 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: ip-dvb@erg.abdn.ac.uk Subject: Re: ULE and FEC References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Benoit Oger wrote: > Hello, > > as new subjects are raised, like encryption, I was thinking it could be > interessant for ULE to propose a FEC system (Forward Error Correction). ULE > is aimed for a wide range of physical media, more or less exposed to noise > and error; therefore an error correction ability could be useful. Actually, > we could be inspired by the DVB-H draft that provide MPE with such a system, > called MPE-FEC. DVB-H derive from DVB-T standard, it deals with optimisation > for wireless communication like the reduction of the average power > consumption for mobile or a better resistance to noise. > > MPE-FEC simply combine datagrams interleaving and a Reed-Solomon code. It is > designed in such a way that it will be transparent for a receiver not > supporting MPE-FEC. Datagrams are encapsulated and sent as usual. > Reed-Solomon parity bytes are transmitted on the same Pid but with a > different section type , for ULE it migth be a different type. I don't have precise opinion about the usefullness of such FEC. But indeed, if it was needed, the FEC itself could be inserted in an "extension header", associated to the SNDU itself, as I proposed some time ago (http://www.erg.abdn.ac.uk/ip-dvb/archive/msg00527.html) Such an extension would then be of type : optional extension, if not known, just skip and process next. Regards. Alain. -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com From owner-ip-dvb@erg.abdn.ac.uk Wed Feb 25 10:51:14 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1PAnPWJ028465 for ; Wed, 25 Feb 2004 10:49:26 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1PAnPSc028462 for ip-dvb-subscribed-users; Wed, 25 Feb 2004 10:49:25 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from smail3.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1PAlupk028386 for ; Wed, 25 Feb 2004 10:47:56 GMT Received: from vzmta01.netfr.alcatel.fr (vzmta01.netfr.alcatel.fr [155.132.182.220]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id i1PAl7IH022378 for ; Wed, 25 Feb 2004 11:47:47 +0100 Importance: Low Sensitivity: Subject: =?iso-8859-1?Q?R=E9f=2E_=3A_Re=3A_Encryption_control_of_SNDU?= To: ip-dvb@erg.abdn.ac.uk From: Tarif.Zein-Alabedeen@space.alcatel.fr Date: Wed, 25 Feb 2004 11:44:48 +0100 Message-ID: X-MIMETrack: Serialize by Router on VZMTA01/ALCANET/ALCATEL-SPACE(Release 5.0.12 |February 13, 2003) at 25/02/2004 11:47:48 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 X-Alcanet-MTA-scanned-and-authorized: yes 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 i1PAnMnC028459 Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Thanks bernhard for your answer, In fact, even if we use a secure ULE session mechanism, rekeying is required during a session. PSI/SI is not real time and could not allow synchronized rekeying on the fly without SNDU (or MPE section) loss. The receiver still needs a flag indicating from which SNDU the new key applies. The requirement for such a control field is specified in the dvb-rcs standard (EN 301790) and in EN 301192. In EN 301790 section 6.4.6.3, the exact wording for this is as follows : DVB Multiprotocol Encapsulation sections, according to EN 301 192 [5], the 2-bit payload_scrambling_control field in the section header is used: - 00: not encrypted; - 01: reserved; - 10: encrypted using session key 0; - 11: encrypted using session key 1. Regards Bernhard Nocker @erg.abdn.ac.uk on 24/02/2004 21:25:15 Veuillez répondre à ip-dvb@erg.abdn.ac.uk Envoyé par : owner-ip-dvb@erg.abdn.ac.uk Pour : cc : Objet : Re: Encryption control of SNDU Hi, if it is really required to notify a receiver about scrambled SNDUs I would prefer to use another type field value for that purpose instead of adding new header fields. But it might be as appropriate to start a S-ULE (secure ULE) draft just for that purpose?! Another alternative would be to announce the scrambled ULE in the PSI/SI instead of the encapsulation header fields. Kind regards, Bernhard On Tue, 24 Feb 2004 Tarif.Zein-Alabedeen@space.alcatel.fr wrote: > > > Hi every body > > The current ULE draft does not address the issue of SNDU encryption which > we think is important. > In fact, a requirement has been identified in IP/MPE/MPEG to allow, when > necessary, data encryption at MPE level. Some IP/MPE/MPEG products already > implement this capability (e.g. Alcatel 9780) > Encryption is controlled using the 'payload scrambling control' field (2 > bits) in the MPE header. > > Consequently, it would be necessary to provision an "encryption-control" > field (2 bits) in the SNDU header. > This could also facilitate the transition from MPE to ULE > Here is a proposal for its definition : > bit 1 : indicates if the SNDU is encrypted or not > bit 2 : indicating the type of encryption (when active) odd/even (to > allow key shift on the fly) > > Adding 2 bits would require to add a complete byte to the SNDU header in > order that the header still an integer number of bytes. If this is not > acceptable from a performance point of view, we can envisage to shorten the > 'length' field from 15 bits down to 13 bits (note that in MPE, the length > field is 12 bits). > > waiting for your feedback > regards > > T. Zein > > ALCATEL SPACE > DRT/RST -- Ingénieur Systèmes > Tel : 0534356918 / Fax : 0534355560 > Porte : W.220 > > > T. Zein ALCATEL SPACE DRT/RST -- Ingénieur Systèmes Tel : 0534356918 / Fax : 0534355560 Porte : W.220 From owner-ip-dvb@erg.abdn.ac.uk Wed Feb 25 11:01:33 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1PAxeJc028862 for ; Wed, 25 Feb 2004 10:59:40 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1PAxeWu028861 for ip-dvb-subscribed-users; Wed, 25 Feb 2004 10:59:40 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from loewe.cosy.sbg.ac.at (loewe.cosy.sbg.ac.at [141.201.2.12]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1PAwRPA028803 for ; Wed, 25 Feb 2004 10:58:28 GMT Received: from milbe (milbe.cosy.sbg.ac.at [141.201.2.21]) by loewe.cosy.sbg.ac.at (8.8.8/8.8.7) with SMTP id LAA18434 for ; Wed, 25 Feb 2004 11:58:28 +0100 (MET) From: "Bernhard Collini-Nocker" To: Subject: RE: ULE and FEC Date: Wed, 25 Feb 2004 11:58:28 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Hello, since I am on holidays :-) I take the chance to be more active in this discussion group. Well, FEC is a very good point, and the need for it in DVB-T is certainly existing. My question, apart from whether or not to add a FEC type, at this point is, what error patterns are being considered. We also have a DVB-T set-up running in our lab and the probability that packets (SNDUs) can be corrected with FEC and interleaving alone is from my experiences rather low, given that outages (link losses during station movements) are typically affecting quite many TS cells corresponding to many SNDUs and, hence, retransmissions are needed to maintain reliability. Best regards, Bernhard > -----Original Message----- > From: owner-ip-dvb@erg.abdn.ac.uk [mailto:owner-ip-dvb@erg.abdn.ac.uk]On > Behalf Of Benoit Oger > Sent: Mittwoch, 25. Februar 2004 10:38 > To: ip-dvb@erg.abdn.ac.uk > Subject: ULE and FEC > > > Hello, > > as new subjects are raised, like encryption, I was thinking it could be > interessant for ULE to propose a FEC system (Forward Error > Correction). ULE > is aimed for a wide range of physical media, more or less exposed to noise > and error; therefore an error correction ability could be useful. > Actually, > we could be inspired by the DVB-H draft that provide MPE with > such a system, > called MPE-FEC. DVB-H derive from DVB-T standard, it deals with > optimisation > for wireless communication like the reduction of the average power > consumption for mobile or a better resistance to noise. > > MPE-FEC simply combine datagrams interleaving and a Reed-Solomon > code. It is > designed in such a way that it will be transparent for a receiver not > supporting MPE-FEC. Datagrams are encapsulated and sent as usual. > Reed-Solomon parity bytes are transmitted on the same Pid but with a > different section type , for ULE it migth be a different type. > > Your thoughts about that. > > > Benoit Oger > Thales Broadcast & Multimedia > > From owner-ip-dvb@erg.abdn.ac.uk Wed Feb 25 11:32:33 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1PBVfsh000110 for ; Wed, 25 Feb 2004 11:31:41 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1PBVf0u000109 for ip-dvb-subscribed-users; Wed, 25 Feb 2004 11:31:41 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from rediffmail.com (webmail25.rediffmail.com [203.199.83.147] (may be forged)) by erg.abdn.ac.uk (8.12.11/8.12.11) with SMTP id i1PBUVWj000077 for ; Wed, 25 Feb 2004 11:30:31 GMT Received: (qmail 8258 invoked by uid 510); 25 Feb 2004 11:30:26 -0000 Date: 25 Feb 2004 11:30:26 -0000 Message-ID: <20040225113026.8257.qmail@webmail25.rediffmail.com> Received: from unknown (203.197.138.199) by rediffmail.com via HTTP; 25 feb 2004 11:30:26 -0000 MIME-Version: 1.0 From: "William StanisLaus" To: "IPDVB" Cc: alain.ritoux@6wind.com Subject: Re: Re: Encryption control of SNDU Content-type: multipart/alternative; boundary="Next_1077708626---0-203.199.83.147-8239" X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk This is a multipart mime message --Next_1077708626---0-203.199.83.147-8239 Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

=0AHi,
=0A    L2 scrambling is used only for Conditional A= ccess System, i.e. settop boxes.. correct me if i'm wrong.
=0AMPEG IP pa= yload can be well protected by any standard L3 encryption algorithms as sai= d by alain.
=0A
=0ABest Regards,
=0AWilliam.
=0A
=0A
=0AO= n Wed, 25 Feb 2004 alain.ritoux@6wind.com wrote :
=0A>
=0A>
= =0A>Tarif.Zein-Alabedeen@space.alcatel.fr wrote:
=0A>
=0A>&g= t;
=0A>>Hi every body
=0A>>
=0A>>The current ULE= draft does not address the issue of SNDU encryption which
=0A>>we= think is important.
=0A>>In fact, a requirement has been identifi= ed in IP/MPE/MPEG to allow, when
=0A>>necessary, data encryption a= t MPE level. Some IP/MPE/MPEG products already
=0A>>implement this= capability (e.g. Alcatel 9780)
=0A>>Encryption is controlled usin= g the 'payload scrambling control' field (2
=0A>>bits) in the MPE = header.
=0A>
=0A>I fail to see why we would need an L2 encrypti= on to carry IP/IPv6
=0A>traffic, when IPsec/IKE is already defined in= cluding encryption,
=0A>authentication, key distribution and all that= kind of stuff.
=0A>Would it not be re-inventing the (rather complex)= wheel ?
=0A>
=0A>Regards.
=0A>Alain.
=0A>-- Alain = RITOUX
=0A>Tel +33-1-39-30-92-32
=0A>Fax +33-1-39-30-92-11
= =0A>visit our web http://www.6wind.com
=0A>
=0A=0A

=0A
=0A=0A --Next_1077708626---0-203.199.83.147-8239 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi,=0A L2 scrambling is used only for Conditional Access System, i.e. s= ettop boxes.. correct me if i'm wrong.=0AMPEG IP payload can be well protec= ted by any standard L3 encryption algorithms as said by alain.=0A=0ABest Re= gards,=0AWilliam.=0A=0A=0AOn Wed, 25 Feb 2004 alain.ritoux@6wind.com wrote = :=0A>=0A>=0A>Tarif.Zein-Alabedeen@space.alcatel.fr wrote:=0A>=0A>>=0A>>Hi e= very body=0A>>=0A>>The current ULE draft does not address the issue of SNDU= encryption which=0A>>we think is important.=0A>>In fact, a requirement has= been identified in IP/MPE/MPEG to allow, when=0A>>necessary, data encrypti= on at MPE level. Some IP/MPE/MPEG products already=0A>>implement this capab= ility (e.g. Alcatel 9780)=0A>>Encryption is controlled using the 'payload s= crambling control' field (2=0A>>bits) in the MPE header.=0A>=0A>I fail to s= ee why we would need an L2 encryption to carry IP/IPv6=0A>traffic, when IPs= ec/IKE is already defined including encryption,=0A>authentication, key dist= ribution and all that kind of stuff.=0A>Would it not be re-inventing the (r= ather complex) wheel ?=0A>=0A>Regards.=0A>Alain.=0A>-- Alain RITOUX=0A>Tel = +33-1-39-30-92-32=0A>Fax +33-1-39-30-92-11=0A>visit our web http://www.6win= d.com=0A>=0A --Next_1077708626---0-203.199.83.147-8239-- From owner-ip-dvb@erg.abdn.ac.uk Wed Feb 25 11:46:31 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1PBjlof000694 for ; Wed, 25 Feb 2004 11:45:47 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1PBjkn6000693 for ip-dvb-subscribed-users; Wed, 25 Feb 2004 11:45:46 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from smail3.alcatel.fr (colt-na7.alcatel.fr [62.23.212.7]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1PBjJsg000677 for ; Wed, 25 Feb 2004 11:45:19 GMT Received: from vzmta01.netfr.alcatel.fr (vzmta01.netfr.alcatel.fr [155.132.182.220]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id i1PBj2IF006973 for ; Wed, 25 Feb 2004 12:45:07 +0100 Importance: Low Sensitivity: Subject: =?iso-8859-1?Q?R=E9f=2E_=3A_Re=3A_Encryption_control_of_SNDU?= To: ip-dvb@erg.abdn.ac.uk From: Tarif.Zein-Alabedeen@space.alcatel.fr Date: Wed, 25 Feb 2004 12:41:12 +0100 Message-ID: X-MIMETrack: Serialize by Router on VZMTA01/ALCANET/ALCATEL-SPACE(Release 5.0.12 |February 13, 2003) at 25/02/2004 12:45:08 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 X-Alcanet-MTA-scanned-and-authorized: yes 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 i1PBjjtu000690 Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Well, L3 IPsec vs L2 encryption is rather an old debate. Any way, L2 encryption is almost always asked for by satellite providers to allow intrinsic securtiy within the system independantly of L3 security. IPsec is an option which is not always applied. How many poeple do have their DSL link secured with IPsec? if this is not dramatic in a wired system since it is rather difficult to snif your DSL line, a wireless system is rather vulnerable. That is why such L2 securtiy has been provisioned for dvb-rcs systems. Encryption at MPEG layer as suggested in the requirements ID (draft-fair-ipdvb-req-04.txt) can not allow a per receiver keying If such a solution is not put into ULE, it may simply turn to be inapplicable to dvb-rcs systems :( cheers tarif alain.ritoux@6wind.com@erg.abdn.ac.uk on 25/02/2004 10:36:33 Veuillez répondre à ip-dvb@erg.abdn.ac.uk Envoyé par : owner-ip-dvb@erg.abdn.ac.uk Pour : IPDVB cc : Objet : Re: Encryption control of SNDU Tarif.Zein-Alabedeen@space.alcatel.fr wrote: > > Hi every body > > The current ULE draft does not address the issue of SNDU encryption which > we think is important. > In fact, a requirement has been identified in IP/MPE/MPEG to allow, when > necessary, data encryption at MPE level. Some IP/MPE/MPEG products already > implement this capability (e.g. Alcatel 9780) > Encryption is controlled using the 'payload scrambling control' field (2 > bits) in the MPE header. I fail to see why we would need an L2 encryption to carry IP/IPv6 traffic, when IPsec/IKE is already defined including encryption, authentication, key distribution and all that kind of stuff. Would it not be re-inventing the (rather complex) wheel ? Regards. Alain. -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com T. Zein ALCATEL SPACE DRT/RST -- Ingénieur Systèmes Tel : 0534356918 / Fax : 0534355560 Porte : W.220 From owner-ip-dvb@erg.abdn.ac.uk Wed Feb 25 12:41:25 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1PCeVfQ002641 for ; Wed, 25 Feb 2004 12:40:31 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1PCeVk6002640 for ip-dvb-subscribed-users; Wed, 25 Feb 2004 12:40:31 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from loewe.cosy.sbg.ac.at (loewe.cosy.sbg.ac.at [141.201.2.12]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1PCdDcn002568 for ; Wed, 25 Feb 2004 12:39:13 GMT Received: from milbe (milbe.cosy.sbg.ac.at [141.201.2.21]) by loewe.cosy.sbg.ac.at (8.8.8/8.8.7) with SMTP id NAA08853 for ; Wed, 25 Feb 2004 13:39:12 +0100 (MET) From: "Bernhard Collini-Nocker" To: Subject: =?iso-8859-1?Q?RE:_R=E9f._:_Re:_Encryption_control_of_SNDU?= Date: Wed, 25 Feb 2004 13:39:12 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Dear Tarif, since I am not an expert on scrambling could you please elaborate a little bit on how the receivers do obtain the two keys. Is there a key distribution mechanism or are those keys permanently set in the receiver hardware? Still my personal opinion is that scrambling control should be in a separate standard track. Where to put the 2 necessary bits is a good question, adding another header byte seems too much overhead to me. An potential alternative, provided the MTU of the SNDUs is small enough, which might be the case for DVB-RCS anyhow, could be to limit the Length field and insert those 2 bits after the D bit. That would lead to a 8 K maximum size of SNDUs. Any other ideas and arguments? Regards, Bernhard > Thanks bernhard for your answer, > > In fact, even if we use a secure ULE session mechanism, rekeying is > required during a session. > PSI/SI is not real time and could not allow synchronized rekeying on the > fly without SNDU (or MPE section) loss. > The receiver still needs a flag indicating from which SNDU the new key > applies. > > The requirement for such a control field is specified in the dvb-rcs > standard (EN 301790) and in EN 301192. > In EN 301790 section 6.4.6.3, the exact wording for this is as follows : > > DVB Multiprotocol Encapsulation sections, according to EN 301 192 > [5], the 2-bit > payload_scrambling_control field in the section header is used: > - 00: not encrypted; > - 01: reserved; > - 10: encrypted using session key 0; > - 11: encrypted using session key 1. > > Regards > > > > > > > > Bernhard Nocker @erg.abdn.ac.uk on 24/02/2004 > 21:25:15 > > Veuillez répondre à ip-dvb@erg.abdn.ac.uk > > Envoyé par : owner-ip-dvb@erg.abdn.ac.uk > > > Pour : > cc : > Objet : Re: Encryption control of SNDU > > > Hi, > > if it is really required to notify a receiver about scrambled SNDUs I > would prefer to use another type field value for that purpose instead of > adding new header fields. But it might be as appropriate to start a S-ULE > (secure ULE) draft just for that purpose?! Another alternative would be to > announce the scrambled ULE in the PSI/SI instead of the encapsulation > header fields. > > Kind regards, > Bernhard > > On Tue, 24 Feb 2004 Tarif.Zein-Alabedeen@space.alcatel.fr wrote: > > > > > > > Hi every body > > > > The current ULE draft does not address the issue of SNDU > encryption which > > we think is important. > > In fact, a requirement has been identified in IP/MPE/MPEG to allow, when > > necessary, data encryption at MPE level. Some IP/MPE/MPEG products > already > > implement this capability (e.g. Alcatel 9780) > > Encryption is controlled using the 'payload scrambling control' field (2 > > bits) in the MPE header. > > > > Consequently, it would be necessary to provision an "encryption-control" > > field (2 bits) in the SNDU header. > > This could also facilitate the transition from MPE to ULE > > Here is a proposal for its definition : > > bit 1 : indicates if the SNDU is encrypted or not > > bit 2 : indicating the type of encryption (when active) odd/even (to > > allow key shift on the fly) > > > > Adding 2 bits would require to add a complete byte to the SNDU header in > > order that the header still an integer number of bytes. If this is not > > acceptable from a performance point of view, we can envisage to shorten > the > > 'length' field from 15 bits down to 13 bits (note that in MPE, > the length > > field is 12 bits). > > > > waiting for your feedback > > regards > > > > T. Zein > > > > ALCATEL SPACE > > DRT/RST -- Ingénieur Systèmes > > Tel : 0534356918 / Fax : 0534355560 > > Porte : W.220 > > > > > > > > > > > > > T. Zein > > ALCATEL SPACE > DRT/RST -- Ingénieur Systèmes > Tel : 0534356918 / Fax : 0534355560 > Porte : W.220 > > > > From owner-ip-dvb@erg.abdn.ac.uk Wed Feb 25 13:07:12 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1PD5PCb003504 for ; Wed, 25 Feb 2004 13:05:25 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1PD5PDr003503 for ip-dvb-subscribed-users; Wed, 25 Feb 2004 13:05:25 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from proxy.6wind.com (proxy.ipv6.6wind.com [194.250.197.211]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1PD1Qet003354 for ; Wed, 25 Feb 2004 13:01:26 GMT Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id BBBC16FD for ; Wed, 25 Feb 2004 14:01:26 +0100 (CET) Received: from 6wind.com (vouvray.dev.6wind.com [10.16.0.135]) by intranet.6wind.com (Postfix) with ESMTP id A72D465E; Wed, 25 Feb 2004 14:01:26 +0100 (CET) Message-ID: <403C9D9E.2020909@6wind.com> Date: Wed, 25 Feb 2004 14:05:34 +0100 From: Alain RITOUX 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: ip-dvb@erg.abdn.ac.uk Subject: Re: =?ISO-8859-1?Q?R=E9f=2E_=3A_Re=3A_Encryption_control?= =?ISO-8859-1?Q?_of_SNDU?= References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Tarif.Zein-Alabedeen@space.alcatel.fr wrote: > > Well, L3 IPsec vs L2 encryption is rather an old debate. Yes, and far from me the will to initiate a flame war ;-) > Any way, L2 encryption is almost always asked for by satellite providers to > allow intrinsic securtiy within the system > independantly of L3 security. IPsec is an option which is not always > applied. > How many poeple do have their DSL link secured with IPsec? > if this is not dramatic in a wired system since it is rather difficult to > snif your DSL line, a wireless system is rather vulnerable. I don't really buy those arguments, but I think this debate is out of scope of this WG ;-) but I'm ready to have a discussion with you off-list. > That is why such L2 securtiy has been provisioned for dvb-rcs systems. > Encryption at MPEG layer as suggested in the requirements ID > (draft-fair-ipdvb-req-04.txt) can not allow a per receiver keying > > If such a solution is not put into ULE, it may simply turn to be > inapplicable to dvb-rcs systems :( If such L2 encryption is unavoidable, can it be managed (including keying etc ...) at pure MPEG-2 level ? i.e. there's an encryption done for all traffic using a (some) PID(s), which leaves ULE quite un-concerned ? Cheers. Alain. -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com From owner-ip-dvb@erg.abdn.ac.uk Wed Feb 25 14:43:21 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1PEglhv006961 for ; Wed, 25 Feb 2004 14:42:47 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1PEgl9w006960 for ip-dvb-subscribed-users; Wed, 25 Feb 2004 14:42:47 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from smail3.alcatel.fr (na5.alcatel.fr [194.133.58.5]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1PEgHUP006943 for ; Wed, 25 Feb 2004 14:42:17 GMT Received: from vzmta01.netfr.alcatel.fr (vzmta01.netfr.alcatel.fr [155.132.182.220]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id i1PEfGIG002408 for ; Wed, 25 Feb 2004 15:42:04 +0100 Importance: Low Sensitivity: Subject: =?iso-8859-1?Q?R=E9f=2E_=3A_Re=3A_R=E9f=2E_=3A_Re=3A_Encryption_control?= of SNDU To: ip-dvb@erg.abdn.ac.uk From: Tarif.Zein-Alabedeen@space.alcatel.fr Date: Wed, 25 Feb 2004 15:37:16 +0100 Message-ID: X-MIMETrack: Serialize by Router on VZMTA01/ALCANET/ALCATEL-SPACE(Release 5.0.12 |February 13, 2003) at 25/02/2004 15:42:04 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 X-Alcanet-MTA-scanned-and-authorized: yes 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 i1PEgjGT006957 Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk As I said, encryption at MPEG level does not allow a per receiver encryption key. A PID is "multi receiver" which means that if encryption is applied to TS packets, all receivers tuned to a given PID should have the same key and hence each receiver can deencrypte traffic destined to other receivers. This is no issue if all receivers associated to the same PID are in a closed group (VPN) But if not, the question of privacy rises.... I agree that encryption, session securtiy, key exchange can be handled in another ID. However, ULE is still concerned in the way to control and synchronise this. That is to provide tags allwoing the receiver to know : - if a received SNDU is encrypted or not - if yes, which key is used (this is to allow rekeying..) regards Alain RITOUX @erg.abdn.ac.uk on 25/02/2004 14:05:34 Veuillez répondre à ip-dvb@erg.abdn.ac.uk Envoyé par : owner-ip-dvb@erg.abdn.ac.uk Pour : ip-dvb@erg.abdn.ac.uk cc : Objet : Re: Réf. : Re: Encryption control of SNDU Tarif.Zein-Alabedeen@space.alcatel.fr wrote: > > Well, L3 IPsec vs L2 encryption is rather an old debate. Yes, and far from me the will to initiate a flame war ;-) > Any way, L2 encryption is almost always asked for by satellite providers to > allow intrinsic securtiy within the system > independantly of L3 security. IPsec is an option which is not always > applied. > How many poeple do have their DSL link secured with IPsec? > if this is not dramatic in a wired system since it is rather difficult to > snif your DSL line, a wireless system is rather vulnerable. I don't really buy those arguments, but I think this debate is out of scope of this WG ;-) but I'm ready to have a discussion with you off-list. > That is why such L2 securtiy has been provisioned for dvb-rcs systems. > Encryption at MPEG layer as suggested in the requirements ID > (draft-fair-ipdvb-req-04.txt) can not allow a per receiver keying > > If such a solution is not put into ULE, it may simply turn to be > inapplicable to dvb-rcs systems :( can it be managed (including keying etc ...) at pure MPEG-2 level ? i.e. there's an encryption done for all traffic using a (some) PID(s), which leaves ULE quite un-concerned ? Cheers. Alain. -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com T. Zein ALCATEL SPACE DRT/RST -- Ingénieur Systèmes Tel : 0534356918 / Fax : 0534355560 Porte : W.220 From owner-ip-dvb@erg.abdn.ac.uk Wed Feb 25 15:21:05 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1PFKQWp008208 for ; Wed, 25 Feb 2004 15:20:26 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1PFKQRn008207 for ip-dvb-subscribed-users; Wed, 25 Feb 2004 15:20:26 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from rediffmail.com (webmail25.rediffmail.com [203.199.83.147] (may be forged)) by erg.abdn.ac.uk (8.12.11/8.12.11) with SMTP id i1PFJhZ6008168 for ; Wed, 25 Feb 2004 15:19:44 GMT Received: (qmail 12667 invoked by uid 510); 25 Feb 2004 15:18:58 -0000 Date: 25 Feb 2004 15:18:58 -0000 Message-ID: <20040225151858.12665.qmail@webmail25.rediffmail.com> Received: from unknown (61.11.78.80) by rediffmail.com via HTTP; 25 feb 2004 15:18:58 -0000 MIME-Version: 1.0 From: "William StanisLaus" To: ip-dvb@erg.abdn.ac.uk Cc: "Bernhard Collini-Nocker" Subject: Re: RE: ULE and FEC Content-type: multipart/alternative; boundary="Next_1077722338---0-203.199.83.147-12611" X-ERG-MailScanner: Found to be clean, Found to be clean X-ERG-MailScanner-SpamScore: s, s Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk This is a multipart mime message --Next_1077722338---0-203.199.83.147-12611 Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

=0AHi,
=0A  I don't quite understand FEC in MPE level, can anyo= ne please elaborate or refer some specifications regarding it.
=0A
= =0AThanks and Best Regards,
=0AWilliam.
=0A
=0AOn Wed, 25 Feb 2004= Bernhard Collini-Nocker wrote :
=0A>Hello,
=0A>
=0A>sinc= e I am on holidays :-) I take the chance to be more active in this
=0A&g= t;discussion group.
=0A>
=0A>Well, FEC is a very good point, an= d the need for it in DVB-T is certainly
=0A>existing. My question, ap= art from whether or not to add a FEC type, at
=0A>this point is, what= error patterns are being considered. We also have a
=0A>DVB-T set-up= running in our lab and the probability that packets (SNDUs)
=0A>can = be corrected with FEC and interleaving alone is from my experiences
=0A&= gt;rather low, given that outages (link losses during station movements)=0A>are typically affecting quite many TS cells corresponding to many S= NDUs
=0A>and, hence, retransmissions are needed to maintain reliabili= ty.
=0A>
=0A>Best regards,
=0A>Bernhard
=0A>
=0A= > > -----Original Message-----
=0A> > From: owner-ip-dvb@erg= .abdn.ac.uk [mailto:owner-ip-dvb@erg.abdn.ac.uk]On
=0A> > Behalf O= f Benoit Oger
=0A> > Sent: Mittwoch, 25. Februar 2004 10:38
=0A= > > To: ip-dvb@erg.abdn.ac.uk
=0A> > Subject: ULE and FEC=0A> >
=0A> >
=0A> > Hello,
=0A> >
=0A= > > as new subjects are raised, like encryption, I was thinking it co= uld be
=0A> > interessant for ULE to propose a FEC system (Forward= Error
=0A> > Correction). ULE
=0A> > is aimed for a wide= range of physical media, more or less exposed to noise
=0A> > and= error; therefore an error correction ability could be useful.
=0A> &= gt; Actually,
=0A> > we could be inspired by the DVB-H draft that = provide MPE with
=0A> > such a system,
=0A> > called MPE-= FEC. DVB-H derive from DVB-T standard, it deals with
=0A> > optimi= sation
=0A> > for wireless communication like the reduction of the= average power
=0A> > consumption for mobile or a better resistanc= e to noise.
=0A> >
=0A> > MPE-FEC simply combine datagram= s interleaving and a Reed-Solomon
=0A> > code. It is
=0A> &g= t; designed in such a way that it will be transparent for a receiver not=0A> > supporting MPE-FEC. Datagrams are encapsulated and sent as us= ual.
=0A> > Reed-Solomon parity bytes are transmitted on the same = Pid but with a
=0A> > different section type , for ULE it migth be= a different type.
=0A> >
=0A> > Your thoughts about that= .
=0A> >
=0A> >
=0A> > Benoit Oger
=0A> &g= t; Thales Broadcast & Multimedia
=0A> >
=0A> >
=0A= >
=0A=0A

=0A

=0A=0A --Next_1077722338---0-203.199.83.147-12611 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi,=0A I don't quite understand FEC in MPE level, can anyone please elabo= rate or refer some specifications regarding it.=0A=0AThanks and Best Regard= s,=0AWilliam.=0A=0AOn Wed, 25 Feb 2004 Bernhard Collini-Nocker wrote :=0A>H= ello,=0A>=0A>since I am on holidays :-) I take the chance to be more active= in this=0A>discussion group.=0A>=0A>Well, FEC is a very good point, and th= e need for it in DVB-T is certainly=0A>existing. My question, apart from wh= ether or not to add a FEC type, at=0A>this point is, what error patterns ar= e being considered. We also have a=0A>DVB-T set-up running in our lab and t= he probability that packets (SNDUs)=0A>can be corrected with FEC and interl= eaving alone is from my experiences=0A>rather low, given that outages (link= losses during station movements)=0A>are typically affecting quite many TS = cells corresponding to many SNDUs=0A>and, hence, retransmissions are needed= to maintain reliability.=0A>=0A>Best regards,=0A>Bernhard=0A>=0A> > -----O= riginal Message-----=0A> > From: owner-ip-dvb@erg.abdn.ac.uk [mailto:owner-= ip-dvb@erg.abdn.ac.uk]On=0A> > Behalf Of Benoit Oger=0A> > Sent: Mittwoch, = 25. Februar 2004 10:38=0A> > To: ip-dvb@erg.abdn.ac.uk=0A> > Subject: ULE a= nd FEC=0A> >=0A> >=0A> > Hello,=0A> >=0A> > as new subjects are raised, lik= e encryption, I was thinking it could be=0A> > interessant for ULE to propo= se a FEC system (Forward Error=0A> > Correction). ULE=0A> > is aimed for a = wide range of physical media, more or less exposed to noise=0A> > and error= ; therefore an error correction ability could be useful.=0A> > Actually,=0A= > > we could be inspired by the DVB-H draft that provide MPE with=0A> > suc= h a system,=0A> > called MPE-FEC. DVB-H derive from DVB-T standard, it deal= s with=0A> > optimisation=0A> > for wireless communication like the reducti= on of the average power=0A> > consumption for mobile or a better resistance= to noise.=0A> >=0A> > MPE-FEC simply combine datagrams interleaving and a = Reed-Solomon=0A> > code. It is=0A> > designed in such a way that it will be= transparent for a receiver not=0A> > supporting MPE-FEC. Datagrams are enc= apsulated and sent as usual.=0A> > Reed-Solomon parity bytes are transmitte= d on the same Pid but with a=0A> > different section type , for ULE it migt= h be a different type.=0A> >=0A> > Your thoughts about that.=0A> >=0A> >=0A= > > Benoit Oger=0A> > Thales Broadcast & Multimedia=0A> >=0A> >=0A>=0A --Next_1077722338---0-203.199.83.147-12611-- From owner-ip-dvb@erg.abdn.ac.uk Wed Feb 25 16:23:36 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1PGMt5k010358 for ; Wed, 25 Feb 2004 16:22:55 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1PGMt0H010357 for ip-dvb-subscribed-users; Wed, 25 Feb 2004 16:22:55 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from GWOUT.thalesgroup.com (gwout.thalesgroup.com [195.101.39.227]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1PGMCRg010328 for ; Wed, 25 Feb 2004 16:22:12 GMT Received: from thalescan.corp.thales (200.3.2.3) by GWOUT.thalesgroup.com (NPlex 6.5.026) id 403C027C000156E0 for ip-dvb@erg.abdn.ac.uk; Wed, 25 Feb 2004 17:21:41 +0100 Received: from lowplex.mut.thales ([10.33.37.2]) by thalescan with InterScan Messaging Security Suite; Wed, 25 Feb 2004 17:21:23 +0100 Received: from cnfplex.thomcast.thomson-csf.com (178.1.4.1) by lowplex.mut.thales (NPlex 6.5.026) id 403236700006F3FD for ip-dvb@erg.abdn.ac.uk; Wed, 25 Feb 2004 17:21:23 +0100 Received: from zethos.thomcast.thomson-csf.com (178.3.2.15) by cnfplex.thomcast.thomson-csf.com (NPlex 6.5.026) id 4039B985000030C7 for ip-dvb@erg.abdn.ac.uk; Wed, 25 Feb 2004 17:21:23 +0100 Received: from andromede (178.3.1.43) by zethos.thomcast.thomson-csf.com (NPlex 6.5.026) id 402D05230000656B for ip-dvb@erg.abdn.ac.uk; Wed, 25 Feb 2004 17:24:25 +0100 From: "Benoit Oger" To: Subject: RE: RE: ULE and FEC Date: Wed, 25 Feb 2004 17:17:38 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0187_01C3FBC3.44B28310" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <20040225151858.12665.qmail@webmail25.rediffmail.com> X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk This is a multi-part message in MIME format. ------=_NextPart_000_0187_01C3FBC3.44B28310 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit You can have a look at DVB-H draft, TM 2939. Regards Benoit Oger Thales Broadcast & Multimedia -----Message d'origine----- De : owner-ip-dvb@erg.abdn.ac.uk [mailto:owner-ip-dvb@erg.abdn.ac.uk]De la part de William StanisLaus Envoyé : mercredi 25 février 2004 16:19 À : ip-dvb@erg.abdn.ac.uk Cc : Bernhard Collini-Nocker Objet : Re: RE: ULE and FEC Hi, I don't quite understand FEC in MPE level, can anyone please elaborate or refer some specifications regarding it. Thanks and Best Regards, William. On Wed, 25 Feb 2004 Bernhard Collini-Nocker wrote : >Hello, > >since I am on holidays :-) I take the chance to be more active in this >discussion group. > >Well, FEC is a very good point, and the need for it in DVB-T is certainly >existing. My question, apart from whether or not to add a FEC type, at >this point is, what error patterns are being considered. We also have a >DVB-T set-up running in our lab and the probability that packets (SNDUs) >can be corrected with FEC and interleaving alone is from my experiences >rather low, given that outages (link losses during station movements) >are typically affecting quite many TS cells corresponding to many SNDUs >and, hence, retransmissions are needed to maintain reliability. > >Best regards, >Bernhard > > > -----Original Message----- > > From: owner-ip-dvb@erg.abdn.ac.uk [mailto:owner-ip-dvb@erg.abdn.ac.uk]On > > Behalf Of Benoit Oger > > Sent: Mittwoch, 25. Februar 2004 10:38 > > To: ip-dvb@erg.abdn.ac.uk > > Subject: ULE and FEC > > > > > > Hello, > > > > as new subjects are raised, like encryption, I was thinking it could be > > interessant for ULE to propose a FEC system (Forward Error > > Correction). ULE > > is aimed for a wide range of physical media, more or less exposed to noise > > and error; therefore an error correction ability could be useful. > > Actually, > > we could be inspired by the DVB-H draft that provide MPE with > > such a system, > > called MPE-FEC. DVB-H derive from DVB-T standard, it deals with > > optimisation > > for wireless communication like the reduction of the average power > > consumption for mobile or a better resistance to noise. > > > > MPE-FEC simply combine datagrams interleaving and a Reed-Solomon > > code. It is > > designed in such a way that it will be transparent for a receiver not > > supporting MPE-FEC. Datagrams are encapsulated and sent as usual. > > Reed-Solomon parity bytes are transmitted on the same Pid but with a > > different section type , for ULE it migth be a different type. > > > > Your thoughts about that. > > > > > > Benoit Oger > > Thales Broadcast & Multimedia > > > > > ------=_NextPart_000_0187_01C3FBC3.44B28310 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
You = can have a look=20 at DVB-H draft, TM 2939.
 
Regards
 
Benoit Oger
Thales Broadcast &=20 Multimedia
 
 
 -----Message=20 d'origine-----
De : owner-ip-dvb@erg.abdn.ac.uk=20 [mailto:owner-ip-dvb@erg.abdn.ac.uk]De la part de William=20 StanisLaus
Envoy=E9 : mercredi 25 f=E9vrier 2004=20 16:19
=C0 : ip-dvb@erg.abdn.ac.uk
Cc : = Bernhard=20 Collini-Nocker
Objet : Re: RE: ULE and=20 FEC

Hi,
  I don't quite understand FEC in MPE level, can anyone = please=20 elaborate or refer some specifications regarding it.

Thanks and = Best=20 Regards,
William.

On Wed, 25 Feb 2004 Bernhard = Collini-Nocker wrote=20 :
>Hello,
>
>since I am on holidays :-) I take the = chance to=20 be more active in this
>discussion group.
>
>Well, = FEC is a=20 very good point, and the need for it in DVB-T is = certainly
>existing. My=20 question, apart from whether or not to add a FEC type, at
>this = point=20 is, what error patterns are being considered. We also have = a
>DVB-T=20 set-up running in our lab and the probability that packets = (SNDUs)
>can=20 be corrected with FEC and interleaving alone is from my=20 experiences
>rather low, given that outages (link losses during = station=20 movements)
>are typically affecting quite many TS cells = corresponding to=20 many SNDUs
>and, hence, retransmissions are needed to maintain=20 reliability.
>
>Best = regards,
>Bernhard
>
> >=20 -----Original Message-----
> > From: = owner-ip-dvb@erg.abdn.ac.uk=20 [mailto:owner-ip-dvb@erg.abdn.ac.uk]On
> > Behalf Of Benoit=20 Oger
> > Sent: Mittwoch, 25. Februar 2004 10:38
> > = To:=20 ip-dvb@erg.abdn.ac.uk
> > Subject: ULE and FEC
> = >
>=20 >
> > Hello,
> >
> > as new subjects are = raised,=20 like encryption, I was thinking it could be
> > interessant = for ULE=20 to propose a FEC system (Forward Error
> > Correction). = ULE
>=20 > is aimed for a wide range of physical media, more or less exposed = to=20 noise
> > and error; therefore an error correction ability = could be=20 useful.
> > Actually,
> > we could be inspired by = the DVB-H=20 draft that provide MPE with
> > such a system,
> > = called=20 MPE-FEC. DVB-H derive from DVB-T standard, it deals with
> >=20 optimisation
> > for wireless communication like the = reduction of the=20 average power
> > consumption for mobile or a better = resistance to=20 noise.
> >
> > MPE-FEC simply combine datagrams = interleaving=20 and a Reed-Solomon
> > code. It is
> > designed in = such a=20 way that it will be transparent for a receiver not
> > = supporting=20 MPE-FEC. Datagrams are encapsulated and sent as usual.
> >=20 Reed-Solomon parity bytes are transmitted on the same Pid but with = a
>=20 > different section type , for ULE it migth be a different = type.
>=20 >
> > Your thoughts about that.
> >
> = >
>=20 > Benoit Oger
> > Thales Broadcast & = Multimedia
>=20 >
> >
>



------=_NextPart_000_0187_01C3FBC3.44B28310-- From owner-ip-dvb@erg.abdn.ac.uk Wed Feb 25 17:16:00 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1PHEsd5012174 for ; Wed, 25 Feb 2004 17:14:54 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1PHEsBB012173 for ip-dvb-subscribed-users; Wed, 25 Feb 2004 17:14:54 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from mail1.iabg.de (mail1.iabg.de [194.139.245.9]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1PHE0S9012109 for ; Wed, 25 Feb 2004 17:14:00 GMT Received: from mail1.iabg.de (localhost [127.0.0.1]) by localhost (Mailserver1 IABG) with ESMTP id 5322D9095 for ; Wed, 25 Feb 2004 18:13:56 +0100 (CET) Received: from exchange03.iabg.de (exchange03.iabg.de [10.128.200.37]) by mail1.iabg.de (Mailserver1 IABG) with ESMTP id 3EF8D8F34 for ; Wed, 25 Feb 2004 18:13:56 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: =?iso-8859-1?Q?AW=3A_R=E9f=2E_=3A_Re=3A_Encryption_control_of_SNDU?= Date: Wed, 25 Feb 2004 18:13:55 +0100 Message-ID: <69A5E767EC979846826F566C7932A3F2074E27@exchange03.iabg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: =?iso-8859-1?Q?R=E9f=2E_=3A_Re=3A_Encryption_control_of_SNDU?= Thread-Index: AcP7oke7LI2TVn15Q6+S/f4YUuDeCAAHzzgA From: "Fritsche Wolfgang" 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 i1PHErel012170 Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Scrambling and FEC are first examples for possible future extensions of ULE, which have not been foreseen during the original design. Certainly these will not be the last ones. Therefore I don't think using space from the length field is a good way to serve these future needs, and would agree with Alains proposal that a cleaner, more flexible and more efficient way to allow extensibility of ULE is the specification of an optional extension header. Like for IPv6 this keeps the basic header slim for efficient processing and allows the introduction of new functionality while keeping backward compatibility (older ULE versions simply can skip new functionality). Cheers, Wolfgang > -----Ursprüngliche Nachricht----- > Von: owner-ip-dvb@erg.abdn.ac.uk > [mailto:owner-ip-dvb@erg.abdn.ac.uk] Im Auftrag von Bernhard > Collini-Nocker > Gesendet: Mittwoch, 25. Februar 2004 13:39 > An: ip-dvb@erg.abdn.ac.uk > Betreff: RE: Réf. : Re: Encryption control of SNDU > > > Dear Tarif, > > since I am not an expert on scrambling could you please > elaborate a little bit on how the receivers do obtain the two > keys. Is there a key distribution mechanism or are those keys > permanently set in the receiver hardware? Still my personal > opinion is that scrambling control should be in a separate > standard track. Where to put the 2 necessary bits is a good > question, adding another header byte seems too much overhead > to me. An potential alternative, provided the MTU of the > SNDUs is small enough, which might be the case for DVB-RCS > anyhow, could be to limit the Length field and insert those 2 > bits after the D bit. That would lead to a 8 K maximum size of SNDUs. > > Any other ideas and arguments? > > Regards, > Bernhard > > > Thanks bernhard for your answer, > > > > In fact, even if we use a secure ULE session mechanism, rekeying is > > required during a session. PSI/SI is not real time and > could not allow > > synchronized rekeying on the fly without SNDU (or MPE section) loss. > > The receiver still needs a flag indicating from which SNDU > the new key > > applies. > > > > The requirement for such a control field is specified in > the dvb-rcs > > standard (EN 301790) and in EN 301192. In EN 301790 section > 6.4.6.3, > > the exact wording for this is as follows : > > > > DVB Multiprotocol Encapsulation sections, according to EN > 301 192 [5], > > the 2-bit payload_scrambling_control field in the section header is > > used: > > - 00: not encrypted; > > - 01: reserved; > > - 10: encrypted using session key 0; > > - 11: encrypted using session key 1. > > > > Regards > > > > > > > > > > > > > > > > Bernhard Nocker @erg.abdn.ac.uk on > 24/02/2004 > > 21:25:15 > > > > Veuillez répondre à ip-dvb@erg.abdn.ac.uk > > > > Envoyé par : owner-ip-dvb@erg.abdn.ac.uk > > > > > > Pour : > > cc : > > Objet : Re: Encryption control of SNDU > > > > > > Hi, > > > > if it is really required to notify a receiver about > scrambled SNDUs I > > would prefer to use another type field value for that > purpose instead > > of adding new header fields. But it might be as appropriate > to start a > > S-ULE (secure ULE) draft just for that purpose?! Another > alternative > > would be to announce the scrambled ULE in the PSI/SI instead of the > > encapsulation header fields. > > > > Kind regards, > > Bernhard > > > > On Tue, 24 Feb 2004 Tarif.Zein-Alabedeen@space.alcatel.fr wrote: > > > > > > > > > > > Hi every body > > > > > > The current ULE draft does not address the issue of SNDU > > encryption which > > > we think is important. > > > In fact, a requirement has been identified in IP/MPE/MPEG > to allow, > > > when necessary, data encryption at MPE level. Some IP/MPE/MPEG > > > products > > already > > > implement this capability (e.g. Alcatel 9780) > > > Encryption is controlled using the 'payload scrambling control' > > > field (2 > > > bits) in the MPE header. > > > > > > Consequently, it would be necessary to provision an > > > "encryption-control" field (2 bits) in the SNDU header. > This could > > > also facilitate the transition from MPE to ULE Here is a proposal > > > for its definition : > > > bit 1 : indicates if the SNDU is encrypted or not > > > bit 2 : indicating the type of encryption (when > active) odd/even (to > > > allow key shift on the fly) > > > > > > Adding 2 bits would require to add a complete byte to the SNDU > > > header in order that the header still an integer number > of bytes. If > > > this is not acceptable from a performance point of view, we can > > > envisage to shorten > > the > > > 'length' field from 15 bits down to 13 bits (note that in MPE, > > the length > > > field is 12 bits). > > > > > > waiting for your feedback > > > regards > > > > > > T. Zein > > > > > > ALCATEL SPACE > > > DRT/RST -- Ingénieur Systèmes > > > Tel : 0534356918 / Fax : 0534355560 > > > Porte : W.220 > > > > > > > > > > > > > > > > > > > > > > > T. Zein > > > > ALCATEL SPACE > > DRT/RST -- Ingénieur Systèmes > > Tel : 0534356918 / Fax : 0534355560 > > Porte : W.220 > > > > > > > > > > From owner-ip-dvb@erg.abdn.ac.uk Thu Feb 26 07:58:38 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1Q7vobn012258 for ; Thu, 26 Feb 2004 07:57:50 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1Q7voWo012257 for ip-dvb-subscribed-users; Thu, 26 Feb 2004 07:57:50 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from ftp.ccrle.nec.de (ftp.netlab.nec.de [195.37.70.21]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1Q7vFJn012235; Thu, 26 Feb 2004 07:57:16 GMT Received: from [172.16.16.208] (scout.netlab.nec.de [195.37.70.100]) by ftp.ccrle.nec.de (Postfix) with ESMTP id 8FB26F5A9; Thu, 26 Feb 2004 09:02:02 +0100 (CET) Date: Thu, 26 Feb 2004 08:57:20 +0100 From: Martin Stiemerling To: ip-dvb@erg.abdn.ac.uk, margaret@thingmagic.com Cc: gorry@erg.abdn.ac.uk Subject: RE: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02. Message-ID: <2147483647.1077785840@[139.100.140.135]> In-Reply-To: References: X-Mailer: Mulberry/3.1.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Hi all bar-WG interested, I'll be in Korea, but I'm not sure whether I can make it to the bar. So if there is any please post time and location to the list. Thanks, Martin --On Montag, 23. Februar 2004 15:42 Uhr +0200 Rod.Walsh@nokia.com wrote: | Hi Margaret et al. | | (Sorry about the dekay - just waiting to see if anyone else flagged | interest in a "bar-WG" in Korea - none yet) | | I'd be happy to make time for this. Anyone else interested? (If there's | only the two of us the drinks are on me, otherwise we'll see :) | | How about Tuesday 1130-1500 or 1515-1545? | | Cheers, Rod. | | | -----Original Message----- | From: owner-ip-dvb@erg.abdn.ac.uk [mailto:owner-ip-dvb@erg.abdn.ac.uk]On | Behalf Of ext Margaret Wasserman | Sent: Friday, February 13, 2004 11:14 PM | To: ip-dvb@erg.abdn.ac.uk | Cc: Gorry Fairhurst | Subject: RE: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02. | | | | Hi Rod, | |> (I'll be in Korea, so would be happy to share a couple of round with |> anyone interested in a bar-WG - not a bar-bof anymore :) | | If you don't mind, I'll take you up on this! I don't want to distract | the WG from its chartered work, but I would like to better understand | the current state of standardization in the field and how our work in | IPDVB will fit in. | | It would be great if Gorry can join us, and anyone else who wants to | come, of course. | | Margaret | | | From owner-ip-dvb@erg.abdn.ac.uk Thu Feb 26 10:33:52 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1QAXMNp017498 for ; Thu, 26 Feb 2004 10:33:22 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1QAXMKl017497 for ip-dvb-subscribed-users; Thu, 26 Feb 2004 10:33:22 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@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.12.11/8.12.11) with ESMTP id i1QAWTVr017456 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 26 Feb 2004 10:32:30 GMT Received: from ccsrnrpc16.ee.surrey.ac.uk ([131.227.88.65] helo=surrey.ac.uk) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 1AwIoV-0007lN-00; Thu, 26 Feb 2004 10:32:19 +0000 Message-ID: <403DCB32.30AE6F12@surrey.ac.uk> Date: Thu, 26 Feb 2004 10:32:18 +0000 From: Haitham Cruickshank Organization: CCSR X-Mailer: Mozilla 4.78 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Re: Encryption control of SNDU References: <403C6CA1.6050708@6wind.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-102.1 required=5.5 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_XM,USER_IN_WHITELIST, X_ACCEPT_LANG autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Scanner: exiscan *1AwIoV-0007lN-00*v5sXu4tXCL.* (SECM, UniS) X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Hi Alain and All, I like to add my voice to Alain's, regarding keeping ULE simple and free from security complications. Also using IPSEC mean closer integration with terrestrial IP networks. However, Bernhard mentioned a good point: "I do see reasons for scrambling e.g. for the case to prevent from traffic analysis". I think this problem can be solved using IPSEC between satellite nodes (before ULE encapsulation) in two ways: 1. Using IPSEC ESP in transparent mode. This means the IP header is sent in the clear and IP payload is encrypted. This solution is efficient but might not prevent traffic analysis using IP addresses. 2. Using IPSEC ESP in tunnel mode. This means IP header and payload are encrypted. This solution is better against traffic analysis, but there is the extra overhead of IPSEC tunnelling. Regards. Haitham alain.ritoux@6wind.com wrote: > Tarif.Zein-Alabedeen@space.alcatel.fr wrote: > > > > > Hi every body > > > > The current ULE draft does not address the issue of SNDU encryption which > > we think is important. > > In fact, a requirement has been identified in IP/MPE/MPEG to allow, when > > necessary, data encryption at MPE level. Some IP/MPE/MPEG products already > > implement this capability (e.g. Alcatel 9780) > > Encryption is controlled using the 'payload scrambling control' field (2 > > bits) in the MPE header. > > I fail to see why we would need an L2 encryption to carry IP/IPv6 > traffic, when IPsec/IKE is already defined including encryption, > authentication, key distribution and all that kind of stuff. > Would it not be re-inventing the (rather complex) wheel ? > > Regards. > Alain. > -- > Alain RITOUX > Tel +33-1-39-30-92-32 > Fax +33-1-39-30-92-11 > visit our web http://www.6wind.com -- Dr. Haitham S. Cruickshank Senior Research Fellow 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/ From owner-ip-dvb@erg.abdn.ac.uk Thu Feb 26 12:34:15 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1QCXEmJ021700 for ; Thu, 26 Feb 2004 12:33:14 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1QCXDeo021699 for ip-dvb-subscribed-users; Thu, 26 Feb 2004 12:33:13 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from [10.0.1.106] (maxp10.abdn.ac.uk [139.133.7.169]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1QCU5Hp021554 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 26 Feb 2004 12:30:12 GMT User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Thu, 26 Feb 2004 12:29:39 +0000 Subject: Re: Encryption control of SNDU From: Gorry Fairhurst To: Message-ID: In-Reply-To: <403DCB32.30AE6F12@surrey.ac.uk> 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-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk So, I'm trying to build a list of "issues for ULE" and the questions I have are: (i) Does the proposed ULE base header format (4/12B of header) need to be changed to support any required encryption/scrambling? Possible answers include: * Yes - because the ULE header must not be increased when link encryption is used. * No - because the ULE header can specify a TYPE that could indicate an encrypted payload, and hence this issue could be solved by using an extension header of some form. If it is YES, then this has design implications for the ULE Spec. If it is NO, then some text on how to implement the encryption header would be a useful input - perhaps this should be a short separate ID? - We can discuss this more easily if we have a proposal and a short example, I'd also be keen to get expert security advice, we don't wish to repeat any of the mistakes made by others. If we can find a solution that is accepted and widely applicable, we could then either add this to the ULE Spec or as a separate document. (b) Whatever the result of the above question, it would be MOST beneficial to have some security inputs to the REQUIREMENTS ID. This document needs to evolve to clearly express the motivations of the ipdvb protocol framework. This is the next draft on the table for discussion.... Can anyone offer 2 or 3 paragraphs on why we need to do/not to do encryption/scrambling at the ULE layer, and what the relationship is to MPEG-2 scrambling and IPSEC? Gorry Fairhurst On 26/2/04 10:32 am, "Haitham Cruickshank" wrote: > Hi Alain and All, > > I like to add my voice to Alain's, regarding keeping ULE simple and free from > security complications. Also using IPSEC mean closer integration with > terrestrial IP networks. > > However, Bernhard mentioned a good point: "I do see reasons for scrambling > e.g. > for the case to prevent from traffic analysis". I think this problem can be > solved using IPSEC between satellite nodes (before ULE encapsulation) in two > ways: > > 1. Using IPSEC ESP in transparent mode. This means the IP header is sent in > the > clear and IP payload is encrypted. This solution is efficient but might not > prevent traffic analysis using IP addresses. > 2. Using IPSEC ESP in tunnel mode. This means IP header and payload are > encrypted. This solution is better against traffic analysis, but there is the > extra overhead of IPSEC tunnelling. > > Regards. > Haitham > > alain.ritoux@6wind.com wrote: > >> Tarif.Zein-Alabedeen@space.alcatel.fr wrote: >> >>> >>> Hi every body >>> >>> The current ULE draft does not address the issue of SNDU encryption which >>> we think is important. >>> In fact, a requirement has been identified in IP/MPE/MPEG to allow, when >>> necessary, data encryption at MPE level. Some IP/MPE/MPEG products already >>> implement this capability (e.g. Alcatel 9780) >>> Encryption is controlled using the 'payload scrambling control' field (2 >>> bits) in the MPE header. >> >> I fail to see why we would need an L2 encryption to carry IP/IPv6 >> traffic, when IPsec/IKE is already defined including encryption, >> authentication, key distribution and all that kind of stuff. >> Would it not be re-inventing the (rather complex) wheel ? >> >> Regards. >> Alain. >> -- >> Alain RITOUX >> Tel +33-1-39-30-92-32 >> Fax +33-1-39-30-92-11 >> visit our web http://www.6wind.com > > -- > Dr. Haitham S. Cruickshank > > Senior Research Fellow > 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/ > > From owner-ip-dvb@erg.abdn.ac.uk Thu Feb 26 13:58:29 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1QDvKCo024791 for ; Thu, 26 Feb 2004 13:57:20 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1QDvKTo024790 for ip-dvb-subscribed-users; Thu, 26 Feb 2004 13:57:20 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from [209.116.240.194] (foxtrot.nab.org [209.116.240.194]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1QDuhQC024767 for ; Thu, 26 Feb 2004 13:56:43 GMT Received: from mail.nab.org by [209.116.240.194] via smtpd (for mavis.erg.abdn.ac.uk [139.133.204.77]) with ESMTP; Thu, 26 Feb 2004 08:56:44 -0500 Received: (private information removed) Message-ID: <5A659834E1607E4EBD72FCE2FE5C9CF102FEBF32@mail.NAB.ORG> From: "Allison, Art" To: "'ip-dvb@erg.abdn.ac.uk'" Subject: RE: Encryption control of SNDU Date: Thu, 26 Feb 2004 08:56:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk I add my voice to those saying keep this ULE recommendation free from security complications. It seems to me that whatever security that anyone feels is needed can happen above (or below) this transport recommendations place in the stack of protocols. The entire payload of all packets identified by a PID can be scrambled at the MPEG-2 layer, with what ever CA standard is appropriate. At the IP layer (and/or higher) there are tools available, such as IPSEC. With respect to traffic analysis protection, that too does not seem to need definition at this layer. However, my difficulty in understanding what traffic analysis means or could yield to an attacker in a one-way broadcast environment may be affecting this assessment. Regards, Art ::{)> Art Allison Director Advanced Engineering NAB 1771 N St NW Washington DC 20036 202 429 5418 -----Original Message----- From: Haitham Cruickshank [mailto:H.Cruickshank@eim.surrey.ac.uk] Sent: Thursday, February 26, 2004 5:32 AM To: ip-dvb@erg.abdn.ac.uk Subject: Re: Encryption control of SNDU Hi Alain and All, I like to add my voice to Alain's, regarding keeping ULE simple and free from security complications. Also using IPSEC mean closer integration with terrestrial IP networks. However, Bernhard mentioned a good point: "I do see reasons for scrambling e.g. for the case to prevent from traffic analysis". I think this problem can be solved using IPSEC between satellite nodes (before ULE encapsulation) in two ways: 1. Using IPSEC ESP in transparent mode. This means the IP header is sent in the clear and IP payload is encrypted. This solution is efficient but might not prevent traffic analysis using IP addresses. 2. Using IPSEC ESP in tunnel mode. This means IP header and payload are encrypted. This solution is better against traffic analysis, but there is the extra overhead of IPSEC tunnelling. Regards. Haitham alain.ritoux@6wind.com wrote: > Tarif.Zein-Alabedeen@space.alcatel.fr wrote: > > > > > Hi every body > > > > The current ULE draft does not address the issue of SNDU encryption which > > we think is important. > > In fact, a requirement has been identified in IP/MPE/MPEG to allow, when > > necessary, data encryption at MPE level. Some IP/MPE/MPEG products already > > implement this capability (e.g. Alcatel 9780) > > Encryption is controlled using the 'payload scrambling control' field (2 > > bits) in the MPE header. > > I fail to see why we would need an L2 encryption to carry IP/IPv6 > traffic, when IPsec/IKE is already defined including encryption, > authentication, key distribution and all that kind of stuff. > Would it not be re-inventing the (rather complex) wheel ? > > Regards. > Alain. > -- > Alain RITOUX > Tel +33-1-39-30-92-32 > Fax +33-1-39-30-92-11 > visit our web http://www.6wind.com -- Dr. Haitham S. Cruickshank Senior Research Fellow 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/ From owner-ip-dvb@erg.abdn.ac.uk Thu Feb 26 14:22:18 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1QELl8r025800 for ; Thu, 26 Feb 2004 14:21:47 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1QELl0w025799 for ip-dvb-subscribed-users; Thu, 26 Feb 2004 14:21:47 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from proxy.6wind.com (proxy.ipv6.6wind.com [194.250.197.211]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1QEL7YY025775 for ; Thu, 26 Feb 2004 14:21:07 GMT Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id E043E76A for ; Thu, 26 Feb 2004 15:21:07 +0100 (CET) Received: from 6wind.com (vouvray.dev.6wind.com [10.16.0.135]) by intranet.6wind.com (Postfix) with ESMTP id B7A5C6AF for ; Thu, 26 Feb 2004 15:21:07 +0100 (CET) Message-ID: <403E01CB.3000301@6wind.com> Date: Thu, 26 Feb 2004 15:25:15 +0100 From: Alain RITOUX 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 Subject: Re: Encryption control of SNDU References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Gorry Fairhurst wrote: > So, I'm trying to build a list of "issues for ULE" and the questions I have > are: > > (i) Does the proposed ULE base header format (4/12B of header) need to be > changed to support any required encryption/scrambling? > > Possible answers include: > > * Yes - because the ULE header must not be increased when > link encryption is used. > > * No - because the ULE header can specify a TYPE that could > indicate an encrypted payload, and hence this issue > could be solved by using an extension header of some form. > > If it is YES, then this has design implications for the ULE Spec. I would say No, because : - I don't really understand the need for ULE level encryption see point I) - If needed, it can be separated from ULE base specs. see point II) I) Why ULE level encryption ? ============================= I still don't sse the need for an ULE-level encryption, because I see 3 possibilities of encryption 1) At MPEG-2 level, i.e. same encryption for whole content of a PID 2) At ULE level, i.e. encryption on a per SNDU basis for the case as Tarif said, where PID is mutli-receiver (belonging to different groups) 3) At IP level but what can distinguish 2 SNDU ? - IP addresses ? - DVB Mac addr ? But the DVB Mac addr is itself the result of IP address/prefix resolution (which can use destination and/or sources) So I think it can all be expresed in term of either destination and/or source Addresses, which can perfectly be handled by IPsec. So 2) and 3) seem to me to offer the same granularity and 3) is already defined and working. This is my current understanding, and a counter-example where 2) would solve a use-case and not 3) would be very helpfull. Anyway, I may have missed something, so : II) Etxension Header for Encryption ==================================== *IF* an ULE encryption is needed, then some extension header can be defined to provide it, so the SNDU would be like : - [ULE_Header] [DVB_MAC*] [SEC_Header] [xxx SNDU Payload xxx] | +--> Type = sec_header (*) if MAC addres bit is '0' - The SEC_Header would be +---+---+---+--// ..... // ----+ | NH | L | security params | +---+---+---+--// ..... // ----+ with NH = Type of SNDU payload (IP, IPv6, ...) L = Length of SEC_Header security params will define key material, type of security (encryption, authentication, ....), algo, whatever ... In the extension headers I proposed, the SEC_Header would be one of the "drop packets if unknown" type. - The SNDU payload woul be clear/encrypt/padded accordingly to what params will be found in SEC_Header. With that approach, the only thing needed is to include the Extension Headers mechanism definition in the ULE base specs. Then ALL that SEC_Header stuff can be described in a separate doc, and good luck with the (re)keying framework/protocols, security analysis ... Regards. Alain. -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com From owner-ip-dvb@erg.abdn.ac.uk Thu Feb 26 16:28:59 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1QGRqXv000061 for ; Thu, 26 Feb 2004 16:27:52 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1QGRqqh000060 for ip-dvb-subscribed-users; Thu, 26 Feb 2004 16:27:52 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from smail3.alcatel.fr (na5.alcatel.fr [194.133.58.5]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1QGRJgn000042 for ; Thu, 26 Feb 2004 16:27:20 GMT Received: from vzmta01.netfr.alcatel.fr (vzmta01.netfr.alcatel.fr [155.132.182.220]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id i1QGABd5027400 for ; Thu, 26 Feb 2004 17:27:13 +0100 Importance: Low Sensitivity: Subject: =?iso-8859-1?Q?R=E9f=2E_=3A_Re=3A_Encryption_control_of_SNDU?= To: ip-dvb@erg.abdn.ac.uk From: Tarif.Zein-Alabedeen@space.alcatel.fr Date: Thu, 26 Feb 2004 17:23:07 +0100 Message-ID: X-MIMETrack: Serialize by Router on VZMTA01/ALCANET/ALCATEL-SPACE(Release 5.0.12 |February 13, 2003) at 26/02/2004 17:27:13 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 X-Alcanet-MTA-scanned-and-authorized: yes 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 i1QGRokV000057 Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Hi alain and every body Concerning point I, let me go back to dvb-rcs : encryption at the encapsulation layer (which is now MPE but may become ULE in the future) has been provisioned and the way it is controlled by the 2 bits field in the MPE header has been clearly specified (see my precedent mail) I am not aware of the exact reasons which led poeple who contributed to the dvb-rcs definition to do this may be they did something wrong or expected a functionnality that will never be used....!!!! But it is more probable that they had real reasons to do this (so we can avoid to reinvent the wheel as you said) Any one has an idea? I see an example which could make case 3 difficult to apply. It concerns bridging When forwarding (in the Gateway for example) is performed by bridging (as in Ethernet switches) and not by routing (as routers), IPsec can not apply because the GW handles frames and not datagrams (am I wrong?). Such case may happen with e.g a PPPOE access scheme. So if IPsec is not applied end-to-end (but this can not be controlled by the satellite segment), traffic will be transmitted clear on the sat interface Concerning the use of the extension header, the main question is : when encryption is applied at ULE level, do we need the encryption control field in all SNDUs or not. If yes, the extension header solution may turn to be inefficient since it would lead to about 5 bytes extra header (taking your example below). I submitted this question to Alcatel's security experts but would be great if others in this groupe could also think about it and make suggestions regards Alain RITOUX @erg.abdn.ac.uk on 26/02/2004 15:25:15 Veuillez répondre à ip-dvb@erg.abdn.ac.uk Envoyé par : owner-ip-dvb@erg.abdn.ac.uk Pour : IPDVB cc : Objet : Re: Encryption control of SNDU Gorry Fairhurst wrote: > So, I'm trying to build a list of "issues for ULE" and the questions I have > are: > > (i) Does the proposed ULE base header format (4/12B of header) need to be > changed to support any required encryption/scrambling? > > Possible answers include: > > * Yes - because the ULE header must not be increased when > link encryption is used. > > * No - because the ULE header can specify a TYPE that could > indicate an encrypted payload, and hence this issue > could be solved by using an extension header of some form. > > If it is YES, then this has design implications for the ULE Spec. I would say No, because : - I don't really understand the need for ULE level encryption see point I) - If needed, it can be separated from ULE base specs. see point II) I) Why ULE level encryption ? ============================= I still don't sse the need for an ULE-level encryption, because I see 3 possibilities of encryption 1) At MPEG-2 level, i.e. same encryption for whole content of a PID 2) At ULE level, i.e. encryption on a per SNDU basis for the case as Tarif said, where PID is mutli-receiver (belonging to different groups) 3) At IP level but what can distinguish 2 SNDU ? - IP addresses ? - DVB Mac addr ? But the DVB Mac addr is itself the result of IP address/prefix resolution (which can use destination and/or sources) So I think it can all be expresed in term of either destination and/or source Addresses, which can perfectly be handled by IPsec. So 2) and 3) seem to me to offer the same granularity and 3) is already defined and working. This is my current understanding, and a counter-example where 2) would solve a use-case and not 3) would be very helpfull. Anyway, I may have missed something, so : II) Etxension Header for Encryption ==================================== *IF* an ULE encryption is needed, then some extension header can be defined to provide it, so the SNDU would be like : - [ULE_Header] [DVB_MAC*] [SEC_Header] [xxx SNDU Payload xxx] | +--> Type = sec_header (*) if MAC addres bit is '0' - The SEC_Header would be +---+---+---+--// ..... // ----+ | NH | L | security params | +---+---+---+--// ..... // ----+ with NH = Type of SNDU payload (IP, IPv6, ...) L = Length of SEC_Header security params will define key material, type of security (encryption, authentication, ....), algo, whatever ... In the extension headers I proposed, the SEC_Header would be one of the "drop packets if unknown" type. - The SNDU payload woul be clear/encrypt/padded accordingly to what params will be found in SEC_Header. With that approach, the only thing needed is to include the Extension Headers mechanism definition in the ULE base specs. Then ALL that SEC_Header stuff can be described in a separate doc, and good luck with the (re)keying framework/protocols, security analysis ... Regards. Alain. -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com T. Zein ALCATEL SPACE DRT/RST -- Ingénieur Systèmes Tel : 0534356918 / Fax : 0534355560 Porte : W.220 From owner-ip-dvb@erg.abdn.ac.uk Thu Feb 26 17:16:57 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1QHFXjB001836 for ; Thu, 26 Feb 2004 17:15:33 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1QHFW9C001832 for ip-dvb-subscribed-users; Thu, 26 Feb 2004 17:15:33 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from smail3.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1QHEFox001757 for ; Thu, 26 Feb 2004 17:14:15 GMT Received: from vzmta01.netfr.alcatel.fr (vzmta01.netfr.alcatel.fr [155.132.182.220]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id i1QHDwc8022929 for ; Thu, 26 Feb 2004 18:14:08 +0100 Importance: Low Sensitivity: Subject: =?iso-8859-1?Q?R=E9f=2E_=3A_Re=3A_Encryption_control_of_SNDU?= To: ip-dvb@erg.abdn.ac.uk X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Laurent.Claverotte@space.alcatel.fr Date: Thu, 26 Feb 2004 18:11:07 +0100 X-MIMETrack: Serialize by Router on VZMTA01/ALCANET/ALCATEL-SPACE(Release 5.0.12 |February 13, 2003) at 26/02/2004 18:14:08 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 X-Alcanet-MTA-scanned-and-authorized: yes 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 i1QHFT9o001828 Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Dear All, I am working on layer 2 security solution for broadband satellite systems based on the DVB-RCS standard (part 9.4 of the EN301790) and I see several advantages for an ULE-level encryption as explained below. Why ULE level encryption ? 1. Role Model and security requirements Satcom systems based on DVB-S/DVB-RCS are operated by Access Network Operators that want to provide their customers (ISP) with security services. Common targeted security services are : terminal authentication and data confidentiality (for the unicast and multicast streams) between the gateway and the terminals (also limited to the satcom system). The objective is to provide the same level of privacy as the terrestrial links. Moreover, in the same time, the ISP may want to provide end-to-end security services to the end-users (based on the well known IPSec). As a matter, I think this is really important to understand that both security solutions ((ANO to ISP) and (ISP to End-users)) can co-exist and are economically viable. 2. Solutions comparison For the end-to-end security solution between the ISP and the end-users, it is obvious that IPSec or an application security (TLS or SSL) are largely deployed and accepted by the telecom world. Regarding the satcom security (between the gateway and the terminals), different solutions were envisaged by Alcatel Space : - DVB-S Common Scrambling (security solution deployed for the digital broadcast television) : this solution is not compliant to the granularity security requirement (scrambling per PID and not per unicast user!). Moreover, key distribution techniques are one way only and does not benefit from the interactive return link. - IPSec has lot of drawbacks : it is not a L2 solution, it is an end-to-end technology, it can interfere with the end-to-end security solution, it can interfere with satellite techniques (PEP), it does not provide encryption of multicast flows and it generates many overheads and number of signaling messages!!!!!! Lots of comparison studies and simulations have been performed by Alcatel leading to reject this solution!! - Proprietary solutions close to the DVB-S CS : same conclusion as DVB-S CS - DVB-RCS security solution : we believe that it is the most interesting solution regarding the intrinsic satcom security as it complies with the ANO security requirements. Indeed, it is a layer 2 solution (control plane defined in the DVB-RCS standard and traffic plane below the IP layer) enabling to encrypt not only IP streams but also Ethernet frames (PPPoE for example) or other protocols... It can support unicast or multicast streams encryption. Moreover, regarding the performances, It largely reduces the number of signaling messages and overheads (main worry in satcom!). It is currently based on the 2 bits payload_scrambling_control of the MPE header providing the information if the packet is encrypted or not and with which key (odd or even)...... and this essential information would be canceled in the ULE definition. 3. Concurrent systems and standardization As you know, the main concurrent to the european ETSI DVB-S/DVB-RCS standards is the US DOCSIS standard that includes (in its baseline!!!) a layer 2 security solution providing terminal authentication and confidentiality (called BPI+). Alcatel believes that it is really important to make the DVB-RCS standard evolve (current Satlab contributions) to offer a complete DVB-RCS security solution that can be compared to the US DOCSIS standard. That would really be worrying if the ULE encapsulation could not include this feature because it would not be compliant with the DVB-RCS security solution. I hope that you will understand my concern. Regards. Laurent Claverotte Alain RITOUX @erg.abdn.ac.uk on 26/02/2004 15:25:15 Veuillez répondre à ip-dvb@erg.abdn.ac.uk Envoyé par : owner-ip-dvb@erg.abdn.ac.uk Pour : IPDVB cc : Objet : Re: Encryption control of SNDU Gorry Fairhurst wrote: > So, I'm trying to build a list of "issues for ULE" and the questions I have > are: > > (i) Does the proposed ULE base header format (4/12B of header) need to be > changed to support any required encryption/scrambling? > > Possible answers include: > > * Yes - because the ULE header must not be increased when > link encryption is used. > > * No - because the ULE header can specify a TYPE that could > indicate an encrypted payload, and hence this issue > could be solved by using an extension header of some form. > > If it is YES, then this has design implications for the ULE Spec. I would say No, because : - I don't really understand the need for ULE level encryption see point I) - If needed, it can be separated from ULE base specs. see point II) I) Why ULE level encryption ? ============================= I still don't sse the need for an ULE-level encryption, because I see 3 possibilities of encryption 1) At MPEG-2 level, i.e. same encryption for whole content of a PID 2) At ULE level, i.e. encryption on a per SNDU basis for the case as Tarif said, where PID is mutli-receiver (belonging to different groups) 3) At IP level but what can distinguish 2 SNDU ? - IP addresses ? - DVB Mac addr ? But the DVB Mac addr is itself the result of IP address/prefix resolution (which can use destination and/or sources) So I think it can all be expresed in term of either destination and/or source Addresses, which can perfectly be handled by IPsec. So 2) and 3) seem to me to offer the same granularity and 3) is already defined and working. This is my current understanding, and a counter-example where 2) would solve a use-case and not 3) would be very helpfull. Anyway, I may have missed something, so : II) Etxension Header for Encryption ==================================== *IF* an ULE encryption is needed, then some extension header can be defined to provide it, so the SNDU would be like : - [ULE_Header] [DVB_MAC*] [SEC_Header] [xxx SNDU Payload xxx] | +--> Type = sec_header (*) if MAC addres bit is '0' - The SEC_Header would be +---+---+---+--// ..... // ----+ | NH | L | security params | +---+---+---+--// ..... // ----+ with NH = Type of SNDU payload (IP, IPv6, ...) L = Length of SEC_Header security params will define key material, type of security (encryption, authentication, ....), algo, whatever ... In the extension headers I proposed, the SEC_Header would be one of the "drop packets if unknown" type. - The SNDU payload woul be clear/encrypt/padded accordingly to what params will be found in SEC_Header. With that approach, the only thing needed is to include the Extension Headers mechanism definition in the ULE base specs. Then ALL that SEC_Header stuff can be described in a separate doc, and good luck with the (re)keying framework/protocols, security analysis ... Regards. Alain. -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com Sincères Salutations / Best regards Laurent Claverotte ALCATEL SPACE DSR/DRE Tel : 33 (0)5.34.35.46.47 / Fax : 33 (0)5.34.35.61.69 E-Mail : Laurent.Claverotte@space.alcatel.fr From owner-ip-dvb@erg.abdn.ac.uk Fri Feb 27 07:41:48 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1R7cXvG029466 for ; Fri, 27 Feb 2004 07:38:33 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1R7cWDI029465 for ip-dvb-subscribed-users; Fri, 27 Feb 2004 07:38:32 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from rediffmail.com (webmail35.rediffmail.com [203.199.83.246] (may be forged)) by erg.abdn.ac.uk (8.12.11/8.12.11) with SMTP id i1R7bCbp029419 for ; Fri, 27 Feb 2004 07:37:17 GMT Received: (qmail 20126 invoked by uid 510); 27 Feb 2004 07:37:07 -0000 Date: 27 Feb 2004 07:37:07 -0000 Message-ID: <20040227073707.20125.qmail@webmail35.rediffmail.com> Received: from unknown (203.197.138.199) by rediffmail.com via HTTP; 27 feb 2004 07:37:06 -0000 MIME-Version: 1.0 From: "William StanisLaus" To: ip-dvb@erg.abdn.ac.uk Cc: Tarif.Zein-Alabedeen@space.alcatel.fr Subject: =?iso-8859-1?Q?Re:_R=E9f=2E_:_Re:_Encryption_control_of_SNDU?= Content-type: multipart/alternative; boundary="Next_1077867426---0-203.199.83.246-18543" X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk This is a multipart mime message --Next_1077867426---0-203.199.83.246-18543 Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

=0AHi everyone,
=0A     I like to support for the requ= irement of Encryption/security at L2 with in satellite network(Terminal and= Gateway) for any confidential informations, both signaling and data packet= s.
=0A
=0AFurther to the extension header for ULE,
=0Ait can be m= ade option as we have for destination mac address, without effecting any im= plementation and design
=0A
=0A-  [Dest Mac Addr bit][ext. head= er present bit][ULE_Header] [DVB_MAC*] [Ext. Header*] [xxx SNDU Payload xxx= ]
=0A
=0Awe can change 15 bits of payload length into 14 bits.. which= is much more than the present DSMCC payload/section length, which is 12 bi= ts.
=0Awith that bit we can define any extension header is present for a= ny future updations to the ULE,
=0Athe Ext. Header is defined as
=0A=   +---+--------+---//  ..... // ----+
=0A  |EHT| NHB &a= mp; L| Ext.Header params  |
=0A  +---+--------+---//  ..= ... // ----+
=0A 
=0A  where, EHT =3D 1 byte of extensio= n header type field. Which has to be defined, might be ULE specific.
=0A=           L  =3D LSB 7 bit of ext. header pa= rameter length, i.e. supports 127 bytes.
=0A        =   NHB =3D MSB 1 bit contains if there is any other extension header pr= esent.
=0A       Ext.Header params =3D variable leng= th based on the ext. header parameter length.
=0A
=0ABest Regards,=0AWilliam.
=0A
=0A
=0AOn Thu, 26 Feb 2004 Tarif.Zein-Alabedeen@s= pace.alcatel.fr wrote :
=0A>
=0A>
=0A>Hi alain and every = body
=0A>Concerning point I, let me go back to dvb-rcs : encryption a= t the
=0A>encapsulation layer
=0A>(which is now MPE but may bec= ome ULE in the future) has been provisioned
=0A>and the way it is
= =0A>controlled by the 2 bits field in the MPE header has been clearly sp= ecified
=0A>(see my precedent mail)
=0A>
=0A>I am not awa= re of the exact reasons which led poeple who contributed to the
=0A>d= vb-rcs definition to do this
=0A>may be they did something wrong or e= xpected a functionnality that will
=0A>never be used....!!!!
=0A&g= t;But it is more probable that they had real reasons to do this (so we can<= BR>=0A>avoid to reinvent the wheel as you said)
=0A>Any one has an= idea?
=0A>
=0A>I see an example which could make case 3 diffic= ult to apply. It concerns
=0A>bridging
=0A>When forwarding (in = the Gateway for example) is performed by bridging (as
=0A>in Ethernet= switches) and not by routing (as routers),
=0A>IPsec can not apply b= ecause the GW handles frames and not datagrams (am I
=0A>wrong?). Suc= h case may happen with e.g a PPPOE access scheme.
=0A>So if IPsec is = not applied end-to-end (but this can not be controlled by
=0A>the sat= ellite segment), traffic will be transmitted clear on the
=0A>sat int= erface
=0A>
=0A>Concerning the use of the extension header, the= main question is : when
=0A>encryption is applied at ULE level, do w= e need the encryption control field
=0A>in all SNDUs or not. If yes, = the extension header solution may turn to be
=0A>inefficient since it= would lead to about 5 bytes extra header (taking your
=0A>example be= low). I submitted this question to Alcatel's security experts but
=0A>= ;would be great  if others in this groupe could also think about it an= d make
=0A>suggestions
=0A>
=0A>regards
=0A>
=0A= >
=0A>
=0A>
=0A>
=0A>Alain RITOUX <alain.rito= ux@6wind.com>@erg.abdn.ac.uk on 26/02/2004 15:25:15
=0A>
=0A>= ;Veuillez r=E9pondre =E0 ip-dvb@erg.abdn.ac.uk
=0A>
=0A>Envoy= =E9 par :      owner-ip-dvb@erg.abdn.ac.uk
=0A>
=0A= >
=0A>Pour : IPDVB <ip-dvb@erg.abdn.ac.uk>
=0A>cc :=0A>Objet :    Re: Encryption control of SNDU
=0A>
= =0A>
=0A>
=0A>
=0A>Gorry Fairhurst wrote:
=0A>=0A> > So, I'm trying to build a list of "issues for ULE"= and the questions I
=0A>have
=0A> > are:
=0A> >=0A> > (i) Does the proposed ULE base header format (4/12B of header= ) need to be
=0A> > changed to support any required encryption/scr= ambling?
=0A> >
=0A> > Possible answers include:
=0A&g= t; >
=0A> > * Yes - because the ULE header must not be increase= d when
=0A> >    link encryption is used.
=0A> &g= t;
=0A> > * No - because the ULE header can specify a TYPE that co= uld
=0A> >    indicate an encrypted payload, and hence = this issue
=0A> >    could be solved by using an extens= ion header of some form.
=0A> >
=0A> > If it is YES, then= this has design implications for the ULE Spec.
=0A>
=0A>I woul= d say No, because :
=0A>    - I don't really understand the= need for ULE level encryption
=0A>      see point I)<= BR>=0A>    - If needed, it can be separated from ULE base spec= s. see point II)
=0A>
=0A>I) Why ULE level encryption ?
=0A&= gt;=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
=0A>I still don't sse the need for an ULE-level encry= ption, because
=0A>I see 3 possibilities of encryption
=0A>1) A= t MPEG-2 level, i.e. same encryption for whole content of a PID
=0A>2= ) At ULE level, i.e. encryption on a per SNDU basis for the case as
=0A&= gt;  Tarif said, where PID is mutli-receiver (belonging to different = groups)
=0A>3) At IP level
=0A>
=0A>but what can distingu= ish 2 SNDU ?
=0A>    - IP addresses ?
=0A>  &nbs= p; - DVB Mac addr ?
=0A>But the DVB Mac addr is itself the result of = IP address/prefix
=0A>resolution (which can use destination and/or so= urces)
=0A>So I think it can all be expresed in term of either destin= ation and/or
=0A>source Addresses, which can perfectly be handled by = IPsec. So 2) and 3)
=0A>seem to me to offer the same granularity and = 3) is already defined and
=0A>working.
=0A>
=0A>This is m= y current understanding,  and a counter-example where 2) would
=0A&= gt;solve a use-case and not 3) would be very helpfull.
=0A>Anyway, I = may have missed something, so :
=0A>
=0A>II) Etxension Header f= or Encryption
=0A>=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
=0A>*IF* an= ULE encryption is needed, then some extension header can be
=0A>defi= ned to provide it, so the SNDU would be like :
=0A>
=0A>- = [ULE_Header] [DVB_MAC*] [SEC_Header] [xxx SNDU Payload xxx]
=0A>&nbs= p;         |
=0A>        &nbs= p; +--> Type =3D sec_header
=0A>    (*) if MAC addres b= it is '0'
=0A>
=0A>
=0A>-  The SEC_Header would be=0A>    +---+---+---+--//  ..... // ----+
=0A>&n= bsp;   |  NH  | L |  security params  |
=0A&g= t;    +---+---+---+--//  ..... // ----+
=0A>
=0A&g= t;    with NH =3D Type of SNDU payload (IP, IPv6, ...)
=0A>= ;          L  =3D Length of SEC_Header
=0A= >
=0A>    security params will define key material, typ= e of security
=0A>    (encryption, authentication, ....), = algo, whatever ...
=0A>
=0A>    In the extension hea= ders I proposed, the SEC_Header would be one
=0A>    of th= e "drop packets if unknown"  type.
=0A>
=0A>&nbs= p; - The SNDU payload woul be clear/encrypt/padded accordingly to what
= =0A>    params will be found in SEC_Header.
=0A>
=0A= >With that approach, the only thing needed is to include the Extension=0A>Headers mechanism definition in the ULE base specs. Then ALL that<= BR>=0A>SEC_Header stuff can be described in a separate doc, and good luc= k with
=0A>the (re)keying framework/protocols, security analysis ...<= BR>=0A>
=0A>Regards.
=0A>Alain.
=0A>--
=0A>Alain= RITOUX
=0A>Tel +33-1-39-30-92-32
=0A>Fax +33-1-39-30-92-11
= =0A>visit our web http://www.6wind.com
=0A>
=0A>
=0A><= BR>=0A>
=0A>
=0A>
=0A>T. Zein
=0A>
=0A>ALC= ATEL SPACE
=0A>DRT/RST  --  Ing=E9nieur Syst=E8mes
=0A&g= t;Tel : 0534356918  /  Fax : 0534355560
=0A>Porte : W.220=0A>
=0A>
=0A>
=0A>
=0A=0A

=0A

=0A= =0A --Next_1077867426---0-203.199.83.246-18543 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi everyone,=0A I like to support for the requirement of Encryption/securit= y at L2 with in satellite network(Terminal and Gateway) for any confidentia= l informations, both signaling and data packets.=0A=0AFurther to the extens= ion header for ULE, =0Ait can be made option as we have for destination mac= address, without effecting any implementation and design =0A=0A- [Dest Ma= c Addr bit][ext. header present bit][ULE_Header] [DVB_MAC*] [Ext. Header*] = [xxx SNDU Payload xxx]=0A=0Awe can change 15 bits of payload length into 14= bits.. which is much more than the present DSMCC payload/section length, w= hich is 12 bits.=0Awith that bit we can define any extension header is pres= ent for any future updations to the ULE, =0Athe Ext. Header is defined as= =0A +---+--------+---// ..... // ----+=0A |EHT| NHB & L| Ext.Header pa= rams |=0A +---+--------+---// ..... // ----+=0A =0A where, EHT =3D = 1 byte of extension header type field. Which has to be defined, might be UL= E specific.=0A L =3D LSB 7 bit of ext. header parameter length, = i.e. supports 127 bytes.=0A NHB =3D MSB 1 bit contains if there is= any other extension header present.=0A Ext.Header params =3D variable le= ngth based on the ext. header parameter length.=0A=0ABest Regards,=0AWillia= m.=0A=0A=0AOn Thu, 26 Feb 2004 Tarif.Zein-Alabedeen@space.alcatel.fr wrote = :=0A>=0A>=0A>Hi alain and every body=0A>Concerning point I, let me go back = to dvb-rcs : encryption at the=0A>encapsulation layer=0A>(which is now MPE = but may become ULE in the future) has been provisioned=0A>and the way it is= =0A>controlled by the 2 bits field in the MPE header has been clearly speci= fied=0A>(see my precedent mail)=0A>=0A>I am not aware of the exact reasons = which led poeple who contributed to the=0A>dvb-rcs definition to do this=0A= >may be they did something wrong or expected a functionnality that will=0A>= never be used....!!!!=0A>But it is more probable that they had real reasons= to do this (so we can=0A>avoid to reinvent the wheel as you said)=0A>Any o= ne has an idea?=0A>=0A>I see an example which could make case 3 difficult t= o apply. It concerns=0A>bridging=0A>When forwarding (in the Gateway for exa= mple) is performed by bridging (as=0A>in Ethernet switches) and not by rout= ing (as routers),=0A>IPsec can not apply because the GW handles frames and = not datagrams (am I=0A>wrong?). Such case may happen with e.g a PPPOE acces= s scheme.=0A>So if IPsec is not applied end-to-end (but this can not be con= trolled by=0A>the satellite segment), traffic will be transmitted clear on = the=0A>sat interface=0A>=0A>Concerning the use of the extension header, the= main question is : when=0A>encryption is applied at ULE level, do we need = the encryption control field=0A>in all SNDUs or not. If yes, the extension = header solution may turn to be=0A>inefficient since it would lead to about = 5 bytes extra header (taking your=0A>example below). I submitted this quest= ion to Alcatel's security experts but=0A>would be great if others in this = groupe could also think about it and make=0A>suggestions=0A>=0A>regards=0A>= =0A>=0A>=0A>=0A>=0A>Alain RITOUX @erg.abdn.ac.uk on= 26/02/2004 15:25:15=0A>=0A>Veuillez r=E9pondre =E0 ip-dvb@erg.abdn.ac.uk= =0A>=0A>Envoy=E9 par : owner-ip-dvb@erg.abdn.ac.uk=0A>=0A>=0A>Pour : I= PDVB =0A>cc :=0A>Objet : Re: Encryption control = of SNDU=0A>=0A>=0A>=0A>=0A>Gorry Fairhurst wrote:=0A>=0A> > So, I'm trying = to build a list of "issues for ULE" and the questions I=0A>have=0A> > are:= =0A> >=0A> > (i) Does the proposed ULE base header format (4/12B of header)= need to be=0A> > changed to support any required encryption/scrambling?=0A= > >=0A> > Possible answers include:=0A> >=0A> > * Yes - because the ULE hea= der must not be increased when=0A> > link encryption is used.=0A> >=0A>= > * No - because the ULE header can specify a TYPE that could=0A> > in= dicate an encrypted payload, and hence this issue=0A> > could be solved= by using an extension header of some form.=0A> >=0A> > If it is YES, then = this has design implications for the ULE Spec.=0A>=0A>I would say No, becau= se :=0A> - I don't really understand the need for ULE level encryption= =0A> see point I)=0A> - If needed, it can be separated from ULE bas= e specs. see point II)=0A>=0A>I) Why ULE level encryption ?=0A>=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= =0A>I still don't sse the need for an ULE-level encryption, because=0A>I se= e 3 possibilities of encryption=0A>1) At MPEG-2 level, i.e. same encryption= for whole content of a PID=0A>2) At ULE level, i.e. encryption on a per SN= DU basis for the case as=0A> Tarif said, where PID is mutli-receiver (bel= onging to different groups)=0A>3) At IP level=0A>=0A>but what can distingui= sh 2 SNDU ?=0A> - IP addresses ?=0A> - DVB Mac addr ?=0A>But the DVB = Mac addr is itself the result of IP address/prefix=0A>resolution (which can= use destination and/or sources)=0A>So I think it can all be expresed in te= rm of either destination and/or=0A>source Addresses, which can perfectly be= handled by IPsec. So 2) and 3)=0A>seem to me to offer the same granularity= and 3) is already defined and=0A>working.=0A>=0A>This is my current unders= tanding, and a counter-example where 2) would=0A>solve a use-case and not = 3) would be very helpfull.=0A>Anyway, I may have missed something, so :=0A>= =0A>II) Etxension Header for Encryption=0A>=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=0A>*IF* an ULE encryption is needed, then some extension header can be= =0A>defined to provide it, so the SNDU would be like :=0A>=0A>- [ULE_Heade= r] [DVB_MAC*] [SEC_Header] [xxx SNDU Payload xxx]=0A> |=0A> = +--> Type =3D sec_header=0A> (*) if MAC addres bit is '0'=0A>=0A>=0A= >- The SEC_Header would be=0A> +---+---+---+--// ..... // ----+=0A> = | NH | L | security params |=0A> +---+---+---+--// ..... // --= --+=0A>=0A> with NH =3D Type of SNDU payload (IP, IPv6, ...)=0A> = L =3D Length of SEC_Header=0A>=0A> security params will define key = material, type of security=0A> (encryption, authentication, ....), algo= , whatever ...=0A>=0A> In the extension headers I proposed, the SEC_Hea= der would be one=0A> of the "drop packets if unknown" type.=0A>=0A> = - The SNDU payload woul be clear/encrypt/padded accordingly to what=0A> = params will be found in SEC_Header.=0A>=0A>With that approach, the only th= ing needed is to include the Extension=0A>Headers mechanism definition in t= he ULE base specs. Then ALL that=0A>SEC_Header stuff can be described in a = separate doc, and good luck with=0A>the (re)keying framework/protocols, sec= urity analysis ...=0A>=0A>Regards.=0A>Alain.=0A>--=0A>Alain RITOUX=0A>Tel += 33-1-39-30-92-32=0A>Fax +33-1-39-30-92-11=0A>visit our web http://www.6wind= .com=0A>=0A>=0A>=0A>=0A>=0A>=0A>T. Zein=0A>=0A>ALCATEL SPACE=0A>DRT/RST --= Ing=E9nieur Syst=E8mes=0A>Tel : 0534356918 / Fax : 0534355560=0A>Porte = : W.220=0A>=0A>=0A>=0A>=0A --Next_1077867426---0-203.199.83.246-18543-- From owner-ip-dvb@erg.abdn.ac.uk Fri Feb 27 07:23:05 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1R7MFjs028865 for ; Fri, 27 Feb 2004 07:22:15 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1R7MFUv028864 for ip-dvb-subscribed-users; Fri, 27 Feb 2004 07:22:15 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from proxy.6wind.com (proxy.ipv6.6wind.com [194.250.197.211]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1R7LOdN028829 for ; Fri, 27 Feb 2004 07:21:29 GMT Received: from eagle.6wind.com (givenchy.6wind.com [212.234.238.114]) by proxy.6wind.com (Postfix) with ESMTP id E567E73A for ; Fri, 27 Feb 2004 08:21:12 +0100 (CET) Received: from 6wind.com (unknown [10.16.0.135]) by eagle.6wind.com (Postfix) with ESMTP id 8FB481EC for ; Fri, 27 Feb 2004 08:21:12 +0100 (CET) Message-ID: <403EF0E0.6020506@6wind.com> Date: Fri, 27 Feb 2004 08:25:20 +0100 From: alain.ritoux@6wind.com 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: undisclosed-recipients: ; Subject: Re: =?ISO-8859-1?Q?R=E9f=2E_=3A_Re=3A_Encryption_control?= =?ISO-8859-1?Q?_of_SNDU?= References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Dear Laurent and all, Not being a satcom expert I cannot argue the L2 security details, but I do understanf your concern. But some precision need to be done about the IPsec "drawbacks" paragraph Laurent.Claverotte@space.alcatel.fr wrote: > ... snip > > 2. Solutions comparison > > ... snip > - IPSec has lot of drawbacks : it is not a L2 solution, it is an > end-to-end technology, it can interfere with the end-to-end security > solution, it can interfere with satellite techniques (PEP), it does not > provide encryption of multicast flows and it generates many overheads and > number of signaling messages!!!!!! Lots of comparison studies and > simulations have been performed by Alcatel leading to reject this > solution!! * It is not an L2 solution : well, some might see it a a plus. end of religious debate ;-) * its is an end-to-end technology No, It can support end-to-end security (I mean host-to-host), but the tunnel mode is available for security gateways, hence allowing securisation of part of the total path. for exemple between the DVB sender, and the DVB receiver (even if it is a host and not a router it can behave as a security gateway for himself). * it can interfere with end-to-end security solution ??? I don't understand the argument : It is a solution, that works at IP level, in both end-to-end model or gateway-to-gateway model. Both models can be used simultaneously, while working over a secure L2, for transporting SSL ... I see no contradiction. * it can interfere with satellite techniques (PEP) Could you elaborate, because all it does it take an IP packet and generate one other IP packet. How can satellite technique interfere without messing into IP level? * multicast : Indeed it does not protect multicast yet, but work is in progress. if there is an easy solution to key distribution, the msec IETF wg should be informed * it generates overhead : Yes there is overhead, but I don't really see fields in AH/ESP that are unncessary. * many signalling messages : I thnk you refer here to IKE. Of course some messages are exchanged for key negociation, but I think it is the price for dynamic keying. L2 securisation with dynamic keying will allso generate messages exchanges. Anyway, those exchanges are done for each IPsec tunnel, and once done have generated key whose lifetime can be chosen (in term of duration and/or tarfic volume), so the overhead relatively to the global volume should be quite small. Are those Alcatel comparison studies and/or simulations available somewhere, could be interesting. Regards. Alain. -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com From owner-ip-dvb@erg.abdn.ac.uk Fri Feb 27 07:40:05 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1R7cZRT029470 for ; Fri, 27 Feb 2004 07:38:35 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1R7cZWm029469 for ip-dvb-subscribed-users; Fri, 27 Feb 2004 07:38:35 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from rediffmail.com (webmail36.rediffmail.com [203.199.83.248] (may be forged)) by erg.abdn.ac.uk (8.12.11/8.12.11) with SMTP id i1R7bFEL029402 for ; Fri, 27 Feb 2004 07:37:16 GMT Received: (qmail 25994 invoked by uid 510); 27 Feb 2004 07:36:30 -0000 Date: 27 Feb 2004 07:36:30 -0000 Message-ID: <20040227073630.25988.qmail@webmail36.rediffmail.com> Received: from unknown (203.197.138.199) by rediffmail.com via HTTP; 27 feb 2004 07:36:29 -0000 MIME-Version: 1.0 From: "William StanisLaus" To: ip-dvb@erg.abdn.ac.uk Cc: Tarif.Zein-Alabedeen@space.alcatel.fr Subject: =?iso-8859-1?Q?Re:_R=E9f=2E_:_Re:_Encryption_control_of_SNDU?= Content-type: multipart/alternative; boundary="Next_1077867389---0-203.199.83.248-25971" X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk This is a multipart mime message --Next_1077867389---0-203.199.83.248-25971 Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

=0AHi everyone,
=0A     I like to support for the requ= irement of Encryption/security at L2 with in satellite network(Terminal and= Gateway) for any confidential informations, both signaling and data packet= s.
=0A
=0AFurther to the extension header for ULE,
=0Ait can be m= ade option as we have for destination mac address, without effecting any im= plementation and design
=0A
=0A-  [Dest Mac Addr bit][ext. head= er present bit][ULE_Header] [DVB_MAC*] [Ext. Header*] [xxx SNDU Payload xxx= ]
=0A
=0Awe can change 15 bits of payload length into 14 bits.. which= is much more than the present DSMCC payload/section length, which is 12 bi= ts.
=0Awith that bit we can define any extension header is present for a= ny future updations to the ULE,
=0Athe Ext. Header is defined as
=0A=   +---+--------+---//  ..... // ----+
=0A  |EHT| NHB &a= mp; L| Ext.Header params  |
=0A  +---+--------+---//  ..= ... // ----+
=0A 
=0A  where, EHT =3D 1 byte of extensio= n header type field. Which has to be defined, might be ULE specific.
=0A=           L  =3D LSB 7 bit of ext. header pa= rameter length, i.e. supports 127 bytes.
=0A        =   NHB =3D MSB 1 bit contains if there is any other extension header pr= esent.
=0A       Ext.Header params =3D variable leng= th based on the ext. header parameter length.
=0A
=0ABest Regards,=0AWilliam.
=0A
=0A
=0AOn Thu, 26 Feb 2004 Tarif.Zein-Alabedeen@s= pace.alcatel.fr wrote :
=0A>
=0A>
=0A>Hi alain and every = body
=0A>Concerning point I, let me go back to dvb-rcs : encryption a= t the
=0A>encapsulation layer
=0A>(which is now MPE but may bec= ome ULE in the future) has been provisioned
=0A>and the way it is
= =0A>controlled by the 2 bits field in the MPE header has been clearly sp= ecified
=0A>(see my precedent mail)
=0A>
=0A>I am not awa= re of the exact reasons which led poeple who contributed to the
=0A>d= vb-rcs definition to do this
=0A>may be they did something wrong or e= xpected a functionnality that will
=0A>never be used....!!!!
=0A&g= t;But it is more probable that they had real reasons to do this (so we can<= BR>=0A>avoid to reinvent the wheel as you said)
=0A>Any one has an= idea?
=0A>
=0A>I see an example which could make case 3 diffic= ult to apply. It concerns
=0A>bridging
=0A>When forwarding (in = the Gateway for example) is performed by bridging (as
=0A>in Ethernet= switches) and not by routing (as routers),
=0A>IPsec can not apply b= ecause the GW handles frames and not datagrams (am I
=0A>wrong?). Suc= h case may happen with e.g a PPPOE access scheme.
=0A>So if IPsec is = not applied end-to-end (but this can not be controlled by
=0A>the sat= ellite segment), traffic will be transmitted clear on the
=0A>sat int= erface
=0A>
=0A>Concerning the use of the extension header, the= main question is : when
=0A>encryption is applied at ULE level, do w= e need the encryption control field
=0A>in all SNDUs or not. If yes, = the extension header solution may turn to be
=0A>inefficient since it= would lead to about 5 bytes extra header (taking your
=0A>example be= low). I submitted this question to Alcatel's security experts but
=0A>= ;would be great  if others in this groupe could also think about it an= d make
=0A>suggestions
=0A>
=0A>regards
=0A>
=0A= >
=0A>
=0A>
=0A>
=0A>Alain RITOUX <alain.rito= ux@6wind.com>@erg.abdn.ac.uk on 26/02/2004 15:25:15
=0A>
=0A>= ;Veuillez r=E9pondre =E0 ip-dvb@erg.abdn.ac.uk
=0A>
=0A>Envoy= =E9 par :      owner-ip-dvb@erg.abdn.ac.uk
=0A>
=0A= >
=0A>Pour : IPDVB <ip-dvb@erg.abdn.ac.uk>
=0A>cc :=0A>Objet :    Re: Encryption control of SNDU
=0A>
= =0A>
=0A>
=0A>
=0A>Gorry Fairhurst wrote:
=0A>=0A> > So, I'm trying to build a list of "issues for ULE"= and the questions I
=0A>have
=0A> > are:
=0A> >=0A> > (i) Does the proposed ULE base header format (4/12B of header= ) need to be
=0A> > changed to support any required encryption/scr= ambling?
=0A> >
=0A> > Possible answers include:
=0A&g= t; >
=0A> > * Yes - because the ULE header must not be increase= d when
=0A> >    link encryption is used.
=0A> &g= t;
=0A> > * No - because the ULE header can specify a TYPE that co= uld
=0A> >    indicate an encrypted payload, and hence = this issue
=0A> >    could be solved by using an extens= ion header of some form.
=0A> >
=0A> > If it is YES, then= this has design implications for the ULE Spec.
=0A>
=0A>I woul= d say No, because :
=0A>    - I don't really understand the= need for ULE level encryption
=0A>      see point I)<= BR>=0A>    - If needed, it can be separated from ULE base spec= s. see point II)
=0A>
=0A>I) Why ULE level encryption ?
=0A&= gt;=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
=0A>I still don't sse the need for an ULE-level encry= ption, because
=0A>I see 3 possibilities of encryption
=0A>1) A= t MPEG-2 level, i.e. same encryption for whole content of a PID
=0A>2= ) At ULE level, i.e. encryption on a per SNDU basis for the case as
=0A&= gt;  Tarif said, where PID is mutli-receiver (belonging to different = groups)
=0A>3) At IP level
=0A>
=0A>but what can distingu= ish 2 SNDU ?
=0A>    - IP addresses ?
=0A>  &nbs= p; - DVB Mac addr ?
=0A>But the DVB Mac addr is itself the result of = IP address/prefix
=0A>resolution (which can use destination and/or so= urces)
=0A>So I think it can all be expresed in term of either destin= ation and/or
=0A>source Addresses, which can perfectly be handled by = IPsec. So 2) and 3)
=0A>seem to me to offer the same granularity and = 3) is already defined and
=0A>working.
=0A>
=0A>This is m= y current understanding,  and a counter-example where 2) would
=0A&= gt;solve a use-case and not 3) would be very helpfull.
=0A>Anyway, I = may have missed something, so :
=0A>
=0A>II) Etxension Header f= or Encryption
=0A>=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
=0A>*IF* an= ULE encryption is needed, then some extension header can be
=0A>defi= ned to provide it, so the SNDU would be like :
=0A>
=0A>- = [ULE_Header] [DVB_MAC*] [SEC_Header] [xxx SNDU Payload xxx]
=0A>&nbs= p;         |
=0A>        &nbs= p; +--> Type =3D sec_header
=0A>    (*) if MAC addres b= it is '0'
=0A>
=0A>
=0A>-  The SEC_Header would be=0A>    +---+---+---+--//  ..... // ----+
=0A>&n= bsp;   |  NH  | L |  security params  |
=0A&g= t;    +---+---+---+--//  ..... // ----+
=0A>
=0A&g= t;    with NH =3D Type of SNDU payload (IP, IPv6, ...)
=0A>= ;          L  =3D Length of SEC_Header
=0A= >
=0A>    security params will define key material, typ= e of security
=0A>    (encryption, authentication, ....), = algo, whatever ...
=0A>
=0A>    In the extension hea= ders I proposed, the SEC_Header would be one
=0A>    of th= e "drop packets if unknown"  type.
=0A>
=0A>&nbs= p; - The SNDU payload woul be clear/encrypt/padded accordingly to what
= =0A>    params will be found in SEC_Header.
=0A>
=0A= >With that approach, the only thing needed is to include the Extension=0A>Headers mechanism definition in the ULE base specs. Then ALL that<= BR>=0A>SEC_Header stuff can be described in a separate doc, and good luc= k with
=0A>the (re)keying framework/protocols, security analysis ...<= BR>=0A>
=0A>Regards.
=0A>Alain.
=0A>--
=0A>Alain= RITOUX
=0A>Tel +33-1-39-30-92-32
=0A>Fax +33-1-39-30-92-11
= =0A>visit our web http://www.6wind.com
=0A>
=0A>
=0A><= BR>=0A>
=0A>
=0A>
=0A>T. Zein
=0A>
=0A>ALC= ATEL SPACE
=0A>DRT/RST  --  Ing=E9nieur Syst=E8mes
=0A&g= t;Tel : 0534356918  /  Fax : 0534355560
=0A>Porte : W.220=0A>
=0A>
=0A>
=0A>
=0A=0A

=0A

=0A= =0A --Next_1077867389---0-203.199.83.248-25971 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi everyone,=0A I like to support for the requirement of Encryption/securit= y at L2 with in satellite network(Terminal and Gateway) for any confidentia= l informations, both signaling and data packets.=0A=0AFurther to the extens= ion header for ULE, =0Ait can be made option as we have for destination mac= address, without effecting any implementation and design =0A=0A- [Dest Ma= c Addr bit][ext. header present bit][ULE_Header] [DVB_MAC*] [Ext. Header*] = [xxx SNDU Payload xxx]=0A=0Awe can change 15 bits of payload length into 14= bits.. which is much more than the present DSMCC payload/section length, w= hich is 12 bits.=0Awith that bit we can define any extension header is pres= ent for any future updations to the ULE, =0Athe Ext. Header is defined as= =0A +---+--------+---// ..... // ----+=0A |EHT| NHB & L| Ext.Header pa= rams |=0A +---+--------+---// ..... // ----+=0A =0A where, EHT =3D = 1 byte of extension header type field. Which has to be defined, might be UL= E specific.=0A L =3D LSB 7 bit of ext. header parameter length, = i.e. supports 127 bytes.=0A NHB =3D MSB 1 bit contains if there is= any other extension header present.=0A Ext.Header params =3D variable le= ngth based on the ext. header parameter length.=0A=0ABest Regards,=0AWillia= m.=0A=0A=0AOn Thu, 26 Feb 2004 Tarif.Zein-Alabedeen@space.alcatel.fr wrote = :=0A>=0A>=0A>Hi alain and every body=0A>Concerning point I, let me go back = to dvb-rcs : encryption at the=0A>encapsulation layer=0A>(which is now MPE = but may become ULE in the future) has been provisioned=0A>and the way it is= =0A>controlled by the 2 bits field in the MPE header has been clearly speci= fied=0A>(see my precedent mail)=0A>=0A>I am not aware of the exact reasons = which led poeple who contributed to the=0A>dvb-rcs definition to do this=0A= >may be they did something wrong or expected a functionnality that will=0A>= never be used....!!!!=0A>But it is more probable that they had real reasons= to do this (so we can=0A>avoid to reinvent the wheel as you said)=0A>Any o= ne has an idea?=0A>=0A>I see an example which could make case 3 difficult t= o apply. It concerns=0A>bridging=0A>When forwarding (in the Gateway for exa= mple) is performed by bridging (as=0A>in Ethernet switches) and not by rout= ing (as routers),=0A>IPsec can not apply because the GW handles frames and = not datagrams (am I=0A>wrong?). Such case may happen with e.g a PPPOE acces= s scheme.=0A>So if IPsec is not applied end-to-end (but this can not be con= trolled by=0A>the satellite segment), traffic will be transmitted clear on = the=0A>sat interface=0A>=0A>Concerning the use of the extension header, the= main question is : when=0A>encryption is applied at ULE level, do we need = the encryption control field=0A>in all SNDUs or not. If yes, the extension = header solution may turn to be=0A>inefficient since it would lead to about = 5 bytes extra header (taking your=0A>example below). I submitted this quest= ion to Alcatel's security experts but=0A>would be great if others in this = groupe could also think about it and make=0A>suggestions=0A>=0A>regards=0A>= =0A>=0A>=0A>=0A>=0A>Alain RITOUX @erg.abdn.ac.uk on= 26/02/2004 15:25:15=0A>=0A>Veuillez r=E9pondre =E0 ip-dvb@erg.abdn.ac.uk= =0A>=0A>Envoy=E9 par : owner-ip-dvb@erg.abdn.ac.uk=0A>=0A>=0A>Pour : I= PDVB =0A>cc :=0A>Objet : Re: Encryption control = of SNDU=0A>=0A>=0A>=0A>=0A>Gorry Fairhurst wrote:=0A>=0A> > So, I'm trying = to build a list of "issues for ULE" and the questions I=0A>have=0A> > are:= =0A> >=0A> > (i) Does the proposed ULE base header format (4/12B of header)= need to be=0A> > changed to support any required encryption/scrambling?=0A= > >=0A> > Possible answers include:=0A> >=0A> > * Yes - because the ULE hea= der must not be increased when=0A> > link encryption is used.=0A> >=0A>= > * No - because the ULE header can specify a TYPE that could=0A> > in= dicate an encrypted payload, and hence this issue=0A> > could be solved= by using an extension header of some form.=0A> >=0A> > If it is YES, then = this has design implications for the ULE Spec.=0A>=0A>I would say No, becau= se :=0A> - I don't really understand the need for ULE level encryption= =0A> see point I)=0A> - If needed, it can be separated from ULE bas= e specs. see point II)=0A>=0A>I) Why ULE level encryption ?=0A>=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= =0A>I still don't sse the need for an ULE-level encryption, because=0A>I se= e 3 possibilities of encryption=0A>1) At MPEG-2 level, i.e. same encryption= for whole content of a PID=0A>2) At ULE level, i.e. encryption on a per SN= DU basis for the case as=0A> Tarif said, where PID is mutli-receiver (bel= onging to different groups)=0A>3) At IP level=0A>=0A>but what can distingui= sh 2 SNDU ?=0A> - IP addresses ?=0A> - DVB Mac addr ?=0A>But the DVB = Mac addr is itself the result of IP address/prefix=0A>resolution (which can= use destination and/or sources)=0A>So I think it can all be expresed in te= rm of either destination and/or=0A>source Addresses, which can perfectly be= handled by IPsec. So 2) and 3)=0A>seem to me to offer the same granularity= and 3) is already defined and=0A>working.=0A>=0A>This is my current unders= tanding, and a counter-example where 2) would=0A>solve a use-case and not = 3) would be very helpfull.=0A>Anyway, I may have missed something, so :=0A>= =0A>II) Etxension Header for Encryption=0A>=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=0A>*IF* an ULE encryption is needed, then some extension header can be= =0A>defined to provide it, so the SNDU would be like :=0A>=0A>- [ULE_Heade= r] [DVB_MAC*] [SEC_Header] [xxx SNDU Payload xxx]=0A> |=0A> = +--> Type =3D sec_header=0A> (*) if MAC addres bit is '0'=0A>=0A>=0A= >- The SEC_Header would be=0A> +---+---+---+--// ..... // ----+=0A> = | NH | L | security params |=0A> +---+---+---+--// ..... // --= --+=0A>=0A> with NH =3D Type of SNDU payload (IP, IPv6, ...)=0A> = L =3D Length of SEC_Header=0A>=0A> security params will define key = material, type of security=0A> (encryption, authentication, ....), algo= , whatever ...=0A>=0A> In the extension headers I proposed, the SEC_Hea= der would be one=0A> of the "drop packets if unknown" type.=0A>=0A> = - The SNDU payload woul be clear/encrypt/padded accordingly to what=0A> = params will be found in SEC_Header.=0A>=0A>With that approach, the only th= ing needed is to include the Extension=0A>Headers mechanism definition in t= he ULE base specs. Then ALL that=0A>SEC_Header stuff can be described in a = separate doc, and good luck with=0A>the (re)keying framework/protocols, sec= urity analysis ...=0A>=0A>Regards.=0A>Alain.=0A>--=0A>Alain RITOUX=0A>Tel += 33-1-39-30-92-32=0A>Fax +33-1-39-30-92-11=0A>visit our web http://www.6wind= .com=0A>=0A>=0A>=0A>=0A>=0A>=0A>T. Zein=0A>=0A>ALCATEL SPACE=0A>DRT/RST --= Ing=E9nieur Syst=E8mes=0A>Tel : 0534356918 / Fax : 0534355560=0A>Porte = : W.220=0A>=0A>=0A>=0A>=0A --Next_1077867389---0-203.199.83.248-25971-- From owner-ip-dvb@erg.abdn.ac.uk Fri Feb 27 08:07:05 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1R84hqS000420 for ; Fri, 27 Feb 2004 08:04:43 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1R84hcB000417 for ip-dvb-subscribed-users; Fri, 27 Feb 2004 08:04:43 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from [10.0.1.108] (maxp4.abdn.ac.uk [139.133.7.163]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1R80dtT000251 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 27 Feb 2004 08:00:43 GMT User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Fri, 27 Feb 2004 07:53:28 +0000 Subject: Re: Encryption control of SNDU From: Gorry Fairhurst To: Message-ID: In-Reply-To: <403E01CB.3000301@6wind.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-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Thanks Alain for the example "extension format" - I like the idea you put forward of extension headers for optional items, the the Receiver *may* wish to use to enhance processing - this can be very powerful, particularly with unidirectional and/or multipoint feeds, and avoids explicit configuration for each Receiver. - But I think the encryption information is mandatory to processing the SNDU, so an alternate way to extend the header would be to assign one (or a block of several contiguous) codepoints from the TYPE field. This could be more efficient to implement, and would carry the same semantics as other packet types - i.e. The type field indicates how to demultiplex the PDU. An example could be: < ----------------------------- SNDU ----------------------------- > +-+-------------------------------------------------------+--------+ |D| Length | ENC |ETYPE | PDU | CRC-32 | +-+-------------------------------------------------------+--------+ Where ENC = a predefined 2B TYPE value, and ETYPE is the 2B type field Corresponding to the PDU. Several ENC values could be specified. Additional overhead = 2B. If necessary, one or more bytes could be added between ENC and ETYPE, It would be useful to think if these were desirable i.e. could assist security decoding (or not). So, I'm saying is: (i) We now have two ways to extend ULE, we need to see which is most appropriate, and for what. (ii) The part of the text that I cut is equally important, we need inputs on *WHY* and *HOW* the encryption should be done. Gorry Fairhurst. On 26/2/04 2:25 pm, "Alain RITOUX" wrote: > > > Gorry Fairhurst wrote: > >> So, I'm trying to build a list of "issues for ULE" and the questions I have >> are: >> >> (i) Does the proposed ULE base header format (4/12B of header) need to be >> changed to support any required encryption/scrambling? >> >> Possible answers include: > Anyway, I may have missed something, so : > > II) Etxension Header for Encryption > ==================================== > *IF* an ULE encryption is needed, then some extension header can be > defined to provide it, so the SNDU would be like : > > - [ULE_Header] [DVB_MAC*] [SEC_Header] [xxx SNDU Payload xxx] > | > +--> Type = sec_header > (*) if MAC addres bit is '0' > > > - The SEC_Header would be > +---+---+---+--// ..... // ----+ > | NH | L | security params | > +---+---+---+--// ..... // ----+ > > with NH = Type of SNDU payload (IP, IPv6, ...) > L = Length of SEC_Header > > security params will define key material, type of security > (encryption, authentication, ....), algo, whatever ... > > In the extension headers I proposed, the SEC_Header would be one > of the "drop packets if unknown" type. > > - The SNDU payload woul be clear/encrypt/padded accordingly to what > params will be found in SEC_Header. > > With that approach, the only thing needed is to include the Extension > Headers mechanism definition in the ULE base specs. Then ALL that > SEC_Header stuff can be described in a separate doc, and good luck with > the (re)keying framework/protocols, security analysis ... > > Regards. > Alain. From owner-ip-dvb@erg.abdn.ac.uk Fri Feb 27 08:37:48 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1R8b9cb001498 for ; Fri, 27 Feb 2004 08:37:09 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1R8b9QK001497 for ip-dvb-subscribed-users; Fri, 27 Feb 2004 08:37:09 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from mgfr2.nagra.fr ([194.3.26.9]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1R8Uqjq001272 for ; Fri, 27 Feb 2004 08:30:55 GMT Received: from servmgap05.mg.k.grp ([10.2.4.221]) by mgfr2.nagra.fr (8.12.10/8.12.10) with ESMTP id i1R8UfVv003908 for ; Fri, 27 Feb 2004 09:30:43 +0100 (MET) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3FD0B.FABE3D68" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: =?iso-8859-1?Q?RE=3A_R=E9f=2E_=3A_Re=3A_Encryption_control_of_SNDU?= Date: Fri, 27 Feb 2004 09:30:38 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: =?iso-8859-1?Q?R=E9f=2E_=3A_Re=3A_Encryption_control_of_SNDU?= Thread-Index: AcP8kLHXZ41/NKhxS9ec4lXH+FGT+wAeEeGg From: "Wendling Bertrand" To: X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3FD0B.FABE3D68 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Laurent, In your mail you wrote : Moreover, key distribution techniques are one way only and does not = benefit from the interactive return link. I cannot agree with you, CA systems for Broadcast TV take since years = benefit from interactive return link for key distribution (individual = addressing base).=20 Regards Bertrand =20 =20 -----Original Message----- From: owner-ip-dvb@erg.abdn.ac.uk [ = mailto:owner-ip-dvb@erg.abdn.ac.uk]On Behalf Of Laurent.Claverotte@space.alcatel.fr Sent: Thursday, February 26, 2004 6:11 PM To: ip-dvb@erg.abdn.ac.uk Subject: R=E9f. : Re: Encryption control of SNDU Importance: Low Dear All, I am working on layer 2 security solution for broadband satellite = systems based on the DVB-RCS standard (part 9.4 of the EN301790) and I see = several advantages for an ULE-level encryption as explained below. Why ULE level encryption ? 1. Role Model and security requirements Satcom systems based on DVB-S/DVB-RCS are operated by Access Network Operators that want to provide their customers (ISP) with security services. Common targeted security services are : terminal authentication and data confidentiality (for the unicast and multicast streams) between the = gateway and the terminals (also limited to the satcom system). The objective is to provide the same level of privacy as the terrestrial links. Moreover, in the same time, the ISP may want to provide end-to-end = security services to the end-users (based on the well known IPSec). As a matter, I think this is really important to understand that both security solutions ((ANO to ISP) and (ISP to End-users)) can co-exist = and are economically viable. 2. Solutions comparison For the end-to-end security solution between the ISP and the end-users, = it is obvious that IPSec or an application security (TLS or SSL) are = largely deployed and accepted by the telecom world. Regarding the satcom security (between the gateway and the terminals), different solutions were envisaged by Alcatel Space : - DVB-S Common Scrambling (security solution deployed for the digital broadcast television) : this solution is not compliant to the = granularity security requirement (scrambling per PID and not per unicast user!). Moreover, key distribution techniques are one way only and does not = benefit from the interactive return link. - IPSec has lot of drawbacks : it is not a L2 solution, it is an end-to-end technology, it can interfere with the end-to-end security solution, it can interfere with satellite techniques (PEP), it does not provide encryption of multicast flows and it generates many overheads = and number of signaling messages!!!!!! Lots of comparison studies and simulations have been performed by Alcatel leading to reject this solution!! - Proprietary solutions close to the DVB-S CS : same conclusion as DVB-S = CS - DVB-RCS security solution : we believe that it is the most interesting solution regarding the intrinsic satcom security as it complies with = the ANO security requirements. Indeed, it is a layer 2 solution (control plane defined in the DVB-RCS standard and traffic plane below the IP layer) enabling to encrypt not = only IP streams but also Ethernet frames (PPPoE for example) or other protocols... It can support unicast or multicast streams encryption. Moreover, regarding the performances, It largely reduces the number of signaling messages and overheads (main worry in satcom!). It is currently based on the 2 bits payload_scrambling_control of the = MPE header providing the information if the packet is encrypted or not and = with which key (odd or even)...... and this essential information would be canceled in the ULE definition. 3. Concurrent systems and standardization As you know, the main concurrent to the european ETSI DVB-S/DVB-RCS standards is the US DOCSIS standard that includes (in its baseline!!!) a layer 2 security solution providing terminal authentication and confidentiality (called BPI+). Alcatel believes that it is really important to make the DVB-RCS = standard evolve (current Satlab contributions) to offer a complete DVB-RCS = security solution that can be compared to the US DOCSIS standard. That would really be worrying if the ULE encapsulation could not include this feature because it would not be compliant with the DVB-RCS security solution. I hope that you will understand my concern. Regards. Laurent Claverotte Alain RITOUX @erg.abdn.ac.uk on 26/02/2004 = 15:25:15 Veuillez r=E9pondre =E0 ip-dvb@erg.abdn.ac.uk Envoy=E9 par : owner-ip-dvb@erg.abdn.ac.uk Pour : IPDVB cc : Objet : Re: Encryption control of SNDU Gorry Fairhurst wrote: > So, I'm trying to build a list of "issues for ULE" and the questions I have > are: > > (i) Does the proposed ULE base header format (4/12B of header) need to = be > changed to support any required encryption/scrambling? > > Possible answers include: > > * Yes - because the ULE header must not be increased when > link encryption is used. > > * No - because the ULE header can specify a TYPE that could > indicate an encrypted payload, and hence this issue > could be solved by using an extension header of some form. > > If it is YES, then this has design implications for the ULE Spec. I would say No, because : - I don't really understand the need for ULE level encryption see point I) - If needed, it can be separated from ULE base specs. see point II) I) Why ULE level encryption ? =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 I still don't sse the need for an ULE-level encryption, because I see 3 possibilities of encryption 1) At MPEG-2 level, i.e. same encryption for whole content of a PID 2) At ULE level, i.e. encryption on a per SNDU basis for the case as Tarif said, where PID is mutli-receiver (belonging to different = groups) 3) At IP level but what can distinguish 2 SNDU ? - IP addresses ? - DVB Mac addr ? But the DVB Mac addr is itself the result of IP address/prefix resolution (which can use destination and/or sources) So I think it can all be expresed in term of either destination and/or source Addresses, which can perfectly be handled by IPsec. So 2) and 3) seem to me to offer the same granularity and 3) is already defined and working. This is my current understanding, and a counter-example where 2) would solve a use-case and not 3) would be very helpfull. Anyway, I may have missed something, so : II) Etxension Header for Encryption =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 *IF* an ULE encryption is needed, then some extension header can be defined to provide it, so the SNDU would be like : - [ULE_Header] [DVB_MAC*] [SEC_Header] [xxx SNDU Payload xxx] | +--> Type =3D sec_header (*) if MAC addres bit is '0' - The SEC_Header would be +---+---+---+--// ..... // ----+ | NH | L | security params | +---+---+---+--// ..... // ----+ with NH =3D Type of SNDU payload (IP, IPv6, ...) L =3D Length of SEC_Header security params will define key material, type of security (encryption, authentication, ....), algo, whatever ... In the extension headers I proposed, the SEC_Header would be one of the "drop packets if unknown" type. - The SNDU payload woul be clear/encrypt/padded accordingly to what params will be found in SEC_Header. With that approach, the only thing needed is to include the Extension Headers mechanism definition in the ULE base specs. Then ALL that SEC_Header stuff can be described in a separate doc, and good luck with the (re)keying framework/protocols, security analysis ... Regards. Alain. -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com Sinc=E8res Salutations / Best regards Laurent Claverotte ALCATEL SPACE DSR/DRE Tel : 33 (0)5.34.35.46.47 / Fax : 33 (0)5.34.35.61.69 E-Mail : Laurent.Claverotte@space.alcatel.fr ------_=_NextPart_001_01C3FD0B.FABE3D68 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear=20 Laurent,
In your mail you wrote :

Moreover, key distribution = techniques are=20 one way only and does not benefit from the interactive return=20 link.
I cannot=20 agree with you, CA systems for Broadcast TV take since years = benefit from=20 interactive return link for key distribution (individual addressing = base).=20
Regards
Bertrand
 
 

-----Original Message-----
From: owner-ip-dvb@erg.abdn.ac.uk = [mailto:owner-ip-dvb@erg.abdn.= ac.uk]On
Behalf=20 Of Laurent.Claverotte@space.alcatel.fr
Sent: Thursday, February 26, = 2004 6:11=20 PM
To: ip-dvb@erg.abdn.ac.uk
Subject: R=E9f. : Re: Encryption = control of=20 SNDU
Importance: Low




Dear All,

I am working = on=20 layer 2 security solution for broadband satellite systems
based on = the=20 DVB-RCS standard (part 9.4 of the EN301790) and I see = several
advantages for=20 an ULE-level encryption as explained below.

Why ULE level = encryption=20 ?
1. Role Model and security requirements
Satcom systems based on=20 DVB-S/DVB-RCS are operated by Access Network
Operators that want to = provide=20 their customers (ISP) with security
services.
Common targeted = security=20 services are : terminal authentication and data
confidentiality (for = the=20 unicast and multicast streams) between the gateway
and the terminals = (also=20 limited to the satcom system).
The objective is to provide the same = level of=20 privacy as the terrestrial
links.
Moreover, in the same time, the = ISP may=20 want to provide end-to-end security
services to the end-users (based = on the=20 well known IPSec).
As a matter, I think this is really important to=20 understand that both
security solutions ((ANO to ISP) and (ISP to = End-users))=20 can co-exist and
are economically viable.

2. Solutions=20 comparison
For the end-to-end security solution between the ISP and = the=20 end-users, it
is obvious that IPSec or an application security (TLS = or SSL)=20 are largely
deployed and accepted by the telecom world.
Regarding = the=20 satcom security (between the gateway and the terminals),
different = solutions=20 were envisaged by Alcatel Space :
- DVB-S Common Scrambling (security = solution deployed for the digital
broadcast television) : this = solution is=20 not compliant to the granularity
security requirement (scrambling per = PID and=20 not per unicast user!).
Moreover, key distribution techniques are one = way=20 only and does not benefit
from the interactive return link.
- = IPSec has=20 lot of drawbacks :  it is not a L2 solution, it is an
end-to-end = technology, it can interfere with the end-to-end security
solution, = it can=20 interfere with satellite techniques (PEP), it does not
provide = encryption=20 of  multicast flows and it generates many overheads and
number = of=20 signaling messages!!!!!! Lots of comparison studies and
simulations = have been=20 performed by Alcatel leading to reject this
solution!!
- = Proprietary=20 solutions close to the DVB-S CS : same conclusion as DVB-S CS
- = DVB-RCS=20 security solution : we believe that it is the most = interesting
solution=20 regarding the intrinsic satcom security as  it complies with = the
ANO=20 security requirements.
Indeed, it is a layer 2 solution (control = plane=20 defined in the DVB-RCS
standard and traffic plane below the IP layer) = enabling to encrypt not only
IP streams but also Ethernet frames = (PPPoE for=20 example) or other
protocols... It can support unicast or multicast = streams=20 encryption.
Moreover, regarding the performances, It largely reduces = the=20 number of
signaling messages and overheads (main worry in = satcom!).
It is=20 currently based on the 2 bits payload_scrambling_control of the = MPE
header=20 providing the information if the packet is encrypted or not and = with
which=20 key (odd or even)...... and this essential information would = be
canceled in=20 the ULE definition.

3. Concurrent systems and = standardization
As you=20 know, the main concurrent to the european ETSI = DVB-S/DVB-RCS
standards is the=20 US DOCSIS standard that includes (in its baseline!!!) a
layer 2 = security=20 solution providing terminal authentication and
confidentiality = (called=20 BPI+).
Alcatel believes that it is really important to make the = DVB-RCS=20 standard
evolve (current Satlab contributions) to offer a complete = DVB-RCS=20 security
solution that can be compared to the US DOCSIS = standard.
That=20 would really be worrying if the ULE encapsulation could not = include
this=20 feature because it would not be compliant with the DVB-RCS=20 security
solution.

I hope that you will understand my=20 concern.
Regards.
Laurent = Claverotte






Alain=20 RITOUX <alain.ritoux@6wind.com>@erg.abdn.ac.uk on 26/02/2004=20 15:25:15

Veuillez r=E9pondre =E0 = ip-dvb@erg.abdn.ac.uk

Envoy=E9 par=20 :      = owner-ip-dvb@erg.abdn.ac.uk


Pour :=20 IPDVB <ip-dvb@erg.abdn.ac.uk>
cc :
Objet = :    =20 Re: Encryption control of SNDU




Gorry Fairhurst=20 wrote:

> So, I'm trying to build a list of "issues for ULE" = and the=20 questions I
have
> are:
>
> (i) Does the proposed = ULE base=20 header format (4/12B of header) need to be
> changed to support = any=20 required encryption/scrambling?
>
> Possible answers=20 include:
>
> * Yes - because the ULE header must not be = increased=20 when
>     link encryption is = used.
>
> *=20 No - because the ULE header can specify a TYPE that=20 could
>     indicate an encrypted payload, and = hence=20 this issue
>     could be solved by using an = extension=20 header of some form.
>
> If it is YES, then this has design=20 implications for the ULE Spec.

I would say No, because = :
  =20 - I don't really understand the need for ULE level=20 encryption
     see point I)
   - If = needed,=20 it can be separated from ULE base specs. see point II)

I) Why ULE = level=20 encryption = ?
=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
I still don't sse the need for=20 an ULE-level encryption, because
I see 3 possibilities of = encryption
1) At=20 MPEG-2 level, i.e. same encryption for whole content of a PID
2) At = ULE=20 level, i.e. encryption on a per SNDU basis for the case as
  = Tarif said,=20 where PID is mutli-receiver (belonging to different groups)
3) At IP=20 level

but what can distinguish 2 SNDU ?
   - IP = addresses=20 ?
   - DVB Mac addr ?
But the DVB Mac addr is itself the = result=20 of IP address/prefix
resolution (which can use destination and/or=20 sources)
So I think it can all be expresed in term of either = destination=20 and/or
source Addresses, which can perfectly be handled by IPsec. So = 2) and=20 3)
seem to me to offer the same granularity and 3) is already defined = and
working.

This is my current understanding,  and a=20 counter-example where 2) would
solve a use-case and not 3) would be = very=20 helpfull.
Anyway, I may have missed something, so :

II) = Etxension=20 Header for = Encryption
=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
*IF* an ULE=20 encryption is needed, then some extension header can be
defined to = provide=20 it, so the SNDU would be like :

-  [ULE_Header] [DVB_MAC*]=20 [SEC_Header] [xxx SNDU Payload=20 xxx]
        =20 |
         +--> Type =3D=20 sec_header
    (*) if MAC addres bit is = '0'


- =20 The SEC_Header would be
    +---+---+---+--//  = ..... //=20 ----+
    |   NH  | L |  security=20 params  |
    +---+---+---+--//  ..... //=20 ----+

    with NH =3D Type of SNDU payload (IP, = IPv6,=20 ...)
         L  =3D = Length of=20 SEC_Header

    security params will define key = material,=20 type of security
    (encryption, authentication, = ....), algo,=20 whatever ...

    In the extension headers I = proposed, the=20 SEC_Header would be one
    of the "drop packets if=20 unknown"  type.

  - The SNDU payload woul be=20 clear/encrypt/padded accordingly to what
    params = will be=20 found in SEC_Header.

With that approach, the only thing needed is = to=20 include the Extension
Headers mechanism definition in the ULE base = specs.=20 Then ALL that
SEC_Header stuff can be described in a separate doc, = and good=20 luck with
the (re)keying framework/protocols, security analysis=20 ...

Regards.
Alain.
--
Alain RITOUX
Tel=20 +33-1-39-30-92-32
Fax +33-1-39-30-92-11
visit our web http://www.6wind.com






Sinc=E8= res=20 Salutations / Best regards
Laurent Claverotte

ALCATEL=20 SPACE
DSR/DRE
Tel : 33 (0)5.34.35.46.47  /  Fax : 33=20 (0)5.34.35.61.69
E-Mail :=20 Laurent.Claverotte@space.alcatel.fr




------_=_NextPart_001_01C3FD0B.FABE3D68-- From owner-ip-dvb@erg.abdn.ac.uk Fri Feb 27 10:36:49 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1RAZNsE005525 for ; Fri, 27 Feb 2004 10:35:23 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1RAZNYC005524 for ip-dvb-subscribed-users; Fri, 27 Feb 2004 10:35:23 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from mail1.iabg.de (mail1.iabg.de [194.139.245.9]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1RAYD0n005456 for ; Fri, 27 Feb 2004 10:34:13 GMT Received: from mail1.iabg.de (localhost [127.0.0.1]) by localhost (Mailserver1 IABG) with ESMTP id 80DEF9400 for ; Fri, 27 Feb 2004 11:34:10 +0100 (CET) Received: from exchange03.iabg.de (exchange03.iabg.de [10.128.200.37]) by mail1.iabg.de (Mailserver1 IABG) with ESMTP id 6C7A093F7 for ; Fri, 27 Feb 2004 11:34:10 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: =?iso-8859-1?Q?AW=3A_R=E9f=2E_=3A_Re=3A_Encryption_control_of_SNDU?= Date: Fri, 27 Feb 2004 11:34:10 +0100 Message-ID: <69A5E767EC979846826F566C7932A3F2074E2F@exchange03.iabg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: =?iso-8859-1?Q?R=E9f=2E_=3A_Re=3A_Encryption_control_of_SNDU?= Thread-Index: AcP8jxZkCYX8tSKeQDqaoR8HC1EgRwAi/4gQ From: "Fritsche Wolfgang" 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 i1RAZLTN005520 Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk > -----Ursprüngliche Nachricht----- > Von: owner-ip-dvb@erg.abdn.ac.uk > [mailto:owner-ip-dvb@erg.abdn.ac.uk] Im Auftrag von > Tarif.Zein-Alabedeen@space.alcatel.fr > Gesendet: Donnerstag, 26. Februar 2004 17:23 > An: ip-dvb@erg.abdn.ac.uk > Betreff: Réf. : Re: Encryption control of SNDU > Wichtigkeit: Niedrig > > > > > Hi alain and every body > Concerning point I, let me go back to dvb-rcs : encryption at > the encapsulation layer (which is now MPE but may become ULE > in the future) has been provisioned and the way it is > controlled by the 2 bits field in the MPE header has been > clearly specified (see my precedent mail) > > I am not aware of the exact reasons which led poeple who > contributed to the dvb-rcs definition to do this may be they > did something wrong or expected a functionnality that will > never be used....!!!! But it is more probable that they had > real reasons to do this (so we can avoid to reinvent the > wheel as you said) Any one has an idea? Before requiring the adoption of these 2bits we really should know and understand their reasons, and assess if they still exist for ULE. > > I see an example which could make case 3 difficult to apply. > It concerns bridging When forwarding (in the Gateway for > example) is performed by bridging (as in Ethernet switches) > and not by routing (as routers), IPsec can not apply because > the GW handles frames and not datagrams (am I wrong?). Such > case may happen with e.g a PPPOE access scheme. So if IPsec > is not applied end-to-end (but this can not be controlled by > the satellite segment), traffic will be transmitted clear on > the sat interface I don't think your example above necessarily means cleartext transmission. Even when briding is used on the encapsulator, there is a node before, which performs routing functionality. Often this node is controlled by the same entity as the encapsulator in "bridging mode" (e.g. a Teleport operator), so the IPsec SA could start in this case on the router. In case the encapsulator in "bridging mode" and its closest preceding router are controlled by different entities, you still could apply security on MPEG level. Cheers, Wolfgang > > Concerning the use of the extension header, the main question > is : when encryption is applied at ULE level, do we need the > encryption control field in all SNDUs or not. If yes, the > extension header solution may turn to be inefficient since it > would lead to about 5 bytes extra header (taking your example > below). I submitted this question to Alcatel's security > experts but would be great if others in this groupe could > also think about it and make suggestions > > regards > > > > > > Alain RITOUX @erg.abdn.ac.uk on > 26/02/2004 15:25:15 > > Veuillez répondre à ip-dvb@erg.abdn.ac.uk > > Envoyé par : owner-ip-dvb@erg.abdn.ac.uk > > > Pour : IPDVB > cc : > Objet : Re: Encryption control of SNDU > > > > > Gorry Fairhurst wrote: > > > So, I'm trying to build a list of "issues for ULE" and the > questions I > have > > are: > > > > (i) Does the proposed ULE base header format (4/12B of > header) need to > > be changed to support any required encryption/scrambling? > > > > Possible answers include: > > > > * Yes - because the ULE header must not be increased when > > link encryption is used. > > > > * No - because the ULE header can specify a TYPE that could > > indicate an encrypted payload, and hence this issue > > could be solved by using an extension header of some form. > > > > If it is YES, then this has design implications for the ULE Spec. > > I would say No, because : > - I don't really understand the need for ULE level encryption > see point I) > - If needed, it can be separated from ULE base specs. see point II) > > I) Why ULE level encryption ? > ============================= > I still don't sse the need for an ULE-level encryption, > because I see 3 possibilities of encryption > 1) At MPEG-2 level, i.e. same encryption for whole content of a PID > 2) At ULE level, i.e. encryption on a per SNDU basis for the case as > Tarif said, where PID is mutli-receiver (belonging to > different groups) > 3) At IP level > > but what can distinguish 2 SNDU ? > - IP addresses ? > - DVB Mac addr ? > But the DVB Mac addr is itself the result of IP > address/prefix resolution (which can use destination and/or > sources) So I think it can all be expresed in term of either > destination and/or source Addresses, which can perfectly be > handled by IPsec. So 2) and 3) seem to me to offer the same > granularity and 3) is already defined and working. > > This is my current understanding, and a counter-example > where 2) would solve a use-case and not 3) would be very > helpfull. Anyway, I may have missed something, so : > > II) Etxension Header for Encryption > ==================================== > *IF* an ULE encryption is needed, then some extension header > can be defined to provide it, so the SNDU would be like : > > - [ULE_Header] [DVB_MAC*] [SEC_Header] [xxx SNDU Payload xxx] > | > +--> Type = sec_header > (*) if MAC addres bit is '0' > > > - The SEC_Header would be > +---+---+---+--// ..... // ----+ > | NH | L | security params | > +---+---+---+--// ..... // ----+ > > with NH = Type of SNDU payload (IP, IPv6, ...) > L = Length of SEC_Header > > security params will define key material, type of security > (encryption, authentication, ....), algo, whatever ... > > In the extension headers I proposed, the SEC_Header would be one > of the "drop packets if unknown" type. > > - The SNDU payload woul be clear/encrypt/padded accordingly to what > params will be found in SEC_Header. > > With that approach, the only thing needed is to include the > Extension Headers mechanism definition in the ULE base specs. > Then ALL that SEC_Header stuff can be described in a separate > doc, and good luck with the (re)keying framework/protocols, > security analysis ... > > Regards. > Alain. > -- > Alain RITOUX > Tel +33-1-39-30-92-32 > Fax +33-1-39-30-92-11 > visit our web http://www.6wind.com > > > > > > > T. Zein > > ALCATEL SPACE > DRT/RST -- Ingénieur Systèmes > Tel : 0534356918 / Fax : 0534355560 > Porte : W.220 > > > > > From owner-ip-dvb@erg.abdn.ac.uk Fri Feb 27 10:42:31 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1RAeshe005735 for ; Fri, 27 Feb 2004 10:40:54 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1RAerjk005734 for ip-dvb-subscribed-users; Fri, 27 Feb 2004 10:40:54 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from mail1.iabg.de (mail1.iabg.de [194.139.245.9]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1RAdhsu005663 for ; Fri, 27 Feb 2004 10:39:43 GMT Received: from mail1.iabg.de (localhost [127.0.0.1]) by localhost (Mailserver1 IABG) with ESMTP id 4C33293F7 for ; Fri, 27 Feb 2004 11:39:41 +0100 (CET) Received: from exchange03.iabg.de (exchange03.iabg.de [10.128.200.37]) by mail1.iabg.de (Mailserver1 IABG) with ESMTP id 3A17E9317 for ; Fri, 27 Feb 2004 11:39:41 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: =?iso-8859-1?Q?AW=3A_R=E9f=2E_=3A_Re=3A_Encryption_control_of_SNDU?= Date: Fri, 27 Feb 2004 11:39:41 +0100 Message-ID: <69A5E767EC979846826F566C7932A3F2074E30@exchange03.iabg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: =?iso-8859-1?Q?R=E9f=2E_=3A_Re=3A_Encryption_control_of_SNDU?= Thread-Index: AcP9Gm9JrRufZdHSSPqB1qHuH7iR8wAAtYoA From: "Fritsche Wolfgang" 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 i1RAemQ5005729 Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk > -----Ursprüngliche Nachricht----- > Von: owner-ip-dvb@erg.abdn.ac.uk > [mailto:owner-ip-dvb@erg.abdn.ac.uk] Im Auftrag von > alain.ritoux@6wind.com > Gesendet: Freitag, 27. Februar 2004 08:25 > Betreff: Re: Réf. : Re: Encryption control of SNDU > > > > Dear Laurent and all, > > Not being a satcom expert I cannot argue the L2 security > details, but I do understanf your concern. But some precision > need to be done about the IPsec "drawbacks" paragraph > > Laurent.Claverotte@space.alcatel.fr wrote: > > > ... snip > > > > 2. Solutions comparison > > > > ... snip > > - IPSec has lot of drawbacks : it is not a L2 solution, it is an > > end-to-end technology, it can interfere with the end-to-end security > > solution, it can interfere with satellite techniques (PEP), > it does not > > provide encryption of multicast flows and it generates > many overheads and > > number of signaling messages!!!!!! Lots of comparison studies and > > simulations have been performed by Alcatel leading to reject this > > solution!! > > * It is not an L2 solution : > well, some might see it a a plus. end of religious debate ;-) > > * its is an end-to-end technology > No, It can support end-to-end security (I mean host-to-host), > but the tunnel mode is available for security gateways, hence > allowing securisation of part of the total path. for exemple > between the DVB sender, and the DVB receiver (even if it is a > host and not a router it can behave as a security gateway for > himself). > > * it can interfere with end-to-end security solution > ??? I don't understand the argument : > It is a solution, that works at IP level, in both end-to-end > model or gateway-to-gateway model. Both models can be used > simultaneously, while working over a secure L2, for > transporting SSL ... I see no contradiction. > > * it can interfere with satellite techniques (PEP) > Could you elaborate, because all it does it take an IP packet > and generate one other IP packet. How can satellite technique > interfere without messing into IP level? If it interferes with PEPs depends on the architecture, that is the position of the IPsec functionality relatively to the PEPs. > > * multicast : > Indeed it does not protect multicast yet, but work is in > progress. if there is an easy solution to key distribution, > the msec IETF wg should be informed Multicast security without key management should work already with most IPsec implementations (they should not differ between IP unicast and IP Multicast destination address of an SA, and the spec also doesn't exlude this). Multicast key management is in the cycle of standardisation, and has already been demonstrated as prototype (Haitham and Logica have done this within an ESA project, making using GSAKMP light). Cheers, Wolfgang > > * it generates overhead : > Yes there is overhead, but I don't really see fields in > AH/ESP that are unncessary. > > * many signalling messages : > I thnk you refer here to IKE. Of course some messages are > exchanged for key negociation, but I think it is the price > for dynamic keying. L2 securisation with dynamic keying will > allso generate messages exchanges. Anyway, those exchanges > are done for each IPsec tunnel, and once done have generated > key whose lifetime can be chosen (in term of duration and/or > tarfic volume), so the overhead relatively to the global > volume should be quite small. > > Are those Alcatel comparison studies and/or simulations > available somewhere, could be interesting. > > Regards. > Alain. > -- > Alain RITOUX > Tel +33-1-39-30-92-32 > Fax +33-1-39-30-92-11 > visit our web http://www.6wind.com > > From owner-ip-dvb@erg.abdn.ac.uk Fri Feb 27 10:54:34 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1RArSXL006266 for ; Fri, 27 Feb 2004 10:53:28 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1RArRZF006265 for ip-dvb-subscribed-users; Fri, 27 Feb 2004 10:53:28 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from proxy.6wind.com (proxy.ipv6.6wind.com [194.250.197.211]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1RApt4D006183 for ; Fri, 27 Feb 2004 10:51:55 GMT Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id 6E97D763 for ; Fri, 27 Feb 2004 11:51:57 +0100 (CET) Received: from 6wind.com (vouvray.dev.6wind.com [10.16.0.135]) by intranet.6wind.com (Postfix) with ESMTP id 3E11215; Fri, 27 Feb 2004 11:51:57 +0100 (CET) Message-ID: <403F2245.7020601@6wind.com> Date: Fri, 27 Feb 2004 11:56:05 +0100 From: Alain RITOUX 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: ip-dvb@erg.abdn.ac.uk Subject: ULE extensions References: <20040227073707.20125.qmail@webmail35.rediffmail.com> In-Reply-To: <20040227073707.20125.qmail@webmail35.rediffmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Hello William and all, (I changed the title to separate thread for ULE extension, from thread about encryption) > Further to the extension header for ULE, > it can be made option as we have for destination mac address, without effecting any implementation and design > > - [Dest Mac Addr bit][ext. header present bit][ULE_Header] [DVB_MAC*] [Ext. Header*] [xxx SNDU Payload xxx] > > we can change 15 bits of payload length into 14 bits.. which is much more than the present DSMCC payload/section length, which is 12 bits. > with that bit we can define any extension header is present for any future updations to the ULE, > the Ext. Header is defined as > +---+--------+---// ..... // ----+ > |EHT| NHB & L| Ext.Header params | > +---+--------+---// .... // ----+ > > where, EHT = 1 byte of extension header type field. Which has to be defined, might be ULE specific. > L = LSB 7 bit of ext. header parameter length, i.e. supports 127 bytes. > NHB = MSB 1 bit contains if there is any other extension header present. > Ext.Header params = variable length based on the ext. header parameter length. > If I understand correctly, the type field in the ULE header remains unchanged, and indicates the final payload. The EHT is from a different namespace. So the deal is (1 bit of ULE length) + (1 bit in ExtHdr length) dealed for (1 byte in each ExtHdr) This seems VERY good to me. If we also compare with Gorry's last proposal, > < ----------------------------- SNDU ----------------------------- > > +-+-------------------------------------------------------+--------+ > |D| Length | ENC |ETYPE | PDU | CRC-32 | > +-+-------------------------------------------------------+--------+ > > Where ENC = a predefined 2B TYPE value, and ETYPE is the 2B type > field Corresponding to the PDU. Several ENC values could be specified. > Additional overhead = 2B. it has the very same overhead, but keeps the possibility - to chain headers. - to make them blindly parsable. Indeed if some extension are mandatory, we can still, with this new extension model, split the naming space in 2 parts : <128 - Optional ExtHeader : if unknown, skip and process next >=128 - Mandatory ExtHeader : if unknown, drop SNDU So I'm in favour of this 3rd extention scheme (until of course somebody finds a way to gain one more byte ;-)) [ And just a word about encryption : if it is done by such an ExtHdr format, it just has to use a "Mandatory Ext Header", and the ULE specs just has to define this ext mechanism. The "how" and "why" use encryption will not be linked to ULE, but to ULE-security-extension and described in the separate I-D please any response to this part should start an other thread ] Regards. Alain. -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com From owner-ip-dvb@erg.abdn.ac.uk Fri Feb 27 13:06:52 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1RD4tLa010956 for ; Fri, 27 Feb 2004 13:04:55 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1RD4saD010954 for ip-dvb-subscribed-users; Fri, 27 Feb 2004 13:04:54 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley-ipv6.erg.abdn.ac.uk [IPv6:2001:630:241:1:20a:95ff:fe7d:5f0c]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1RD0JrC010780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 27 Feb 2004 13:00:22 GMT Message-ID: <403F3F64.7040900@erg.abdn.ac.uk> Date: Fri, 27 Feb 2004 13:00:20 +0000 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Re: =?ISO-8859-1?Q?R=E9f=2E_=3A_Re=3A_Encryption_control?= =?ISO-8859-1?Q?_of_SNDU?= References: <20040227073630.25988.qmail@webmail36.rediffmail.com> In-Reply-To: <20040227073630.25988.qmail@webmail36.rediffmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk OK, so this is a third way to introduce an extension header, that takes one bit form the Length field, but otherwise resembles Alain's... approach. gorry William StanisLaus wrote: >Further to the extension header for ULE, >it can be made option as we have for destination mac address, without effecting any implementation and design > >- [Dest Mac Addr bit][ext. header present bit][ULE_Header] [DVB_MAC*] [Ext. Header*] [xxx SNDU Payload xxx] > >we can change 15 bits of payload length into 14 bits.. which is much more than the present DSMCC payload/section length, which is 12 bits. >with that bit we can define any extension header is present for any future updations to the ULE, >the Ext. Header is defined as > +---+--------+---// ..... // ----+ > |EHT| NHB & L| Ext.Header params | > +---+--------+---// ..... // ----+ > > where, EHT = 1 byte of extension header type field. Which has to be defined, might be ULE specific. > L = LSB 7 bit of ext. header parameter length, i.e. supports 127 bytes. > NHB = MSB 1 bit contains if there is any other extension header present. > Ext.Header params = variable length based on the ext. header parameter length. > >Best Regards, >William. > > >On Thu, 26 Feb 2004 Tarif.Zein-Alabedeen@space.alcatel.fr wrote : > > >>Hi alain and every body >>Concerning point I, let me go back to dvb-rcs : encryption at the >>encapsulation layer >>(which is now MPE but may become ULE in the future) has been provisioned >>and the way it is >>controlled by the 2 bits field in the MPE header has been clearly specified >>(see my precedent mail) >> >>I am not aware of the exact reasons which led poeple who contributed to the >>dvb-rcs definition to do this >>may be they did something wrong or expected a functionnality that will >>never be used....!!!! >>But it is more probable that they had real reasons to do this (so we can >>avoid to reinvent the wheel as you said) >>Any one has an idea? >> >>I see an example which could make case 3 difficult to apply. It concerns >>bridging >>When forwarding (in the Gateway for example) is performed by bridging (as >>in Ethernet switches) and not by routing (as routers), >>IPsec can not apply because the GW handles frames and not datagrams (am I >>wrong?). Such case may happen with e.g a PPPOE access scheme. >>So if IPsec is not applied end-to-end (but this can not be controlled by >>the satellite segment), traffic will be transmitted clear on the >>sat interface >> >>Concerning the use of the extension header, the main question is : when >>encryption is applied at ULE level, do we need the encryption control field >>in all SNDUs or not. If yes, the extension header solution may turn to be >>inefficient since it would lead to about 5 bytes extra header (taking your >>example below). I submitted this question to Alcatel's security experts but >>would be great if others in this groupe could also think about it and make >>suggestions >> >>regards >> >> >> >> >> >>Alain RITOUX @erg.abdn.ac.uk on 26/02/2004 15:25:15 >> >>Veuillez répondre à ip-dvb@erg.abdn.ac.uk >> >>Envoyé par : owner-ip-dvb@erg.abdn.ac.uk >> >> >>Pour : IPDVB >>cc : >>Objet : Re: Encryption control of SNDU >> >> >> >> >>Gorry Fairhurst wrote: >> >> >> >>>So, I'm trying to build a list of "issues for ULE" and the questions I >>> >>> >>have >> >> >>>are: >>> >>>(i) Does the proposed ULE base header format (4/12B of header) need to be >>>changed to support any required encryption/scrambling? >>> >>>Possible answers include: >>> >>>* Yes - because the ULE header must not be increased when >>> link encryption is used. >>> >>>* No - because the ULE header can specify a TYPE that could >>> indicate an encrypted payload, and hence this issue >>> could be solved by using an extension header of some form. >>> >>>If it is YES, then this has design implications for the ULE Spec. >>> >>> >>I would say No, because : >> - I don't really understand the need for ULE level encryption >> see point I) >> - If needed, it can be separated from ULE base specs. see point II) >> >>I) Why ULE level encryption ? >>============================= >>I still don't sse the need for an ULE-level encryption, because >>I see 3 possibilities of encryption >>1) At MPEG-2 level, i.e. same encryption for whole content of a PID >>2) At ULE level, i.e. encryption on a per SNDU basis for the case as >> Tarif said, where PID is mutli-receiver (belonging to different groups) >>3) At IP level >> >>but what can distinguish 2 SNDU ? >> - IP addresses ? >> - DVB Mac addr ? >>But the DVB Mac addr is itself the result of IP address/prefix >>resolution (which can use destination and/or sources) >>So I think it can all be expresed in term of either destination and/or >>source Addresses, which can perfectly be handled by IPsec. So 2) and 3) >>seem to me to offer the same granularity and 3) is already defined and >>working. >> >>This is my current understanding, and a counter-example where 2) would >>solve a use-case and not 3) would be very helpfull. >>Anyway, I may have missed something, so : >> >>II) Etxension Header for Encryption >>==================================== >>*IF* an ULE encryption is needed, then some extension header can be >>defined to provide it, so the SNDU would be like : >> >>- [ULE_Header] [DVB_MAC*] [SEC_Header] [xxx SNDU Payload xxx] >> | >> +--> Type = sec_header >> (*) if MAC addres bit is '0' >> >> >>- The SEC_Header would be >> +---+---+---+--// ..... // ----+ >> | NH | L | security params | >> +---+---+---+--// ..... // ----+ >> >> with NH = Type of SNDU payload (IP, IPv6, ...) >> L = Length of SEC_Header >> >> security params will define key material, type of security >> (encryption, authentication, ....), algo, whatever ... >> >> In the extension headers I proposed, the SEC_Header would be one >> of the "drop packets if unknown" type. >> >> - The SNDU payload woul be clear/encrypt/padded accordingly to what >> params will be found in SEC_Header. >> >>With that approach, the only thing needed is to include the Extension >>Headers mechanism definition in the ULE base specs. Then ALL that >>SEC_Header stuff can be described in a separate doc, and good luck with >>the (re)keying framework/protocols, security analysis ... >> >>Regards. >>Alain. >>-- >>Alain RITOUX >>Tel +33-1-39-30-92-32 >>Fax +33-1-39-30-92-11 >>visit our web http://www.6wind.com >> >> >> >> >> >> >>T. Zein >> >>ALCATEL SPACE >>DRT/RST -- Ingénieur Systèmes >>Tel : 0534356918 / Fax : 0534355560 >>Porte : W.220 >> >> >> >> >> >> > > > From owner-ip-dvb@erg.abdn.ac.uk Sat Feb 28 06:39:08 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1S6cMgt018022 for ; Sat, 28 Feb 2004 06:38:22 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1S6cMV9018021 for ip-dvb-subscribed-users; Sat, 28 Feb 2004 06:38:22 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from rediffmail.com (webmail25.rediffmail.com [203.199.83.147] (may be forged)) by erg.abdn.ac.uk (8.12.11/8.12.11) with SMTP id i1S6b32b017963 for ; Sat, 28 Feb 2004 06:37:04 GMT Received: (qmail 7226 invoked by uid 510); 28 Feb 2004 06:37:00 -0000 Date: 28 Feb 2004 06:37:00 -0000 Message-ID: <20040228063700.7223.qmail@webmail25.rediffmail.com> Received: from unknown (203.197.138.199) by rediffmail.com via HTTP; 28 feb 2004 06:36:59 -0000 MIME-Version: 1.0 From: "William StanisLaus" To: ip-dvb@erg.abdn.ac.uk Cc: "Alain RITOUX" Subject: Re: ULE extensions Content-type: multipart/alternative; boundary="Next_1077950219---0-203.199.83.147-7090" X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk This is a multipart mime message --Next_1077950219---0-203.199.83.147-7090 Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

=0AHi Alain and all,
=0A
=0AI have a small concern here on
=0A=
=0A> > < ----------------------------- SNDU ------------------= ----------- >
=0A> > +-+---------------------------------------= ----------------+--------+
=0A> > |D| Length | ENC |ETYPE |  =               PDU      &n= bsp;       | CRC-32 |
=0A> > +-+-------------------= ------------------------------------+--------+
=0Ahere, always ENC which= is 2 bytes wasted even if we don't support ULE encryption. Also there is n= o provision for future extension of any other informations which can be add= ed to the ULE header, say for example LLC_SNAP support, Section number(in c= ase if any one of the intermediate MPEG1-TS packet is lost for a particular= SNDU, Receiver can request that particular SNDU from the sender with Secti= on number in ULE.. this might be for error detection, packet loss etc).
= =0A
=0AIn the other approach, based on the extension header bit, we can = add extension headers, which can chain more than one extension headers as w= ell.
=0AIf there is no extension is required and if we are going to foll= ow the simple approach, then  extension header bit is set to ZERO and = there is no modification to the present ULE draft.
=0A
=0A
=0ABest= Regards,
=0AWilliam.
=0A
=0AOn Fri, 27 Feb 2004 Alain RITOUX wrot= e :
=0A>Hello William and all,
=0A>
=0A>(I changed the ti= tle to separate thread for ULE extension, from
=0A>thread about encry= ption)
=0A>
=0A>
=0A>>Further to the extension header = for ULE, it can be made option as we have for destination mac address, with= out effecting any implementation and design
=0A>>-  [Dest Ma= c Addr bit][ext. header present bit][ULE_Header] [DVB_MAC*] [Ext. Header*] = [xxx SNDU Payload xxx]
=0A>>
=0A>>we can change 15 bits o= f payload length into 14 bits.. which is much more than the present DSMCC p= ayload/section length, which is 12 bits.
=0A>>with that bit we can= define any extension header is present for any future updations to the ULE= , the Ext. Header is defined as
=0A>>    +---+--------+-= --//  ..... // ----+
=0A>>    |EHT| NHB & L| Ex= t.Header params  |
=0A>>    +---+--------+---//&nbs= p; .... // ----+
=0A>>      where, EHT =3D 1 byte = of extension header type field. Which has to be defined, might be ULE speci= fic.
=0A>>          L  =3D LSB 7 b= it of ext. header parameter length, i.e. supports 127 bytes.
=0A>>=           NHB =3D MSB 1 bit contains if there is = any other extension header present.
=0A>>      &nbs= p; Ext.Header params =3D variable length based on the ext. header parameter= length.
=0A>>
=0A>
=0A>If I understand correctly, the= type field in the ULE header remains
=0A>unchanged, and indicates th= e final payload. The EHT is from a different
=0A>namespace.
=0A>= ;
=0A>So the deal is
=0A>  (1 bit of ULE length) + (1 bit = in ExtHdr length) dealed for
=0A>  (1 byte in each ExtHdr)
= =0A>
=0A>This seems VERY good to me.
=0A>
=0A>If we al= so compare with Gorry's last proposal,
=0A>
=0A> > < ----= ------------------------- SNDU ----------------------------- >
=0A>= ; > +-+-------------------------------------------------------+--------+=
=0A> > |D| Length | ENC |ETYPE |         = ;       PDU              = | CRC-32 |
=0A> > +-+---------------------------------------------= ----------+--------+
=0A> >
=0A> > Where ENC =3D a predef= ined 2B TYPE  value, and ETYPE is the 2B type
=0A> > field Co= rresponding to the PDU. Several ENC values could be specified.
=0A> &= gt; Additional overhead =3D 2B.
=0A>
=0A>it has the very same o= verhead, but keeps the possibility
=0A>  - to chain headers.=0A>  - to make them blindly parsable.
=0A>
=0A>Indee= d if some extension are mandatory, we can still, with
=0A>this new ex= tension model, split the naming space in 2 parts :
=0A>
=0A>&nb= sp; <128  - Optional ExtHeader  : if unknown, skip and process= next
=0A> >=3D128  - Mandatory ExtHeader : if unknown, drop = SNDU
=0A>
=0A>
=0A>So I'm in favour of this 3rd extention= scheme (until of course somebody
=0A>finds a way to gain one more by= te ;-))
=0A>
=0A>[
=0A>  And just a word about encry= ption : if it is done by such an ExtHdr
=0A>  format, it just ha= s to use a "Mandatory Ext Header", and the ULE
=0A>  s= pecs just has to define this ext mechanism. The "how" and "w= hy"
=0A>  use encryption will not be linked to ULE, but to = ULE-security-extension
=0A>  and described in the separate I-D=0A>
=0A>  please any response to this part should start an= other thread
=0A>]
=0A>
=0A>Regards.
=0A>Alain.=0A>-- Alain RITOUX
=0A>Tel +33-1-39-30-92-32
=0A>Fax +33-1= -39-30-92-11
=0A>visit our web http://www.6wind.com
=0A>
=0A= =0A

=0A

=0A=0A --Next_1077950219---0-203.199.83.147-7090 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Alain and all,=0A=0AI have a small concern here on =0A=0A> > < ---------= -------------------- SNDU ----------------------------- >=0A> > +-+--------= -----------------------------------------------+--------+=0A> > |D| Length = | ENC |ETYPE | PDU | CRC-32 |=0A> > +-+--------= -----------------------------------------------+--------+=0Ahere, always EN= C which is 2 bytes wasted even if we don't support ULE encryption. Also the= re is no provision for future extension of any other informations which can= be added to the ULE header, say for example LLC_SNAP support, Section numb= er(in case if any one of the intermediate MPEG1-TS packet is lost for a par= ticular SNDU, Receiver can request that particular SNDU from the sender wit= h Section number in ULE.. this might be for error detection, packet loss et= c).=0A=0AIn the other approach, based on the extension header bit, we can a= dd extension headers, which can chain more than one extension headers as we= ll.=0AIf there is no extension is required and if we are going to follow th= e simple approach, then extension header bit is set to ZERO and there is n= o modification to the present ULE draft.=0A=0A=0ABest Regards,=0AWilliam.= =0A=0AOn Fri, 27 Feb 2004 Alain RITOUX wrote :=0A>Hello William and all,=0A= >=0A>(I changed the title to separate thread for ULE extension, from=0A>thr= ead about encryption)=0A>=0A>=0A>>Further to the extension header for ULE, = it can be made option as we have for destination mac address, without effec= ting any implementation and design =0A>>- [Dest Mac Addr bit][ext. header = present bit][ULE_Header] [DVB_MAC*] [Ext. Header*] [xxx SNDU Payload xxx]= =0A>>=0A>>we can change 15 bits of payload length into 14 bits.. which is m= uch more than the present DSMCC payload/section length, which is 12 bits.= =0A>>with that bit we can define any extension header is present for any fu= ture updations to the ULE, the Ext. Header is defined as=0A>> +---+-----= ---+---// ..... // ----+=0A>> |EHT| NHB & L| Ext.Header params |=0A>> = +---+--------+---// .... // ----+=0A>> where, EHT =3D 1 byte of e= xtension header type field. Which has to be defined, might be ULE specific.= =0A>> L =3D LSB 7 bit of ext. header parameter length, i.e. sup= ports 127 bytes.=0A>> NHB =3D MSB 1 bit contains if there is any = other extension header present.=0A>> Ext.Header params =3D variable leng= th based on the ext. header parameter length.=0A>>=0A>=0A>If I understand c= orrectly, the type field in the ULE header remains=0A>unchanged, and indica= tes the final payload. The EHT is from a different=0A>namespace.=0A>=0A>So = the deal is=0A> (1 bit of ULE length) + (1 bit in ExtHdr length) dealed fo= r=0A> (1 byte in each ExtHdr)=0A>=0A>This seems VERY good to me.=0A>=0A>If= we also compare with Gorry's last proposal,=0A>=0A> > < ------------------= ----------- SNDU ----------------------------- >=0A> > +-+-----------------= --------------------------------------+--------+=0A> > |D| Length | ENC |ET= YPE | PDU | CRC-32 |=0A> > +-+-----------------= --------------------------------------+--------+=0A> >=0A> > Where ENC =3D = a predefined 2B TYPE value, and ETYPE is the 2B type=0A> > field Correspon= ding to the PDU. Several ENC values could be specified.=0A> > Additional ov= erhead =3D 2B.=0A>=0A>it has the very same overhead, but keeps the possibil= ity=0A> - to chain headers.=0A> - to make them blindly parsable.=0A>=0A= >Indeed if some extension are mandatory, we can still, with=0A>this new ext= ension model, split the naming space in 2 parts :=0A>=0A> <128 - Optional= ExtHeader : if unknown, skip and process next=0A> >=3D128 - Mandatory Ex= tHeader : if unknown, drop SNDU=0A>=0A>=0A>So I'm in favour of this 3rd ext= ention scheme (until of course somebody=0A>finds a way to gain one more byt= e ;-))=0A>=0A>[=0A> And just a word about encryption : if it is done by su= ch an ExtHdr=0A> format, it just has to use a "Mandatory Ext Header", and = the ULE=0A> specs just has to define this ext mechanism. The "how" and "wh= y"=0A> use encryption will not be linked to ULE, but to ULE-security-exten= sion=0A> and described in the separate I-D=0A>=0A> please any response to= this part should start an other thread=0A>]=0A>=0A>Regards.=0A>Alain.=0A>-= - Alain RITOUX=0A>Tel +33-1-39-30-92-32=0A>Fax +33-1-39-30-92-11=0A>visit o= ur web http://www.6wind.com=0A>=0A --Next_1077950219---0-203.199.83.147-7090-- From owner-ip-dvb@erg.abdn.ac.uk Sat Feb 28 17:07:25 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1SH5thb009762 for ; Sat, 28 Feb 2004 17:05:55 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1SH5sFT009761 for ip-dvb-subscribed-users; Sat, 28 Feb 2004 17:05:54 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from rediffmail.com (webmail33.rediffmail.com [203.199.83.245] (may be forged)) by erg.abdn.ac.uk (8.12.11/8.12.11) with SMTP id i1SH4Zre009709 for ; Sat, 28 Feb 2004 17:04:36 GMT Received: (qmail 6820 invoked by uid 510); 28 Feb 2004 17:04:32 -0000 Date: 28 Feb 2004 17:04:32 -0000 Message-ID: <20040228170432.6819.qmail@mailweb33.rediffmail.com> Received: from unknown (61.11.83.126) by rediffmail.com via HTTP; 28 feb 2004 17:04:32 -0000 MIME-Version: 1.0 From: "William StanisLaus" To: ip-dvb@erg.abdn.ac.uk Cc: "Alain RITOUX" Subject: ULE encryption Support. Content-type: multipart/alternative; boundary="Next_1077987872---0-203.199.83.245-6806" X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk X-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk This is a multipart mime message --Next_1077987872---0-203.199.83.245-6806 Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

=0AHi Alain,
=0A    Its seems when are sure to have some ex= t. headers as mandatory.. we can well define in as part of the standarded U= LE header itself as any other IE (Information Element) in ULE header. I can= see the only exception as Optional Headers support to keep the ULE header = minimal. Except MUST HAVE IE's in ULE we can push all other things into opt= ional headers, and we can leave it to the implementation whether to support= those optional headers are not.
=0ARegarding Encryption, i personnely f= eel that it should be an optional header, since it is not all Satellite net= work operators interest to implement encryption in L2.
=0A
=0ABest Re= gards,
=0AWilliam.
=0A
=0AOn Fri, 27 Feb 2004 Alain RITOUX wrote :=
=0A
=0A<snip>
=0A
=0A>
=0A>[
=0A>  A= nd just a word about encryption : if it is done by such an ExtHdr
=0A>= ;  format, it just has to use a "Mandatory Ext Header", and = the ULE
=0A>  specs just has to define this ext mechanism. The &= quot;how" and "why"
=0A>  use encryption will not= be linked to ULE, but to ULE-security-extension
=0A>  and descr= ibed in the separate I-D
=0A>
=0A>  please any response to= this part should start an other thread
=0A>]
=0A>
=0A>Re= gards.
=0A>Alain.
=0A>-- Alain RITOUX
=0A>Tel +33-1-39-30= -92-32
=0A>Fax +33-1-39-30-92-11
=0A>visit our web http://www.6= wind.com
=0A>
=0A=0A

=0A

=0A=0A --Next_1077987872---0-203.199.83.245-6806 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Alain,=0A Its seems when are sure to have some ext. headers as mandat= ory.. we can well define in as part of the standarded ULE header itself as = any other IE (Information Element) in ULE header. I can see the only except= ion as Optional Headers support to keep the ULE header minimal. Except MUST= HAVE IE's in ULE we can push all other things into optional headers, and w= e can leave it to the implementation whether to support those optional head= ers are not.=0ARegarding Encryption, i personnely feel that it should be an= optional header, since it is not all Satellite network operators interest = to implement encryption in L2.=0A=0ABest Regards,=0AWilliam.=0A=0AOn Fri, 2= 7 Feb 2004 Alain RITOUX wrote :=0A=0A=0A=0A>=0A>[=0A> And just a wor= d about encryption : if it is done by such an ExtHdr=0A> format, it just h= as to use a "Mandatory Ext Header", and the ULE=0A> specs just has to defi= ne this ext mechanism. The "how" and "why"=0A> use encryption will not be = linked to ULE, but to ULE-security-extension=0A> and described in the sepa= rate I-D=0A>=0A> please any response to this part should start an other th= read=0A>]=0A>=0A>Regards.=0A>Alain.=0A>-- Alain RITOUX=0A>Tel +33-1-39-30-9= 2-32=0A>Fax +33-1-39-30-92-11=0A>visit our web http://www.6wind.com=0A>=0A --Next_1077987872---0-203.199.83.245-6806-- From owner-ip-dvb@erg.abdn.ac.uk Sun Feb 29 17:24:35 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1THLNdk018831 for ; Sun, 29 Feb 2004 17:21:23 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i1THLN9b018830 for ip-dvb-subscribed-users; Sun, 29 Feb 2004 17:21:23 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i1THJFZf018708 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Sun, 29 Feb 2004 17:19:17 GMT Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1THJDT07226; Sun, 29 Feb 2004 19:19:13 +0200 (EET) X-Scanned: Sun, 29 Feb 2004 19:18:58 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i1THIwpc006563; Sun, 29 Feb 2004 19:18:58 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00RAH2Ht; Sun, 29 Feb 2004 19:18:56 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1THIu718864; Sun, 29 Feb 2004 19:18:56 +0200 (EET) Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 29 Feb 2004 19:18:55 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 29 Feb 2004 19:18:54 +0200 content-class: urn:content-classes:message Subject: IPDVB bar-bof in Seoul MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sun, 29 Feb 2004 19:18:55 +0200 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ipdvb bar-bof Thread-Index: AcP9OP/uUIrCbpUtT8GRu/jeSllShgBrLFQA From: To: Cc: , , X-OriginalArrivalTime: 29 Feb 2004 17:18:54.0890 (UTC) FILETIME=[1BCEA0A0:01C3FEE8] 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 i1THLHQg018823 Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk X-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk Hello everyone Anyone interested in talking IPDVB, and maybe an early afternoon beverage, is welcome to join a few of us in Bobby London's pub on Tuesday 15:15 (3:15pm). Cheers, Rod.