From owner-ip-dvb@erg.abdn.ac.uk Mon Mar 1 11:00: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 i21AkQHM014921 for ; Mon, 1 Mar 2004 10:46:26 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i21AkPJ4014918 for ip-dvb-subscribed-users; Mon, 1 Mar 2004 10:46: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 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 i215YNKr025940 for ; Mon, 1 Mar 2004 05:34:24 GMT Received: (qmail 30990 invoked by uid 510); 1 Mar 2004 05:34:20 -0000 Date: 1 Mar 2004 05:34:20 -0000 Message-ID: <20040301053420.30989.qmail@webmail26.rediffmail.com> Received: from unknown (203.197.138.199) by rediffmail.com via HTTP; 01 mar 2004 05:34:20 -0000 MIME-Version: 1.0 From: "William StanisLaus" To: "Alain RITOUX" Cc: ip-dvb@erg.abdn.ac.uk Subject: Re: Re: ULE encryption Support. Content-type: multipart/alternative; boundary="Next_1078119260---0-203.199.83.148-30982" 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_1078119260---0-203.199.83.148-30982 Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

=0AHi Alain,
=0A    Good day. please see the comments inli= ned.
=0A
=0ARegards,
=0AWilliam.
=0A
=0AOn Sun, 29 Feb 2004 = Alain RITOUX wrote :
=0A>Hi William
=0A>
=0A>Yes, in defi= nfin the behaviour un ULE base specs, we'll have backward compatibility
= =0A>for future extension. My point for optional vs madatory extension, w= as indeed not very
=0A>well explained : some other words should be ch= osen, because all I had in mind was, to
=0A>define receiver's behavio= ur when he doesn't know the extension header. So two examples
=0A>(on= ly exmpales for the sake of extension headers, no opnion implide on the fct= s).
=0A>
=0A>- encryption  : if not known, of course the f= ollowing payload cannot be decrypted, and
=0A>will be pure garbage. S= o the best behaviour sugested by sender is drop it, you won't
=0A>und= erstand what follows.
=0A
=0A<William> you are right, This case= is, if present MUST support optional header for any recevier :)
=0A
= =0A>- FEC : it can help to correct errors. If not known, it canot be use= d, but th payload
=0A>that follows, still makes sense, so go on.
= =0A
=0A<William> I am sorry that i'm unclear about the FEC at MPE = level, i was just verifying in our terminal, but here FEC is the part of ou= r FPGA in DVB driver, even MPEG2 software driver isn't aware of FEC. Can an= yone please elaborate how FEC is taken care in MPE, it will be also helpful= if you can suggest any specifications which talks about FEC in MPE.
=0A=
=0A>
=0A>So it we change the terms "Optional/Mandatory&qu= ot; by "Process-Next/Discard" for the
=0A>exte header class= ification, would it be more clear ?
=0A>
=0A>I agree with you t= his encrypt (if needed) should be optional. Not everybodys needs
=0A>= it to, be ULE-compliant. Of course those interested shiould by ULE-Encrypio= n-compliant.
=0A>
=0A>
=0A>Regards.
=0A>Alain
= =0A>
=0A>William StanisLaus wrote:
=0A>
=0A>>Hi Ala= in,
=0A>>    Its seems when are sure to have some ext. h= eaders as mandatory.. we can well define in as part of the standarded ULE h= eader 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 mini= mal. Except MUST HAVE IE's in ULE we can push all other things into optiona= l headers, and we can leave it to the implementation whether to support tho= se optional headers are not.
=0A>>Regarding Encryption, i personne= ly feel that it should be an optional header, since it is not all Satellite= network operators interest to implement encryption in L2.
=0A>>=0A>>Best Regards,
=0A>>William.
=0A>>
=0A>= >
=0A>
=0A=0A

=0A

=0A=0A --Next_1078119260---0-203.199.83.148-30982 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Alain,=0A Good day. please see the comments inlined.=0A=0ARegards,= =0AWilliam.=0A=0AOn Sun, 29 Feb 2004 Alain RITOUX wrote :=0A>Hi William=0A>= =0A>Yes, in definfin the behaviour un ULE base specs, we'll have backward c= ompatibility=0A>for future extension. My point for optional vs madatory ext= ension, was indeed not very=0A>well explained : some other words should be = chosen, because all I had in mind was, to=0A>define receiver's behaviour wh= en he doesn't know the extension header. So two examples=0A>(only exmpales = for the sake of extension headers, no opnion implide on the fcts).=0A>=0A>-= encryption : if not known, of course the following payload cannot be decr= ypted, and=0A>will be pure garbage. So the best behaviour sugested by sende= r is drop it, you won't=0A>understand what follows.=0A=0A you are = right, This case is, if present MUST support optional header for any recevi= er :)=0A=0A>- FEC : it can help to correct errors. If not known, it canot b= e used, but th payload=0A>that follows, still makes sense, so go on.=0A=0A<= William> I am sorry that i'm unclear about the FEC at MPE level, i was just= verifying in our terminal, but here FEC is the part of our FPGA in DVB dri= ver, even MPEG2 software driver isn't aware of FEC. Can anyone please elabo= rate how FEC is taken care in MPE, it will be also helpful if you can sugge= st any specifications which talks about FEC in MPE.=0A=0A>=0A>So it we chan= ge the terms "Optional/Mandatory" by "Process-Next/Discard" for the=0A>exte= header classification, would it be more clear ?=0A>=0A>I agree with you th= is encrypt (if needed) should be optional. Not everybodys needs=0A>it to, b= e ULE-compliant. Of course those interested shiould by ULE-Encrypion-compli= ant.=0A>=0A>=0A>Regards.=0A>Alain=0A>=0A>William StanisLaus wrote:=0A>=0A>>= Hi Alain,=0A>> Its seems when are sure to have some ext. headers as mand= atory.. we can well define in as part of the standarded ULE header itself a= s any other IE (Information Element) in ULE header. I can see the only exce= ption as Optional Headers support to keep the ULE header minimal. Except MU= ST HAVE IE's in ULE we can push all other things into optional headers, and= we can leave it to the implementation whether to support those optional he= aders are not.=0A>>Regarding Encryption, i personnely feel that it should b= e an optional header, since it is not all Satellite network operators inter= est to implement encryption in L2.=0A>>=0A>>Best Regards,=0A>>William.=0A>>= =0A>>=0A>=0A --Next_1078119260---0-203.199.83.148-30982-- From owner-ip-dvb@erg.abdn.ac.uk Mon Mar 1 11:14: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 i21BDXZH016807 for ; Mon, 1 Mar 2004 11:13:33 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i21BDXcj016806 for ip-dvb-subscribed-users; Mon, 1 Mar 2004 11:13: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 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 i21BCOb7016757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Mar 2004 11:12:25 GMT Message-ID: <40431A99.1000703@erg.abdn.ac.uk> Date: Mon, 01 Mar 2004 11:12:25 +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 CC: "Allison,Art" Subject: Re: Question on Continuity Counter field References: <20040218050438.16049.qmail@mailweb33.rediffmail.com> In-Reply-To: <20040218050438.16049.qmail@mailweb33.rediffmail.com> Content-Type: text/plain; charset=windows-1252; 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 I'm trying to ensure the next rev of the ID will read correctly, specifically here is the current text I propose. I hope this is much more strongly aligned with ISO MPEG-2, based on all the list discussion: 1) New text for 5.1 Encapsulation: "The Encapsulation MUST ensure that all TS Packets set the MPEG-2 Continuity Counter carried in the TS Packet header, according to [ISO-MPEG]. This value MUST be incremented by one (modulo 16) for each successive fragment/complete SNDU sent using a TS Logical Channel. " 2) New text for Receiver processing: "The Receiver MUST check the MPEG-2 Continuity Counter carried in the TS Packet header [ISO-MPEG]. If two (or more) successive TS Packets within the same TS Logical Channel carry the same Continuity Counter value, the duplicate TS Packets MUST be silently discarded. If the received value is NOT identical to that in the previous TS Packet, and it 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. [XXX Author note: the default action MUST be above to support conformant MPEG-2 streams. Should we allow a configuration variable to disable this? – A clear case for usage would need to be established XXX] Note that the MPEG2-2 Transmission network is permitted to carry Duplicate TS Packets [ISO-MPEG], which are normally detected by the MPEG-2 Continuity Counter. A Receiver that does not perform the above Continuity Counter check, will accept duplicate copies of TS Packets to the reassembly procedure. In such cases, the SNDU CRC-32 integrity check will normally result in discard of these SNDUs, resulting in unexpected PDU loss. " 3) To proceed in addressing the Author note, will require further discussion on this list. Gorry William StanisLaus wrote: >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 Mon Mar 1 13:28: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 i21DRDQ5022201 for ; Mon, 1 Mar 2004 13:27:13 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i21DRCe9022200 for ip-dvb-subscribed-users; Mon, 1 Mar 2004 13:27: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 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 i21DQ90f022160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Mar 2004 13:26:10 GMT Message-ID: <404339F2.60107@erg.abdn.ac.uk> Date: Mon, 01 Mar 2004 13:26:10 +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 CC: Alain RITOUX Subject: Re: ULE encryption Support. References: <20040301053420.30989.qmail@webmail26.rediffmail.com> In-Reply-To: <20040301053420.30989.qmail@webmail26.rediffmail.com> 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 Just a word or two, to try and help people establish the correct context, to communicate... 1) FEC coding is used as a part of physical layer for most media, i.e. below the MPEG-2 bit stream. This type of FEC is NOT the concern of this group and is sepcified by others. 2) Coding may also be used above the MPEG-2 TS layer, in some scenarios to further improve robustness to loss (i.e. corruption of the MPEG-2 TS packet stream). The duplication method, discussed in the "continuity counter" thread is an example of this - albeit rather crude from a coding point of view, and within the transport stream. A "recent" extension to MPE, added the optional ability to do more powerful FEC coding as a part of the encapsulation. 3) FEC coding may also be done above the transport layer, to protect the end-to-end communication from the effects of packet loss. For more details of such schemes see the AVT and RMT WGs of the IETF. So, (2) is what relates to this WG. Gorry From owner-ip-dvb@erg.abdn.ac.uk Mon Mar 1 13:42: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 i21Dg6rI022860 for ; Mon, 1 Mar 2004 13:42:06 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i21Dg6Ge022859 for ip-dvb-subscribed-users; Mon, 1 Mar 2004 13:42:06 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 i21DfZJ5022833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 1 Mar 2004 13:41:35 GMT Message-ID: <40433D90.2000409@erg.abdn.ac.uk> Date: Mon, 01 Mar 2004 13:41:36 +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: ULE encryption Support. References: <20040301053420.30989.qmail@webmail26.rediffmail.com> In-Reply-To: <20040301053420.30989.qmail@webmail26.rediffmail.com> 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 So, if I understand the thread: 1) The current spec only permits "mandatory" TYPE field processing, that is if you can't handle a specific TYPE code-point, (such as bridging, or the hypothetical encryption header), the Receiver MUST discard the SNDU Payload. We do this by chaining several TYPE values one after another in the SNDU header (as defined in bridging). Older ("ignorant") receivers MUST discard all PDUs for which they do not recognise *all* the preceding hedaer TYPEs. 2) If we wish to do "optional" header processing, the above does not work, there is no way for a Receiver to skip the unrecognised extension header, and hence identify the start of the actual payload. To do this would require a new TYPE code-point, which we could call something like "EXTENSION" and which either explicitly, or implicitly carries the length of the total extension header. Within the extension header, we can define several EXTENSION OPTIONS - as required for each use. I suggest the advantage of this two-level approach, is that when people think of new functions that need header support,they can choose either the MANDATORY TYPE format (1), or (if the PDU is still viable), the Extension OPTION format (2). Cases where (2) could apply include: * Treat this packet with a specific QoS profile * There is FEC information available for this packet - the new extension header addedin in these examples should allow an "ignorant" Receiver to skip the extension header, and yet still forwarding the encapsulated PDU. Is that it? - if so, do we need MANDATORY & ESTENSION, can we not just say declare a type code for REQUIRED headers and a EXTENSION OPTION for non-required options? Gorry William StanisLaus wrote: >Hi Alain, > Good day. please see the comments inlined. > >Regards, >William. > >On Sun, 29 Feb 2004 Alain RITOUX wrote : > > >>Hi William >> >>Yes, in definfin the behaviour un ULE base specs, we'll have backward compatibility >>for future extension. My point for optional vs madatory extension, was indeed not very >>well explained : some other words should be chosen, because all I had in mind was, to >>define receiver's behaviour when he doesn't know the extension header. So two examples >>(only exmpales for the sake of extension headers, no opnion implide on the fcts). >> >>- encryption : if not known, of course the following payload cannot be decrypted, and >>will be pure garbage. So the best behaviour sugested by sender is drop it, you won't >>understand what follows. >> >> > > you are right, This case is, if present MUST support optional header for any recevier :) > > > >>- FEC : it can help to correct errors. If not known, it canot be used, but th payload >>that follows, still makes sense, so go on. >> >> > > I am sorry that i'm unclear about the FEC at MPE level, i was just verifying in our terminal, but here FEC is the part of our FPGA in DVB driver, even MPEG2 software driver isn't aware of FEC. Can anyone please elaborate how FEC is taken care in MPE, it will be also helpful if you can suggest any specifications which talks about FEC in MPE. > > > >>So it we change the terms "Optional/Mandatory" by "Process-Next/Discard" for the >>exte header classification, would it be more clear ? >> >>I agree with you this encrypt (if needed) should be optional. Not everybodys needs >>it to, be ULE-compliant. Of course those interested shiould by ULE-Encrypion-compliant. >> >> >>Regards. >>Alain >> >>William StanisLaus wrote: >> >> >> >>>Hi Alain, >>> Its seems when are sure to have some ext. headers as mandatory.. 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 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 optional headers, and we can leave it to the implementation whether to support those optional headers are not. >>>Regarding 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. >>> >>>Best Regards, >>>William. >>> >>> >>> >>> > > > From owner-ip-dvb@erg.abdn.ac.uk Mon Mar 1 13:51:27 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 i21Dot6x023288 for ; Mon, 1 Mar 2004 13:50:55 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i21DotcZ023287 for ip-dvb-subscribed-users; Mon, 1 Mar 2004 13:50: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 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 i21DoTBt023272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 1 Mar 2004 13:50:30 GMT Message-ID: <40433FA6.4040504@erg.abdn.ac.uk> Date: Mon, 01 Mar 2004 13:50:30 +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: ULE extensions References: <20040228063700.7223.qmail@webmail25.rediffmail.com> In-Reply-To: <20040228063700.7223.qmail@webmail25.rediffmail.com> 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 William StanisLaus wrote: >Hi Alain and all, > >I have a small concern here on > > > >>>< ----------------------------- SNDU ----------------------------- > >>>+-+-------------------------------------------------------+--------+ >>>|D| Length | ENC |ETYPE | PDU | CRC-32 | >>>+-+-------------------------------------------------------+--------+ >>> >>> >here, always ENC which is 2 bytes wasted even if we don't support ULE encryption. > No that's not what I meant, here is the suggestion: The basic ULE frame type in this hypothetical example would be "ENCRYPTED-CONTENT" some well known code-point. This adds a null (zero byte) header, followed by a new type field. The new type field that follows carries the TYPE of the ULE payload being transported over the link. - Of course, you could define another TYPE value at this point too, such as bridging, but that also adds more overhead. > Also there is no provision for future extension of any other informations which can be added to > the ULE header, say for example LLC_SNAP support, Why would you neeed LLC_SNAP? > Section number(in case 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 Section number in ULE > .. this might be for error detection, packet loss etc). Ok, if you wanted to add other functions, you can define more headers.... >In the other approach, based on the extension header bit, we can add extension > >headers, which can chain more than one extension headers as well. >If there is no extension is required and if we are going to follow the simple > >approach, then extension header bit is set to ZERO and there is no modification > >to the present ULE draft. > > You can do it both ways.... > >Best Regards, >William. > >On Fri, 27 Feb 2004 Alain RITOUX wrote : > > >>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 Mon Mar 1 15:22: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 i21FLsnY026856 for ; Mon, 1 Mar 2004 15:21:54 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i21FLsXc026855 for ip-dvb-subscribed-users; Mon, 1 Mar 2004 15:21: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 [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 i21FLPCQ026833 for ; Mon, 1 Mar 2004 15:21:25 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; Mon, 1 Mar 2004 10:21:26 -0500 Received: (private information removed) Message-ID: <5A659834E1607E4EBD72FCE2FE5C9CF102FEBF57@mail.NAB.ORG> From: "Allison, Art" To: "'ip-dvb@erg.abdn.ac.uk'" Cc: Alain RITOUX Subject: RE: ULE encryption Support. Date: Mon, 1 Mar 2004 10:21:24 -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 Thanks for the post about layering, Gorry.. it does seem that we don't stick to the 'right' place in the stack in all out posts. As far as the place in the layers for duplication of transport packets, that seems to me to be at the MPEG-2 transport layer, not above it. I read Gorry pointing to the first phrase of #2 when he says this group is focused on #2 as the rest is explanation of the underlying protocol. I agree that the layer just above the MPEG-2 transport is the focus of this group. Given that focus, before adding an additional protection means at this layer, it seems that the person suggesting such should bear the burden of asserting what improvement in BER can be expected over that provided by the lower and higher layers. I am skeptical that one can add error correction at this layer that any significant benefit in a real world RF channel. I say this because: If the RF channel outage/fade/interference is large enough to corrupt data beyond the RF recovery means ability to correct, it is unlikely that error correction will help (theoretically one would need to have a large temporal spread of data with error correction overhead to cover such a condition - which would be a significant complication with latency impact). It is very unlikely that a bad packet is actually in the data and falsely signaled as good, (i.e., the MPEG-2 packet error bit not set when the packet is bad). I don't know the FEC in OFDM or QPSK systems in use; but the FEC in 8VSB has a lower false-positive error rate than CD-ROM. I would expect that to be ~true of any RF layer FEC. So additional error detection at the layer in this group's scope seems unlikely to help in the severe outage case and unlikely to help in the very-low-probability case where the complex pattern of bit errors would cause a false positive. In just what condition/case does it help? And by how much BER improvement? 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: Monday, March 01, 2004 8:26 AM To: ip-dvb@erg.abdn.ac.uk Cc: Alain RITOUX Subject: Re: ULE encryption Support. Just a word or two, to try and help people establish the correct context, to communicate... 1) FEC coding is used as a part of physical layer for most media, i.e. below the MPEG-2 bit stream. This type of FEC is NOT the concern of this group and is sepcified by others. 2) Coding may also be used above the MPEG-2 TS layer, in some scenarios to further improve robustness to loss (i.e. corruption of the MPEG-2 TS packet stream). The duplication method, discussed in the "continuity counter" thread is an example of this - albeit rather crude from a coding point of view, and within the transport stream. A "recent" extension to MPE, added the optional ability to do more powerful FEC coding as a part of the encapsulation. 3) FEC coding may also be done above the transport layer, to protect the end-to-end communication from the effects of packet loss. For more details of such schemes see the AVT and RMT WGs of the IETF. So, (2) is what relates to this WG. Gorry From owner-ip-dvb@erg.abdn.ac.uk Mon Mar 1 14:55:40 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 i21EtIb8025968 for ; Mon, 1 Mar 2004 14:55:18 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i21EtIUn025967 for ip-dvb-subscribed-users; Mon, 1 Mar 2004 14:55: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 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 i21Esr7W025947 for ; Mon, 1 Mar 2004 14:54:53 GMT Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id 4A98C6E0 for ; Mon, 1 Mar 2004 15:54:54 +0100 (CET) Received: from 6wind.com (vouvray.dev.6wind.com [10.16.0.135]) by intranet.6wind.com (Postfix) with ESMTP id 1E23F254; Mon, 1 Mar 2004 15:54:54 +0100 (CET) Message-ID: <40434FB7.9050107@6wind.com> Date: Mon, 01 Mar 2004 15:59:03 +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 extensions References: <20040228063700.7223.qmail@webmail25.rediffmail.com> <40433FA6.4040504@erg.abdn.ac.uk> In-Reply-To: <40433FA6.4040504@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 Gorry Fairhurst wrote: > > > William StanisLaus wrote: > >> Hi Alain and all, >> >> I have a small concern here on >> >> >>>> < ----------------------------- SNDU ----------------------------- > >>>> +-+-------------------------------------------------------+--------+ >>>> |D| Length | ENC |ETYPE | PDU | CRC-32 | >>>> +-+-------------------------------------------------------+--------+ >>>> >> >> here, always ENC which is 2 bytes wasted even if we don't support ULE >> encryption. >> > > No that's not what I meant, here is the suggestion: > > The basic ULE frame type in this hypothetical example would be > "ENCRYPTED-CONTENT" > some well known code-point. This adds a null (zero byte) header, > followed by a new type field. > > The new type field that follows carries the TYPE of the ULE payload > being transported over the link. > - Of course, you could define another TYPE value at this point too, > such as bridging, but that also adds more overhead. OK I got it. I fact, if there is a code point for that with well known/defined data, the the "encrypt" thing can de fully done. What William and I were proposing was a more generic mechanism, available for extension-to-come. So what we proposed was to introduce an Extension Header format : - The presence of extension headers is specified by a bit in ULE header - Each extension header has a bit telling whether what follows is the payload or another extension header. - Each extension header includes its own length, so Ext Header chain can be parsed blindly - Each Extension Header includes its own type, and this type has a field indicating what to do if this type is unknown. + drop SNDU + ignore, and parse blindly to the next (if present) Ext Header or to the playload. In fact the generic Ext Header processing would then be MANDATORY It will allow implem to parse blindly unknwon Ext Headers The "encryption" stuff can easily fit into this generic scheme with the same overhead. The plus is that it would be able to live its own life independanlty from (ExtHdr aware)ULE base specs. What is the feeling of the WG on this header chaining ? 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 Mon Mar 1 15:36: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 i21Fa9n5027434 for ; Mon, 1 Mar 2004 15:36:09 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i21Fa9N3027433 for ip-dvb-subscribed-users; Mon, 1 Mar 2004 15:36: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 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 i21FZXVK027401 for ; Mon, 1 Mar 2004 15:35:33 GMT Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id 173A966E; Mon, 1 Mar 2004 16:35:34 +0100 (CET) Received: from 6wind.com (vouvray.dev.6wind.com [10.16.0.135]) by intranet.6wind.com (Postfix) with ESMTP id 03E8015; Mon, 1 Mar 2004 16:35:34 +0100 (CET) Message-ID: <4043593F.6020306@6wind.com> Date: Mon, 01 Mar 2004 16:39:43 +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: "Allison, Art" Cc: "'ip-dvb@erg.abdn.ac.uk'" Subject: Re: ULE encryption Support. References: <5A659834E1607E4EBD72FCE2FE5C9CF102FEBF57@mail.NAB.ORG> In-Reply-To: <5A659834E1607E4EBD72FCE2FE5C9CF102FEBF57@mail.NAB.ORG> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Allison, Art wrote: > Thanks for the post about layering, Gorry.. it does seem that we don't stick > to the 'right' place in the stack in all out posts. > As far as the place in the layers for duplication of transport packets, that > seems to me to be at the MPEG-2 transport layer, not above it. I read > Gorry pointing to the first phrase of #2 when he says this group is focused > on #2 as the rest is explanation of the underlying protocol. I defintively agree. All proposition that I made, where about the possibility of Extension Headers, and its mechanisms. The reference about encryption and/or FEC was for me JUST an example of usage. It DOES NOT imply support for the FEC / encrpyt / whatever function at this level. I should have kept the 2 subjects more separated. In fact : - for FEC, I have no expertise on that subject, and have no opinion. - for Encrypt, I believe it is not in the correct layer to do 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 Mon Mar 1 15:45: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 i21FijDa027780 for ; Mon, 1 Mar 2004 15:44:45 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i21Fiigj027779 for ip-dvb-subscribed-users; Mon, 1 Mar 2004 15:44: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 [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 i21Fi86c027733 for ; Mon, 1 Mar 2004 15:44: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; Mon, 1 Mar 2004 10:44:09 -0500 Received: (private information removed) Message-ID: <5A659834E1607E4EBD72FCE2FE5C9CF102FEBF58@mail.NAB.ORG> From: "Allison, Art" To: "'ip-dvb@erg.abdn.ac.uk'" Subject: RE: ULE encryption Support. Date: Mon, 1 Mar 2004 10:44:05 -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 So, if we should not encrypt at this layer [agree with Alain] and we should not put additional error correction at this layer.. it seems we no longer have a reason to add more than a just-in-case escape bit just in case a yet-to-be-invented function is needed someday. Art ::{)> Art Allison Director Advanced Engineering NAB 1771 N St NW Washington DC 20036 202 429 5418 -----Original Message----- From: Alain RITOUX [mailto:alain.ritoux@6wind.com] Sent: Monday, March 01, 2004 10:40 AM To: Allison, Art Cc: 'ip-dvb@erg.abdn.ac.uk' Subject: Re: ULE encryption Support. Allison, Art wrote: > Thanks for the post about layering, Gorry.. it does seem that we don't stick > to the 'right' place in the stack in all out posts. > As far as the place in the layers for duplication of transport packets, that > seems to me to be at the MPEG-2 transport layer, not above it. I read > Gorry pointing to the first phrase of #2 when he says this group is focused > on #2 as the rest is explanation of the underlying protocol. I defintively agree. All proposition that I made, where about the possibility of Extension Headers, and its mechanisms. The reference about encryption and/or FEC was for me JUST an example of usage. It DOES NOT imply support for the FEC / encrpyt / whatever function at this level. I should have kept the 2 subjects more separated. In fact : - for FEC, I have no expertise on that subject, and have no opinion. - for Encrypt, I believe it is not in the correct layer to do 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 Mon Mar 1 17:07:42 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 i21H69Fn001001 for ; Mon, 1 Mar 2004 17:06:09 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i21H67uJ000997 for ip-dvb-subscribed-users; Mon, 1 Mar 2004 17:06:08 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 i21H44xh000894 for ; Mon, 1 Mar 2004 17:04:05 GMT Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id 3F750F5 for ; Mon, 1 Mar 2004 18:04:05 +0100 (CET) Received: from 6wind.com (vouvray.dev.6wind.com [10.16.0.135]) by intranet.6wind.com (Postfix) with ESMTP id 2080835; Mon, 1 Mar 2004 18:04:05 +0100 (CET) Message-ID: <40436DFE.7030500@6wind.com> Date: Mon, 01 Mar 2004 18:08:14 +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 encryption Support. References: <5A659834E1607E4EBD72FCE2FE5C9CF102FEBF58@mail.NAB.ORG> In-Reply-To: <5A659834E1607E4EBD72FCE2FE5C9CF102FEBF58@mail.NAB.ORG> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Allison, Art wrote: > So, if we should not encrypt at this layer [agree with Alain] and we should > not put additional error correction at this layer.. it seems we no longer > have a reason to add more than a just-in-case escape bit just in case a > yet-to-be-invented function is needed someday. Not totally agree. This "reserve" may have no usage now, but the mechanism is not that heavy, and once it is done, it will allow introduciton of "possible" ext headers in a backward-compatible way, which seems to me worth the price. 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 Mon Mar 1 19:20:45 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 i21JIUp7007204 for ; Mon, 1 Mar 2004 19:18:30 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i21JISHF007203 for ip-dvb-subscribed-users; Mon, 1 Mar 2004 19:18: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 [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 i21JENaR006987 for ; Mon, 1 Mar 2004 19:14:24 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; Mon, 1 Mar 2004 14:14:25 -0500 Received: (private information removed) Message-ID: <5A659834E1607E4EBD72FCE2FE5C9CF102FEBF59@mail.NAB.ORG> From: "Allison, Art" To: "'ip-dvb@erg.abdn.ac.uk'" Subject: RE: ULE encryption Support. Date: Mon, 1 Mar 2004 14:14:23 -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-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk As to backwards compatibility, no mater how it is defined, the initial products will not process and use newly defined data. So, even if the original product can process the larger header, it can do nothing with data with a new meaning defined after the product is built: With a bit = 0 it is the 'Rev0' standard device Gen0. With a bit = 1 a Gen0 device cannot process the data, but can process all Rev0 data. With a series of bits, a Gen0 device cannot process the data, but can process all Rev0 data. At each header instance a different type can be signaled. Bits are bucks for broadcasters, and each one has a fixed pipe size, so we must resist sending any more than absolutely needed. I can make a case for NO expansion bit, as the new service can be defined when the application is defined and new devices can process it -- but 1 bit per header is ok. Please help me see what I must be missing that justifies use of more bits... Art ::{)> Art Allison Director Advanced Engineering NAB 1771 N St NW Washington DC 20036 202 429 5418 -----Original Message----- From: Alain RITOUX [mailto:alain.ritoux@6wind.com] Sent: Monday, March 01, 2004 12:08 PM To: ip-dvb@erg.abdn.ac.uk Subject: Re: ULE encryption Support. Allison, Art wrote: > So, if we should not encrypt at this layer [agree with Alain] and we should > not put additional error correction at this layer.. it seems we no longer > have a reason to add more than a just-in-case escape bit just in case a > yet-to-be-invented function is needed someday. Not totally agree. This "reserve" may have no usage now, but the mechanism is not that heavy, and once it is done, it will allow introduciton of "possible" ext headers in a backward-compatible way, which seems to me worth the price. 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 Mon Mar 1 20:57:51 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 i21KLtA4010545 for ; Mon, 1 Mar 2004 20:21:55 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i21KLshH010544 for ip-dvb-subscribed-users; Mon, 1 Mar 2004 20:21: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 i21KHb72010304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 1 Mar 2004 20:17:39 GMT Message-ID: <40439A62.7070209@erg.abdn.ac.uk> Date: Mon, 01 Mar 2004 20:17:38 +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: ULE encryption Support. References: <5A659834E1607E4EBD72FCE2FE5C9CF102FEBF59@mail.NAB.ORG> In-Reply-To: <5A659834E1607E4EBD72FCE2FE5C9CF102FEBF59@mail.NAB.ORG> 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 X-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk Art, I think the scheme being talked about is rather like IPv6 extension headers. Devices that don't understand the extension headers, simply ignore the extensions and continue to process the packet. A similar thing could be done at the link layer for specific ULE payloads that would benefit from this. As you say, no requirements have yet been written for ULE that match this need, although they may appear sooner (or even later). The question that needs to be addressed by this WG is should ULE allow such extension headers to be defined in future? We don't have to define them now, but we will have to define the MECHANISM by which they can be later added. If we don't include this possibility now, we'd have to version the whole protocol to get this functionality later (this would have a serious deployment issues). Gorry Allison, Art wrote: >As to backwards compatibility, no mater how it is defined, the initial >products will not process and use newly defined data. So, even if the >original product can process the larger header, it can do nothing with data >with a new meaning defined after the product is built: >With a bit = 0 it is the 'Rev0' standard device Gen0. >With a bit = 1 a Gen0 device cannot process the data, but can process >all Rev0 data. >With a series of bits, a Gen0 device cannot process the data, but can >process all Rev0 data. >At each header instance a different type can be signaled. > >Bits are bucks for broadcasters, and each one has a fixed pipe size, so we >must resist sending any more than absolutely needed. I can make a case for >NO expansion bit, as the new service can be defined when the application is >defined and new devices can process it -- but 1 bit per header is ok. > >Please help me see what I must be missing that justifies use of more bits... >Art >::{)> >Art Allison >Director Advanced Engineering >NAB >1771 N St NW >Washington DC 20036 >202 429 5418 > > >-----Original Message----- >From: Alain RITOUX [mailto:alain.ritoux@6wind.com] >Sent: Monday, March 01, 2004 12:08 PM >To: ip-dvb@erg.abdn.ac.uk >Subject: Re: ULE encryption Support. > > > > >Allison, Art wrote: > > > >>So, if we should not encrypt at this layer [agree with Alain] and we >> >> >should > > >>not put additional error correction at this layer.. it seems we no longer >>have a reason to add more than a just-in-case escape bit just in case a >>yet-to-be-invented function is needed someday. >> >> > >Not totally agree. This "reserve" may have no usage now, but the >mechanism is not that heavy, and once it is done, it will allow >introduciton of "possible" ext headers in a backward-compatible >way, which seems to me worth the price. > >Cheers >Alain. > > From owner-ip-dvb@erg.abdn.ac.uk Mon Mar 1 22:12:26 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 i21MBtAX015217 for ; Mon, 1 Mar 2004 22:11:55 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i21MBs1V015216 for ip-dvb-subscribed-users; Mon, 1 Mar 2004 22:11: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 [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 i21MBLfv015194 for ; Mon, 1 Mar 2004 22:11:21 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; Mon, 1 Mar 2004 17:11:22 -0500 Received: (private information removed) Message-ID: <5A659834E1607E4EBD72FCE2FE5C9CF102FEBF63@mail.NAB.ORG> From: "Allison, Art" To: "'ip-dvb@erg.abdn.ac.uk'" Subject: RE: ULE encryption Support. Date: Mon, 1 Mar 2004 17:11:21 -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 X-ERG-MailScanner-SpamScore: s, s Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk It is always a tough call to decide where the tradeoff point is between general capability and efficiency... when one sees that there might be such extensions in the future one certainly should allow for the expansion to avoid the problem of versioning the recommendation. For a more flexible method we could use the DSM-CC data carousel.. but that is too flexible and has too much overhead... In this case adding extension headers seems to be overkill because it seems very remote that they will ever be used. The functional capability of this layer be stable. So, 1 bits can be escape.. and then define more in that...but a different structure would follow. But if you want more, two bits would provide ability to add 2 new unforeseen extensions and then an escape to a different structure. Three bits provides 6 new explicitly defined versions, then the escape. ..... Even conservatively, how many bits do we need for this just in case? Is 2 enough? 3? 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: Monday, March 01, 2004 3:18 PM To: ip-dvb@erg.abdn.ac.uk Subject: Re: ULE encryption Support. Art, I think the scheme being talked about is rather like IPv6 extension headers. Devices that don't understand the extension headers, simply ignore the extensions and continue to process the packet. A similar thing could be done at the link layer for specific ULE payloads that would benefit from this. As you say, no requirements have yet been written for ULE that match this need, although they may appear sooner (or even later). The question that needs to be addressed by this WG is should ULE allow such extension headers to be defined in future? We don't have to define them now, but we will have to define the MECHANISM by which they can be later added. If we don't include this possibility now, we'd have to version the whole protocol to get this functionality later (this would have a serious deployment issues). Gorry Allison, Art wrote: >As to backwards compatibility, no mater how it is defined, the initial >products will not process and use newly defined data. So, even if the >original product can process the larger header, it can do nothing with data >with a new meaning defined after the product is built: >With a bit = 0 it is the 'Rev0' standard device Gen0. >With a bit = 1 a Gen0 device cannot process the data, but can process >all Rev0 data. >With a series of bits, a Gen0 device cannot process the data, but can >process all Rev0 data. >At each header instance a different type can be signaled. > >Bits are bucks for broadcasters, and each one has a fixed pipe size, so we >must resist sending any more than absolutely needed. I can make a case for >NO expansion bit, as the new service can be defined when the application is >defined and new devices can process it -- but 1 bit per header is ok. > >Please help me see what I must be missing that justifies use of more bits... >Art >::{)> >Art Allison >Director Advanced Engineering >NAB >1771 N St NW >Washington DC 20036 >202 429 5418 > > >-----Original Message----- >From: Alain RITOUX [mailto:alain.ritoux@6wind.com] >Sent: Monday, March 01, 2004 12:08 PM >To: ip-dvb@erg.abdn.ac.uk >Subject: Re: ULE encryption Support. > > > > >Allison, Art wrote: > > > >>So, if we should not encrypt at this layer [agree with Alain] and we >> >> >should > > >>not put additional error correction at this layer.. it seems we no longer >>have a reason to add more than a just-in-case escape bit just in case a >>yet-to-be-invented function is needed someday. >> >> > >Not totally agree. This "reserve" may have no usage now, but the >mechanism is not that heavy, and once it is done, it will allow >introduciton of "possible" ext headers in a backward-compatible >way, which seems to me worth the price. > >Cheers >Alain. > > From owner-ip-dvb@erg.abdn.ac.uk Mon Mar 1 23:09: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 i21N8kq9017084 for ; Mon, 1 Mar 2004 23:08:46 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i21N8kKi017083 for ip-dvb-subscribed-users; Mon, 1 Mar 2004 23:08: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 ladron.cs.nmt.edu (ladron.cs.nmt.edu [129.138.6.58]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i21N7Xc4017031 for ; Mon, 1 Mar 2004 23:07:34 GMT Received: from Clausen (attila.cs.nmt.edu [129.138.6.121]) by ladron.cs.nmt.edu (8.11.6/8.11.2) with SMTP id i21N4P416952 for ; Mon, 1 Mar 2004 16:04:26 -0700 Message-ID: <005601c3ffea$ab0afcc0$79068a81@Clausen> From: "HDClausen" To: References: <5A659834E1607E4EBD72FCE2FE5C9CF102FEBF63@mail.NAB.ORG> Subject: Re: ULE encryption Support. Date: Mon, 1 Mar 2004 16:09:44 -0800 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-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 > It is always a tough call to decide where the tradeoff point is between > general capability and efficiency... when one sees that there might be such > extensions in the future one certainly should allow for the expansion to > avoid the problem of versioning the recommendation. > The idea was always to have an encapsulation mechanism that is as lean as possible ("every bit counts on a satellite channel") but allows for any user to encapsulate whatever next level protocol they can afford. So the functionality should be primarily confined to segmentation and reassembly. Everything else such as encryption or FEC should be done on the next level of processing - meaning the next level header pretty much in the same manner as IPv6 does on the network layer. > For a more flexible method we could use the DSM-CC data carousel.. but that > is too flexible and has too much overhead... > agree > In this case adding extension headers seems to be overkill because it seems > very remote that they will ever be used. The functional capability of this > layer be stable. > ULE should just provide a basic functionality and leave any extensions to the next layer of processing. If people need that functionality they will have to pay for the additional header fields without enforcing additional overhead on the basic service. > So, 1 bits can be escape.. and then define more in that...but a different > structure would follow. > But if you want more, two bits would provide ability to add 2 new unforeseen > extensions and then an escape to a different structure. Three bits provides > 6 new explicitly defined versions, then the escape. > ..... > > Even conservatively, how many bits do we need for this just in case? Is 2 > enough? 3? > I vote for 1 bit - "next level header follows". --Horst Clausen NMT (formerly Univ. Salzburg) > > 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: Monday, March 01, 2004 3:18 PM > To: ip-dvb@erg.abdn.ac.uk > Subject: Re: ULE encryption Support. > > > Art, I think the scheme being talked about is rather like IPv6 > extension headers. Devices that don't understand the extension > headers, simply ignore the extensions and continue to process the packet. > A similar thing could be done at the link layer for specific ULE payloads > that would benefit from this. As you say, no requirements have yet been > written for ULE that match this need, although they may appear sooner > (or even later). > > The question that needs to be addressed by this WG is should ULE allow > such extension headers to be defined in future? > > We don't have to define them now, but we will have to define the > MECHANISM by > which they can be later added. If we don't include this possibility now, > we'd have to version the whole protocol to get this functionality later > (this would have a serious deployment issues). > > Gorry > > Allison, Art wrote: > > >As to backwards compatibility, no mater how it is defined, the initial > >products will not process and use newly defined data. So, even if the > >original product can process the larger header, it can do nothing with data > >with a new meaning defined after the product is built: > >With a bit = 0 it is the 'Rev0' standard device Gen0. > >With a bit = 1 a Gen0 device cannot process the data, but can process > >all Rev0 data. > >With a series of bits, a Gen0 device cannot process the data, but can > >process all Rev0 data. > >At each header instance a different type can be signaled. > > > >Bits are bucks for broadcasters, and each one has a fixed pipe size, so we > >must resist sending any more than absolutely needed. I can make a case for > >NO expansion bit, as the new service can be defined when the application is > >defined and new devices can process it -- but 1 bit per header is ok. > > > >Please help me see what I must be missing that justifies use of more > bits... > >Art > >::{)> > >Art Allison > >Director Advanced Engineering > >NAB > >1771 N St NW > >Washington DC 20036 > >202 429 5418 > > > > > >-----Original Message----- > >From: Alain RITOUX [mailto:alain.ritoux@6wind.com] > >Sent: Monday, March 01, 2004 12:08 PM > >To: ip-dvb@erg.abdn.ac.uk > >Subject: Re: ULE encryption Support. > > > > > > > > > >Allison, Art wrote: > > > > > > > >>So, if we should not encrypt at this layer [agree with Alain] and we > >> > >> > >should > > > > > >>not put additional error correction at this layer.. it seems we no longer > >>have a reason to add more than a just-in-case escape bit just in case a > >>yet-to-be-invented function is needed someday. > >> > >> > > > >Not totally agree. This "reserve" may have no usage now, but the > >mechanism is not that heavy, and once it is done, it will allow > >introduciton of "possible" ext headers in a backward-compatible > >way, which seems to me worth the price. > > > >Cheers > >Alain. > > > > > From owner-ip-dvb@erg.abdn.ac.uk Tue Mar 2 05:07:10 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 i2256fvC029590 for ; Tue, 2 Mar 2004 05:06:41 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2256fS7029589 for ip-dvb-subscribed-users; Tue, 2 Mar 2004 05:06: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 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 i22567Gq029562 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 2 Mar 2004 05:06:09 GMT Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i22562T18698; Tue, 2 Mar 2004 07:06:02 +0200 (EET) X-Scanned: Tue, 2 Mar 2004 07:05:32 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i2255WKg000706; Tue, 2 Mar 2004 07:05:32 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00Gq4a34; Tue, 02 Mar 2004 07:05:32 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2255V718424; Tue, 2 Mar 2004 07:05:31 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 2 Mar 2004 07:05:32 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 2 Mar 2004 07:05:31 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 2 Mar 2004 07:05:33 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IPDVB bar-bof in Seoul X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Tue, 2 Mar 2004 07:05:30 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPDVB bar-bof in Seoul Thread-Index: AcQADBDggu8HXlXXTVaklwoMl7r7KgABqO8A From: To: Cc: , , , , X-OriginalArrivalTime: 02 Mar 2004 05:05:33.0791 (UTC) FILETIME=[FDEF3EF0:01C40013] 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 i2256c8g029581 Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Since Bobby London's only opens at 5pm let's meet in the lobby bar on the ground floor @ 15:15 (the one wil the very high ceiling and occassional live performances - and very expensive drinks - and with the waterfall view). (I guess the fact I only just learned that the pub doesn't open before 5pm confirms that I am not a compulsive pub goer :) Cheers, Rod. From owner-ip-dvb@erg.abdn.ac.uk Tue Mar 2 08:35: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 i228Z7jQ007347 for ; Tue, 2 Mar 2004 08:35:07 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i228Z6dD007346 for ip-dvb-subscribed-users; Tue, 2 Mar 2004 08:35:06 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 i228Dm6R006188 for ; Tue, 2 Mar 2004 08:13:49 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 JAA06424 for ; Tue, 2 Mar 2004 09:13:48 +0100 (MET) From: "Bernhard Collini-Nocker" To: Subject: RE: ULE encryption Support. Date: Tue, 2 Mar 2004 09:13:48 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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: <5A659834E1607E4EBD72FCE2FE5C9CF102FEBF59@mail.NAB.ORG> 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, [snip] > > Bits are bucks for broadcasters, and each one has a fixed pipe size, so we > must resist sending any more than absolutely needed. I can make > a case for > NO expansion bit, as the new service can be defined when the > application is > defined and new devices can process it -- but 1 bit per header is ok. Do you think it would be wise to introduce another one or two bits telling the receiver what to do if the (optional) next header is not understood: - discard packet - ignore header or something else? Any opinions? Bernhard From owner-ip-dvb@erg.abdn.ac.uk Tue Mar 2 09:39:56 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 i229dMWS009839 for ; Tue, 2 Mar 2004 09:39:22 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i229dMBY009838 for ip-dvb-subscribed-users; Tue, 2 Mar 2004 09:39: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 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 i229cWeC009790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 2 Mar 2004 09:38:33 GMT Message-ID: <40445619.3030204@erg.abdn.ac.uk> Date: Tue, 02 Mar 2004 09:38:33 +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: ULE encryption Support. References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk The current ID (-02) says DISCARD if TYPE is unrecognised, this is a pre-requisite anyway. I'd go for IGNORE if EXTENSION is unrecognised, an extension adds functionality, and so if the Receiver recognises the TYPE, it can still process the header. Do we need more complex functions? Gorry Bernhard Collini-Nocker wrote: >Hello, > >[snip] > > >>Bits are bucks for broadcasters, and each one has a fixed pipe size, so we >>must resist sending any more than absolutely needed. I can make >>a case for >>NO expansion bit, as the new service can be defined when the >>application is >>defined and new devices can process it -- but 1 bit per header is ok. >> >> > >Do you think it would be wise to introduce another one or two bits telling >the receiver what to do if the (optional) next header is not understood: >- discard packet >- ignore header >or something else? > >Any opinions? > >Bernhard > > > > From h.v.r@easynet.be Tue Mar 2 17:54:58 2004 Received: from smtp2.mail.be.easynet.net (smtp2.mail.be.easynet.net [IPv6:2001:6f8:200:1::1:76]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i22HrncP029060 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 2 Mar 2004 17:53:50 GMT Received: from 213-193-167-2.adsl.easynet.be ([213.193.167.2] helo=linux) by smtp2.mail.be.easynet.net with esmtp (Exim 4.30) id 1AyE5V-0004mM-QK for ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk; Tue, 02 Mar 2004 18:53:49 +0100 Content-Type: text/plain; charset="us-ascii" From: hugo van ruyskensvelde To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk Subject: unsubscribe Date: Tue, 2 Mar 2004 18:54:12 +0100 User-Agent: KMail/1.4.3 MIME-Version: 1.0 Message-Id: <200403021854.12821.h.v.r@easynet.be> X-ERG-MailScanner: Found to be clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by erg.abdn.ac.uk id i22HrncP029060 unsubscribe From owner-ip-dvb@erg.abdn.ac.uk Tue Mar 2 20:33: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 i22KXOHa005035 for ; Tue, 2 Mar 2004 20:33:24 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i22KXOXY005034 for ip-dvb-subscribed-users; Tue, 2 Mar 2004 20:33: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 mail1.iabg.de (mail1.iabg.de [194.139.245.9]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i22KWn7I005003 for ; Tue, 2 Mar 2004 20:32:49 GMT Received: from mail1.iabg.de (localhost [127.0.0.1]) by localhost (Mailserver1 IABG) with ESMTP id 3564C967C for ; Tue, 2 Mar 2004 21:32:45 +0100 (CET) Received: from exchange03.iabg.de (exchange03.iabg.de [10.128.200.37]) by mail1.iabg.de (Mailserver1 IABG) with SMTP id 244019677 for ; Tue, 2 Mar 2004 21:32:45 +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: Interoperability test document based on ULE available Date: Tue, 2 Mar 2004 21:32:45 +0100 Message-ID: <69A5E767EC979846826F566C7932A3F2133526@exchange03.iabg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Interoperability test document based on ULE available Thread-Index: AcQAlYTDXWMdSv4mSDqXO2+9Yuf9YQ== 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 i22KXNIS005030 Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Dear WG members, IABG and 6WIND are happy to provide interoperability test results from a joint test event with GCS / University of Salzburg. The aim of the test was to proof interoperability between the ULE implementation of 6WIND (6WINDGate 6221 acting as DVB-S sender / receiver) and the ULE implementation of GCS (Open DVB Gateway acting as DVB-S sender, Linux based PC with Pent@Value / Technotrend card acting as receiver) and to provide dumps of TS-cells to the ipdvb WG. The ULE implementation is based on draft-fair-ipdvb-ule-02. The test were performed by generating IPv4 and IPv6 traffic with ping applications, utilizing different packet sizes to trigger ULE corner cases. In summary we are happy to report that the interoperability tests have been executed successfully, i.e. the ULE implementations of 6WIND and GCS are interoperable using a 6WINDGate or ODG as DVB-S sender and a 6WINDGate or Linux PC with Pent@Value or Technotrend DVB-S card as receiver. The test document (in PDF format) is accessible from from our ESA project webpage at http://telecom.esa.int/telecom/www/object/index.cfm?fobjectid=11271 (see "Documentation -> IPDVB Interoperability Test Results" at the bottom of the right navigation bar) We would also be happy to provide a copy of the document for the IP over MPEG-2/DVB webpage hosted by Gorry. With best regards, Gerhard Gessler (IABG) Wolfgang Fritsche (IABG) Alain Ritoux (6WIND) -------------------------------------------- Gerhard Gessler Communication Networks, IABG mbH Einsteinstr. 20 85521 Ottobrunn, Germany Telefon: +49 89 6088 - 2021 Fax: +49 89 6088 - 2845 E-Mail: gessler@iabg.de From owner-ip-dvb@erg.abdn.ac.uk Wed Mar 3 06:05: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 i2364ZKu025912 for ; Wed, 3 Mar 2004 06:04:35 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2364ZnI025911 for ip-dvb-subscribed-users; Wed, 3 Mar 2004 06:04: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 fsnt.future.futsoft.com ([203.197.140.35]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i23636R9025842 for ; Wed, 3 Mar 2004 06:03:10 GMT Received: from kailash.future.futsoft.com (unverified [203.197.140.36]) by fsnt.future.futsoft.com (Content Technologies SMTPRS 4.3.6) with ESMTP id for ; Wed, 3 Mar 2004 11:33:25 +0530 Received: from williams (williams.future.futsoft.com [10.8.3.24]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id i235xhb07181 for ; Wed, 3 Mar 2004 11:29:43 +0530 From: "William StanisLaus" To: Subject: RE: ULE encryption Support. Date: Wed, 3 Mar 2004 11:31:41 +0530 Message-ID: <000f01c400e5$00550860$1803080a@future.futsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <5A659834E1607E4EBD72FCE2FE5C9CF102FEBF63@mail.NAB.ORG> 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, Art, the proposal for extension bit, works like a chain header.. i.e. Please refer the Alain's previous post. Regards, William >> >> I have a small concern here on >> >> >>>> < ----------------------------- SNDU ----------------------------- > >>>> +-+-------------------------------------------------------+--------+ >>>> |D| Length | ENC |ETYPE | PDU | CRC-32 | >>>> +-+-------------------------------------------------------+--------+ >>>> >> >> here, always ENC which is 2 bytes wasted even if we don't support ULE >> encryption. >> > > No that's not what I meant, here is the suggestion: > > The basic ULE frame type in this hypothetical example would be > "ENCRYPTED-CONTENT" > some well known code-point. This adds a null (zero byte) header, > followed by a new type field. > > The new type field that follows carries the TYPE of the ULE payload > being transported over the link. > - Of course, you could define another TYPE value at this point too, > such as bridging, but that also adds more overhead. OK I got it. I fact, if there is a code point for that with well known/defined data, the the "encrypt" thing can de fully done. What William and I were proposing was a more generic mechanism, available for extension-to-come. So what we proposed was to introduce an Extension Header format : - The presence of extension headers is specified by a bit in ULE header - Each extension header has a bit telling whether what follows is the payload or another extension header. - Each extension header includes its own length, so Ext Header chain can be parsed blindly - Each Extension Header includes its own type, and this type has a field indicating what to do if this type is unknown. + drop SNDU + ignore, and parse blindly to the next (if present) Ext Header or to the playload. In fact the generic Ext Header processing would then be MANDATORY It will allow implem to parse blindly unknwon Ext Headers The "encryption" stuff can easily fit into this generic scheme with the same overhead. The plus is that it would be able to live its own life independanlty from (ExtHdr aware)ULE base specs. What is the feeling of the WG on this header chaining ? Cheers. Alain. -----Original Message----- From: owner-ip-dvb@erg.abdn.ac.uk [mailto:owner-ip-dvb@erg.abdn.ac.uk]On Behalf Of Allison, Art Sent: Tuesday, March 02, 2004 3:41 AM To: 'ip-dvb@erg.abdn.ac.uk' Subject: RE: ULE encryption Support. It is always a tough call to decide where the tradeoff point is between general capability and efficiency... when one sees that there might be such extensions in the future one certainly should allow for the expansion to avoid the problem of versioning the recommendation. For a more flexible method we could use the DSM-CC data carousel.. but that is too flexible and has too much overhead... In this case adding extension headers seems to be overkill because it seems very remote that they will ever be used. The functional capability of this layer be stable. So, 1 bits can be escape.. and then define more in that...but a different structure would follow. But if you want more, two bits would provide ability to add 2 new unforeseen extensions and then an escape to a different structure. Three bits provides 6 new explicitly defined versions, then the escape. ..... Even conservatively, how many bits do we need for this just in case? Is 2 enough? 3? 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: Monday, March 01, 2004 3:18 PM To: ip-dvb@erg.abdn.ac.uk Subject: Re: ULE encryption Support. Art, I think the scheme being talked about is rather like IPv6 extension headers. Devices that don't understand the extension headers, simply ignore the extensions and continue to process the packet. A similar thing could be done at the link layer for specific ULE payloads that would benefit from this. As you say, no requirements have yet been written for ULE that match this need, although they may appear sooner (or even later). The question that needs to be addressed by this WG is should ULE allow such extension headers to be defined in future? We don't have to define them now, but we will have to define the MECHANISM by which they can be later added. If we don't include this possibility now, we'd have to version the whole protocol to get this functionality later (this would have a serious deployment issues). Gorry Allison, Art wrote: >As to backwards compatibility, no mater how it is defined, the initial >products will not process and use newly defined data. So, even if the >original product can process the larger header, it can do nothing with data >with a new meaning defined after the product is built: >With a bit = 0 it is the 'Rev0' standard device Gen0. >With a bit = 1 a Gen0 device cannot process the data, but can process >all Rev0 data. >With a series of bits, a Gen0 device cannot process the data, but can >process all Rev0 data. >At each header instance a different type can be signaled. > >Bits are bucks for broadcasters, and each one has a fixed pipe size, so we >must resist sending any more than absolutely needed. I can make a case for >NO expansion bit, as the new service can be defined when the application is >defined and new devices can process it -- but 1 bit per header is ok. > >Please help me see what I must be missing that justifies use of more bits... >Art >::{)> >Art Allison >Director Advanced Engineering >NAB >1771 N St NW >Washington DC 20036 >202 429 5418 > > >-----Original Message----- >From: Alain RITOUX [mailto:alain.ritoux@6wind.com] >Sent: Monday, March 01, 2004 12:08 PM >To: ip-dvb@erg.abdn.ac.uk >Subject: Re: ULE encryption Support. > > > > >Allison, Art wrote: > > > >>So, if we should not encrypt at this layer [agree with Alain] and we >> >> >should > > >>not put additional error correction at this layer.. it seems we no longer >>have a reason to add more than a just-in-case escape bit just in case a >>yet-to-be-invented function is needed someday. >> >> > >Not totally agree. This "reserve" may have no usage now, but the >mechanism is not that heavy, and once it is done, it will allow >introduciton of "possible" ext headers in a backward-compatible >way, which seems to me worth the price. > >Cheers >Alain. > > *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From owner-ip-dvb@erg.abdn.ac.uk Wed Mar 3 15:49:26 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 i23FT9hs017960 for ; Wed, 3 Mar 2004 15:29:09 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i23FT8JJ017958 for ip-dvb-subscribed-users; Wed, 3 Mar 2004 15:29: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 [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 i23F2J4A016596 for ; Wed, 3 Mar 2004 15:02:21 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, 3 Mar 2004 10:02:21 -0500 Received: (private information removed) Message-ID: <5A659834E1607E4EBD72FCE2FE5C9CF102FEBF7D@mail.NAB.ORG> From: "Allison, Art" To: "'ip-dvb@erg.abdn.ac.uk'" Subject: RE: ULE encryption Support. Date: Wed, 3 Mar 2004 10:02:16 -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 William: Thanks for providing the clarification below. All: Having a single bit who's defined state indicates "extension is present" or "no extension" addresses the transmission efficiency concern. Defining the structure for that extension, just in case it is ever needed, seems to be mostly a receiving product complexity trade off. While on a conceptual level, I still don't see enough benefit from defining it now; the assessment of representatives of consumer product manufacturers would seem to be what should be given the most weight in deciding how much to make mandatory in this voluntary recommendation. Art ::{)> Art Allison Director Advanced Engineering NAB 1771 N St NW Washington DC 20036 202 429 5418 -----Original Message----- From: William StanisLaus [mailto:williams@future.futsoft.com] Sent: Wednesday, March 03, 2004 1:02 AM To: ip-dvb@erg.abdn.ac.uk Subject: RE: ULE encryption Support. Hi, Art, the proposal for extension bit, works like a chain header.. i.e. Please refer the Alain's previous post. Regards, William >> >> I have a small concern here on >> >> >>>> < ----------------------------- SNDU ----------------------------- > >>>> +-+-------------------------------------------------------+--------+ >>>> |D| Length | ENC |ETYPE | PDU | CRC-32 | >>>> +-+-------------------------------------------------------+--------+ >>>> >> >> here, always ENC which is 2 bytes wasted even if we don't support ULE >> encryption. >> > > No that's not what I meant, here is the suggestion: > > The basic ULE frame type in this hypothetical example would be > "ENCRYPTED-CONTENT" > some well known code-point. This adds a null (zero byte) header, > followed by a new type field. > > The new type field that follows carries the TYPE of the ULE payload > being transported over the link. > - Of course, you could define another TYPE value at this point too, > such as bridging, but that also adds more overhead. OK I got it. I fact, if there is a code point for that with well known/defined data, the the "encrypt" thing can de fully done. What William and I were proposing was a more generic mechanism, available for extension-to-come. So what we proposed was to introduce an Extension Header format : - The presence of extension headers is specified by a bit in ULE header - Each extension header has a bit telling whether what follows is the payload or another extension header. - Each extension header includes its own length, so Ext Header chain can be parsed blindly - Each Extension Header includes its own type, and this type has a field indicating what to do if this type is unknown. + drop SNDU + ignore, and parse blindly to the next (if present) Ext Header or to the playload. In fact the generic Ext Header processing would then be MANDATORY It will allow implem to parse blindly unknwon Ext Headers The "encryption" stuff can easily fit into this generic scheme with the same overhead. The plus is that it would be able to live its own life independanlty from (ExtHdr aware)ULE base specs. What is the feeling of the WG on this header chaining ? Cheers. Alain. -----Original Message----- From: owner-ip-dvb@erg.abdn.ac.uk [mailto:owner-ip-dvb@erg.abdn.ac.uk]On Behalf Of Allison, Art Sent: Tuesday, March 02, 2004 3:41 AM To: 'ip-dvb@erg.abdn.ac.uk' Subject: RE: ULE encryption Support. It is always a tough call to decide where the tradeoff point is between general capability and efficiency... when one sees that there might be such extensions in the future one certainly should allow for the expansion to avoid the problem of versioning the recommendation. For a more flexible method we could use the DSM-CC data carousel.. but that is too flexible and has too much overhead... In this case adding extension headers seems to be overkill because it seems very remote that they will ever be used. The functional capability of this layer be stable. So, 1 bits can be escape.. and then define more in that...but a different structure would follow. But if you want more, two bits would provide ability to add 2 new unforeseen extensions and then an escape to a different structure. Three bits provides 6 new explicitly defined versions, then the escape. ..... Even conservatively, how many bits do we need for this just in case? Is 2 enough? 3? 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: Monday, March 01, 2004 3:18 PM To: ip-dvb@erg.abdn.ac.uk Subject: Re: ULE encryption Support. Art, I think the scheme being talked about is rather like IPv6 extension headers. Devices that don't understand the extension headers, simply ignore the extensions and continue to process the packet. A similar thing could be done at the link layer for specific ULE payloads that would benefit from this. As you say, no requirements have yet been written for ULE that match this need, although they may appear sooner (or even later). The question that needs to be addressed by this WG is should ULE allow such extension headers to be defined in future? We don't have to define them now, but we will have to define the MECHANISM by which they can be later added. If we don't include this possibility now, we'd have to version the whole protocol to get this functionality later (this would have a serious deployment issues). Gorry Allison, Art wrote: >As to backwards compatibility, no mater how it is defined, the initial >products will not process and use newly defined data. So, even if the >original product can process the larger header, it can do nothing with data >with a new meaning defined after the product is built: >With a bit = 0 it is the 'Rev0' standard device Gen0. >With a bit = 1 a Gen0 device cannot process the data, but can process >all Rev0 data. >With a series of bits, a Gen0 device cannot process the data, but can >process all Rev0 data. >At each header instance a different type can be signaled. > >Bits are bucks for broadcasters, and each one has a fixed pipe size, so we >must resist sending any more than absolutely needed. I can make a case for >NO expansion bit, as the new service can be defined when the application is >defined and new devices can process it -- but 1 bit per header is ok. > >Please help me see what I must be missing that justifies use of more bits... >Art >::{)> >Art Allison >Director Advanced Engineering >NAB >1771 N St NW >Washington DC 20036 >202 429 5418 > > >-----Original Message----- >From: Alain RITOUX [mailto:alain.ritoux@6wind.com] >Sent: Monday, March 01, 2004 12:08 PM >To: ip-dvb@erg.abdn.ac.uk >Subject: Re: ULE encryption Support. > > > > >Allison, Art wrote: > > > >>So, if we should not encrypt at this layer [agree with Alain] and we >> >> >should > > >>not put additional error correction at this layer.. it seems we no longer >>have a reason to add more than a just-in-case escape bit just in case a >>yet-to-be-invented function is needed someday. >> >> > >Not totally agree. This "reserve" may have no usage now, but the >mechanism is not that heavy, and once it is done, it will allow >introduciton of "possible" ext headers in a backward-compatible >way, which seems to me worth the price. > >Cheers >Alain. > > *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From owner-ip-dvb@erg.abdn.ac.uk Mon Mar 8 15:53:56 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 i28FqZkM025655 for ; Mon, 8 Mar 2004 15:52:35 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i28FqYeN025654 for ip-dvb-subscribed-users; Mon, 8 Mar 2004 15:52: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 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 i28Fp7Ts025589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 8 Mar 2004 15:51:08 GMT Message-ID: <404C966D.3060603@erg.abdn.ac.uk> Date: Mon, 08 Mar 2004 15:51:09 +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: ULE : Encryption Support, FEC, and Extension headers. References: <5A659834E1607E4EBD72FCE2FE5C9CF102FEBF58@mail.NAB.ORG> <40436DFE.7030500@6wind.com> In-Reply-To: <40436DFE.7030500@6wind.com> 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 X-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk There's been a lot of discussion on the list about three related topics: (i) The (potential/actual) need for FEC and Encryption (ii) How to implement headers in ULE to support Encryption (iii) Whether ULE should support optional extension headers. I don't wnat to stop any of this debate, but I would like to try and put a marker in the email threads so that those not following the detail of the various discussions, have a picture of where the group seems to have consensus. So here's my recommendation as WG Chair: (1) ULE Extension Headers - We have described a number of ways we can encode extra headers associated with a specific SNDU, that a receiver may optionaly ignore without having to discard a PDU. However, we have yet to agree if this is needed and which way is best. The most promising seem to be: (a) use a 16-bit type field to indicate "extension header follows" (b) use a 1-bit flag to indicate "extension header follows" (c) the assignment of type field values to identify each individual extension header. I recommend we add only a "place holder note" in the next revision of the ULE draft (to be released in about one-two weeks) which says the WG could possibly consider future extension headers (if needed), and continue this discussion for the next revision (this can happen quickly if the WG gets consensus, at the moment I see too many options and unclear concrete examples). (2) FEC and Encryption, the requirements for these must be clearly defined in an Internet Draft (reference could be made to other, e.g. ETSI documents). This could be one or more individual drafts - or by contribution of IETF-style text for the "ipdvb requirements" ID. This will assure, we have a common basis for discussion, either on the mailing list or (if issues do prove hard to resolve in this way) at the San Diego IETF. I'm anxious ULE collects only *useful* options. Note: These individual ID's could be very short (a few pages) and could finally be "combined" into the ULE (and/or requirements) text, should they be accepted by the group. (3) After production of a WG ULE ID, I'd like the WG to progress the charter item of adopting a requirements WG Internet Draft. This document must provide background, identify use-cases, and implementation options; leading to appropriate recommendations. We can either start from the existing (somewhat imperfect/incomplete) requirements draft: http://www.ietf.org/internet-drafts/draft-fair-ipdvb-req-04.txt ....or make one (or more) new ones. Thoughts? Gorry Fairhurst (ipdvb WG Chair) From owner-ip-dvb@erg.abdn.ac.uk Wed Mar 10 16:35: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 i2AGZWwr016701 for ; Wed, 10 Mar 2004 16:35:32 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2AGZWhT016700 for ip-dvb-subscribed-users; Wed, 10 Mar 2004 16:35: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 [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 i2AGYbDd016665 for ; Wed, 10 Mar 2004 16:34:38 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, 10 Mar 2004 11:34:39 -0500 Received: (private information removed) Message-ID: <5A659834E1607E4EBD72FCE2FE5C9CF102FEBFD9@mail.NAB.ORG> From: "Allison, Art" To: "'ip-dvb@erg.abdn.ac.uk'" Subject: ULE Extension Headers Date: Wed, 10 Mar 2004 11:34:35 -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-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk Taking one.... (1) ULE Extension Headers - We have described a number of ways we can encode extra headers associated with a specific SNDU, that a receiver may optionally ignore without having to discard a PDU. However, we have yet to agree if this is needed and which way is best. The most promising seem to be: (a) use a 16-bit type field to indicate "extension header follows" (b) use a 1-bit flag to indicate "extension header follows" (c) the assignment of type field values to identify each individual extension header. I recommend we add only a "place holder note" in the next revision of the ULE draft (to be released in about one-two weeks) which says the WG could possibly consider future extension headers (if needed), and continue this discussion for the next revision (this can happen quickly if the WG gets consensus, at the moment I see too many options and unclear concrete examples). ---- I thought discussion faded to silence after I acknowledged (b) was ok with me. (And I thought some wanted to define the following structure when the bit is set - an activity to which I do not think there were objections.) So maybe we have acceptance of an approach for this item? 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: Monday, March 08, 2004 10:51 AM To: ip-dvb@erg.abdn.ac.uk Subject: ULE : Encryption Support, FEC, and Extension headers. There's been a lot of discussion on the list about three related topics: (i) The (potential/actual) need for FEC and Encryption (ii) How to implement headers in ULE to support Encryption (iii) Whether ULE should support optional extension headers. I don't wnat to stop any of this debate, but I would like to try and put a marker in the email threads so that those not following the detail of the various discussions, have a picture of where the group seems to have consensus. So here's my recommendation as WG Chair: (1) ULE Extension Headers - We have described a number of ways we can encode extra headers associated with a specific SNDU, that a receiver may optionaly ignore without having to discard a PDU. However, we have yet to agree if this is needed and which way is best. The most promising seem to be: (a) use a 16-bit type field to indicate "extension header follows" (b) use a 1-bit flag to indicate "extension header follows" (c) the assignment of type field values to identify each individual extension header. I recommend we add only a "place holder note" in the next revision of the ULE draft (to be released in about one-two weeks) which says the WG could possibly consider future extension headers (if needed), and continue this discussion for the next revision (this can happen quickly if the WG gets consensus, at the moment I see too many options and unclear concrete examples). (2) FEC and Encryption, the requirements for these must be clearly defined in an Internet Draft (reference could be made to other, e.g. ETSI documents). This could be one or more individual drafts - or by contribution of IETF-style text for the "ipdvb requirements" ID. This will assure, we have a common basis for discussion, either on the mailing list or (if issues do prove hard to resolve in this way) at the San Diego IETF. I'm anxious ULE collects only *useful* options. Note: These individual ID's could be very short (a few pages) and could finally be "combined" into the ULE (and/or requirements) text, should they be accepted by the group. (3) After production of a WG ULE ID, I'd like the WG to progress the charter item of adopting a requirements WG Internet Draft. This document must provide background, identify use-cases, and implementation options; leading to appropriate recommendations. We can either start from the existing (somewhat imperfect/incomplete) requirements draft: http://www.ietf.org/internet-drafts/draft-fair-ipdvb-req-04.txt ....or make one (or more) new ones. Thoughts? Gorry Fairhurst (ipdvb WG Chair) From owner-ip-dvb@erg.abdn.ac.uk Wed Mar 10 17:20: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 i2AHIdiI018627 for ; Wed, 10 Mar 2004 17:18:39 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2AHIdCk018625 for ip-dvb-subscribed-users; Wed, 10 Mar 2004 17:18:39 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 out004.verizon.net (out004pub.verizon.net [206.46.170.142]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i2AHH631018543 for ; Wed, 10 Mar 2004 17:17:07 GMT Received: from copernicus ([68.163.221.56]) by out004.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040310171704.GXVO11989.out004.verizon.net@copernicus> for ; Wed, 10 Mar 2004 11:17:04 -0600 Message-ID: <05f801c406c3$93c04fe0$b402a8c0@copernicus> From: "Marie-Jose Montpetit" To: References: <5A659834E1607E4EBD72FCE2FE5C9CF102FEBFD9@mail.NAB.ORG> Subject: Re: ULE Extension Headers Date: Wed, 10 Mar 2004 12:17:29 -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 out004.verizon.net from [68.163.221.56] at Wed, 10 Mar 2004 11:17:03 -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-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk I disagree with the "if needed" and would like to see the extension headers as part of the new revision even if the actual mechanism is TBD. We can come up with a series of concrete use cases. I think extension headers are essential to support future services (security being one) and ensure extensibility. Marie-Jose ----- Original Message ----- From: "Allison, Art" To: Sent: Wednesday, March 10, 2004 11:34 AM Subject: ULE Extension Headers > Taking one.... > (1) ULE Extension Headers - We have described a number of ways we can > encode extra headers associated with a specific SNDU, that a receiver > may optionally ignore without having to discard a PDU. However, we > have yet to agree if this is needed and which way is best. The most > promising seem to be: > (a) use a 16-bit type field to indicate "extension header follows" > (b) use a 1-bit flag to indicate "extension header follows" > (c) the assignment of type field values to identify each > individual extension header. > > I recommend we add only a "place holder note" in the next revision of > the ULE draft (to be released in about one-two weeks) which says the WG > could possibly consider future extension headers (if needed), and > continue this discussion for the next revision (this can happen quickly > if the WG gets consensus, at the moment I see too many options > and unclear concrete examples). > > ---- > I thought discussion faded to silence after I acknowledged (b) > was ok with me. (And I thought some wanted to define the following structure > when the bit is set - an activity to which I do not think there were > objections.) > So maybe we have acceptance of an approach for this item? > > 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: Monday, March 08, 2004 10:51 AM > To: ip-dvb@erg.abdn.ac.uk > Subject: ULE : Encryption Support, FEC, and Extension headers. > > > > There's been a lot of discussion on the list about three related topics: > (i) The (potential/actual) need for FEC and Encryption > (ii) How to implement headers in ULE to support Encryption > (iii) Whether ULE should support optional extension headers. > > I don't wnat to stop any of this debate, but I would like to try and put > a marker in the email threads so that those not following the detail > of the various discussions, have a picture of where the group seems > to have consensus. > > So here's my recommendation as WG Chair: > > (1) ULE Extension Headers - We have described a number of ways we can > encode extra headers associated with a specific SNDU, that a receiver > may optionaly ignore without having to discard a PDU. However, we > have yet to agree if this is needed and which way is best. The most > promising seem to be: > (a) use a 16-bit type field to indicate "extension header follows" > (b) use a 1-bit flag to indicate "extension header follows" > (c) the assignment of type field values to identify each > individual extension header. > > I recommend we add only a "place holder note" in the next revision of > the ULE draft (to be released in about one-two weeks) which says the WG > could possibly consider future extension headers (if needed), and > continue this discussion for the next revision (this can happen quickly > if the WG gets consensus, at the moment I see too many options > and unclear concrete examples). > > (2) FEC and Encryption, the requirements for these must be clearly > defined in an Internet Draft (reference could be made to other, e.g. > ETSI documents). This could be one or more individual drafts - > or by contribution of IETF-style text for the "ipdvb requirements" ID. > This will assure, we have a common basis for discussion, either on the > mailing list or (if issues do prove hard to resolve in this way) at the > San Diego IETF. I'm anxious ULE collects only *useful* options. > Note: These individual ID's could be very short (a few pages) and > could finally be "combined" into the ULE (and/or requirements) text, > should they be accepted by the group. > > (3) After production of a WG ULE ID, I'd like the WG to progress the > charter item of adopting a requirements WG Internet Draft. This document > must provide background, identify use-cases, and implementation options; > leading to appropriate recommendations. We can either start from the > existing (somewhat imperfect/incomplete) requirements draft: > > http://www.ietf.org/internet-drafts/draft-fair-ipdvb-req-04.txt > > ....or make one (or more) new ones. Thoughts? > > Gorry Fairhurst > (ipdvb WG Chair) > > From owner-ip-dvb@erg.abdn.ac.uk Wed Mar 10 17:33: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 i2AHUVvJ019199 for ; Wed, 10 Mar 2004 17:30:31 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2AHUU1K019192 for ip-dvb-subscribed-users; Wed, 10 Mar 2004 17:30: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 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 i2AHSGhe019079 for ; Wed, 10 Mar 2004 17:28:16 GMT Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id BA2AD3C5 for ; Wed, 10 Mar 2004 18:28:27 +0100 (CET) Received: from 6wind.com (vouvray.dev.6wind.com [10.16.0.135]) by intranet.6wind.com (Postfix) with ESMTP id 9AEB55DA; Wed, 10 Mar 2004 18:28:16 +0100 (CET) Message-ID: <404F512D.2070400@6wind.com> Date: Wed, 10 Mar 2004 18:32:29 +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 Extension Headers References: <5A659834E1607E4EBD72FCE2FE5C9CF102FEBFD9@mail.NAB.ORG> In-Reply-To: <5A659834E1607E4EBD72FCE2FE5C9CF102FEBFD9@mail.NAB.ORG> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk Allison, Art wrote: > Taking one.... > (1) ULE Extension Headers - We have described a number of ways we can > encode extra headers associated with a specific SNDU, that a receiver > may optionally ignore without having to discard a PDU. However, we > have yet to agree if this is needed and which way is best. The most > promising seem to be: > (a) use a 16-bit type field to indicate "extension header follows" > (b) use a 1-bit flag to indicate "extension header follows" > (c) the assignment of type field values to identify each > individual extension header. > > I recommend we add only a "place holder note" in the next revision of > the ULE draft (to be released in about one-two weeks) which says the WG > could possibly consider future extension headers (if needed), and > continue this discussion for the next revision (this can happen quickly > if the WG gets consensus, at the moment I see too many options > and unclear concrete examples). > > ---- > I thought discussion faded to silence after I acknowledged (b) > was ok with me. (And I thought some wanted to define the following structure > when the bit is set - an activity to which I do not think there were > objections.) I also am in favour of b) A structure was proposed for the case where the bit is set. I didn't feel any strong objection against the proposed definition, neither a great support ;-) but we were just 3 or 4 to discuss about it, I don't know the feeling of the WG about this stuff. How to proceed any further ? > So maybe we have acceptance of an approach for this item? maybe. 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 Mar 10 17:23:17 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 i2AHMd01018835 for ; Wed, 10 Mar 2004 17:22:39 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2AHMdkG018834 for ip-dvb-subscribed-users; Wed, 10 Mar 2004 17:22:39 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 i2AHLBuH018773 for ; Wed, 10 Mar 2004 17:21:12 GMT Received: (qmail 28310 invoked by uid 510); 10 Mar 2004 17:21:08 -0000 Date: 10 Mar 2004 17:21:08 -0000 Message-ID: <20040310172108.28309.qmail@webmail25.rediffmail.com> Received: from unknown (61.11.82.35) by rediffmail.com via HTTP; 10 mar 2004 17:21:08 -0000 MIME-Version: 1.0 From: "William StanisLaus" To: ip-dvb@erg.abdn.ac.uk Subject: Re: ULE Extension Headers Content-type: multipart/alternative; boundary="Next_1078939268---0-203.199.83.147-28295" 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 X-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk This is a multipart mime message --Next_1078939268---0-203.199.83.147-28295 Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

=0AHi Art,
=0A  Please refer the previous post on definition to = the proposal (b) which describes the ext. bit.
=0A
=0Ahttp://www.erg.= abdn.ac.uk/ip-dvb/archive/msg00584.html
=0A
=0ABest Regards,
=0AWi= lliam.
=0A
=0AOn Wed, 10 Mar 2004 Allison, Art wrote :
=0A>Taki= ng one....
=0A>(1) ULE Extension Headers - We have described a number= of ways we can
=0A>encode extra headers associated with a specific S= NDU, that a receiver
=0A>may optionally ignore without having to disc= ard a PDU. However, we
=0A>have yet to agree if this is needed and wh= ich way is best. The most
=0A>promising seem to be:
=0A>  =   (a) use a 16-bit type field to indicate "extension header foll= ows"
=0A>    (b) use a 1-bit flag to indicate "e= xtension header follows"
=0A>    (c) the assignment o= f type field values to identify each
=0A>        = individual extension header.
=0A>
=0A>I recommend we add only = a "place holder note" in the next revision of
=0A>the ULE d= raft (to be released in about one-two weeks) which says the WG
=0A>co= uld possibly consider future extension headers (if needed), and
=0A>c= ontinue this discussion for the next revision (this can happen quickly
= =0A>if the WG gets consensus, at the moment I see too many options
= =0A>and unclear concrete examples).
=0A>
=0A>----
=0A>= I thought discussion faded to silence after I <effectively> acknowled= ged (b)
=0A>was ok with me. (And I thought some wanted to define the = following structure
=0A>when the bit is set - an activity to which I = do not think there were
=0A>objections.)
=0A>So maybe we have a= cceptance of an approach for this item?
=0A>
=0A>Art
=0A>= ::{)>
=0A>Art Allison
=0A>Director Advanced Engineering
= =0A>NAB
=0A>1771 N St NW
=0A>Washington DC 20036
=0A>2= 02 429 5418
=0A>
=0A>
=0A>-----Original Message-----
= =0A> From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk]
=0A>Sent:= Monday, March 08, 2004 10:51 AM
=0A>To: ip-dvb@erg.abdn.ac.uk
=0A= >Subject: ULE : Encryption Support, FEC, and Extension headers.
=0A&g= t;
=0A>
=0A>
=0A>There's been a lot of discussion on the = list about three related topics:
=0A>    (i) The (potentia= l/actual) need for FEC and Encryption
=0A>    (ii) How to = implement headers in ULE to support Encryption
=0A>    (ii= i) Whether ULE should support optional extension headers.
=0A>
=0A= >I don't wnat to stop any of this debate, but I would like to try and pu= t
=0A>a marker in the email threads so that those not following the d= etail
=0A>of the various discussions, have a picture of where the gro= up seems
=0A>to have consensus.
=0A>
=0A>So here's my rec= ommendation as WG Chair:
=0A>
=0A>(1) ULE Extension Headers - W= e have described a number of ways we can
=0A>encode extra headers ass= ociated with a specific SNDU, that a receiver
=0A>may optionaly ignor= e without having to discard a PDU. However, we
=0A>have yet to agree = if this is needed and which way is best. The most
=0A>promising seem = to be:
=0A>    (a) use a 16-bit type field to indicate &qu= ot;extension header follows"
=0A>    (b) use a 1-bit = flag to indicate "extension header follows"
=0A>  &nbs= p; (c) the assignment of type field values to identify each
=0A>&nbs= p;       individual extension header.
=0A>
=0A>= I recommend we add only a "place holder note" in the next revisio= n of
=0A>the ULE draft (to be released in about one-two weeks) which = says the WG
=0A>could possibly consider future extension headers (if = needed), and
=0A>continue this discussion for the next revision (this= can happen quickly
=0A>if the WG gets consensus, at the moment I see= too many options
=0A>and unclear concrete examples).
=0A>
= =0A>(2) FEC and Encryption, the requirements for these must be clearly=0A>defined in an Internet Draft (reference could be made to other, e.= g.
=0A>ETSI documents). This could be one or more individual drafts -=
=0A>or by contribution of IETF-style text for the "ipdvb requir= ements" ID.
=0A>This will assure, we have a common basis for dis= cussion, either on the
=0A>mailing list or (if issues do prove hard t= o resolve in this way) at the
=0A>San Diego IETF. I'm anxious ULE col= lects only *useful* options.
=0A>Note: These individual ID's could be= very short (a few pages) and
=0A>could finally be "combined&quo= t; into the ULE (and/or requirements) text,
=0A>should they be accept= ed by the group.
=0A>
=0A>(3) After production of a WG ULE ID, = I'd like the WG to progress the
=0A>charter item of adopting a requir= ements WG Internet Draft. This document
=0A>must provide background, = identify use-cases, and implementation options;
=0A>leading to approp= riate recommendations.  We can either start from the
=0A>existin= g (somewhat imperfect/incomplete) requirements draft:
=0A>
=0A>= http://www.ietf.org/internet-drafts/draft-fair-ipdvb-req-04.txt
=0A><= BR>=0A>....or make one (or more) new ones. Thoughts?
=0A>
=0A&g= t;Gorry Fairhurst
=0A>(ipdvb WG Chair)
=0A>
=0A=0A

=0A
=0A=0A --Next_1078939268---0-203.199.83.147-28295 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Art,=0A Please refer the previous post on definition to the proposal (b= ) which describes the ext. bit.=0A=0Ahttp://www.erg.abdn.ac.uk/ip-dvb/archi= ve/msg00584.html=0A=0ABest Regards,=0AWilliam.=0A=0AOn Wed, 10 Mar 2004 All= ison, Art wrote :=0A>Taking one....=0A>(1) ULE Extension Headers - We have = described a number of ways we can=0A>encode extra headers associated with a= specific SNDU, that a receiver=0A>may optionally ignore without having to = discard a PDU. However, we=0A>have yet to agree if this is needed and which= way is best. The most=0A>promising seem to be:=0A> (a) use a 16-bit ty= pe field to indicate "extension header follows"=0A> (b) use a 1-bit fla= g to indicate "extension header follows"=0A> (c) the assignment of type= field values to identify each=0A> individual extension header.=0A>= =0A>I recommend we add only a "place holder note" in the next revision of= =0A>the ULE draft (to be released in about one-two weeks) which says the WG= =0A>could possibly consider future extension headers (if needed), and=0A>co= ntinue this discussion for the next revision (this can happen quickly=0A>if= the WG gets consensus, at the moment I see too many options=0A>and unclear= concrete examples).=0A>=0A>----=0A>I thought discussion faded to silence a= fter I acknowledged (b)=0A>was ok with me. (And I thought som= e wanted to define the following structure=0A>when the bit is set - an acti= vity to which I do not think there were=0A>objections.)=0A>So maybe we have= acceptance of an approach for this item?=0A>=0A>Art=0A>::{)>=0A>Art Alliso= n=0A>Director Advanced Engineering=0A>NAB=0A>1771 N St NW=0A>Washington DC = 20036=0A>202 429 5418=0A>=0A>=0A>-----Original Message-----=0A> From: Gorry= Fairhurst [mailto:gorry@erg.abdn.ac.uk]=0A>Sent: Monday, March 08, 2004 10= :51 AM=0A>To: ip-dvb@erg.abdn.ac.uk=0A>Subject: ULE : Encryption Support, F= EC, and Extension headers.=0A>=0A>=0A>=0A>There's been a lot of discussion = on the list about three related topics:=0A> (i) The (potential/actual) = need for FEC and Encryption=0A> (ii) How to implement headers in ULE to= support Encryption=0A> (iii) Whether ULE should support optional exten= sion headers.=0A>=0A>I don't wnat to stop any of this debate, but I would l= ike to try and put=0A>a marker in the email threads so that those not follo= wing the detail=0A>of the various discussions, have a picture of where the = group seems=0A>to have consensus.=0A>=0A>So here's my recommendation as WG = Chair:=0A>=0A>(1) ULE Extension Headers - We have described a number of way= s we can=0A>encode extra headers associated with a specific SNDU, that a re= ceiver=0A>may optionaly ignore without having to discard a PDU. However, we= =0A>have yet to agree if this is needed and which way is best. The most=0A>= promising seem to be:=0A> (a) use a 16-bit type field to indicate "exte= nsion header follows"=0A> (b) use a 1-bit flag to indicate "extension h= eader follows"=0A> (c) the assignment of type field values to identify = each=0A> individual extension header.=0A>=0A>I recommend we add onl= y a "place holder note" in the next revision of=0A>the ULE draft (to be rel= eased in about one-two weeks) which says the WG=0A>could possibly consider = future extension headers (if needed), and=0A>continue this discussion for t= he next revision (this can happen quickly=0A>if the WG gets consensus, at t= he moment I see too many options=0A>and unclear concrete examples).=0A>=0A>= (2) FEC and Encryption, the requirements for these must be clearly=0A>defin= ed in an Internet Draft (reference could be made to other, e.g.=0A>ETSI doc= uments). This could be one or more individual drafts -=0A>or by contributio= n of IETF-style text for the "ipdvb requirements" ID.=0A>This will assure, = we have a common basis for discussion, either on the=0A>mailing list or (if= issues do prove hard to resolve in this way) at the=0A>San Diego IETF. I'm= anxious ULE collects only *useful* options.=0A>Note: These individual ID's= could be very short (a few pages) and=0A>could finally be "combined" into = the ULE (and/or requirements) text,=0A>should they be accepted by the group= .=0A>=0A>(3) After production of a WG ULE ID, I'd like the WG to progress t= he=0A>charter item of adopting a requirements WG Internet Draft. This docum= ent=0A>must provide background, identify use-cases, and implementation opti= ons;=0A>leading to appropriate recommendations. We can either start from t= he=0A>existing (somewhat imperfect/incomplete) requirements draft:=0A>=0A>h= ttp://www.ietf.org/internet-drafts/draft-fair-ipdvb-req-04.txt=0A>=0A>....o= r make one (or more) new ones. Thoughts?=0A>=0A>Gorry Fairhurst=0A>(ipdvb W= G Chair)=0A>=0A --Next_1078939268---0-203.199.83.147-28295-- From owner-ip-dvb@erg.abdn.ac.uk Wed Mar 10 18:27:50 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 i2AIRLIU021580 for ; Wed, 10 Mar 2004 18:27:21 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2AIRLSr021579 for ip-dvb-subscribed-users; Wed, 10 Mar 2004 18:27: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 i2AIQEXJ021530 for ; Wed, 10 Mar 2004 18:26:14 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, 10 Mar 2004 13:26:16 -0500 Received: (private information removed) Message-ID: <5A659834E1607E4EBD72FCE2FE5C9CF102FEBFDE@mail.NAB.ORG> From: "Allison, Art" To: "'ip-dvb@erg.abdn.ac.uk'" Subject: RE: ULE Extension Headers Date: Wed, 10 Mar 2004 13:26:15 -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-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk William I do not see how referring me to old posts without taking a position facilitates progress. I was not and am not attempting to reopen discussion. It seemed that it was time for preferences to be expressed. Given the clarifications and lack of continued objection; it seemed to me that maybe (b) had enough support. So calling for a measurement of consensus seemed in order. The alternatives that were clearly set forth by our esteemed Chair and are: 'a', 'b', 'c' or 'no choice'. So if each of us that cares asserts "I prefer (x)" or "for the reasons I have previously posted I prefer (y)" we provide data upon which a way forward can be based. It is most reasonable to interpret silence is "I don't care". I stated my preference. I urge helping the Chair to avoid having to report 'no choice' by stating yours. Art ::{)> Art Allison Director Advanced Engineering NAB 1771 N St NW Washington DC 20036 202 429 5418 -----Original Message----- From: William StanisLaus [mailto:williams77@rediffmail.com] Sent: Wednesday, March 10, 2004 12:21 PM To: ip-dvb@erg.abdn.ac.uk Subject: Re: ULE Extension Headers Hi Art, Please refer the previous post on definition to the proposal (b) which describes the ext. bit. http://www.erg.abdn.ac.uk/ip-dvb/archive/msg00584.html Best Regards, William. On Wed, 10 Mar 2004 Allison, Art wrote : >Taking one.... >(1) ULE Extension Headers - We have described a number of ways we can >encode extra headers associated with a specific SNDU, that a receiver >may optionally ignore without having to discard a PDU. However, we >have yet to agree if this is needed and which way is best. The most >promising seem to be: > (a) use a 16-bit type field to indicate "extension header follows" > (b) use a 1-bit flag to indicate "extension header follows" > (c) the assignment of type field values to identify each > individual extension header. > >I recommend we add only a "place holder note" in the next revision of >the ULE draft (to be released in about one-two weeks) which says the WG >could possibly consider future extension headers (if needed), and >continue this discussion for the next revision (this can happen quickly >if the WG gets consensus, at the moment I see too many options >and unclear concrete examples). > >---- >I thought discussion faded to silence after I acknowledged (b) >was ok with me. (And I thought some wanted to define the following structure >when the bit is set - an activity to which I do not think there were >objections.) >So maybe we have acceptance of an approach for this item? > >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: Monday, March 08, 2004 10:51 AM >To: ip-dvb@erg.abdn.ac.uk >Subject: ULE : Encryption Support, FEC, and Extension headers. > > > >There's been a lot of discussion on the list about three related topics: > (i) The (potential/actual) need for FEC and Encryption > (ii) How to implement headers in ULE to support Encryption > (iii) Whether ULE should support optional extension headers. > >I don't wnat to stop any of this debate, but I would like to try and put >a marker in the email threads so that those not following the detail >of the various discussions, have a picture of where the group seems >to have consensus. > >So here's my recommendation as WG Chair: > >(1) ULE Extension Headers - We have described a number of ways we can >encode extra headers associated with a specific SNDU, that a receiver >may optionaly ignore without having to discard a PDU. However, we >have yet to agree if this is needed and which way is best. The most >promising seem to be: > (a) use a 16-bit type field to indicate "extension header follows" > (b) use a 1-bit flag to indicate "extension header follows" > (c) the assignment of type field values to identify each > individual extension header. > >I recommend we add only a "place holder note" in the next revision of >the ULE draft (to be released in about one-two weeks) which says the WG >could possibly consider future extension headers (if needed), and >continue this discussion for the next revision (this can happen quickly >if the WG gets consensus, at the moment I see too many options >and unclear concrete examples). > >(2) FEC and Encryption, the requirements for these must be clearly >defined in an Internet Draft (reference could be made to other, e.g. >ETSI documents). This could be one or more individual drafts - >or by contribution of IETF-style text for the "ipdvb requirements" ID. >This will assure, we have a common basis for discussion, either on the >mailing list or (if issues do prove hard to resolve in this way) at the >San Diego IETF. I'm anxious ULE collects only *useful* options. >Note: These individual ID's could be very short (a few pages) and >could finally be "combined" into the ULE (and/or requirements) text, >should they be accepted by the group. > >(3) After production of a WG ULE ID, I'd like the WG to progress the >charter item of adopting a requirements WG Internet Draft. This document >must provide background, identify use-cases, and implementation options; >leading to appropriate recommendations. We can either start from the >existing (somewhat imperfect/incomplete) requirements draft: > >http://www.ietf.org/internet-drafts/draft-fair-ipdvb-req-04.txt > >....or make one (or more) new ones. Thoughts? > >Gorry Fairhurst >(ipdvb WG Chair) > From owner-ip-dvb@erg.abdn.ac.uk Wed Mar 10 19:16:50 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 i2AJEo9H023393 for ; Wed, 10 Mar 2004 19:14:50 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2AJEoIm023392 for ip-dvb-subscribed-users; Wed, 10 Mar 2004 19:14: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 mailandnews.com (server236.fastdnsservers.com [209.81.157.236] (may be forged)) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i2AJDiD6023324 for ; Wed, 10 Mar 2004 19:13:44 GMT X-WM-Posted-At: mailandnews.com; Wed, 10 Mar 04 14:10:59 -0500 X-WebMail-UserID: williams77 Date: Wed, 10 Mar 2004 14:10:59 -0500 From: William StanisLaus To: ip-dvb@erg.abdn.ac.uk X-EXP32-SerialNo: 50000000 Subject: RE: ULE Extension Headers Message-ID: <404F25D2@mailandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: InterChange (Hydra) SMTP v3.62.01 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-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk Hi Art, I apologize, hope there is a possible misunderstanding. I was supporting (b) as well. >(And I thought some wanted to define the following structure when the >bit is set - an activity to which I do not think there were >objections.) which has caused misunderstanding.. to define the structure for extension bit is set. Sorry for inconvenience again. Best Regards, William. -----Original Message----- From: owner-ip-dvb@erg.abdn.ac.uk [mailto:owner-ip-dvb@erg.abdn.ac.uk] On Behalf Of Allison, Art Sent: Wednesday, March 10, 2004 11:56 PM To: 'ip-dvb@erg.abdn.ac.uk' Subject: RE: ULE Extension Headers William I do not see how referring me to old posts without taking a position facilitates progress. I was not and am not attempting to reopen discussion. It seemed that it was time for preferences to be expressed. Given the clarifications and lack of continued objection; it seemed to me that maybe (b) had enough support. So calling for a measurement of consensus seemed in order. The alternatives that were clearly set forth by our esteemed Chair and are: 'a', 'b', 'c' or 'no choice'. So if each of us that cares asserts "I prefer (x)" or "for the reasons I have previously posted I prefer (y)" we provide data upon which a way forward can be based. It is most reasonable to interpret silence is "I don't care". I stated my preference. I urge helping the Chair to avoid having to report 'no choice' by stating yours. Art ::{)> Art Allison Director Advanced Engineering NAB 1771 N St NW Washington DC 20036 202 429 5418 -----Original Message----- From: William StanisLaus [mailto:williams77@rediffmail.com] Sent: Wednesday, March 10, 2004 12:21 PM To: ip-dvb@erg.abdn.ac.uk Subject: Re: ULE Extension Headers Hi Art, Please refer the previous post on definition to the proposal (b) which describes the ext. bit. http://www.erg.abdn.ac.uk/ip-dvb/archive/msg00584.html Best Regards, William. On Wed, 10 Mar 2004 Allison, Art wrote : >Taking one.... >(1) ULE Extension Headers - We have described a number of ways we can >encode extra headers associated with a specific SNDU, that a receiver >may optionally ignore without having to discard a PDU. However, we have >yet to agree if this is needed and which way is best. The most >promising seem to be: > (a) use a 16-bit type field to indicate "extension header follows" > (b) use a 1-bit flag to indicate "extension header follows" > (c) the assignment of type field values to identify each > individual extension header. > >I recommend we add only a "place holder note" in the next revision of >the ULE draft (to be released in about one-two weeks) which says the WG >could possibly consider future extension headers (if needed), and >continue this discussion for the next revision (this can happen quickly >if the WG gets consensus, at the moment I see too many options and >unclear concrete examples). > >---- >I thought discussion faded to silence after I >acknowledged (b) >was ok with me. (And I thought some wanted to define the following structure >when the bit is set - an activity to which I do not think there were >objections.) >So maybe we have acceptance of an approach for this item? > >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: Monday, March 08, 2004 10:51 AM >To: ip-dvb@erg.abdn.ac.uk >Subject: ULE : Encryption Support, FEC, and Extension headers. > > > >There's been a lot of discussion on the list about three related topics: > (i) The (potential/actual) need for FEC and Encryption > (ii) How to implement headers in ULE to support Encryption > (iii) Whether ULE should support optional extension headers. > >I don't wnat to stop any of this debate, but I would like to try and >put a marker in the email threads so that those not following the >detail of the various discussions, have a picture of where the group >seems to have consensus. > >So here's my recommendation as WG Chair: > >(1) ULE Extension Headers - We have described a number of ways we can >encode extra headers associated with a specific SNDU, that a receiver >may optionaly ignore without having to discard a PDU. However, we have >yet to agree if this is needed and which way is best. The most >promising seem to be: > (a) use a 16-bit type field to indicate "extension header follows" > (b) use a 1-bit flag to indicate "extension header follows" > (c) the assignment of type field values to identify each > individual extension header. > >I recommend we add only a "place holder note" in the next revision of >the ULE draft (to be released in about one-two weeks) which says the WG >could possibly consider future extension headers (if needed), and >continue this discussion for the next revision (this can happen quickly >if the WG gets consensus, at the moment I see too many options and >unclear concrete examples). > >(2) FEC and Encryption, the requirements for these must be clearly >defined in an Internet Draft (reference could be made to other, e.g. >ETSI documents). This could be one or more individual drafts - or by >contribution of IETF-style text for the "ipdvb requirements" ID. This >will assure, we have a common basis for discussion, either on the >mailing list or (if issues do prove hard to resolve in this way) at the >San Diego IETF. I'm anxious ULE collects only *useful* options. >Note: These individual ID's could be very short (a few pages) and could >finally be "combined" into the ULE (and/or requirements) text, should >they be accepted by the group. > >(3) After production of a WG ULE ID, I'd like the WG to progress the >charter item of adopting a requirements WG Internet Draft. This >document must provide background, identify use-cases, and >implementation options; leading to appropriate recommendations. We can >either start from the existing (somewhat imperfect/incomplete) >requirements draft: > >http://www.ietf.org/internet-drafts/draft-fair-ipdvb-req-04.txt > >....or make one (or more) new ones. Thoughts? > >Gorry Fairhurst >(ipdvb WG Chair) > From owner-ip-dvb@erg.abdn.ac.uk Wed Mar 10 19:36:22 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 i2AJYWvk024285 for ; Wed, 10 Mar 2004 19:34:32 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2AJYWEi024284 for ip-dvb-subscribed-users; Wed, 10 Mar 2004 19:34: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 [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 i2AJXRnD024216 for ; Wed, 10 Mar 2004 19:33:28 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, 10 Mar 2004 14:33:29 -0500 Received: (private information removed) Message-ID: <5A659834E1607E4EBD72FCE2FE5C9CF102FEBFE8@mail.NAB.ORG> From: "Allison, Art" To: "'ip-dvb@erg.abdn.ac.uk'" Subject: RE: ULE Extension Headers Date: Wed, 10 Mar 2004 14:33:27 -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-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk Thank you for the clarification. Someone once said a journey... begins with a small step. Selecting b would be at least a small step. Gorry, I hope you are counting. Art ::{)> Art Allison Director Advanced Engineering NAB 1771 N St NW Washington DC 20036 202 429 5418 -----Original Message----- From: William StanisLaus [mailto:williams77@mailandnews.com] Sent: Wednesday, March 10, 2004 2:11 PM To: ip-dvb@erg.abdn.ac.uk Subject: RE: ULE Extension Headers Hi Art, I apologize, hope there is a possible misunderstanding. I was supporting (b) as well. >(And I thought some wanted to define the following structure when the >bit is set - an activity to which I do not think there were >objections.) which has caused misunderstanding.. to define the structure for extension bit is set. Sorry for inconvenience again. Best Regards, William. From owner-ip-dvb@erg.abdn.ac.uk Wed Mar 10 20:27:51 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 i2AKQvgi026228 for ; Wed, 10 Mar 2004 20:26:57 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2AKQvKR026227 for ip-dvb-subscribed-users; Wed, 10 Mar 2004 20:26: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 ladron.cs.nmt.edu (ladron.cs.nmt.edu [129.138.6.58]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i2AKPmDk026180 for ; Wed, 10 Mar 2004 20:25:49 GMT Received: from Clausen (attila.cs.nmt.edu [129.138.6.121]) by ladron.cs.nmt.edu (8.11.6/8.11.2) with SMTP id i2AKMPX20806 for ; Wed, 10 Mar 2004 13:22:25 -0700 Message-ID: <006201c406e6$940b74c0$79068a81@Clausen> From: "HDClausen" To: References: <5A659834E1607E4EBD72FCE2FE5C9CF102FEBFE8@mail.NAB.ORG> Subject: Re: ULE Extension Headers Date: Wed, 10 Mar 2004 13:28:06 -0800 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-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-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk I strongly support b). --Horst ----- Original Message ----- From: "Allison, Art" To: Sent: Wednesday, March 10, 2004 11:33 AM Subject: RE: ULE Extension Headers > Thank you for the clarification. Someone once said a journey... begins with > a small step. Selecting b would be at least a small step. > > Gorry, I hope you are counting. > > Art > ::{)> > Art Allison > Director Advanced Engineering > NAB > 1771 N St NW > Washington DC 20036 > 202 429 5418 > > > -----Original Message----- > From: William StanisLaus [mailto:williams77@mailandnews.com] > Sent: Wednesday, March 10, 2004 2:11 PM > To: ip-dvb@erg.abdn.ac.uk > Subject: RE: ULE Extension Headers > > > Hi Art, > I apologize, hope there is a possible misunderstanding. I was > supporting (b) > as well. > > > >(And I thought some wanted to define the following structure when the > >bit is set - an activity to which I do not think there were > >objections.) > > > which has caused misunderstanding.. to define the structure for extension > bit > is set. > > Sorry for inconvenience again. > > Best Regards, > William. > > From owner-ip-dvb@erg.abdn.ac.uk Thu Mar 11 07:48:02 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 i2B7l7Jg021450 for ; Thu, 11 Mar 2004 07:47:07 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2B7l7AX021449 for ip-dvb-subscribed-users; Thu, 11 Mar 2004 07:47: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 GWOUT.thalesgroup.com (gwout.thalesgroup.com [195.101.39.227]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i2B7kUc2021420 for ; Thu, 11 Mar 2004 07:46:30 GMT Received: from thalescan.corp.thales (200.3.2.3) by GWOUT.thalesgroup.com (NPlex 6.5.026) id 404611FA000A52B3 for ip-dvb@erg.abdn.ac.uk; Thu, 11 Mar 2004 08:46:06 +0100 Received: from lowplex.mut.thales ([10.33.37.2]) by thalescan with InterScan Messaging Security Suite; Thu, 11 Mar 2004 08:45:39 +0100 Received: from cnfplex.thomcast.thomson-csf.com (178.1.4.1) by lowplex.mut.thales (NPlex 6.5.026) id 404F62E500005275 for ip-dvb@erg.abdn.ac.uk; Thu, 11 Mar 2004 08:45:39 +0100 Received: from zethos.thomcast.thomson-csf.com (178.3.2.15) by cnfplex.thomcast.thomson-csf.com (NPlex 6.5.026) id 404C2BB300003478 for ip-dvb@erg.abdn.ac.uk; Thu, 11 Mar 2004 08:45:39 +0100 Received: from andromede (178.3.1.43) by zethos.thomcast.thomson-csf.com (NPlex 6.5.026) id 403DA5D00000C1FA for ip-dvb@erg.abdn.ac.uk; Thu, 11 Mar 2004 08:48:53 +0100 From: "Benoit Oger" To: Subject: RE: ULE Extension Headers Date: Thu, 11 Mar 2004 08:41: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.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <5A659834E1607E4EBD72FCE2FE5C9CF102FEBFDE@mail.NAB.ORG> 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-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk To my opinion extension headers management is definitely needed. For this I am in favour of 'b' solution. Benoit Oger Thales Broadcast and Multimedia > -----Message d'origine----- > De : owner-ip-dvb@erg.abdn.ac.uk [mailto:owner-ip-dvb@erg.abdn.ac.uk]De > la part de Allison, Art > Envoyé : mercredi 10 mars 2004 19:26 > À : 'ip-dvb@erg.abdn.ac.uk' > Objet : RE: ULE Extension Headers > > > William > I do not see how referring me to old posts without taking a position > facilitates progress. I was not and am not attempting to reopen > discussion. > It seemed that it was time for preferences to be expressed. Given the > clarifications and lack of continued objection; it seemed to me that maybe > (b) had enough support. So calling for a measurement of consensus > seemed in > order. > > The alternatives that were clearly set forth by our esteemed > Chair and are: > > 'a', 'b', 'c' or 'no choice'. > > So if each of us that cares asserts "I prefer (x)" or "for the reasons I > have previously posted I prefer (y)" we provide data upon which a way > forward can be based. It is most reasonable to interpret silence > is "I don't > care". > > I stated my preference. I urge helping the Chair to avoid having to report > 'no choice' by stating yours. > > Art > ::{)> > Art Allison > Director Advanced Engineering > NAB > 1771 N St NW > Washington DC 20036 > 202 429 5418 > > > -----Original Message----- > From: William StanisLaus [mailto:williams77@rediffmail.com] > Sent: Wednesday, March 10, 2004 12:21 PM > To: ip-dvb@erg.abdn.ac.uk > Subject: Re: ULE Extension Headers > > > Hi Art, > Please refer the previous post on definition to the proposal (b) which > describes the ext. bit. > > http://www.erg.abdn.ac.uk/ip-dvb/archive/msg00584.html > > Best Regards, > William. > > On Wed, 10 Mar 2004 Allison, Art wrote : > >Taking one.... > >(1) ULE Extension Headers - We have described a number of ways we can > >encode extra headers associated with a specific SNDU, that a receiver > >may optionally ignore without having to discard a PDU. However, we > >have yet to agree if this is needed and which way is best. The most > >promising seem to be: > > (a) use a 16-bit type field to indicate "extension header follows" > > (b) use a 1-bit flag to indicate "extension header follows" > > (c) the assignment of type field values to identify each > > individual extension header. > > > >I recommend we add only a "place holder note" in the next revision of > >the ULE draft (to be released in about one-two weeks) which says the WG > >could possibly consider future extension headers (if needed), and > >continue this discussion for the next revision (this can happen quickly > >if the WG gets consensus, at the moment I see too many options > >and unclear concrete examples). > > > >---- > >I thought discussion faded to silence after I acknowledged > (b) > >was ok with me. (And I thought some wanted to define the following > structure > >when the bit is set - an activity to which I do not think there were > >objections.) > >So maybe we have acceptance of an approach for this item? > > > >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: Monday, March 08, 2004 10:51 AM > >To: ip-dvb@erg.abdn.ac.uk > >Subject: ULE : Encryption Support, FEC, and Extension headers. > > > > > > > >There's been a lot of discussion on the list about three related topics: > > (i) The (potential/actual) need for FEC and Encryption > > (ii) How to implement headers in ULE to support Encryption > > (iii) Whether ULE should support optional extension headers. > > > >I don't wnat to stop any of this debate, but I would like to try and put > >a marker in the email threads so that those not following the detail > >of the various discussions, have a picture of where the group seems > >to have consensus. > > > >So here's my recommendation as WG Chair: > > > >(1) ULE Extension Headers - We have described a number of ways we can > >encode extra headers associated with a specific SNDU, that a receiver > >may optionaly ignore without having to discard a PDU. However, we > >have yet to agree if this is needed and which way is best. The most > >promising seem to be: > > (a) use a 16-bit type field to indicate "extension header follows" > > (b) use a 1-bit flag to indicate "extension header follows" > > (c) the assignment of type field values to identify each > > individual extension header. > > > >I recommend we add only a "place holder note" in the next revision of > >the ULE draft (to be released in about one-two weeks) which says the WG > >could possibly consider future extension headers (if needed), and > >continue this discussion for the next revision (this can happen quickly > >if the WG gets consensus, at the moment I see too many options > >and unclear concrete examples). > > > >(2) FEC and Encryption, the requirements for these must be clearly > >defined in an Internet Draft (reference could be made to other, e.g. > >ETSI documents). This could be one or more individual drafts - > >or by contribution of IETF-style text for the "ipdvb requirements" ID. > >This will assure, we have a common basis for discussion, either on the > >mailing list or (if issues do prove hard to resolve in this way) at the > >San Diego IETF. I'm anxious ULE collects only *useful* options. > >Note: These individual ID's could be very short (a few pages) and > >could finally be "combined" into the ULE (and/or requirements) text, > >should they be accepted by the group. > > > >(3) After production of a WG ULE ID, I'd like the WG to progress the > >charter item of adopting a requirements WG Internet Draft. This document > >must provide background, identify use-cases, and implementation options; > >leading to appropriate recommendations. We can either start from the > >existing (somewhat imperfect/incomplete) requirements draft: > > > >http://www.ietf.org/internet-drafts/draft-fair-ipdvb-req-04.txt > > > >....or make one (or more) new ones. Thoughts? > > > >Gorry Fairhurst > >(ipdvb WG Chair) > > From owner-ip-dvb@erg.abdn.ac.uk Thu Mar 11 14:21: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 i2BEKEQP007277 for ; Thu, 11 Mar 2004 14:20:14 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2BEKE5R007276 for ip-dvb-subscribed-users; Thu, 11 Mar 2004 14:20:14 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 i2BEHabm007110 for ; Thu, 11 Mar 2004 14:17:37 GMT Received: (qmail 16744 invoked by uid 510); 11 Mar 2004 14:17:32 -0000 Date: 11 Mar 2004 14:17:32 -0000 Message-ID: <20040311141732.16743.qmail@webmail36.rediffmail.com> Received: from unknown (203.197.138.199) by rediffmail.com via HTTP; 11 mar 2004 14:17:32 -0000 MIME-Version: 1.0 From: "William StanisLaus" To: ip-dvb@erg.abdn.ac.uk Subject: Section Packing for ULE Content-type: multipart/alternative; boundary="Next_1079014652---0-203.199.83.248-16716" 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-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk This is a multipart mime message --Next_1079014652---0-203.199.83.248-16716 Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

=0AHi everyone,
=0A      Good day.. i was wondering ab= out Section Packing in ULE level, since we are using Satellite link with mu= ch larger bandwidth, In our case, ULE supports payload as big as 15 bits or= 14 bits(incase of ext. header bit) i.e. 16384 bytes of payload as a single= ULE. Instead of carring over ULE header on every IP/ARP/Bridged Packet, if= we can section pack multiple IP/ARP/Bridged packets into one ULE header an= d reduce the overhead of ULE header. This is again an extension header whic= h specifies the use of Section Packing.
=0A
=0ANOTE: here Section is = SNDU payload.
=0A
=0ABest Regards,
=0AWilliam.=0A

=0A

= =0A=0A --Next_1079014652---0-203.199.83.248-16716 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi everyone,=0A Good day.. i was wondering about Section Packing in UL= E level, since we are using Satellite link with much larger bandwidth, In o= ur case, ULE supports payload as big as 15 bits or 14 bits(incase of ext. h= eader bit) i.e. 16384 bytes of payload as a single ULE. Instead of carring = over ULE header on every IP/ARP/Bridged Packet, if we can section pack mult= iple IP/ARP/Bridged packets into one ULE header and reduce the overhead of = ULE header. This is again an extension header which specifies the use of Se= ction Packing.=0A=0ANOTE: here Section is SNDU payload.=0A=0ABest Regards,= =0AWilliam. --Next_1079014652---0-203.199.83.248-16716-- From owner-ip-dvb@erg.abdn.ac.uk Thu Mar 11 16:29: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 i2BGStXQ012598 for ; Thu, 11 Mar 2004 16:28:55 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2BGSsQI012596 for ip-dvb-subscribed-users; Thu, 11 Mar 2004 16:28: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 [10.0.1.129] (maxp28.abdn.ac.uk [139.133.7.187]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i2BGRsbu012535 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 11 Mar 2004 16:27:56 GMT User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Thu, 11 Mar 2004 16:28:05 +0000 Subject: Re: ULE Extension Headers From: Gorry Fairhurst To: Message-ID: In-Reply-To: <404F512D.2070400@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 X-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk Let's see if I can help steer this discussion. * I note there is some enthusiasm to consider the idea of a ULE extension header. That is useful to know, but I don't see a consensus YET. * As I said earlier, I am against holding-up the publishing of the first rev of the ULE WG draft. I believe we should publish the draft as soon as possible (next week), to make sure the rest of the text is acceptable to the WG. We CAN issue a new revision of the ID soon after with this new functionality (if we are ready) - there's no minimum time between revisions!!! Here is my suggestion to progress the extension header topic: * We need first to at least find a list of examples of likely/potential use... Let us do this in the context of setting some (potential/actual) requirements/architecture - this also is a WG charter item! Any volunteers of 1-3 paragraphs of ID text describing for each of the ideas for use: Security; FEC; QoS; priority; Multiple-SNDU-Payload; anything else? * I'm not yet clear of the relative costs of (a,b,c) in terms of implementation, registry management, transmission efficiency - one thing that would be very useful would be to write a short ID with a proposed solution, to have something concrete to compare the design options with. Any volunteers for either of the above? Gorry P.S. I didn't mean to ask for a vote (a,b,c) - I was trying to summarise the options I had seen... Sorry if that caused some confusion. On 10/3/04 5:32 pm, "Alain RITOUX" wrote: > > > Allison, Art wrote: >> Taking one.... >> (1) ULE Extension Headers - We have described a number of ways we can >> encode extra headers associated with a specific SNDU, that a receiver >> may optionally ignore without having to discard a PDU. However, we >> have yet to agree if this is needed and which way is best. The most >> promising seem to be: >> (a) use a 16-bit type field to indicate "extension header follows" >> (b) use a 1-bit flag to indicate "extension header follows" >> (c) the assignment of type field values to identify each >> individual extension header. >> >> I recommend we add only a "place holder note" in the next revision of >> the ULE draft (to be released in about one-two weeks) which says the WG >> could possibly consider future extension headers (if needed), and >> continue this discussion for the next revision (this can happen quickly >> if the WG gets consensus, at the moment I see too many options >> and unclear concrete examples). >> >> ---- >> I thought discussion faded to silence after I acknowledged (b) >> was ok with me. (And I thought some wanted to define the following structure >> when the bit is set - an activity to which I do not think there were >> objections.) > > I also am in favour of b) A structure was proposed for the case where > the bit is set. I didn't feel any strong objection against the proposed > definition, neither a great support ;-) but we were just 3 or 4 to > discuss about it, I don't know the feeling of the WG about this stuff. > How to proceed any further ? > >> So maybe we have acceptance of an approach for this item? > maybe. > > Cheers. > Alain. From owner-ip-dvb@erg.abdn.ac.uk Thu Mar 11 17:40: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 i2BHcW4O015382 for ; Thu, 11 Mar 2004 17:38:32 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2BHcWud015381 for ip-dvb-subscribed-users; Thu, 11 Mar 2004 17: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 out010.verizon.net (out010pub.verizon.net [206.46.170.133]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i2BHbwq7015346 for ; Thu, 11 Mar 2004 17:37:58 GMT Received: from copernicus ([68.163.221.56]) by out010.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040311173758.UIEQ26728.out010.verizon.net@copernicus> for ; Thu, 11 Mar 2004 11:37:58 -0600 Message-ID: <089d01c4078f$aa2a6780$b402a8c0@copernicus> From: "Marie-Jose Montpetit" To: References: Subject: Re: ULE Extension Headers Date: Thu, 11 Mar 2004 12:38:19 -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 out010.verizon.net from [68.163.221.56] at Thu, 11 Mar 2004 11:37:56 -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-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk I volunteer for some examples. Marie-Jose ----- Original Message ----- From: "Gorry Fairhurst" To: Sent: Thursday, March 11, 2004 11:28 AM Subject: Re: ULE Extension Headers > > Let's see if I can help steer this discussion. > > * I note there is some enthusiasm to consider the idea of a ULE extension > header. That is useful to know, but I don't see a consensus YET. > > * As I said earlier, I am against holding-up the publishing of the first rev > of the ULE WG draft. I believe we should publish the draft as soon as > possible (next week), to make sure the rest of the text is acceptable to the > WG. We CAN issue a new revision of the ID soon after with this new > functionality (if we are ready) - there's no minimum time between > revisions!!! > > Here is my suggestion to progress the extension header topic: > > * We need first to at least find a list of examples of likely/potential > use... Let us do this in the context of setting some (potential/actual) > requirements/architecture - this also is a WG charter item! Any volunteers > of 1-3 paragraphs of ID text describing for each of the ideas for use: > Security; FEC; QoS; priority; Multiple-SNDU-Payload; anything else? > > * I'm not yet clear of the relative costs of (a,b,c) in terms of > implementation, registry management, transmission efficiency - one thing > that would be very useful would be to write a short ID with a proposed > solution, to have something concrete to compare the design options with. > > Any volunteers for either of the above? > > Gorry > > P.S. I didn't mean to ask for a vote (a,b,c) - I was trying to summarise the > options I had seen... Sorry if that caused some confusion. > > On 10/3/04 5:32 pm, "Alain RITOUX" wrote: > > > > > > > Allison, Art wrote: > >> Taking one.... > >> (1) ULE Extension Headers - We have described a number of ways we can > >> encode extra headers associated with a specific SNDU, that a receiver > >> may optionally ignore without having to discard a PDU. However, we > >> have yet to agree if this is needed and which way is best. The most > >> promising seem to be: > >> (a) use a 16-bit type field to indicate "extension header follows" > >> (b) use a 1-bit flag to indicate "extension header follows" > >> (c) the assignment of type field values to identify each > >> individual extension header. > >> > >> I recommend we add only a "place holder note" in the next revision of > >> the ULE draft (to be released in about one-two weeks) which says the WG > >> could possibly consider future extension headers (if needed), and > >> continue this discussion for the next revision (this can happen quickly > >> if the WG gets consensus, at the moment I see too many options > >> and unclear concrete examples). > >> > >> ---- > >> I thought discussion faded to silence after I acknowledged (b) > >> was ok with me. (And I thought some wanted to define the following structure > >> when the bit is set - an activity to which I do not think there were > >> objections.) > > > > I also am in favour of b) A structure was proposed for the case where > > the bit is set. I didn't feel any strong objection against the proposed > > definition, neither a great support ;-) but we were just 3 or 4 to > > discuss about it, I don't know the feeling of the WG about this stuff. > > How to proceed any further ? > > > >> So maybe we have acceptance of an approach for this item? > > maybe. > > > > Cheers. > > Alain. > > From owner-ip-dvb@erg.abdn.ac.uk Thu Mar 11 18:06: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 i2BI5LM3016512 for ; Thu, 11 Mar 2004 18:05:21 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2BI5Kwo016510 for ip-dvb-subscribed-users; Thu, 11 Mar 2004 18:05: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 i2BI2FmA016354 for ; Thu, 11 Mar 2004 18:02:15 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, 11 Mar 2004 13:02:17 -0500 Received: (private information removed) Message-ID: <5A659834E1607E4EBD72FCE2FE5C9CF102FEC002@mail.NAB.ORG> From: "Allison, Art" To: "'ip-dvb@erg.abdn.ac.uk'" Subject: RE: ULE Extension Headers Date: Thu, 11 Mar 2004 13:02:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk With respect, I have seen no one register any other preference than (b) on list. I have been doing standards work for over 20 years and one always wants to get all folks to express their position, but if they will not then those who do represent the consensus and you move on. I don't see lack of a consensus in this matter, by any standard for consensus. Perhaps there is off-list correspondence, but with respect that is not appropriate to consider here. Gorry, if you do not support (b), and are feel your posting is inhibited because you are the Chair, perhaps just post with your "Chair hat off" for the record. 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: Thursday, March 11, 2004 11:28 AM To: ip-dvb@erg.abdn.ac.uk Subject: Re: ULE Extension Headers Let's see if I can help steer this discussion. * I note there is some enthusiasm to consider the idea of a ULE extension header. That is useful to know, but I don't see a consensus YET. * As I said earlier, I am against holding-up the publishing of the first rev of the ULE WG draft. I believe we should publish the draft as soon as possible (next week), to make sure the rest of the text is acceptable to the WG. We CAN issue a new revision of the ID soon after with this new functionality (if we are ready) - there's no minimum time between revisions!!! Here is my suggestion to progress the extension header topic: * We need first to at least find a list of examples of likely/potential use... Let us do this in the context of setting some (potential/actual) requirements/architecture - this also is a WG charter item! Any volunteers of 1-3 paragraphs of ID text describing for each of the ideas for use: Security; FEC; QoS; priority; Multiple-SNDU-Payload; anything else? * I'm not yet clear of the relative costs of (a,b,c) in terms of implementation, registry management, transmission efficiency - one thing that would be very useful would be to write a short ID with a proposed solution, to have something concrete to compare the design options with. Any volunteers for either of the above? Gorry P.S. I didn't mean to ask for a vote (a,b,c) - I was trying to summarise the options I had seen... Sorry if that caused some confusion. On 10/3/04 5:32 pm, "Alain RITOUX" wrote: > > > Allison, Art wrote: >> Taking one.... >> (1) ULE Extension Headers - We have described a number of ways we can >> encode extra headers associated with a specific SNDU, that a receiver >> may optionally ignore without having to discard a PDU. However, we >> have yet to agree if this is needed and which way is best. The most >> promising seem to be: >> (a) use a 16-bit type field to indicate "extension header follows" >> (b) use a 1-bit flag to indicate "extension header follows" >> (c) the assignment of type field values to identify each >> individual extension header. >> >> I recommend we add only a "place holder note" in the next revision of >> the ULE draft (to be released in about one-two weeks) which says the WG >> could possibly consider future extension headers (if needed), and >> continue this discussion for the next revision (this can happen quickly >> if the WG gets consensus, at the moment I see too many options >> and unclear concrete examples). >> >> ---- >> I thought discussion faded to silence after I acknowledged (b) >> was ok with me. (And I thought some wanted to define the following structure >> when the bit is set - an activity to which I do not think there were >> objections.) > > I also am in favour of b) A structure was proposed for the case where > the bit is set. I didn't feel any strong objection against the proposed > definition, neither a great support ;-) but we were just 3 or 4 to > discuss about it, I don't know the feeling of the WG about this stuff. > How to proceed any further ? > >> So maybe we have acceptance of an approach for this item? > maybe. > > Cheers. > Alain. From owner-ip-dvb@erg.abdn.ac.uk Thu Mar 11 18:31: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 i2BITW3I017520 for ; Thu, 11 Mar 2004 18:29:32 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2BITVKC017517 for ip-dvb-subscribed-users; Thu, 11 Mar 2004 18:29: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 mailandnews.com (server236.fastdnsservers.com [209.81.157.236] (may be forged)) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i2BIRBE7017396 for ; Thu, 11 Mar 2004 18:27:12 GMT Received: from mailandnews.com [209.81.157.230] (williams77@mailandnews.com) by mailandnews.com; Thu, 11 Mar 2004 13:27:09 -0500 X-WM-Posted-At: mailandnews.com; Thu, 11 Mar 04 13:27:09 -0500 X-WM-Posted-At: mailandnews.com; Thu, 11 Mar 04 13:24:34 -0500 X-WebMail-UserID: williams77 Date: Thu, 11 Mar 2004 13:24:34 -0500 From: William StanisLaus To: ip-dvb@erg.abdn.ac.uk X-EXP32-SerialNo: 50000000 Subject: RE: ULE Extension Headers Message-ID: <404FF989@mailandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: InterChange (Hydra) SMTP v3.62.01 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-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk Hi, I'll Volunteer for ULE extension header definition and encoding/decoding at sender/receiver. Also few examples. ~William. -----Original Message----- From: owner-ip-dvb@erg.abdn.ac.uk [mailto:owner-ip-dvb@erg.abdn.ac.uk] On Behalf Of Gorry Fairhurst Sent: Thursday, March 11, 2004 9:58 PM To: ip-dvb@erg.abdn.ac.uk Subject: Re: ULE Extension Headers Let's see if I can help steer this discussion. * I note there is some enthusiasm to consider the idea of a ULE extension header. That is useful to know, but I don't see a consensus YET. * As I said earlier, I am against holding-up the publishing of the first rev of the ULE WG draft. I believe we should publish the draft as soon as possible (next week), to make sure the rest of the text is acceptable to the WG. We CAN issue a new revision of the ID soon after with this new functionality (if we are ready) - there's no minimum time between revisions!!! Here is my suggestion to progress the extension header topic: * We need first to at least find a list of examples of likely/potential use... Let us do this in the context of setting some (potential/actual) requirements/architecture - this also is a WG charter item! Any volunteers of 1-3 paragraphs of ID text describing for each of the ideas for use: Security; FEC; QoS; priority; Multiple-SNDU-Payload; anything else? * I'm not yet clear of the relative costs of (a,b,c) in terms of implementation, registry management, transmission efficiency - one thing that would be very useful would be to write a short ID with a proposed solution, to have something concrete to compare the design options with. Any volunteers for either of the above? Gorry P.S. I didn't mean to ask for a vote (a,b,c) - I was trying to summarise the options I had seen... Sorry if that caused some confusion. On 10/3/04 5:32 pm, "Alain RITOUX" wrote: > > > Allison, Art wrote: >> Taking one.... >> (1) ULE Extension Headers - We have described a number of ways we can >> encode extra headers associated with a specific SNDU, that a receiver >> may optionally ignore without having to discard a PDU. However, we >> have yet to agree if this is needed and which way is best. The most >> promising seem to be: >> (a) use a 16-bit type field to indicate "extension header follows" >> (b) use a 1-bit flag to indicate "extension header follows" >> (c) the assignment of type field values to identify each >> individual extension header. >> >> I recommend we add only a "place holder note" in the next revision of >> the ULE draft (to be released in about one-two weeks) which says the WG >> could possibly consider future extension headers (if needed), and >> continue this discussion for the next revision (this can happen quickly >> if the WG gets consensus, at the moment I see too many options >> and unclear concrete examples). >> >> ---- >> I thought discussion faded to silence after I acknowledged (b) >> was ok with me. (And I thought some wanted to define the following structure >> when the bit is set - an activity to which I do not think there were >> objections.) > > I also am in favour of b) A structure was proposed for the case where > the bit is set. I didn't feel any strong objection against the proposed > definition, neither a great support ;-) but we were just 3 or 4 to > discuss about it, I don't know the feeling of the WG about this stuff. > How to proceed any further ? > >> So maybe we have acceptance of an approach for this item? > maybe. > > Cheers. > Alain. From owner-ip-dvb@erg.abdn.ac.uk Thu Mar 11 21:44: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 i2BLhc0t025549 for ; Thu, 11 Mar 2004 21:43:39 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2BLhc3W025548 for ip-dvb-subscribed-users; Thu, 11 Mar 2004 21: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 [10.0.1.129] (maxp11.abdn.ac.uk [139.133.7.170]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i2BLh83S025529 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 11 Mar 2004 21:43:10 GMT User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Thu, 11 Mar 2004 21:43:00 +0000 Subject: Re: ULE Extension Headers From: Gorry Fairhurst To: Message-ID: In-Reply-To: <5A659834E1607E4EBD72FCE2FE5C9CF102FEC002@mail.NAB.ORG> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk On 11/3/04 6:02 pm, "Allison, Art" wrote: > With respect, I have seen no one register any other preference than (b) on > list. > I have been doing standards work for over 20 years and one always > wants to get all folks to express their position, but if they will not then > those who do represent the consensus and you move on. I don't believe we have reached this stage of HAVING to decide, I want to get this correct. I **DO** still welcome inputs from any others on the list. > > I don't see lack of a consensus in this matter, by any standard for > consensus. Perhaps there is off-list correspondence, but with respect that > is not appropriate to consider here. > > Gorry, if you do not support (b), and are feel your posting is inhibited > because you are the Chair, perhaps just post with your "Chair hat off" for > the record. OK, my thoughts are: I can see pros and cons in (b) and (c ) - at the moment looking at our implementation approach it looks like c will probably be easier to implement and offers easy parsing of multiple extensions.... > > 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: Thursday, March 11, 2004 11:28 AM > To: ip-dvb@erg.abdn.ac.uk > Subject: Re: ULE Extension Headers > > > > Let's see if I can help steer this discussion. > > * I note there is some enthusiasm to consider the idea of a ULE extension > header. That is useful to know, but I don't see a consensus YET. > > * As I said earlier, I am against holding-up the publishing of the first rev > of the ULE WG draft. I believe we should publish the draft as soon as > possible (next week), to make sure the rest of the text is acceptable to the > WG. We CAN issue a new revision of the ID soon after with this new > functionality (if we are ready) - there's no minimum time between > revisions!!! > > Here is my suggestion to progress the extension header topic: > > * We need first to at least find a list of examples of likely/potential > use... Let us do this in the context of setting some (potential/actual) > requirements/architecture - this also is a WG charter item! Any volunteers > of 1-3 paragraphs of ID text describing for each of the ideas for use: > Security; FEC; QoS; priority; Multiple-SNDU-Payload; anything else? > > * I'm not yet clear of the relative costs of (a,b,c) in terms of > implementation, registry management, transmission efficiency - one thing > that would be very useful would be to write a short ID with a proposed > solution, to have something concrete to compare the design options with. > > Any volunteers for either of the above? > > Gorry > > P.S. I didn't mean to ask for a vote (a,b,c) - I was trying to summarise the > options I had seen... Sorry if that caused some confusion. > > On 10/3/04 5:32 pm, "Alain RITOUX" wrote: > >> >> >> Allison, Art wrote: >>> Taking one.... >>> (1) ULE Extension Headers - We have described a number of ways we can >>> encode extra headers associated with a specific SNDU, that a receiver >>> may optionally ignore without having to discard a PDU. However, we >>> have yet to agree if this is needed and which way is best. The most >>> promising seem to be: >>> (a) use a 16-bit type field to indicate "extension header follows" >>> (b) use a 1-bit flag to indicate "extension header follows" >>> (c) the assignment of type field values to identify each >>> individual extension header. >>> >>> I recommend we add only a "place holder note" in the next revision of >>> the ULE draft (to be released in about one-two weeks) which says the WG >>> could possibly consider future extension headers (if needed), and >>> continue this discussion for the next revision (this can happen quickly >>> if the WG gets consensus, at the moment I see too many options >>> and unclear concrete examples). >>> >>> ---- >>> I thought discussion faded to silence after I acknowledged > (b) >>> was ok with me. (And I thought some wanted to define the following > structure >>> when the bit is set - an activity to which I do not think there were >>> objections.) >> >> I also am in favour of b) A structure was proposed for the case where >> the bit is set. I didn't feel any strong objection against the proposed >> definition, neither a great support ;-) but we were just 3 or 4 to >> discuss about it, I don't know the feeling of the WG about this stuff. >> How to proceed any further ? >> >>> So maybe we have acceptance of an approach for this item? >> maybe. >> >> Cheers. >> Alain. > From owner-ip-dvb@erg.abdn.ac.uk Fri Mar 12 06:07:07 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 i2C65Wsk016516 for ; Fri, 12 Mar 2004 06:05:32 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2C65WUF016515 for ip-dvb-subscribed-users; Fri, 12 Mar 2004 06:05: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 mailandnews.com (server236.fastdnsservers.com [209.81.157.236] (may be forged)) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i2C63e7r016427 for ; Fri, 12 Mar 2004 06:03:41 GMT Received: from [209.81.157.230] (williams77@mailandnews.com) by mailandnews.com; Fri, 12 Mar 2004 01:03:40 -0500 X-WM-Posted-At: mailandnews.com; Fri, 12 Mar 04 01:03:40 -0500 X-WM-Posted-At: mailandnews.com; Fri, 12 Mar 04 01:01:09 -0500 X-WebMail-UserID: williams77 Date: Fri, 12 Mar 2004 01:01:09 -0500 From: William StanisLaus To: ip-dvb@erg.abdn.ac.uk Cc: gorry@erg.abdn.ac.uk X-EXP32-SerialNo: 50000000 Subject: ULE Extension Headers Message-ID: <40514DF6@mailandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: InterChange (Hydra) SMTP v3.62.01 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-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk Hi everyone, I just started to draft the defintion for ULE extension headers, but i am becoming creative and crazy :), I have pasted the updation which i have done, though it is not complete, Wish to have your comments and views. 4. SNDU Format PDUs (IP packets and bridged Ethernet frames)are encapsulated using ULE to form a SNDU. Each SNDU is sent as an MPEG-2 Payload Unit. The encapsulation format to be used for PDUs is illustrated below: <---------------------------- SNDU ----------------------------- > +-+-------+------+---------------------+----------------+--------+ |E|Length | Type | Ext.Header* | PDU | CRC-32 | +-+-------+------+---------------------+----------------+--------+ Figure 1: SNDU Encapsulation All multi-byte values in ULE (including Length, Type, and Destination fields) are transmitted in network byte order (most significant byte first). Appendix A provides informative examples of usage. 4.1 The Destination Address Present Field Can be removed and moved on to Extension Header 4.2 Extension Header Present Field The most significant bit of the Length Field carries the value of the Extension Header Present Field, the E-bit. A Value of 1 indicates the absence of extension header for ULE. Otherwise a value of 0 indicates presence of extension header(see section 4.6). By default, the E-bit value MUST be set to a value 1. i.e. extension header doesn't exist. 4.3 Length Field 4.4 End Indicator 4.5 Type Field , Even if the extension headers are present, the Type Field carries the final SNDU payload type, i.e. even the payload is scrambled IP packet, it SHOULD have the value of 0x0800 in case of IPv4 4.6 SNDU Extension Header Field The SNDU extension header format to be used is illustrated below: < ----------------------- Ext. Header Field ---------------------- > +----------------+-----+---------------+----// ....... //----------+ |Ext.Header Type |NEHB | Ext. H Length |Ext. Header Param Value | +----------------+-----+---------------+---// ....... //-----------+ Figure 2: Extension header format 4.6.1 Extension Header Type Field The 4-bit extension header type field indicates the additional information for the SNDU header, which has to be considered in decoding/encoding of the SNDU payload. But it is not MANDATORY to consider all the extension headers, again it is an implementation decision. The extension header types are yet to be finialized(MAX 15 different ext. header types). TBD For example, 0 - Security Header 1 - Section Packing 2 - Section number 3 - Payload Start Pointer/offset 4 - Source Mac Address 5 - Destination Mac Address etc.. TBD 4.6.2 Next Extension header present field The most significant bit of the extension header Length Field carries the value of the Next Extension Header Present Field, the N-bit. A Value of 0 indicates the absence of next extension header. Otherwise a value of 1 indicates presence of extension header. By default, the N-bit value MUST be set to a value 0. i.e. next extension header doesn't exist. 4.6.3 Extension header Length The 7-bit value that indicates the extension header value length, in bytes, for the Extension header of ULE. 4.6.4 Extension Header Param Value This is the varible length parameter value for extension header. The length of this parameter is set by Extension header length(Section 4.6.3) based on the extension header type(Section 4.6.1). For example, Extension header type is 5 - Destionation Mac Address then, Extension header length is 6 - i.e. 6 bytes of ext. header value extension header param value is 00:50:c2:2f:42:43 Extension header type is 3 - Payload Start Pointer/offset then, Extension header length is 2 - i.e. 2 bytes of offset where payload starts extension header param value is 20 This is the typical example, if we say some of the extension headers as Mandatory and some are optional. In that case, all mandatory extension headers comes first, then follows payload start offset ext. header and all optional ext. headers next, if the receiver wishes to consider these optional, its well and fine otherwise, it can just discard and jump to the payload. SNDU Destination Address Field will be moved on to 4.6 subsection at appropirate location. From owner-ip-dvb@erg.abdn.ac.uk Fri Mar 12 08:36:50 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 i2C8YR0M022344 for ; Fri, 12 Mar 2004 08:34:27 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2C8YQXf022343 for ip-dvb-subscribed-users; Fri, 12 Mar 2004 08:34: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 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 i2C8UdOp022188 for ; Fri, 12 Mar 2004 08:30:39 GMT Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id 581D149F for ; Fri, 12 Mar 2004 09:30:52 +0100 (CET) Received: from 6wind.com (vouvray.dev.6wind.com [10.16.0.135]) by intranet.6wind.com (Postfix) with ESMTP id 1280F7E3; Fri, 12 Mar 2004 09:30:39 +0100 (CET) Message-ID: <4051762C.8020109@6wind.com> Date: Fri, 12 Mar 2004 09:34:52 +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 Extension Headers References: <40514DF6@mailandnews.com> In-Reply-To: <40514DF6@mailandnews.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 X-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk Hi William, First thanks, for drafting. I have seval concerns : - Destination Address Field You propose to make it become one of the extension headers, and I admit I had the same idea, but I think extension headers should be reserved for additinal data that are not usually present in SNDU, because such mechanism has an extra cost (2 bytes). The current definition of ULE, makes the Dest Add field a MUST for all unicast traffic. So the bit gained in ULE header finally gives extra overhead of 2 bytes, and if it is for 90% (no idea about the value ;-)) of ULE SNDU, it's an heavy cost. So I would be in favour of keeping the destination Address bit, and create th Extension header bit separate (i.e. stealing one more bit from length field). - The Ext Header format Why 4 bits for ext header type ? It makes following info (length, data ..) not aligned on byte boundary. I would prefer 8 bits type. - The Ext Header Processing You state that ext header processing (I mean internal processing, not blind parse) is not mandatory, but I think that ext header that changes payload semantic should be made mandatory (i.e. cause the SNDU to be dropped if type is not known). For that I would propose (with an 8 bit type) to split ext header type byte in 1 bit do idicate behaviour (drop/process next) 7 bits for exte headertype itself > ... snip ... > 4.5 Type Field > , Even if the extension headers are present, the Type Field > carries the final SNDU payload type, i.e. even the payload is > scrambled > IP packet, it SHOULD have the value of 0x0800 in case of IPv4 ==> it MUST have the value of 0x800 in case of IPv4 > > 4.6.2 Next Extension header present field > > The most significant bit of the extension header Length Field carries > the value of the Next Extension Header Present Field, the N-bit. > A Value of 0 indicates the absence of next extension header. Otherwise > a value of 1 indicates presence of extension header. > > By default, the N-bit value MUST be set to a value 0. i.e. > next extension header doesn't exist. Wherever this bit is, it would be better to have the ULE-end-indicator / padding values, make this bit tell "no extension headers" So the opposite value would do it: A Value of 1 indicates the absence of next extension header. Otherwise a value of 0 indicates presence of extension header. By default, the N-bit value MUST be set to a value 0. i.e. next extension header doesn't exist. > > 4.6.3 Extension header Length > > The 7-bit value that indicates the extension header value length, in bytes, > for the Extension header of ULE. Precision to add : This Length does NOT include the first two bytes of Extension Header (type-length pair). Cheers. Alain. -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com From owner-ip-dvb@erg.abdn.ac.uk Fri Mar 12 09:20: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 i2C9ItfS024308 for ; Fri, 12 Mar 2004 09:18:55 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2C9Itap024307 for ip-dvb-subscribed-users; Fri, 12 Mar 2004 09:18: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 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 i2C9H8AZ024212 for ; Fri, 12 Mar 2004 09:17:09 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 KAA05834 for ; Fri, 12 Mar 2004 10:17:08 +0100 (MET) From: "Bernhard Collini-Nocker" To: Subject: RE: ULE Extension Headers Date: Fri, 12 Mar 2004 10:17:07 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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: <40514DF6@mailandnews.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 X-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk Hi, in my opionion it is a good idea to think about both the D bit and the E bit again. The D bit is useful in those cases where a destination MAC address is requested for filtering/addressing purposes. It could be a Type value as well, altough this adds duplicate Types wrt to functionality. The E bit could instead be a Type value as well and only if the format of the header fields of the Ext header is not the same it could become a different Ext header. The consequence of having no D and E bit but a Type value would be that the Type field could be renamed to Next Header field, which it then essentially is. It would, however, require a different assigment strategy. Other suggestions and/or opinions? Regards, Bernhard > > Hi everyone, > I just started to draft the defintion for ULE extension headers, but i am > becoming creative and crazy :), I have pasted the updation which > i have done, > though it is not complete, Wish to have your comments and views. > > > > 4. SNDU Format > > PDUs (IP packets and bridged Ethernet frames)are > encapsulated using > ULE to form a SNDU. Each SNDU is sent as an MPEG-2 > Payload Unit. The > encapsulation format to be used for PDUs is illustrated below: > > <---------------------------- SNDU ----------------------------- > > +-+-------+------+---------------------+----------------+--------+ > |E|Length | Type | Ext.Header* | PDU | CRC-32 | > +-+-------+------+---------------------+----------------+--------+ > > Figure 1: SNDU Encapsulation > > All multi-byte values in ULE (including Length, Type, and > Destination fields) are transmitted in network byte order (most > significant byte first). Appendix A provides informative > examples of > usage. > > 4.1 The Destination Address Present Field > Can be removed and moved on to Extension Header > > 4.2 Extension Header Present Field > > The most significant bit of the Length Field carries the > value of the > Extension Header Present Field, the E-bit. A Value of 1 > indicates the > absence of extension header for ULE. Otherwise a value of > 0 indicates > presence of extension header(see section 4.6). > > By default, the E-bit value MUST be set to a value 1. i.e. > extension header doesn't exist. > > 4.3 Length Field > > > 4.4 End Indicator > > > 4.5 Type Field > , Even if the extension headers are present, > the Type Field > carries the final SNDU payload type, i.e. even the payload is > scrambled > IP packet, it SHOULD have the value of 0x0800 in case of IPv4 > > > 4.6 SNDU Extension Header Field > The SNDU extension header format to be used is illustrated below: > > < ----------------------- Ext. Header Field > ---------------------- > > +----------------+-----+---------------+----// ....... > //----------+ > |Ext.Header Type |NEHB | Ext. H Length |Ext. Header Param > Value | > +----------------+-----+---------------+---// ....... > //-----------+ > > Figure 2: Extension header format > > 4.6.1 Extension Header Type Field > The 4-bit extension header type field indicates the additional > information for the SNDU header, which has to be considered in > decoding/encoding of the SNDU payload. But it is not MANDATORY > to consider all the extension headers, again it is an > implementation > decision. > > The extension header types are yet to be finialized(MAX 15 different > ext. header types). TBD > > For example, > > 0 - Security Header > 1 - Section Packing > 2 - Section number > 3 - Payload Start Pointer/offset > 4 - Source Mac Address > 5 - Destination Mac Address > etc.. TBD > > 4.6.2 Next Extension header present field > > The most significant bit of the extension header Length > Field carries > the value of the Next Extension Header Present Field, the N-bit. > A Value of 0 indicates the absence of next extension > header. Otherwise > a value of 1 indicates presence of extension header. > > By default, the N-bit value MUST be set to a value 0. i.e. > next extension header doesn't exist. > > 4.6.3 Extension header Length > > The 7-bit value that indicates the extension header value > length, in bytes, > for the Extension header of ULE. > > 4.6.4 Extension Header Param Value > > This is the varible length parameter value for extension > header. The > length of > this parameter is set by Extension header length(Section > 4.6.3) based > on the > extension header type(Section 4.6.1). > > For example, > > Extension header type is 5 - Destionation Mac Address then, > Extension header length is 6 - i.e. 6 bytes of ext. header value > extension header param value is 00:50:c2:2f:42:43 > > Extension header type is 3 - Payload Start Pointer/offset then, > Extension header length is 2 - i.e. 2 bytes of offset > where payload > starts > extension header param value is 20 > This is the typical example, if we say some of the > extension headers as > Mandatory > and some are optional. In that case, all mandatory > extension headers > comes first, > then follows payload start offset ext. header and all > optional ext. > headers > next, if the receiver wishes to consider these optional, > its well and > fine > otherwise, it can just discard and jump to the payload. > > SNDU Destination Address Field > will be moved on to 4.6 subsection at > appropirate location. > > > > > From owner-ip-dvb@erg.abdn.ac.uk Fri Mar 12 10:36: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 i2CAYZ68028413 for ; Fri, 12 Mar 2004 10:34:36 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2CAYZ7j028412 for ip-dvb-subscribed-users; Fri, 12 Mar 2004 10:34: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 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 i2CAXQjd028319 for ; Fri, 12 Mar 2004 10:33:26 GMT Received: from vzmta01.netfr.alcatel.fr (vzmta01.netfr.alcatel.fr [155.132.182.220]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id i2C9sogK008842 for ; Fri, 12 Mar 2004 11:33:04 +0100 Importance: Low Sensitivity: Subject: =?iso-8859-1?Q?R=E9f=2E_=3A_RE=3A_ULE_Extension_Headers?= To: ip-dvb@erg.abdn.ac.uk X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Sebastien.Josset@space.alcatel.fr Date: Fri, 12 Mar 2004 11:24:21 +0100 X-MIMETrack: Serialize by Router on VZMTA01/ALCANET/ALCATEL-SPACE(Release 5.0.12 |February 13, 2003) at 12/03/2004 11:33: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 i2CAYWd8028408 Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk Hi, >The consequence of having no D and E bit but a Type value would be that the >Type field could be renamed to Next Header field, which it then essentially >is. It would, however, require a different assigment strategy. I fully agree with this suggestion. I'm in charge of ULE implementation in the IST-SatIP6 demonstrator (IPv6 interconnection thanks Satellite) and the current ULE definition needs additionnal fields to be usable in a meshed satellite system with on-board switching. As a matter of fact, we use nether D nor E. Only a type field is needed. Best regards, Sébastien Josset "Bernhard Collini-Nocker" @erg.abdn.ac.uk on 12/03/2004 10:17:07 Veuillez répondre à ip-dvb@erg.abdn.ac.uk Envoyé par : owner-ip-dvb@erg.abdn.ac.uk Pour : cc : Objet : RE: ULE Extension Headers Hi, in my opionion it is a good idea to think about both the D bit and the E bit again. The D bit is useful in those cases where a destination MAC address is requested for filtering/addressing purposes. It could be a Type value as well, altough this adds duplicate Types wrt to functionality. The E bit could instead be a Type value as well and only if the format of the header fields of the Ext header is not the same it could become a different Ext header. The consequence of having no D and E bit but a Type value would be that the Type field could be renamed to Next Header field, which it then essentially is. It would, however, require a different assigment strategy. Other suggestions and/or opinions? Regards, Bernhard > > Hi everyone, > I just started to draft the defintion for ULE extension headers, but i am > becoming creative and crazy :), I have pasted the updation which > i have done, > though it is not complete, Wish to have your comments and views. > > > > 4. SNDU Format > > PDUs (IP packets and bridged Ethernet frames)are > encapsulated using > ULE to form a SNDU. Each SNDU is sent as an MPEG-2 > Payload Unit. The > encapsulation format to be used for PDUs is illustrated below: > > <---------------------------- SNDU ----------------------------- > > +-+-------+------+---------------------+----------------+--------+ > |E|Length | Type | Ext.Header* | PDU | CRC-32 | > +-+-------+------+---------------------+----------------+--------+ > > Figure 1: SNDU Encapsulation > > All multi-byte values in ULE (including Length, Type, and > Destination fields) are transmitted in network byte order (most > significant byte first). Appendix A provides informative > examples of > usage. > > 4.1 The Destination Address Present Field > Can be removed and moved on to Extension Header > > 4.2 Extension Header Present Field > > The most significant bit of the Length Field carries the > value of the > Extension Header Present Field, the E-bit. A Value of 1 > indicates the > absence of extension header for ULE. Otherwise a value of > 0 indicates > presence of extension header(see section 4.6). > > By default, the E-bit value MUST be set to a value 1. i.e. > extension header doesn't exist. > > 4.3 Length Field > > > 4.4 End Indicator > > > 4.5 Type Field > , Even if the extension headers are present, > the Type Field > carries the final SNDU payload type, i.e. even the payload is > scrambled > IP packet, it SHOULD have the value of 0x0800 in case of IPv4 > > > 4.6 SNDU Extension Header Field > The SNDU extension header format to be used is illustrated below: > > < ----------------------- Ext. Header Field > ---------------------- > > +----------------+-----+---------------+----// ....... > //----------+ > |Ext.Header Type |NEHB | Ext. H Length |Ext. Header Param > Value | > +----------------+-----+---------------+---// ....... > //-----------+ > > Figure 2: Extension header format > > 4.6.1 Extension Header Type Field > The 4-bit extension header type field indicates the additional > information for the SNDU header, which has to be considered in > decoding/encoding of the SNDU payload. But it is not MANDATORY > to consider all the extension headers, again it is an > implementation > decision. > > The extension header types are yet to be finialized(MAX 15 different > ext. header types). TBD > > For example, > > 0 - Security Header > 1 - Section Packing > 2 - Section number > 3 - Payload Start Pointer/offset > 4 - Source Mac Address > 5 - Destination Mac Address > etc.. TBD > > 4.6.2 Next Extension header present field > > The most significant bit of the extension header Length > Field carries > the value of the Next Extension Header Present Field, the N-bit. > A Value of 0 indicates the absence of next extension > header. Otherwise > a value of 1 indicates presence of extension header. > > By default, the N-bit value MUST be set to a value 0. i.e. > next extension header doesn't exist. > > 4.6.3 Extension header Length > > The 7-bit value that indicates the extension header value > length, in bytes, > for the Extension header of ULE. > > 4.6.4 Extension Header Param Value > > This is the varible length parameter value for extension > header. The > length of > this parameter is set by Extension header length(Section > 4.6.3) based > on the > extension header type(Section 4.6.1). > > For example, > > Extension header type is 5 - Destionation Mac Address then, > Extension header length is 6 - i.e. 6 bytes of ext. header value > extension header param value is 00:50:c2:2f:42:43 > > Extension header type is 3 - Payload Start Pointer/offset then, > Extension header length is 2 - i.e. 2 bytes of offset > where payload > starts > extension header param value is 20 > This is the typical example, if we say some of the > extension headers as > Mandatory > and some are optional. In that case, all mandatory > extension headers > comes first, > then follows payload start offset ext. header and all > optional ext. > headers > next, if the receiver wishes to consider these optional, > its well and > fine > otherwise, it can just discard and jump to the payload. > > SNDU Destination Address Field > will be moved on to 4.6 subsection at > appropirate location. > > > > > ALCATEL SPACE Research Department/Advanced Telecom Satellite Systems Tel : +33 (0)53435 5104 / Fax : +33 (0)53435 5560 Porte : W218 / E-Mail : sebastien.josset@space.alcatel.fr ALCATEL SPACE From owner-ip-dvb@erg.abdn.ac.uk Fri Mar 12 11:02: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 i2CAww1j029791 for ; Fri, 12 Mar 2004 10:58:58 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2CAwv0c029790 for ip-dvb-subscribed-users; Fri, 12 Mar 2004 10:58:58 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 mail.future.futsoft.com ([203.197.140.35]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i2CAuX3s029685 for ; Fri, 12 Mar 2004 10:56:36 GMT Received: from kailash.future.futsoft.com (unverified [203.197.140.36]) by mail.future.futsoft.com (Content Technologies SMTPRS 4.3.12) with ESMTP id for ; Fri, 12 Mar 2004 16:25:31 +0530 Received: from williams (williams.future.futsoft.com [10.8.3.24]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id i2CArLb27644 for ; Fri, 12 Mar 2004 16:23:21 +0530 From: "William StanisLaus" To: Subject: RE: ULE Extension Headers Date: Fri, 12 Mar 2004 16:25:41 +0530 Message-ID: <000601c40820$8fc5d820$1803080a@future.futsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <4051762C.8020109@6wind.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 X-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk Hi Alain, Well, my initial proposal on ULE extension headers is also to retain the D-Bit, But today when i really start the draft, i went crazy, like why don't we push the Dest. Mac into Ext. Header. I understand your concern here, saving 2 bytes(Satellite traffics are very expensive ;)). in that case, i should work out in a better way... Regarding 4-bit for Ext. header Type, initially i thought, we'll not be having ext. header more than 15. Also one bit for Next Ext. Header. Then remaining 3 bits can be used for ext. header Length, if Length is going to be multiples of 2 i.e. it supports max 7 * 2 = 14 bytes of ext. header value, which is much bigger to support todays needs. But i wonder the future enhancements. If we agree on 8-bits of Ext. Header type field, we can support the Drop/process next bit, incase the Receiver is uneducated about the ext. header type received. Remaining 1 bit for next ext. header field and 7 bits for ext. header length, which was the orginal proposal :) +----------------+-----+---------------+----// ....... //----------+ |Ext.Header Type |NEHB | Ext. H Length |Ext. Header Param Value | +----------------+-----+---------------+---// ....... //-----------+ Ext. Header type = 1 byte NEHB = 1 bit ( if 0 Ext. Header is present, otherwise not present) Ext. H Length = 7 bits ( Length here is only the Ext. Header Param Value length) Ext. Header Param Value = variable length based on Ext. H Length i.e. MAX 127 bytes Best Regards, William -----Original Message----- From: owner-ip-dvb@erg.abdn.ac.uk [mailto:owner-ip-dvb@erg.abdn.ac.uk]On Behalf Of Alain RITOUX Sent: Friday, March 12, 2004 2:05 PM To: ip-dvb@erg.abdn.ac.uk Subject: Re: ULE Extension Headers Hi William, First thanks, for drafting. I have seval concerns : - Destination Address Field You propose to make it become one of the extension headers, and I admit I had the same idea, but I think extension headers should be reserved for additinal data that are not usually present in SNDU, because such mechanism has an extra cost (2 bytes). The current definition of ULE, makes the Dest Add field a MUST for all unicast traffic. So the bit gained in ULE header finally gives extra overhead of 2 bytes, and if it is for 90% (no idea about the value ;-)) of ULE SNDU, it's an heavy cost. So I would be in favour of keeping the destination Address bit, and create th Extension header bit separate (i.e. stealing one more bit from length field). - The Ext Header format Why 4 bits for ext header type ? It makes following info (length, data ..) not aligned on byte boundary. I would prefer 8 bits type. - The Ext Header Processing You state that ext header processing (I mean internal processing, not blind parse) is not mandatory, but I think that ext header that changes payload semantic should be made mandatory (i.e. cause the SNDU to be dropped if type is not known). For that I would propose (with an 8 bit type) to split ext header type byte in 1 bit do idicate behaviour (drop/process next) 7 bits for exte headertype itself > ... snip ... > 4.5 Type Field > , Even if the extension headers are present, the Type Field > carries the final SNDU payload type, i.e. even the payload is > scrambled > IP packet, it SHOULD have the value of 0x0800 in case of IPv4 ==> it MUST have the value of 0x800 in case of IPv4 > > 4.6.2 Next Extension header present field > > The most significant bit of the extension header Length Field carries > the value of the Next Extension Header Present Field, the N-bit. > A Value of 0 indicates the absence of next extension header. Otherwise > a value of 1 indicates presence of extension header. > > By default, the N-bit value MUST be set to a value 0. i.e. > next extension header doesn't exist. Wherever this bit is, it would be better to have the ULE-end-indicator / padding values, make this bit tell "no extension headers" So the opposite value would do it: A Value of 1 indicates the absence of next extension header. Otherwise a value of 0 indicates presence of extension header. By default, the N-bit value MUST be set to a value 0. i.e. next extension header doesn't exist. > > 4.6.3 Extension header Length > > The 7-bit value that indicates the extension header value length, in bytes, > for the Extension header of ULE. Precision to add : This Length does NOT include the first two bytes of Extension Header (type-length pair). 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 *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From owner-ip-dvb@erg.abdn.ac.uk Fri Mar 12 11:11: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 i2CB9YDh000384 for ; Fri, 12 Mar 2004 11:09:34 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2CB9X8p000381 for ip-dvb-subscribed-users; Fri, 12 Mar 2004 11:09: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 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 i2CB619i000142 for ; Fri, 12 Mar 2004 11:06:01 GMT Received: from eagle.6wind.com (givenchy.6wind.com [212.234.238.114]) by proxy.6wind.com (Postfix) with ESMTP id 79C696E4 for ; Fri, 12 Mar 2004 12:06:14 +0100 (CET) Received: from 6wind.com (unknown [10.16.0.135]) by eagle.6wind.com (Postfix) with ESMTP id 13934228; Fri, 12 Mar 2004 12:05:39 +0100 (CET) Message-ID: <40519A96.5030000@6wind.com> Date: Fri, 12 Mar 2004 12:10:14 +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: 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-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk Bernhard Collini-Nocker wrote: > Hi, > > in my opionion it is a good idea to think about both the D bit and the E bit > again. > The D bit is useful in those cases where a destination MAC address is > requested for filtering/addressing purposes. It could be a Type value as > well, altough this adds duplicate Types wrt to functionality. > The E bit could instead be a Type value as well and only if the format of > the header fields of the Ext header is not the same it could become a > different Ext header. > > The consequence of having no D and E bit but a Type value would be that the > Type field could be renamed to Next Header field, which it then essentially > is. It would, however, require a different assigment strategy. That is closed to what I proposed, and the pb I see, is that, with a type/next header used to extension header, we have the same namespace for both, and so the extension headers need to provide the "name" of the next header (being and ext header or the payload itself). hence, each extension header need 2 bytes to indicate what follows. If we choose william strategy, the type field is linked to payload, and extension header use a different name space, with only 1 byte to identfy itself : - price : 1 bit in ULE header. - gain : one byte per extension header. Cheers. Alain. -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com From owner-ip-dvb@erg.abdn.ac.uk Fri Mar 12 11:15:13 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 i2CBCbU0000532 for ; Fri, 12 Mar 2004 11:12:37 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2CBCbQV000531 for ip-dvb-subscribed-users; Fri, 12 Mar 2004 11:12: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 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 i2CBA47F000421 for ; Fri, 12 Mar 2004 11:10:04 GMT Received: from eagle.6wind.com (givenchy.6wind.com [212.234.238.114]) by proxy.6wind.com (Postfix) with ESMTP id 167C46AA for ; Fri, 12 Mar 2004 12:10:18 +0100 (CET) Received: from 6wind.com (unknown [10.16.0.135]) by eagle.6wind.com (Postfix) with ESMTP id A06F4228; Fri, 12 Mar 2004 12:09:42 +0100 (CET) Message-ID: <40519B89.8070405@6wind.com> Date: Fri, 12 Mar 2004 12:14:17 +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: ULE Extension Headers 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-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk Hi Sebastien, > ... snip ... > and the current ULE definition needs additionnal fields to be usable > in a meshed satellite system with on-board switching. So you have concrete example of needed ULE additional fields, please could you share ? Thanks. Alain. -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com From owner-ip-dvb@erg.abdn.ac.uk Fri Mar 12 11:27: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 i2CBP4D0001230 for ; Fri, 12 Mar 2004 11:25:04 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2CBP3TN001227 for ip-dvb-subscribed-users; Fri, 12 Mar 2004 11:25: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 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 i2CBMGUW001054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 12 Mar 2004 11:22:17 GMT Message-ID: <40519D66.5050106@erg.abdn.ac.uk> Date: Fri, 12 Mar 2004 11:22:14 +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: ULE Extension Headers References: <40514DF6@mailandnews.com> <4051762C.8020109@6wind.com> In-Reply-To: <4051762C.8020109@6wind.com> 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 X-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk There's lots of ideas in here. Here are my thoughts for the melting pot... Alain RITOUX wrote: > Hi William, > > First thanks, for drafting. I have seval concerns : > > - Destination Address Field > > You propose to make it become one of the extension headers, and I > admit I had the same idea, but I think extension headers should > be reserved for additinal data that are not usually present in SNDU, > because such mechanism has an extra cost (2 bytes). > > The current definition of ULE, makes the Dest Add field a MUST for all > unicast traffic. So the bit gained in ULE header finally gives extra > overhead of 2 bytes, and if it is for 90% (no idea about the value ;-)) > of ULE SNDU, it's an heavy cost. I agree, it is common to have a destination address. It also is one that could in future be deserving of hardware support - that's also a (small) motive for a fixed position within the header. > > So I would be in favour of keeping the destination Address bit, > and create th Extension header bit separate (i.e. stealing one more > bit from length field). > > - The Ext Header format > > Why 4 bits for ext header type ? It makes following info (length, data > ..) not aligned on byte boundary. Yes - there's a processor cost in this. Is there also cost in a one-bit flag to indicate extensions present - which has to be parsed every SNDU? > I would prefer 8 bits type. > > > - The Ext Header Processing > > You state that ext header processing (I mean internal processing, not > blind parse) is not mandatory, but I think that ext header that changes > payload semantic should be made mandatory (i.e. cause the SNDU to be > dropped if type is not known). Yes - but we already have these (mandatory) extensions supported using the private (IANA assigned) Type field, as in bridging. I do like Bernhard's email suggesting a renaming of the current Type-1 field as "next-header", I was unhappy with the names Type-1 and Type-2. > > For that I would propose (with an 8 bit type) to split ext header type > byte in > 1 bit do idicate behaviour (drop/process next) > 7 bits for exte headertype itself > > > > > >> ... snip ... >> 4.5 Type Field >> , Even if the extension headers are present, the >> Type Field >> carries the final SNDU payload type, i.e. even the payload is >> scrambled >> IP packet, it SHOULD have the value of 0x0800 in case of IPv4 > > ==> it MUST have the value of 0x800 in case of IPv4 > > >> >> 4.6.2 Next Extension header present field >> >> The most significant bit of the extension header Length Field >> carries >> the value of the Next Extension Header Present Field, the N-bit. >> A Value of 0 indicates the absence of next extension header. >> Otherwise >> a value of 1 indicates presence of extension header. >> >> By default, the N-bit value MUST be set to a value 0. i.e. >> next extension header doesn't exist. > > Wherever this bit is, it would be better to have the ULE-end-indicator / > padding values, make this bit tell "no extension headers" > > So the opposite value would do it: > > A Value of 1 indicates the absence of next extension header. Otherwise > a value of 0 indicates presence of extension header. > > By default, the N-bit value MUST be set to a value 0. i.e. > next extension header doesn't exist. > > >> >> 4.6.3 Extension header Length >> >> The 7-bit value that indicates the extension header value length, >> in bytes, >> for the Extension header of ULE. > > Precision to add : This Length does NOT include the first two bytes of > Extension Header (type-length pair). > > > Cheers. > Alain. From owner-ip-dvb@erg.abdn.ac.uk Fri Mar 12 14:20: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 i2CEEVuF008410 for ; Fri, 12 Mar 2004 14:14:32 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2CEEUBF008408 for ip-dvb-subscribed-users; Fri, 12 Mar 2004 14:14: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 mail.future.futsoft.com ([203.197.140.35]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i2CEA6E4008190 for ; Fri, 12 Mar 2004 14:10:08 GMT Received: from kailash.future.futsoft.com (unverified [203.197.140.36]) by mail.future.futsoft.com (Content Technologies SMTPRS 4.3.12) with ESMTP id for ; Fri, 12 Mar 2004 19:39:02 +0530 Received: from williams (williams.future.futsoft.com [10.8.3.24]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id i2CE6vb04577 for ; Fri, 12 Mar 2004 19:36:57 +0530 From: "William StanisLaus" To: Subject: RE: ULE Extension Headers Date: Fri, 12 Mar 2004 19:39:17 +0530 Message-ID: <000b01c4083b$9bfda300$1803080a@future.futsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <000601c40820$8fc5d820$1803080a@future.futsoft.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 X-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk Hi Alain, hope with this update your concerns are addressed. Also i am looking at (c) of Gorry's views. Definitly wish to draft the other vision as well. So that we can discuss the pros n cons Best Regards, William. 4. SNDU Format PDUs (IP packets and bridged Ethernet frames)are encapsulated using ULE to form a SNDU. Each SNDU is sent as an MPEG-2 Payload Unit. The encapsulation format to be used for PDUs is illustrated below: <---------------------------- SNDU ----------------------------- > +-+-+-------+------+---------+-----------+--------------+--------+ |D|E|Length | Type |Dest.Mac*|Ext.Header*| PDU | CRC-32 | +-+-+-------+------+---------+-----------+--------------+--------+ Figure 1: SNDU Encapsulation All multi-byte values in ULE (including Length, Type, and Destination fields) are transmitted in network byte order (most significant byte first). Appendix A provides informative examples of usage. 4.1 The Destination Address Present Field 4.2 Extension Header Present Field The 2nd most significant bit(i.e. 14th bit) of the Length Field carries the value of the Extension Header Present Field, the E-bit. A Value of 0 indicates the absence of extension header for ULE. Otherwise a value of 1 indicates presence of extension header (see section 4.6). By default, the E-bit value MUST be set to a value 0. i.e. extension header doesn't exist. 4.3 Length Field 4.4 End Indicator 4.5 Type Field , Even if the extension headers are present, the Type Field carries the final SNDU payload type, i.e. even the payload is scrambled IP packet, it MUST have the value of 0x0800 in case of IPv4 4.6 SNDU Destination Address Field 4.7 SNDU Extension Header Field The SNDU extension header format to be used is illustrated below: < ----------------------- Ext. Header Field ---------------------- > +-+---------------+-----+--------------+----// ....... //----------+ |P|Ext.Header Type|NEHB |Ext. H Length |Ext. Header Param Value | +-+---------------+-----+--------------+---// ....... //-----------+ Figure 2: Extension header format 4.7.1 Drop/Process(P-Bit) Field The most significant bit of Ext.Header Type carries the value of the Drop/Process Field, the P-bit. A Value of ZERO indicates MUST process this ext. header, If cannot drop the packet, otherwise the value of 1 is the recevier decision to process or skip and proceed further. By default, the P-bit value MUST be set to a value 0. i.e. MUST process the Ext. Header. 4.7.2 Extension Header Type Field The 7-bits extension header type field indicates the additional information for the SNDU header, which has to be considered in decoding/encoding of the SNDU payload. The extension header types are yet to be finialized. TBD For example, 0 - Security Header 1 - Section Packing 2 - Section number 3 - Payload Start Pointer/offset 4 - Source Mac Address etc.. TBD 4.7.3 Next Extension header present field The most significant bit of the extension header Length Field carries the value of the Next Extension Header Present Field, the N-bit. A Value of 0 indicates the absence of next extension header. Otherwise a value of 1 indicates presence of extension header. By default, the N-bit value MUST be set to a value 0. i.e. next extension header doesn't exist. 4.7.4 Extension header Length The 7-bit value that indicates the extension header value length, in bytes, for the Extension header of ULE, excluding Ext. Header type and Length. 4.7.5 Extension Header Param Value This is the varible length parameter value for extension header. The length of this parameter is set by Extension header length (Section 4.7.4) based on the extension header type(Section 4.7.2). For example, Extension header type is 4 - Destionation Mac Address then, Extension header length is 6 - i.e. 6 bytes of ext. header value extension header param value is 00:50:c2:2f:42:43 Extension header type is 3 - Payload Start Pointer/offset then, Extension header length is 2 - i.e. 2 bytes of offset where payload starts extension header param value is 20 This is the typical example, if we say some of the extension headers as Mandatory and some are optional. In that case, all mandatory extension headers comes first, then follows payload start offset ext. header and all optional ext. headers next, if the receiver wishes to consider these optional, its well and fine otherwise, it can just discard and jump to the payload. -----Original Message----- From: owner-ip-dvb@erg.abdn.ac.uk [mailto:owner-ip-dvb@erg.abdn.ac.uk]On Behalf Of William StanisLaus Sent: Friday, March 12, 2004 4:26 PM To: ip-dvb@erg.abdn.ac.uk Subject: RE: ULE Extension Headers Hi Alain, Well, my initial proposal on ULE extension headers is also to retain the D-Bit, But today when i really start the draft, i went crazy, like why don't we push the Dest. Mac into Ext. Header. I understand your concern here, saving 2 bytes(Satellite traffics are very expensive ;)). in that case, i should work out in a better way... Regarding 4-bit for Ext. header Type, initially i thought, we'll not be having ext. header more than 15. Also one bit for Next Ext. Header. Then remaining 3 bits can be used for ext. header Length, if Length is going to be multiples of 2 i.e. it supports max 7 * 2 = 14 bytes of ext. header value, which is much bigger to support todays needs. But i wonder the future enhancements. If we agree on 8-bits of Ext. Header type field, we can support the Drop/process next bit, incase the Receiver is uneducated about the ext. header type received. Remaining 1 bit for next ext. header field and 7 bits for ext. header length, which was the orginal proposal :) +----------------+-----+---------------+----// ....... //----------+ |Ext.Header Type |NEHB | Ext. H Length |Ext. Header Param Value | +----------------+-----+---------------+---// ....... //-----------+ Ext. Header type = 1 byte NEHB = 1 bit ( if 0 Ext. Header is present, otherwise not present) Ext. H Length = 7 bits ( Length here is only the Ext. Header Param Value length) Ext. Header Param Value = variable length based on Ext. H Length i.e. MAX 127 bytes Best Regards, William -----Original Message----- From: owner-ip-dvb@erg.abdn.ac.uk [mailto:owner-ip-dvb@erg.abdn.ac.uk]On Behalf Of Alain RITOUX Sent: Friday, March 12, 2004 2:05 PM To: ip-dvb@erg.abdn.ac.uk Subject: Re: ULE Extension Headers Hi William, First thanks, for drafting. I have seval concerns : - Destination Address Field You propose to make it become one of the extension headers, and I admit I had the same idea, but I think extension headers should be reserved for additinal data that are not usually present in SNDU, because such mechanism has an extra cost (2 bytes). The current definition of ULE, makes the Dest Add field a MUST for all unicast traffic. So the bit gained in ULE header finally gives extra overhead of 2 bytes, and if it is for 90% (no idea about the value ;-)) of ULE SNDU, it's an heavy cost. So I would be in favour of keeping the destination Address bit, and create th Extension header bit separate (i.e. stealing one more bit from length field). - The Ext Header format Why 4 bits for ext header type ? It makes following info (length, data ..) not aligned on byte boundary. I would prefer 8 bits type. - The Ext Header Processing You state that ext header processing (I mean internal processing, not blind parse) is not mandatory, but I think that ext header that changes payload semantic should be made mandatory (i.e. cause the SNDU to be dropped if type is not known). For that I would propose (with an 8 bit type) to split ext header type byte in 1 bit do idicate behaviour (drop/process next) 7 bits for exte headertype itself > ... snip ... > 4.5 Type Field > , Even if the extension headers are present, the Type Field > carries the final SNDU payload type, i.e. even the payload is > scrambled > IP packet, it SHOULD have the value of 0x0800 in case of IPv4 ==> it MUST have the value of 0x800 in case of IPv4 > > 4.6.2 Next Extension header present field > > The most significant bit of the extension header Length Field carries > the value of the Next Extension Header Present Field, the N-bit. > A Value of 0 indicates the absence of next extension header. Otherwise > a value of 1 indicates presence of extension header. > > By default, the N-bit value MUST be set to a value 0. i.e. > next extension header doesn't exist. Wherever this bit is, it would be better to have the ULE-end-indicator / padding values, make this bit tell "no extension headers" So the opposite value would do it: A Value of 1 indicates the absence of next extension header. Otherwise a value of 0 indicates presence of extension header. By default, the N-bit value MUST be set to a value 0. i.e. next extension header doesn't exist. > > 4.6.3 Extension header Length > > The 7-bit value that indicates the extension header value length, in bytes, > for the Extension header of ULE. Precision to add : This Length does NOT include the first two bytes of Extension Header (type-length pair). 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 *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From owner-ip-dvb@erg.abdn.ac.uk Fri Mar 12 14:40:28 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 i2CEdWau009636 for ; Fri, 12 Mar 2004 14:39:32 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2CEdWmq009635 for ip-dvb-subscribed-users; Fri, 12 Mar 2004 14:39: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 [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 i2CEb6kk009519 for ; Fri, 12 Mar 2004 14:37:07 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; Fri, 12 Mar 2004 09:37:08 -0500 Received: (private information removed) Message-ID: <5A659834E1607E4EBD72FCE2FE5C9CF102FEC005@mail.NAB.ORG> From: "Allison, Art" To: "'ip-dvb@erg.abdn.ac.uk'" Subject: RE: ULE Extension Headers Date: Fri, 12 Mar 2004 09:37:02 -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-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk Gorry: Thanks for sharing your assessment about (c). Given that assessment is on the record, I now see the basis for your judging that we are not quite there yet. 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: Thursday, March 11, 2004 4:43 PM To: ip-dvb@erg.abdn.ac.uk Subject: Re: ULE Extension Headers On 11/3/04 6:02 pm, "Allison, Art" wrote: > With respect, I have seen no one register any other preference than (b) on > list. > I have been doing standards work for over 20 years and one always > wants to get all folks to express their position, but if they will not then > those who do represent the consensus and you move on. I don't believe we have reached this stage of HAVING to decide, I want to get this correct. I **DO** still welcome inputs from any others on the list. > > I don't see lack of a consensus in this matter, by any standard for > consensus. Perhaps there is off-list correspondence, but with respect that > is not appropriate to consider here. > > Gorry, if you do not support (b), and are feel your posting is inhibited > because you are the Chair, perhaps just post with your "Chair hat off" for > the record. OK, my thoughts are: I can see pros and cons in (b) and (c ) - at the moment looking at our implementation approach it looks like c will probably be easier to implement and offers easy parsing of multiple extensions.... > > 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: Thursday, March 11, 2004 11:28 AM > To: ip-dvb@erg.abdn.ac.uk > Subject: Re: ULE Extension Headers > > > > Let's see if I can help steer this discussion. > > * I note there is some enthusiasm to consider the idea of a ULE extension > header. That is useful to know, but I don't see a consensus YET. > > * As I said earlier, I am against holding-up the publishing of the first rev > of the ULE WG draft. I believe we should publish the draft as soon as > possible (next week), to make sure the rest of the text is acceptable to the > WG. We CAN issue a new revision of the ID soon after with this new > functionality (if we are ready) - there's no minimum time between > revisions!!! > > Here is my suggestion to progress the extension header topic: > > * We need first to at least find a list of examples of likely/potential > use... Let us do this in the context of setting some (potential/actual) > requirements/architecture - this also is a WG charter item! Any volunteers > of 1-3 paragraphs of ID text describing for each of the ideas for use: > Security; FEC; QoS; priority; Multiple-SNDU-Payload; anything else? > > * I'm not yet clear of the relative costs of (a,b,c) in terms of > implementation, registry management, transmission efficiency - one thing > that would be very useful would be to write a short ID with a proposed > solution, to have something concrete to compare the design options with. > > Any volunteers for either of the above? > > Gorry > > P.S. I didn't mean to ask for a vote (a,b,c) - I was trying to summarise the > options I had seen... Sorry if that caused some confusion. > > On 10/3/04 5:32 pm, "Alain RITOUX" wrote: > >> >> >> Allison, Art wrote: >>> Taking one.... >>> (1) ULE Extension Headers - We have described a number of ways we can >>> encode extra headers associated with a specific SNDU, that a receiver >>> may optionally ignore without having to discard a PDU. However, we >>> have yet to agree if this is needed and which way is best. The most >>> promising seem to be: >>> (a) use a 16-bit type field to indicate "extension header follows" >>> (b) use a 1-bit flag to indicate "extension header follows" >>> (c) the assignment of type field values to identify each >>> individual extension header. >>> >>> I recommend we add only a "place holder note" in the next revision of >>> the ULE draft (to be released in about one-two weeks) which says the WG >>> could possibly consider future extension headers (if needed), and >>> continue this discussion for the next revision (this can happen quickly >>> if the WG gets consensus, at the moment I see too many options >>> and unclear concrete examples). >>> >>> ---- >>> I thought discussion faded to silence after I acknowledged > (b) >>> was ok with me. (And I thought some wanted to define the following > structure >>> when the bit is set - an activity to which I do not think there were >>> objections.) >> >> I also am in favour of b) A structure was proposed for the case where >> the bit is set. I didn't feel any strong objection against the proposed >> definition, neither a great support ;-) but we were just 3 or 4 to >> discuss about it, I don't know the feeling of the WG about this stuff. >> How to proceed any further ? >> >>> So maybe we have acceptance of an approach for this item? >> maybe. >> >> Cheers. >> Alain. > From owner-ip-dvb@erg.abdn.ac.uk Fri Mar 12 15:24: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 i2CFNcCA011496 for ; Fri, 12 Mar 2004 15:23:38 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2CFNc3I011495 for ip-dvb-subscribed-users; Fri, 12 Mar 2004 15:23: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 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 i2CFL4RI011379 for ; Fri, 12 Mar 2004 15:21:05 GMT Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id EF8C96C9 for ; Fri, 12 Mar 2004 16:21:18 +0100 (CET) Received: from 6wind.com (vouvray.dev.6wind.com [10.16.0.135]) by intranet.6wind.com (Postfix) with ESMTP id 50F53698; Fri, 12 Mar 2004 16:21:05 +0100 (CET) Message-ID: <4051D65E.2040801@6wind.com> Date: Fri, 12 Mar 2004 16:25:18 +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 Extension Headers References: <000b01c4083b$9bfda300$1803080a@future.futsoft.com> In-Reply-To: <000b01c4083b$9bfda300$1803080a@future.futsoft.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 X-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk William StanisLaus wrote: > Hi Alain, > hope with this update your concerns are addressed. Also i am looking at (c) Thanks, with this updtae, evry thing seems fine for me. > of Gorry's views. Definitly wish to draft the other vision as well. So that > we can discuss the pros n cons goodn this will provide a solid ground for discusssion. Cheers. Alain. -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com From owner-ip-dvb@erg.abdn.ac.uk Fri Mar 12 15:51: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 i2CFoRP2012648 for ; Fri, 12 Mar 2004 15:50:27 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2CFoR7G012646 for ip-dvb-subscribed-users; Fri, 12 Mar 2004 15:50:27 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 i2CFmXNe012536 for ; Fri, 12 Mar 2004 15:48:33 GMT Received: from vzmta01.netfr.alcatel.fr (vzmta01.netfr.alcatel.fr [155.132.182.220]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id i2CD5FFG003691 for ; Fri, 12 Mar 2004 16:48:21 +0100 Importance: Low Sensitivity: Subject: =?iso-8859-1?Q?R=E9f=2E_=3A_Re=3A_ULE_Extension_Headers?= To: ip-dvb@erg.abdn.ac.uk X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Sebastien.Josset@space.alcatel.fr Date: Fri, 12 Mar 2004 15:23:16 +0100 X-MIMETrack: Serialize by Router on VZMTA01/ALCANET/ALCATEL-SPACE(Release 5.0.12 |February 13, 2003) at 12/03/2004 16:48:21 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 i2CFoOCU012642 Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk Hi Alain, The current ULE definition does work fine for broadcast traffic (DVB-S) with no low level security. With security features, Key replacement needs at least an additionnal two bits field to dynamicaly shift from a key to another. In case of multi source traffic, the packet Reassembly function needs a source identifier and if QoS is provided a QoS flag. Hope it helps, Regards, Sébastien Josset alain.ritoux@6wind.com@erg.abdn.ac.uk on 12/03/2004 12:14:17 Veuillez répondre à ip-dvb@erg.abdn.ac.uk Envoyé par : owner-ip-dvb@erg.abdn.ac.uk Pour : IPDVB cc : Objet : Re: ULE Extension Headers Hi Sebastien, > ... snip ... > and the current ULE definition needs additionnal fields to be usable > in a meshed satellite system with on-board switching. So you have concrete example of needed ULE additional fields, please could you share ? Thanks. Alain. -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com ALCATEL SPACE Research Department/Advanced Telecom Satellite Systems Tel : +33 (0)53435 5104 / Fax : +33 (0)53435 5560 Porte : W218 / E-Mail : sebastien.josset@space.alcatel.fr ALCATEL SPACE From owner-ip-dvb@erg.abdn.ac.uk Fri Mar 12 19:32:42 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 i2CJVta7021561 for ; Fri, 12 Mar 2004 19:31:55 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2CJVtuD021560 for ip-dvb-subscribed-users; Fri, 12 Mar 2004 19:31: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 caci.com (mailserver1.caci.com [204.194.72.241]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i2CJUnr0021507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 12 Mar 2004 19:31:02 GMT Received: from ([10.11.4.62]) by mailserver1.caci.com with ESMTP ; Fri, 12 Mar 2004 14:30:00 -0500 (EST) Subject: unsubscribe To: ip-dvb@erg.abdn.ac.uk Message-ID: From: Henry Rausch Date: Fri, 12 Mar 2004 14:27:09 -0500 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-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk unsubscribe From owner-ip-dvb@erg.abdn.ac.uk Mon Mar 15 05:16:09 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 i2F5Eg5X029755 for ; Mon, 15 Mar 2004 05:14:42 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2F5EfrS029753 for ip-dvb-subscribed-users; Mon, 15 Mar 2004 05:14: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 mail.future.futsoft.com ([203.197.140.35]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i2F5Djnq029700 for ; Mon, 15 Mar 2004 05:13:48 GMT Received: from kailash.future.futsoft.com (unverified [203.197.140.36]) by mail.future.futsoft.com (Content Technologies SMTPRS 4.3.12) with ESMTP id for ; Mon, 15 Mar 2004 10:42:41 +0530 Received: from williams (williams.future.futsoft.com [10.8.3.24]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id i2F5DVb24585 for ; Mon, 15 Mar 2004 10:43:33 +0530 From: "William StanisLaus" To: Subject: RE: ULE Extension Headers Date: Mon, 15 Mar 2004 10:45:54 +0530 Message-ID: <001601c40a4c$981f5900$1803080a@future.futsoft.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0017_01C40A7A.B1D79500" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <4051D65E.2040801@6wind.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk This is a multi-part message in MIME format. ------=_NextPart_000_0017_01C40A7A.B1D79500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Few more updates..Please comment if you have any concerns :), Will post the other two((a) and (c)) versions soon :) so that we can debate and take the best out of three approaches. Smile, 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 -----Original Message----- From: owner-ip-dvb@erg.abdn.ac.uk [mailto:owner-ip-dvb@erg.abdn.ac.uk]On Behalf Of Alain RITOUX Sent: Friday, March 12, 2004 8:55 PM To: ip-dvb@erg.abdn.ac.uk Subject: Re: ULE Extension Headers William StanisLaus wrote: > Hi Alain, > hope with this update your concerns are addressed. Also i am looking at (c) Thanks, with this updtae, evry thing seems fine for me. > of Gorry's views. Definitly wish to draft the other vision as well. So that > we can discuss the pros n cons goodn this will provide a solid ground for discusssion. 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 *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** ------=_NextPart_000_0017_01C40A7A.B1D79500 Content-Type: text/plain; name="ULE_Extension_Header.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="ULE_Extension_Header.txt" 4. SNDU Format=20 =20 PDUs (IP packets and bridged Ethernet frames)are encapsulated using= ULE to form a SNDU. Each SNDU is sent as an MPEG-2 Payload Unit. T= he=20 encapsulation format to be used for PDUs is illustrated below:=20 =20 <---------------------------- SNDU ----------------------------- >= +-+-+-------+------+---------+-----------+--------------+--------+= |D|E|Length | Type |Dest.Mac*|Ext.Header*| PDU | CRC-32 |= +-+-+-------+------+---------+-----------+--------------+--------+= =20 Figure 1: SNDU Encapsulation=20 =20 All multi-byte values in ULE (including Length, Type, and=20 Destination fields) are transmitted in network byte order (most=20 significant byte first). Appendix A provides informative examples o= f=20 usage.=20 4.1 The Destination Address Present Field=20 =20 The most significant bit of the Length Field carries the value of= the Destination Address Present Field, the D-bit. A value of ZERO= indicates the presence of the Destination Address Field (see secti= on=20 4.6). A value of 1 indicates that a Destination Address Field is no= t=20 present (i.e. it is omitted). =20 =20 By default, the D-bit value MUST be set to a value of ZERO, except = for=20 the transmission of an End Indicator (see section 4.4), in which th= is bit MUST be set to the value of 1. =20 =20 4.2 Extension Header Present Field The 2nd most significant bit (i.e. 14th bit) of the Length Field=20 carries the value of the Extension Header Present Field, the E-bit. A Value of 1 indicates the absence of extension header for ULE.=20 Otherwise a value of ZERO indicates presence of extension header (see section 4.6). By default, the E-bit value MUST be set to a value of 1, i.e. next extension header doesn't exist. =20 4.3 Length Field=20 A 14-bit value that indicates the length, in bytes, of the SNDU=20 (encapsulated Ethernet frame, IP datagram or other packet) PDU=20 length, counted from the byte, start of the payload and excluding the CRC at the end.=20 Note the special case described in 4.4. 4.4 End Indicator=20 When the first two bytes of a SNDU has the value 0xFFFF, this=20 denotes an End Indicator (i.e., all 1 s length combined with D-bit= and E-bit value of 1 s). It indicates to the Receiver that there= are no further SNDU are present within the current TS packet (see section 6), and that no Destination Address Field is present. The= value 0xFF has specific semantics in MPEG-2 framing, where it is= used to indicate the presence of padding. This use resembles=20 [ISO-DSMCC].=20 =20 =20 4.5 Type Field=20 The 16-bit Type field indicates the type of payload carried in a=20 SNDU. The set of values that may be assigned to this field is=20 divided into two parts, similar to the allocations for Ethernet. = =20 Ethertypes were originally specified by Xerox under the DIX=20 framework for Ethernet. After specification of IEEE 802.3 [LLC], th= e=20 set of Ethertypes less than or equal to 1500 (0x05FC), assumed the= role of a length indicator. Ethernet receivers use this feature to= discriminate LLC format frames. Hence any IEEE Ethertype <=3D 1500= indicates an LLC frame, and the actual value indicates the length = of=20 the LLC frame. =20 =20 There is a potential security issue when a Receiver receives a PDU= with two length fields: The Receiver would need to validate the= actual length and the Length field and ensure that inconsistent=20 values are not propagated by the network. Specification of two=20 independent length fields is therefore undesirable. In the ULE=20 header, this avoided in the SNDU header by including only one lengt= h=20 value, but bridging of LLC frames re-introduces this consideration= (section 4.9.5).=20 =20 The Ethernet LLC mode of identification is not required in ULE,=20 since the SNDU format always carries an explicit Length Field, and= therefore the procedure in ULE is modified, as below:=20 =20 The first set of ULE Type Field values comprise the set of values <= =3D=20 1500. These Type Field values are IANA assigned (see section 4.5.1= ).=20 =20 The second set of ULE Type Field values comprise the set of values = >=20 1500. In ULE, this indicates that the value is identical to the=20 corresponding type codes specified by the IEEE/DIX type assignments= for Ethernet and recorded in the IANA EtherType registry.=20 =20 =20 4.5.1 Type 1: IANA Assigned Type Fields=20 =20 The first part of the Type space corresponds to the values 0x0000 t= o=20 1500 Decimal. These values may be used to identify link-specific=20 protocols and/or to indicate the presence of extension headers that= carry additional optional protocol fields (e.g. a bridging=20 encapsulation). Use of these values is co-ordinated by an IANA=20 registry.=20 =20 The following types are defined: =20 =20 [XXX IANA ACTION REQUIRED XXX]=20 =20 0x0000: Test SNDU, discarded by the Receiver.=20 0x0001: Bridged Ethernet Frame (i.e. MAC source address follows)=20 =20 [XXX END OF IANA ACTION REQUIRED XXX]=20 =20 =20 The remaining values within the first part of the Type space are=20 reserved for allocation by the IANA.=20 =20 [Author NOTE: Type allocation and appropriate IANA Procedure to be= determined.]=20 =20 =20 4.5.2 Type 2: Ethertype compatible Type Fields=20 =20 The second part of the Type space corresponds to the values 1500=20 (0x05DC) and 0xFFFF. This set of type assignments follow DIX/IEEE= assignments (but exclude use of this field as a frame length=20 indicator) [LLC]. The following types are defined in this document= for part 2:=20 =20 0x0800 : IPv4 Payload (according to IANA EtherTypes)=20 0x86DD : IPv6 Payload (according to IANA EtherTypes)=20 =20 All other assignments in part two of this space should be=20 coordinated with the values defined for IANA EtherType=20 encapsulations.=20 =20 =20 4.6 SNDU Destination MAC Address Field=20 =20 The SNDU Destination MAC Address Field is optional (see section 4.1= ).=20 This field MUST be carried for IP unicast packets destined to=20 routers(i.e. D=3D0). A sender MAY omit this field (D=3D1) for an IP= unicast packet and/or multicast packets delivered to Receivers tha= t=20 are able to utilise a discriminator field (e.g. the IPv4/IPv6=20 destination address), which in combination with the PID value, coul= d=20 be interpreted as a Link-Level address.=20 =20 When the SNDU header indicates the presence of a SNDU Destination= MAC Address field (i.e. D=3D0), a Network Point of Attachment, NPA= , field=20 directly follows the SNDU Type Field. NPA destination addresses ar= e=20 6 B numbers, normally expressed in hexadecimal, used to identify th= e=20 Receiver(s) in a MPEG-2 transmission network that should process a= received SNDU. The value 0x00:00:00:00:00:00, MUST NOT be used as = a=20 destination address in a SNDU. The least significant bit of the=20 first byte of the address is set to 1 for multicast frames, and the= remaining bytes specify the link layer multicast address. The=20 specific value 0xFF:FF:FF:FF:FF:FF is the link broadcast address,= indicating this SNDU is to be delivered to all Receivers.=20 =20 =20 4.7 SNDU Extension Header Field The SNDU extension header format to be used is illustrated below: < ----------------------- Ext. Header Field ---------------------- = >=20 +-+---------------+-----+--------------+----// ....... //----------+ |P|Ext.Header Type|NEHB |Ext. H Length |Ext. Header Param Value | +-+---------------+-----+--------------+---// ....... //-----------= +=20 =20 Figure 2: Extension header format=20 4.7.1 Drop/Process(P-Bit) Field The most significant bit of Ext.Header Type carries the value of the Drop/Process Field, the P-bit. A Value of ZERO indicates MUST proce= ss this ext. header, if cannot process, drop the packet, otherwise the value of 1 is the receivers decision to process or skip and proceed further. By default, the P-bit value MUST be set to a value ZERO. i.e. MUST process the Ext. Header. 4.7.2 Extension Header Type Field The 7-bit extension header type field indicates the additional information for the SNDU header, which MUST be considered in=20 processing the SNDU payload, based on the P-Bit (see section 4.7.1) =09 The extension header types are yet to be finialized. TBD =09 For example, =09 0 - Security Header 1 - Section Packing 2 - Section number 3 - Source Mac Address 4 - Source Identifier 5 - QoS Classifier etc.. TBD =20 4.7.3 Next Extension header present field The most significant bit of the extension header Length Field carri= es=20 the value of the Next Extension Header Present Field, the N-bit.=20 A Value of ZERO indicates the absence of next extension header. Otherwise a value of 1 indicates presence of extension header. By default, the N-bit value MUST be set to a value ZERO. i.e. next extension header does not exist. 4.7.4 Extension header Length The 7-bit value that indicates the extension header value length, i= n=20 bytes for that extension header of ULE, excluding extension header = type=20 and length. 4.7.5 Extension Header Param Value This is the variable length parameter value for extension header. T= he length of this parameter is set by extension header length (see sec= tion 4.7.4) based on the extension header type( see section 4.7.2). For example, a) Security Header When security features are supported by ULE TBD b) Section Packing Provision to combine more than one PDU(IP/Bridged Packet) in single= ULE Header, provided packet identifier (Source PID and MAC, Destination= PID and MAC, if QoS not considered, otherwise packet identifier MAY dif= fer based on QoS) across these packets are identical. Three IP Packets has to be transmitted in a SNDU. Extension header type is 01 i.e. P-Bit =3D 0 ( MUST Process) and ty= pe as Section Packing. Extension header length is 06 i.e. N-Bit =3D 0 (No more extension h= eader) and 6 bytes of ext. header value length =20 Regarding extension header param value, for every PDU, first four b= it are used for index, next 12 bit are used for offset value in the SN= DU payload from start of the payload. =20 <---- Ext.Header ---><------------PDU---------------> =20 ...//+--+--+-+--+-+--+-+--+------+------------+-----------+...// |01|06|0|00|1|40|2|B2| IP1 | IP2 | IP3 | ...//+--+--+-+--+-+--+-+--+------+------------+-----------+...// |____|____|| | | |____|_______| |=20 |____________________| Figure 3: Section Packing example In the above figure, in ext. header param value, 0 - indicates the first packet. 00 - indicates the first packet offset value in payload. 1 - indicates the second packet. 40 - indicates the second packet offset/start position value in HEX i.e 64 decimal. 2 - indicates the third packet. B2 - indicates the third packet offset/start position value in HEX i.e 178 decimal =09 c) Section Number In case, support for connection oriented approach required and Err= or Correction is needed. There MUST be an agreement with Transmitter a= nd Receiver to support Section Number. By which, LOST/ERROR SNDU=92s c= an be corrected by requesting to retransmit those SNDU=92s alone, based o= n the Section Number. d) Source Mac Address=09 Extension header type is 04 i.e. P-Bit =3D 0 ( MUST Process) and ty= pe as Source Mac Address. Extension header length is 06 i.e. N-Bit =3D 0 (No more extension h= eader) and 6 bytes of ext. header value length Extension header param value is 00:50:c2:2f:42:43 e) Source identifier TBD e) QoS Classifier TBD =20 =20 ------=_NextPart_000_0017_01C40A7A.B1D79500-- From owner-ip-dvb@erg.abdn.ac.uk Mon Mar 15 09:24: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 i2F9MsOk008861 for ; Mon, 15 Mar 2004 09:22:54 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2F9Ms6C008858 for ip-dvb-subscribed-users; Mon, 15 Mar 2004 09:22: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 mail.slb.com (eurmta01.london.eur.slb.com [134.32.26.55]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i2F9LnTp008803; Mon, 15 Mar 2004 09:21:50 GMT Received: from conversion-daemon.eurmta01.london.eur.slb.com by eurmta01.london.eur.slb.com (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) id <0HUM00B010Z0D5@eurmta01.london.eur.slb.com>; Mon, 15 Mar 2004 09:21:43 +0000 (GMT) Received: from sgrl.sema.es (sgrl.madrid.eur.slb.com [163.183.160.39]) by eurmta01.london.eur.slb.com (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HUM00C3A1OAFT@eurmta01.london.eur.slb.com>; Mon, 15 Mar 2004 09:14:35 +0000 (GMT) Received: from sgrl.sema.es ([127.0.0.1]) by sgrl.sema.es (Netscape Messaging Server 4.15) with SMTP id HUM1OC00.KZS; Mon, 15 Mar 2004 10:14:36 +0100 Received: from 163.183.152.34 by sgrl.sema.es (InterScan E-Mail VirusWall NT) ; Mon, 15 Mar 2004 10:14:35 +0100 (Romance Standard Time) Received: from mailbcn.sema.es ([127.0.0.1]) by mailbcn.sema.es (Netscape Messaging Server 4.15) with SMTP id HUM33600.AXC; Mon, 15 Mar 2004 10:45:06 +0100 Received: from 163.183.152.197 by mailbcn.sema.es (InterScan E-Mail VirusWall NT); Mon, 15 Mar 2004 10:45:06 +0100 Date: Mon, 15 Mar 2004 10:13:46 +0100 From: josep martrat Subject: unsubscribe To: majordomo@erg.abdn.ac.uk Cc: ip-dvb@erg.abdn.ac.uk Message-id: <405573CA.2090406@barcelona.sema.slb.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) 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-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk unsubscribe From owner-ip-dvb@erg.abdn.ac.uk Mon Mar 15 21:51: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 i2FLooYT010470 for ; Mon, 15 Mar 2004 21:50:50 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2FLoope010467 for ip-dvb-subscribed-users; Mon, 15 Mar 2004 21:50:50 GMT Message-Id: <200403152150.i2FLoope010467@mavis.erg.abdn.ac.uk> X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f From: Internet-Drafts@ietf.org Cc: ip-dvb@erg.abdn.ac.uk To: IETF-Announce: ; Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Date: Mon, 15 Mar 2004 15:56:04 -0500 Subject: I-D ACTION:draft-ietf-ipdvb-ule-00.txt Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over DVB Working Group of the IETF. Title : Ultra Lightweight Encapsulation (ULE) for transmission of IP datagrams over MPEG-2/DVB networks Author(s) : G. Fairhurst, B. Collini-Nocker Filename : draft-ietf-ipdvb-ule-00.txt Pages : 37 Date : 2004-3-15 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipdvb-ule-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipdvb-ule-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipdvb-ule-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-15142820.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipdvb-ule-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipdvb-ule-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-15142820.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ip-dvb@erg.abdn.ac.uk Wed Mar 17 11:05:28 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 i2HB362d007521 for ; Wed, 17 Mar 2004 11:03:06 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2HB35jL007520 for ip-dvb-subscribed-users; Wed, 17 Mar 2004 11:03: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 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 i2HB0ZhA007432 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Wed, 17 Mar 2004 11:00:37 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 1B3Ymf-0003m4-00; Wed, 17 Mar 2004 11:00:25 +0000 Message-ID: <40582FC8.D5D6F000@surrey.ac.uk> Date: Wed, 17 Mar 2004 11:00:24 +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: Security Considerations section for draft-fair-ipdvb-req-04.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-100.1 required=5.5 tests=USER_AGENT_MOZILLA_XM,USER_IN_WHITELIST,X_ACCEPT_LANG version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Scanner: exiscan *1B3Ymf-0003m4-00*JhZU.6Qefxk* (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 X-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk Hi All, I have been discussing with Gorry the security requirements for IP over DVB. Here is some text that I prepared and borrowed some material from the PILC draft on Advice to Link Designers. I also include Laurent Claverotte recent ideas (email) as well, any comments are welcome: *********************************** x. SECURITY REQUIREMENTS FOR IPDVB End-to-end security (including confidentiality, authentication, integrity and access control) are closely associated with the end-user assets they protect. This close association cannot be ensured when providing subnetwork security mechanisms, such as those for MPEG-2 transmission networks. Several security mechanisms that can be used end-to-end have already been deployed in the general Internet and are enjoying increasing use. The most important are: * The Secure Sockets Layer (SSL) and Transport Layer Security, TLS, which is primarily used to protect web commerce; * Pretty Good Privacy (PGP) and S/MIME, primarily used to protect and authenticate email and software distributions; * The Secure Shell (SSH), used to secure remote access and file transfer; * IPsec, a general purpose encryption and authentication mechanism above IP that can be used by any IP application. However, subnetwork security is important [LINK] and should be encouraged, on the principle that it is better than the default situation, which all too often is no security at all. Users of especially vulnerable subnets (such as radio/broadcast networks and /or shared media Internet access) often have control over at most one endpoint - usually a client and therefore cannot enforce the use of end-to-end mechanisms. A related role for subnetwork security is to protect users against traffic analysis, i.e., identifying the communicating parties and determining their communication patterns and volumes even when their actual contents are protected by strong end-to-end security mechanisms (this is important for networks such broadacst/radio, were eaves-dropping is easy). Finally an important role for subnetwork security is the protection of the subnetwork itself. Possible threats to subnetwork assets include theft of service and denial of service; shared media subnets tend to be especially vulnerable to such attacks [LINK]. Security concerns not just the packet data being communicated, but also the control protocols. Appropriate security functions must therefore be provided for ipdvb support protocols [LINK]. x.1 SECURITY REQUIREMENTS FOR ULE Link layer encryption ULE level encryption is commonly used in broadcast/radio links. The encryption and key exchange methods vary significantly, depending on the intended application. For example, DVB-S/DVB-RCS operated by Access Network Operators (ANO) may wish to provide their customers (Internet Service Providers, 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). A common 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 mechanisms such as IPSec). Therefore it is important to understand that both security solutions ((ANO-to-ISP) and (ISP-to-end users)) can co-exist and are economically viable. It is therefore recommended that ULE supports optional encryption of the SNDU payload. Furthermore, it may be desirable to encrypt/authenticate some/all ULE headers. The method of encryption and the way in which keys are exchanged is beyond the scope of the ULE Specification. However, the specification MUST provide a method to allow such encryption to be implemented at the link layer. [LINK] = Advice to Link Designers, IETF PILC WG, BCP (with RFC-Ed). *********************************** FINALLY, here are some thoughts about the TYPE field for security: Some options that may be used include: A type field in the ULE header (16 bits) can be used to indicate that some part of the ULE PDU is encrypted. There are two solutions for the use of the type field: 1. Define a range of types X-to-Y for security. These types will act as security key ID to enable the decryption of the incoming ULE PDUs. 2. A single type value may be defined for encryption (say X) followed by any required Security Association (SA) parameters. The definition of this SA and the related encryption keys are out of the scope for ULE draft. The second solution is more generic and decouples ULE document from any future security extensions, and resembles the IPSEC operations. The former provides functions that resemble those currently used for MPE encapsulation (odd and even keys). Haitham -- 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 Wed Mar 17 14:20:27 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 i2HEIKCJ015762 for ; Wed, 17 Mar 2004 14:18:20 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2HEIJ1D015761 for ip-dvb-subscribed-users; Wed, 17 Mar 2004 14:18: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 i2HEGbIn015667 for ; Wed, 17 Mar 2004 14:16:37 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, 17 Mar 2004 09:16:38 -0500 Received: (private information removed) Message-ID: <5A659834E1607E4EBD72FCE2FE5C9CF102FEC032@mail.NAB.ORG> From: "Allison, Art" To: "'ip-dvb@erg.abdn.ac.uk'" Subject: RE: Security Considerations section for draft-fair-ipdvb-req-04. txt Date: Wed, 17 Mar 2004 09:16:36 -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-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk The suggestion made in the email from Haitham Cruickshank did not seem a reasonable one to me; but I stand ready to hear additional, relevant reasons. To start, I would like to probe the reasons that I found lacking in applicability a bit.. see embedded excerpts and responses. 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: Wednesday, March 17, 2004 6:00 AM To: ip-dvb@erg.abdn.ac.uk Subject: Security Considerations section for draft-fair-ipdvb-req-04.txt Hi All, However, subnetwork security is important [LINK] and should be encouraged, on the principle that it is better than the default situation, which all too often is no security at all. Users of especially vulnerable subnets (such as radio/broadcast networks and /or shared media Internet access) often have control over at most one endpoint - usually a client and therefore cannot enforce the use of end-to-end mechanisms. AA> Just what is the alleged vulnerability? To what exactly? A related role for subnetwork security is to protect users against traffic analysis, i.e., identifying the communicating parties and determining their communication patterns and volumes even when their actual contents are protected by strong end-to-end security mechanisms (this is important for networks such broadacst/radio, were eaves-dropping is easy). AA> Let us explore this a bit. What communication pattern? All that I can see is that the emission station sends x% of their packets using ULE. How is a traffic analysis of any kind going to harm a broadcaster in any way? Please describe how this a threat to the transmitter operator? / Finally an important role for subnetwork security is the protection of the subnetwork itself. Possible threats to subnetwork assets include theft of service AA> Please explain what service is protected from being stolen by this addition. If the contents are not usable, (and each service has many means to so insure), what can one do with these packets? / and denial of service; shared media subnets tend to be especially vulnerable to such attacks AA>I don't see this in the RF domain. One way to deny service from a DTV transmitter is to create interfering RF energy that prevents reception. While possible, RF DFing works fine to track down and eliminate the attacker were it to occur- and it wipes out all reception, not just some packets. I fail to see a motive for anyone to make such an investment, the cost of which is directly related to the number of receivers interfered with. For a satellite service it is much harder to interrupt as one must get into the aperture of the antenna. But you posit a even more complex and sophisticated attack... here is what I think would be required to do selective denial of service at the MPEG packet level: One would have to demodulate the stream, then strip the packets that contain the service to be denied, the re-emit the altered stream (replacing the deleted packets with null or faked packets) and recreate the RF modulation. And even then the attacker would only affect those where he could achieve local undesired to desired signal levels (as he has to override the desired stream with his undesired stream). / Security concerns not just the packet data being communicated, but also the control protocols. AA> Please explain how the control protocols could be altered in the real word considering the RF systems. / Appropriate security functions must therefore be provided for ipdvb support protocols [LINK]. AA> Please provide additional information to show what risk is mitigated in order to support your assertion that this 'must' be done. So far you have not enabled me to see any concrete basis for this complexity, nor that there is even a very small real attack risk. Art ::{)> Art Allison Director Advanced Engineering NAB 1771 N St NW Washington DC 20036 202 429 5418 From owner-ip-dvb@erg.abdn.ac.uk Thu Mar 18 09:09:02 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 i2I969H0001947 for ; Thu, 18 Mar 2004 09:06:09 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2I968bd001945 for ip-dvb-subscribed-users; Thu, 18 Mar 2004 09:06: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 mail19f.dulles19-verio.com (mail19f.dulles19-verio.com [198.170.241.24]) by erg.abdn.ac.uk (8.12.11/8.12.11) with SMTP id i2I92wh7001755 for ; Thu, 18 Mar 2004 09:02:59 GMT Received: from www.innoviti.com (199.239.255.48) by mail19f.dulles19-verio.com (RS ver 1.0.91vs) with SMTP id 1-174376571 for ; Thu, 18 Mar 2004 04:02:55 -0500 (EST) From: "Vinay S." To: Subject: Hepl required regarding the PAT table Date: Thu, 18 Mar 2004 14:35:19 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Loop-Detect: 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-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk hi I m a newbie to DVB-RCS.While trying to get the Program map PIDs, for the different programs,from the PAT table, a variable N is presented in the standard, saying that so many program channels are present.But, I have not found any place/hint indicating what this variable n might be? The exact context is given below.(marked by the Arrow) program_association_table program_association_section() { table_id 8 uimsbf section_syntax_indicator 1 bslbf '0' 1 bslbf reserved 2 bslbf section_length 12 uimsbf transport_stream_id 16 uimsbf reserved 2 bslbf version_number 5 uimsbf current_next_indicator 1 bslbf section_number 8 uimsbf last_section_number 8 uimsbf for (i = 0; i < N; i++) -------------------->what is the value of N? { program_number 16 uimsbf reserved 3 bslbf if (program_number = = '0') { network_PID 13 uimsbf } else { program_map_PID 13 uimsbf } } CRC_32 32 rpchof } with warm regards, Vinay.S From owner-ip-dvb@erg.abdn.ac.uk Thu Mar 18 09:55: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 i2I9sGd7004232 for ; Thu, 18 Mar 2004 09:54:16 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2I9sGgR004231 for ip-dvb-subscribed-users; Thu, 18 Mar 2004 09:54: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 mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i2I9rJSN004169 for ; Thu, 18 Mar 2004 09:53:19 GMT Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 18 Mar 2004 01:52:43 -0800 Received: from 157.54.8.23 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 18 Mar 2004 01:53:13 -0800 Received: from RED-MSG-42.redmond.corp.microsoft.com ([157.54.12.202]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 18 Mar 2004 01:53:11 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: RE: Hepl required regarding the PAT table Date: Thu, 18 Mar 2004 01:53:22 -0800 Message-ID: <19A328037921AA42847A717566D1D6A1016233CE@RED-MSG-42.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Hepl required regarding the PAT table thread-index: AcQMy4NYJoH1J0vxScq1ae5cBAir/gAADGZw From: "Regis Crinon" To: Cc: "Regis Crinon" X-OriginalArrivalTime: 18 Mar 2004 09:53:11.0793 (UTC) FILETIME=[D31D5E10:01C40CCE] 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-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C40CCE.D9AC508A" ------_=_NextPart_001_01C40CCE.D9AC508A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Hi Vinay: =20 This is the typical MPEG-2 Systems way to indicate that the length is not explicitly specified in the syntax. However, it can be easily inferred that this loop cannot take more than (section_length - 9) bytes. (9 =3D 5 bytes after the section_length field + 4 bytes of CRC = at the bottom of the section). The section length cannot exceed 1021 bytes so this further constrains the number of iterations (no more than (1021-9) / 4 =3D 253 programs can be listed in the section ). So, N <=3D 253.=20 =20 =20 While I am at it, I will encourage you to buy the following book (I am one of the authors). It includes a nice intro to MPEG-2 systems where all this kind of stuff is already resolved for you. The title is: Data Broadcasting: Understanding the ATSC Data Broadcast Standard =20 =20 http://www.amazon.com/exec/obidos/tg/detail/-/0071375902/qid=3D1079602791= / sr=3D1-2/ref=3Dsr_1_2/102-4421880-4066506?v=3Dglance&s=3Dbooks =20 =20 Kind regards, =20 Regis. =20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Regis J. Crinon, Ph.D. Lead Program Manager, Core Media Processing Technologies Windows Digital Media Division Microsoft Corporation One Microsoft Way Building 50 - Office 3509 Redmond WA 98052-6399 USA Tel: 425-707-3475 Fax: 425-936-7329 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 =20 =20 -----Original Message----- From: owner-ip-dvb@erg.abdn.ac.uk [mailto:owner-ip-dvb@erg.abdn.ac.uk] On Behalf Of Vinay S. Sent: Thursday, March 18, 2004 1:05 AM To: ip-dvb@erg.abdn.ac.uk Subject: Hepl required regarding the PAT table =20 =20 hi =20 I m a newbie to DVB-RCS.While trying to get the Program map PIDs, for the different programs,from the PAT table, a variable N is presented in the standard, saying that so many program channels are present.But, I have not found any place/hint indicating what this variable n might be? The exact context is given below.(marked by the Arrow) =20 program_association_table program_association_section() { table_id 8 uimsbf section_syntax_indicator 1 bslbf '0' 1 bslbf reserved 2 bslbf section_length 12 uimsbf transport_stream_id 16 uimsbf reserved 2 bslbf version_number 5 uimsbf current_next_indicator 1 bslbf section_number 8 uimsbf last_section_number 8 uimsbf =20 for (i =3D 0; i < N; i++) -------------------->what is the value = of N? { program_number 16 uimsbf reserved 3 bslbf if (program_number =3D =3D '0') { network_PID 13 uimsbf } else { program_map_PID 13 uimsbf } } CRC_32 32 rpchof } =20 =20 with warm regards, Vinay.S =20 =20 ------_=_NextPart_001_01C40CCE.D9AC508A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Hi Vinay:

 

This is the typical MPEG-2 Systems way to indicate that the = length is not explicitly specified in the syntax. However, it can be easily = inferred that this loop cannot take more than (section_length - 9) bytes. (9 =3D 5 = bytes after the  section_length field + 4 bytes of CRC at the bottom of the = section). The section length cannot exceed 1021 bytes so this further constrains the = number of iterations (no more than (1021-9) / 4 =3D 253 programs can be listed = in the section ). So, N <=3D 253.

 

 

While I am at it, I will encourage you to buy the following book = (I am one of the authors). It includes a nice intro to MPEG-2 systems where = all this kind of stuff is already resolved for you.

The title is:

Data Broadcasting: Understanding = the ATSC Data Broadcast Standard

 

 

http://www.amazon.com/exec/obidos/tg/detail/-/0071375902/qid=3D107960= 2791/sr=3D1-2/ref=3Dsr_1_2/102-4421880-4066506?v=3Dglance&s=3Dbooks

 

 

Kind regards,

 

Regis.

 

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

Regis J. Crinon, Ph.D.

Lead Program Manager, Core Media Processing = Technologies

Windows Digital Media Division

Microsoft Corporation

One Microsoft Way

Building 50 - Office 3509

Redmond WA 98052-6399

USA

Tel: 425-707-3475

Fax: 425-936-7329

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

 

 

 

-----Original Message-----
From: owner-ip-dvb@erg.abdn.ac.uk [mailto:owner-ip-dvb@erg.abdn.ac.uk] = On Behalf Of Vinay S.
Sent: Thursday, March 18, 2004 1:05 AM
To: ip-dvb@erg.abdn.ac.uk
Subject: Hepl required regarding the PAT table

 

 

hi

 

 I m a newbie to DVB-RCS.While trying to get the Program = map PIDs, for the

different programs,from the PAT table,

a variable N is presented in the standard, saying that so many = program

channels are present.But, I have not found any = place/hint

indicating what this variable n might be? The exact context is = given

below.(marked by the Arrow)

 

program_association_table

program_association_section()

{

      table_id 8 = uimsbf

      section_syntax_indicator 1 = bslbf

      '0' 1 bslbf

      reserved 2 = bslbf

      section_length 12 = uimsbf

      transport_stream_id 16 = uimsbf

      reserved 2 = bslbf

      version_number 5 = uimsbf

      current_next_indicator 1 = bslbf

      section_number 8 = uimsbf

      last_section_number 8 = uimsbf

 

      for (i =3D 0; i < N; = i++)  -------------------->what is the value of N?

      {

           = ; program_number 16 uimsbf

           = ; reserved 3 bslbf

           = ; if (program_number =3D =3D '0')

           = ; {

           = ;       network_PID 13 uimsbf

           = ; }

           = ; else

           = ; {

           = ; program_map_PID 13 uimsbf

           = ; }

      }

CRC_32 32 rpchof

}

 

 

with warm regards,

Vinay.S

 

 

=00 ------_=_NextPart_001_01C40CCE.D9AC508A-- --------------InterScan_NT_MIME_Boundary-- From owner-ip-dvb@erg.abdn.ac.uk Thu Mar 18 10:08:44 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 i2IA5awN004761 for ; Thu, 18 Mar 2004 10:05:36 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2IA5YM4004759 for ip-dvb-subscribed-users; Thu, 18 Mar 2004 10:05: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 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 i2IA2YKd004627 for ; Thu, 18 Mar 2004 10:02:34 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 LAA24543 for ; Thu, 18 Mar 2004 11:02:34 +0100 (MET) From: "Bernhard Collini-Nocker" To: Subject: RE: Hepl required regarding the PAT table Date: Thu, 18 Mar 2004 11:02:33 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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) 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-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk Hi, > hi > > I m a newbie to DVB-RCS.While trying to get the Program map PIDs, for the > different programs,from the PAT table, > a variable N is presented in the standard, saying that so many program > channels are present.But, I have not found any place/hint > indicating what this variable n might be? The exact context is given > below.(marked by the Arrow) N is simply the number of programs, i.e. collections of correlated PIDs for audio/video/data, to be found as PMTs. > program_association_table > program_association_section() > { > table_id 8 uimsbf > section_syntax_indicator 1 bslbf > '0' 1 bslbf > reserved 2 bslbf > section_length 12 uimsbf > transport_stream_id 16 uimsbf > reserved 2 bslbf > version_number 5 uimsbf > current_next_indicator 1 bslbf > section_number 8 uimsbf > last_section_number 8 uimsbf > > for (i = 0; i < N; i++) -------------------->what is the > value of N? Number of programs. So on a transponder with 8 digital tv programs N equals 8 (or more, if other kind of programs are present). > { > program_number 16 uimsbf > reserved 3 bslbf > if (program_number = = '0') > { > network_PID 13 uimsbf > } > else > { > program_map_PID 13 uimsbf > } > } > CRC_32 32 rpchof > } > > > with warm regards, > Vinay.S Regards, Bernhard From owner-ip-dvb@erg.abdn.ac.uk Thu Mar 18 14:23:50 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 i2IEMBDi016328 for ; Thu, 18 Mar 2004 14:22:11 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2IEMArW016327 for ip-dvb-subscribed-users; Thu, 18 Mar 2004 14:22:10 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 mail19a.dulles19-verio.com (mail19a.dulles19-verio.com [198.170.241.2]) by erg.abdn.ac.uk (8.12.11/8.12.11) with SMTP id i2IEFlJV016000 for ; Thu, 18 Mar 2004 14:15:48 GMT Received: from www.innoviti.com (199.239.255.48) by mail19a.dulles19-verio.com (RS ver 1.0.91vs) with SMTP id 2-1665529342 for ; Thu, 18 Mar 2004 09:15:45 -0500 (EST) From: "Vinay S." To: "Ip-Dvb" Subject: PMT table Date: Thu, 18 Mar 2004 19:48:11 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Loop-Detect: 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-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk Hi I got the PAt table.I have got the PIDs for the PMT for each program. But in the PMT, again I have encountered a problem.In The pmt tables,A descriptor is mentioned,but no description of the descriptor is provided,Can you please help me with this? What is the advantage of leaving some of the Stuff in the grey areas? Regards Vinay with warm regards, Vinay.S From owner-ip-dvb@erg.abdn.ac.uk Thu Mar 18 18:53: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 i2IIqQKi028583 for ; Thu, 18 Mar 2004 18:52:26 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2IIqQ3G028582 for ip-dvb-subscribed-users; Thu, 18 Mar 2004 18:52: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 [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 i2IIp2P7028514 for ; Thu, 18 Mar 2004 18:51:03 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, 18 Mar 2004 13:51:03 -0500 Received: (private information removed) Message-ID: <5A659834E1607E4EBD72FCE2FE5C9CF102FEC045@mail.NAB.ORG> From: "Allison, Art" To: "'ip-dvb@erg.abdn.ac.uk'" Subject: RE: PMT table Date: Thu, 18 Mar 2004 13:50:57 -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-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk Vinay See http://www.atsc.org/standards/Code_Point_Registry.pdf under descriptors for a partial list of tags and references for ones you might find in the PMT inner or outer descriptor loop. (Sorry it has others that go elsewhere and is light on DVB descriptors as the ATSC/DVB coordination effort is not complete.) Art ::{)> Art Allison Director Advanced Engineering NAB 1771 N St NW Washington DC 20036 202 429 5418 -----Original Message----- From: Vinay S. [mailto:vinay@innoviti.com] Sent: Thursday, March 18, 2004 9:18 AM To: Ip-Dvb Subject: PMT table Hi I got the PAt table.I have got the PIDs for the PMT for each program. But in the PMT, again I have encountered a problem.In The pmt tables,A descriptor is mentioned,but no description of the descriptor is provided,Can you please help me with this? What is the advantage of leaving some of the Stuff in the grey areas? Regards Vinay with warm regards, Vinay.S From owner-ip-dvb@erg.abdn.ac.uk Mon Mar 22 10:53: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 i2MAr3Kx011425 for ; Mon, 22 Mar 2004 10:53:03 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2MAr2Jk011424 for ip-dvb-subscribed-users; Mon, 22 Mar 2004 10:53:02 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 i2MAohK1011312 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 22 Mar 2004 10:50:47 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 1B5N0e-0004Vi-00; Mon, 22 Mar 2004 10:50:20 +0000 Message-ID: <405EC4EB.666F005A@surrey.ac.uk> Date: Mon, 22 Mar 2004 10:50:20 +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: Security Considerations section for draft-fair-ipdvb-req-04.txt References: <5A659834E1607E4EBD72FCE2FE5C9CF102FEC032@mail.NAB.ORG> 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 *1B5N0e-0004Vi-00*DmeNyGXasRE* (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 X-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk Hi again, Before answering the specific issues that Art raised, I like to say that most of the material in my previous email (Security Considerations section for draft-fair-ipdvb-req-04.txt) are taken from two source: * draft-ietf-pilc-link-design-15.txt: This document has the consensus of many people in the IETF, where Gorry is a co-author. * Mr. Laurent Claverotte email, where Alcatel are actively developing DVB-RCS equipment. See in-line for extra replies: "Allison, Art" wrote: > The suggestion made in the email from Haitham Cruickshank did not seem a > reasonable one to me; but I stand ready to hear additional, relevant > reasons. To start, I would like to probe the reasons that I found lacking > in applicability a bit.. see embedded excerpts and responses. > > 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: Wednesday, March 17, 2004 6:00 AM > To: ip-dvb@erg.abdn.ac.uk > Subject: Security Considerations section for draft-fair-ipdvb-req-04.txt > > Hi All, > > > However, subnetwork security is important [LINK] and should be > encouraged, on the principle that it is better than the default > situation, which all too often is no security at all. Users of > especially vulnerable subnets (such as radio/broadcast networks and /or > shared media Internet access) often have control over at most one > endpoint - usually a client and therefore cannot enforce the use of > end-to-end mechanisms. > AA> Just what is the alleged vulnerability? To what exactly? The vulnerability refers to two separate issues: 1. Satellite and wireless links are more vulnerable to attacks such as eavesdropping and traffic analysis due to the broadcast nature of these links. 2. End users might not have control on the overall link such as the link between the service provider and the satellite gateway. > > > A related role for subnetwork security is to protect users against > traffic analysis, i.e., identifying the communicating parties and > determining their communication patterns and volumes even when their > actual contents are protected by strong end-to-end security mechanisms > (this is important for networks such broadacst/radio, were > eaves-dropping is easy). > AA> Let us explore this a bit. What communication pattern? All that I can > see is that the emission station sends x% of their packets using ULE. How is > a traffic analysis of any kind going to harm a broadcaster in any way? > Please describe how this a threat to the transmitter operator? > / Even if the information is encrypted, it is possible for intruders to identify communicating parties identities from IP addresses (if not encrypted) or satellite terminal MAC addresses. Therefore intruders can identify the satellite operator customers and this is really bad if the customer is a high profile organization (such as UK MoD or US DoD). > > > Finally an important role for subnetwork > security is the protection of the subnetwork itself. Possible threats > to subnetwork assets include theft of service > > AA> Please explain what service is protected from being stolen by this > addition. > If the contents are not usable, (and each service has many means to so > insure), what can one do with these packets? > / This point is really about source authentication to prevent intruders from high jacking a satellite link and pretending to be a legitimate user. > > > and denial of service; > shared media subnets tend to be especially vulnerable to such attacks > AA>I don't see this in the RF domain. Yes I agree it is difficult in the RF domain > One way to deny service from a DTV > transmitter is to create interfering RF energy that prevents reception. > While possible, RF DFing works fine to track down and eliminate the attacker > were it to occur- and it wipes out all reception, not just some packets. I > fail to see a motive for anyone to make such an investment, the cost of > which is directly related to the number of receivers interfered with. For a > satellite service it is much harder to interrupt as one must get into the > aperture of the antenna. > > But you posit a even more complex and sophisticated attack... here is what I > think would be required to do selective denial of service at the MPEG packet > level: > One would have to demodulate the stream, then strip the packets that > contain the service to be denied, the re-emit the altered stream (replacing > the deleted packets with null or faked packets) and recreate the RF > modulation. And even then the attacker would only affect those where he > could achieve local undesired to desired signal levels (as he has to > override the desired stream with his undesired stream). > / > Yes agree. > > Security concerns not just the packet data being communicated, but also > the control protocols. > AA> Please explain how the control protocols could be altered in the real > word considering the RF systems. > / > This is a system issues not RF. Control protocol refer to two areas: * Connection establishment/termination messages * Network management and routing messages. If intruders can send bogus control/routing messages, then legitimate users might experience denial of service attacks. > > Appropriate security functions must therefore be > provided for ipdvb support protocols [LINK]. > > AA> Please provide additional information to show what risk is mitigated in > order to support your assertion that this 'must' be done. So far you have > not enabled me to see any concrete basis for this complexity, nor that there > is even a very small real attack risk. It is interesting to see that you have such optimistic views about security relating issues, where companies such as CANAL+ have paid a heavy price for smart card frauds (DVB-S Conditional Access). Haitham > > > Art > ::{)> > Art Allison > Director Advanced Engineering > NAB > 1771 N St NW > Washington DC 20036 > 202 429 5418 -- 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 Mon Mar 22 21:39: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 i2MLcRMk011394 for ; Mon, 22 Mar 2004 21:38:27 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2MLcQbM011393 for ip-dvb-subscribed-users; Mon, 22 Mar 2004 21:38:27 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 i2MLbgcY011353 for ; Mon, 22 Mar 2004 21:37: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; Mon, 22 Mar 2004 16:37:44 -0500 Received: (private information removed) Message-ID: <5A659834E1607E4EBD72FCE2FE5C9CF102FEC070@mail.NAB.ORG> From: "Allison, Art" To: "'ip-dvb@erg.abdn.ac.uk'" Subject: RE: Security Considerations section for draft-fair-ipdvb-req-04. txt Date: Mon, 22 Mar 2004 16:37:42 -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-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk It seems we must have a different environment and application in mind and therefore may be talking past each other. It seems that you envision some of the traffic being directed to a narrow set of users (transported by the RF), who will have the keys to de scramble the packets, and who don't want anyone to know the amount of their traffic. If just these users' traffic is scrambled the traffic analysis can still reveal changes in the total amount of private (scrambled) data. I thought this was a Broadcast means, not a narrowcast means. If one were to dedicate part of the bandwidth to send sensitive data, do so in a private manner, not a internationally standardized one. Why give an attacker any information at all? And as one has to get the CA system in place for these users, any protocol can do that (can even use a PID that is not in the PMT). Second, it seems out of scope to put elements in the RF emissions that belong in the contribution process. It seems that you are concerned about attacks on the data flow up to the RF emission. This is a valid and important concern; but seemingly not relevant to a light weight emission protocol. Certainly, these elements are appropriate to consider when it is practical to replace packets. Protection vs. replacement packets in the RF domain is just overkill. See comments below... 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: Monday, March 22, 2004 5:50 AM To: ip-dvb@erg.abdn.ac.uk Subject: Re: Security Considerations section for draft-fair-ipdvb-req-04.txt Hi again, Before answering the specific issues that Art raised, I like to say that most of the material in my previous email (Security Considerations section for draft-fair-ipdvb-req-04.txt) are taken from two source: * draft-ietf-pilc-link-design-15.txt: This document has the consensus of many people in the IETF, where Gorry is a co-author. * Mr. Laurent Claverotte email, where Alcatel are actively developing DVB-RCS equipment. See in-line for extra replies: "Allison, Art" wrote: > The suggestion made in the email from Haitham Cruickshank did not seem a > reasonable one to me; but I stand ready to hear additional, relevant > reasons. To start, I would like to probe the reasons that I found lacking > in applicability a bit.. see embedded excerpts and responses. > > 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: Wednesday, March 17, 2004 6:00 AM > To: ip-dvb@erg.abdn.ac.uk > Subject: Security Considerations section for draft-fair-ipdvb-req-04.txt > > Hi All, > > > However, subnetwork security is important [LINK] and should be > encouraged, on the principle that it is better than the default > situation, which all too often is no security at all. Users of > especially vulnerable subnets (such as radio/broadcast networks and /or > shared media Internet access) often have control over at most one > endpoint - usually a client and therefore cannot enforce the use of > end-to-end mechanisms. > AA> Just what is the alleged vulnerability? To what exactly? The vulnerability refers to two separate issues: 1. Satellite and wireless links are more vulnerable to attacks such as eavesdropping and traffic analysis due to the broadcast nature of these links. AA> Anyone can listen, true. So what? If a user wants to avoid traffic analysis they could send data all the time...the valid receiver will toss the filler as presumably the content would be important to protect at a higher level (IP->UDP->application). 2. End users might not have control on the overall link such as the link between the service provider and the satellite gateway. AA> Seems out of scope hypothetical... that is contribution control not emission transport control. End users=consumers to me, not a broadcaster. This is for an MPEG-2 stream, and if it is important to protect a contribution link, the entire stream can be scrambled for protection. > > > A related role for subnetwork security is to protect users against > traffic analysis, i.e., identifying the communicating parties and > determining their communication patterns and volumes even when their > actual contents are protected by strong end-to-end security mechanisms > (this is important for networks such broadacst/radio, were > eaves-dropping is easy). > AA> Let us explore this a bit. What communication pattern? All that I can > see is that the emission station sends x% of their packets using ULE. How is > a traffic analysis of any kind going to harm a broadcaster in any way? > Please describe how this a threat to the transmitter operator? > / Even if the information is encrypted, it is possible for intruders to identify communicating parties identities from IP addresses (if not encrypted) or satellite terminal MAC addresses. Therefore intruders can identify the satellite operator customers and this is really bad if the customer is a high profile organization (such as UK MoD or US DoD). AA> So the attack you think we need to protect against my this level scrambling is increased traffic FROM a particular IP address (or set) that is associated with a particular user that is being broadcast using RF to get to many locations? Further the amount of traffic need to matter to the sending org and the org does not want to pay for a steady data stream of IP-level protected material; constant flows are the only way to protect against traffic analysis. Or can we expect to hear next that ALL TS packets with ULE need this so that certain important packets are disguised Do you have a statement from any such organization that they want to use this means? As to MAC address, did I miss the requirement for a return channel to make this work? This is one-way only. > > > Finally an important role for subnetwork > security is the protection of the subnetwork itself. Possible threats > to subnetwork assets include theft of service > > AA> Please explain what service is protected from being stolen by this > addition. > If the contents are not usable, (and each service has many means to so > insure), what can one do with these packets? > / This point is really about source authentication to prevent intruders from high jacking a satellite link and pretending to be a legitimate user. AA> Protection against this attack is important, but hardly addressed by scrambling inside some of the transport packets. Contribution links need security, but not at this level, where it does nothing to protect the rest of the transport packets. As a broadcaster, I am concerned about my video being so attacked and replaced, not just the ULE packets in the TS - and therefore the entire link needs to be protected by means appropriate to the attack risk. > > > and denial of service; > shared media subnets tend to be especially vulnerable to such attacks > AA>I don't see this in the RF domain. Yes I agree it is difficult in the RF domain AA> I thought that ALL the intended use is in the RF domain. Wired networks have addressed this issue, of course. It makes zero sense to put MPEG-2 packets which have into IP packets and expect such buried security to prevent much of anything. > One way to deny service from a DTV > transmitter is to create interfering RF energy that prevents reception. > While possible, RF DFing works fine to track down and eliminate the attacker > were it to occur- and it wipes out all reception, not just some packets. I > fail to see a motive for anyone to make such an investment, the cost of > which is directly related to the number of receivers interfered with. For a > satellite service it is much harder to interrupt as one must get into the > aperture of the antenna. > > But you posit a even more complex and sophisticated attack... here is what I > think would be required to do selective denial of service at the MPEG packet > level: > One would have to demodulate the stream, then strip the packets that > contain the service to be denied, the re-emit the altered stream (replacing > the deleted packets with null or faked packets) and recreate the RF > modulation. And even then the attacker would only affect those where he > could achieve local undesired to desired signal levels (as he has to > override the desired stream with his undesired stream). > / > Yes agree. > > Security concerns not just the packet data being communicated, but also > the control protocols. > AA> Please explain how the control protocols could be altered in the real > word considering the RF systems. > / > This is a system issues not RF. Control protocol refer to two areas: * Connection establishment/termination messages * Network management and routing messages. If intruders can send bogus control/routing messages, then legitimate users might experience denial of service attacks. AA> Again, true but out of scope-- protection of contribution links is the job of the link not the job of some of the packets in the payload of that link. > > Appropriate security functions must therefore be > provided for ipdvb support protocols [LINK]. > > AA> Please provide additional information to show what risk is mitigated in > order to support your assertion that this 'must' be done. So far you have > not enabled me to see any concrete basis for this complexity, nor that there > is even a very small real attack risk. It is interesting to see that you have such optimistic views about security relating issues, where companies such as CANAL+ have paid a heavy price for smart card frauds (DVB-S Conditional Access). AA> And as to optimistic, well I learned at the CIA that one can be certain that attacks will occur if there is something to be gained by the attacker. And the something can just be pride in doing so. But all I see here is a push to get more technology into the draft that just increases complexity and provides no practical protection. The first step in deciding what security is appropriate is a risk analysis. I have not seen a case for an international recommendation to have this . Haitham > > > Art > ::{)> > Art Allison > Director Advanced Engineering > NAB > 1771 N St NW > Washington DC 20036 > 202 429 5418 -- 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 Tue Mar 23 10:14: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 i2NACURZ014161 for ; Tue, 23 Mar 2004 10:12:30 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2NACTLJ014160 for ip-dvb-subscribed-users; Tue, 23 Mar 2004 10:12:30 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 i2NAAsTR014076 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 23 Mar 2004 10:10:55 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 1B5irp-0006Od-00 for ip-dvb@erg.abdn.ac.uk; Tue, 23 Mar 2004 10:10:41 +0000 Message-ID: <40600D20.FDBA2A37@surrey.ac.uk> Date: Tue, 23 Mar 2004 10:10:41 +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: Security Considerations section for draft-fair-ipdvb-req-04.txt References: <5A659834E1607E4EBD72FCE2FE5C9CF102FEC070@mail.NAB.ORG> 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 *1B5irp-0006Od-00*mzxfOSDBumg* (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 X-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk Hi again, The several issues raised at Art's email are interesting, but I feel it is going too far into the security related issues, which is not the main focus of the group. I think the security consideration for IP over DVB should be filled objectively and should satisfy two major requirements: 1. The security complexity should be considered carefully so that it will not impact the IP over DVB operation severely 2. The security solution must be conform with IETF views on security and the Internet operations in general. Finally, I think it is time for Gorry to summarize the security related discussions and progress towards the exact text to be put in the requirements and/or the ULE documents. Haitham "Allison, Art" wrote: > It seems we must have a different environment and application in mind and > therefore may be talking past each other. > > It seems that you envision some of the traffic being directed to a narrow > set of users (transported by the RF), who will have the keys to de scramble > the packets, and who don't want anyone to know the amount of their traffic. > If just these users' traffic is scrambled the traffic analysis can still > reveal changes in the total amount of private (scrambled) data. solution to that is to scramble everything, which leads to the need to > address the key management and distribution issues--but that does not seem > to be a light weight approach.> > > I thought this was a Broadcast means, not a narrowcast means. If one were to > dedicate part of the bandwidth to send sensitive data, do so in a private > manner, not a internationally standardized one. Why give an attacker any > information at all? And as one has to get the CA system in place for these > users, any protocol can do that (can even use a PID that is not in the PMT). > > Second, it seems out of scope to put elements in the RF emissions that > belong in the contribution process. It seems that you are concerned about > attacks on the data flow up to the RF emission. This is a valid and > important concern; but seemingly not relevant to a light weight emission > protocol. > Certainly, these elements are appropriate to consider when it is practical > to replace packets. > > Protection vs. replacement packets in the RF domain is just overkill. > See comments below... > 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: Monday, March 22, 2004 5:50 AM > To: ip-dvb@erg.abdn.ac.uk > Subject: Re: Security Considerations section for > draft-fair-ipdvb-req-04.txt > > Hi again, > > Before answering the specific issues that Art raised, I like to say that > most of > the material in my previous email (Security Considerations section for > draft-fair-ipdvb-req-04.txt) are taken from two source: > > * draft-ietf-pilc-link-design-15.txt: This document has the consensus of > many > people in the IETF, where Gorry is a co-author. > * Mr. Laurent Claverotte email, where Alcatel are actively developing > DVB-RCS > equipment. > > See in-line for extra replies: > > "Allison, Art" wrote: > > > The suggestion made in the email from Haitham Cruickshank did not seem a > > reasonable one to me; but I stand ready to hear additional, relevant > > reasons. To start, I would like to probe the reasons that I found > lacking > > in applicability a bit.. see embedded excerpts and responses. > > > > 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: Wednesday, March 17, 2004 6:00 AM > > To: ip-dvb@erg.abdn.ac.uk > > Subject: Security Considerations section for draft-fair-ipdvb-req-04.txt > > > > Hi All, > > > > > > However, subnetwork security is important [LINK] and should be > > encouraged, on the principle that it is better than the default > > situation, which all too often is no security at all. Users of > > especially vulnerable subnets (such as radio/broadcast networks and /or > > shared media Internet access) often have control over at most one > > endpoint - usually a client and therefore cannot enforce the use of > > end-to-end mechanisms. > > AA> Just what is the alleged vulnerability? To what exactly? > > The vulnerability refers to two separate issues: > > 1. Satellite and wireless links are more vulnerable to attacks such as > eavesdropping and traffic analysis due to the broadcast nature of these > links. > AA> Anyone can listen, true. So what? If a user wants to avoid traffic > analysis they could send data all the time...the valid receiver will toss > the filler as presumably the content would be important to protect at a > higher level (IP->UDP->application). > > 2. End users might not have control on the overall link such as the link > between > the service provider and the satellite gateway. > AA> Seems out of scope hypothetical... that is contribution control not > emission transport control. End users=consumers to me, not a broadcaster. > This is for an MPEG-2 stream, and if it is important to protect a > contribution link, the entire stream can be scrambled for protection. > > > > > > A related role for subnetwork security is to protect users against > > traffic analysis, i.e., identifying the communicating parties and > > determining their communication patterns and volumes even when their > > actual contents are protected by strong end-to-end security mechanisms > > (this is important for networks such broadacst/radio, were > > eaves-dropping is easy). > > AA> Let us explore this a bit. What communication pattern? All that I can > > see is that the emission station sends x% of their packets using ULE. How > is > > a traffic analysis of any kind going to harm a broadcaster in any way? > > Please describe how this a threat to the transmitter operator? > > / > > Even if the information is encrypted, it is possible for intruders to > identify > communicating parties identities from IP addresses (if not encrypted) or > satellite terminal MAC addresses. Therefore intruders can identify the > satellite operator customers and this is really bad if the customer is a > high > profile organization (such as UK MoD or US DoD). > > AA> So the attack you think we need to protect against my this level > scrambling is increased traffic FROM a particular IP address (or set) that > is associated with a particular user that is being broadcast using RF to get > to many locations? Further the amount of traffic need to matter to the > sending org and the org does not want to pay for a steady data stream of > IP-level protected material; constant flows are the only way to protect > against traffic analysis. Or can we expect to hear next that ALL TS > packets with ULE need this so that certain important packets are disguised > Do you have a statement from any such organization that they want to use > this means? As to MAC address, did I miss the requirement for a return > channel to make this work? This is one-way only. > > > > > > Finally an important role for subnetwork > > security is the protection of the subnetwork itself. Possible threats > > to subnetwork assets include theft of service > > > > AA> Please explain what service is protected from being stolen by this > > addition. > > If the contents are not usable, (and each service has many means to so > > insure), what can one do with these packets? > > / > > This point is really about source authentication to prevent intruders from > high > jacking a satellite link and pretending to be a legitimate user. > > AA> Protection against this attack is important, but hardly addressed by > scrambling inside some of the transport packets. Contribution links need > security, but not at this level, where it does nothing to protect the rest > of the transport packets. As a broadcaster, I am concerned about my video > being so attacked and replaced, not just the ULE packets in the TS - and > therefore the entire link needs to be protected by means appropriate to the > attack risk. > > > > > > and denial of service; > > shared media subnets tend to be especially vulnerable to such attacks > > AA>I don't see this in the RF domain. > > Yes I agree it is difficult in the RF domain > AA> I thought that ALL the intended use is in the RF domain. Wired networks > have addressed this issue, of course. It makes zero sense to put MPEG-2 > packets which have into IP packets and expect such > buried security to prevent much of anything. > > > One way to deny service from a DTV > > transmitter is to create interfering RF energy that prevents reception. > > While possible, RF DFing works fine to track down and eliminate the > attacker > > were it to occur- and it wipes out all reception, not just some packets. I > > fail to see a motive for anyone to make such an investment, the cost of > > which is directly related to the number of receivers interfered with. For > a > > satellite service it is much harder to interrupt as one must get into the > > aperture of the antenna. > > > > But you posit a even more complex and sophisticated attack... here is what > I > > think would be required to do selective denial of service at the MPEG > packet > > level: > > One would have to demodulate the stream, then strip the packets > that > > contain the service to be denied, the re-emit the altered stream > (replacing > > the deleted packets with null or faked packets) and recreate the RF > > modulation. And even then the attacker would only affect those where he > > could achieve local undesired to desired signal levels (as he has to > > override the desired stream with his undesired stream). > > / > > > > Yes agree. > > > > > Security concerns not just the packet data being communicated, but also > > the control protocols. > > AA> Please explain how the control protocols could be altered in the real > > word considering the RF systems. > > / > > > > This is a system issues not RF. Control protocol refer to two areas: > * Connection establishment/termination messages > * Network management and routing messages. > > If intruders can send bogus control/routing messages, then legitimate users > might experience denial of service attacks. > > AA> Again, true but out of scope-- protection of contribution links is the > job of the link not the job of some of the packets in the payload of that > link. > > > > Appropriate security functions must therefore be > > provided for ipdvb support protocols [LINK]. > > > > AA> Please provide additional information to show what risk is mitigated > in > > order to support your assertion that this 'must' be done. So far you have > > not enabled me to see any concrete basis for this complexity, nor that > there > > is even a very small real attack risk. > > It is interesting to see that you have such optimistic views about security > relating issues, where companies such as CANAL+ have paid a heavy price > for > smart card frauds (DVB-S Conditional Access). > > AA> And as to optimistic, well I learned at the CIA that one can be certain > that attacks will occur if there is something to be gained by the attacker. > And the something can just be pride in doing so. But all I see here is a > push to get more technology into the draft that just increases complexity > and provides no practical protection. The first step in deciding what > security is appropriate is a risk analysis. I have not seen a case for an > international recommendation to have this postulated>. > > Haitham > > > > > > > > Art > > ::{)> > > Art Allison > > Director Advanced Engineering > > NAB > > 1771 N St NW > > Washington DC 20036 > > 202 429 5418 > > -- > 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/ -- 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 Tue Mar 23 11:46: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 i2NBiZul018468 for ; Tue, 23 Mar 2004 11:44:35 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2NBiYOM018466 for ip-dvb-subscribed-users; Tue, 23 Mar 2004 11:44: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 smail3.alcatel.fr (na5.alcatel.fr [194.133.58.5]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i2NBhhE9018403 for ; Tue, 23 Mar 2004 11:43: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 i2N8S0gU026423 for ; Tue, 23 Mar 2004 12:43:34 +0100 Importance: Low Sensitivity: Subject: =?iso-8859-1?Q?R=E9f=2E_=3A_RE=3A_Security_Considerations_section_for?= draft-fair-ipdvb-req-04. txt To: ip-dvb@erg.abdn.ac.uk X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Tarif.Zein-Alabedeen@space.alcatel.fr Date: Tue, 23 Mar 2004 12:12:27 +0100 X-MIMETrack: Serialize by Router on VZMTA01/ALCANET/ALCATEL-SPACE(Release 5.0.12 |February 13, 2003) at 23/03/2004 12:43:34 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 i2NBiVTP018459 Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk hi everybody just a small comment concerning Art considerations : encryption (e.g. in a DVB-RCS system) is mainly intended to data privacy protection that is to avoid others receiving the same channel from being able to look into content (and not the volume of traffic) you are receiving. This can apply to closed groups as you said (e.g. VPN or Intranets), but can as well apply to individual consumers. Even if data itself is not as sensitive.. but who likes that poeple know which kind of content he is browsing at home... Even if the subnetwork is a broadcast type as cable, point to point should be allowed if satellites are to be used as broadband Internet access solutions. In fact, going into issues on how to manage and exchange keys etc is out of scoop of our work. These are more related to the control and management plans and we can re-use what have been defined in DVB-RCS. We have just to address what is required from an encapsulation point of view (data plan) regards Tarif "Allison, Art" @erg.abdn.ac.uk on 22/03/2004 22:37:42 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: Security Considerations section for draft-fair-ipdvb-req-04. txt It seems we must have a different environment and application in mind and therefore may be talking past each other. It seems that you envision some of the traffic being directed to a narrow set of users (transported by the RF), who will have the keys to de scramble the packets, and who don't want anyone to know the amount of their traffic. If just these users' traffic is scrambled the traffic analysis can still reveal changes in the total amount of private (scrambled) data. I thought this was a Broadcast means, not a narrowcast means. If one were to dedicate part of the bandwidth to send sensitive data, do so in a private manner, not a internationally standardized one. Why give an attacker any information at all? And as one has to get the CA system in place for these users, any protocol can do that (can even use a PID that is not in the PMT). Second, it seems out of scope to put elements in the RF emissions that belong in the contribution process. It seems that you are concerned about attacks on the data flow up to the RF emission. This is a valid and important concern; but seemingly not relevant to a light weight emission protocol. Certainly, these elements are appropriate to consider when it is practical to replace packets. Protection vs. replacement packets in the RF domain is just overkill. See comments below... 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: Monday, March 22, 2004 5:50 AM To: ip-dvb@erg.abdn.ac.uk Subject: Re: Security Considerations section for draft-fair-ipdvb-req-04.txt Hi again, Before answering the specific issues that Art raised, I like to say that most of the material in my previous email (Security Considerations section for draft-fair-ipdvb-req-04.txt) are taken from two source: * draft-ietf-pilc-link-design-15.txt: This document has the consensus of many people in the IETF, where Gorry is a co-author. * Mr. Laurent Claverotte email, where Alcatel are actively developing DVB-RCS equipment. See in-line for extra replies: "Allison, Art" wrote: > The suggestion made in the email from Haitham Cruickshank did not seem a > reasonable one to me; but I stand ready to hear additional, relevant > reasons. To start, I would like to probe the reasons that I found lacking > in applicability a bit.. see embedded excerpts and responses. > > 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: Wednesday, March 17, 2004 6:00 AM > To: ip-dvb@erg.abdn.ac.uk > Subject: Security Considerations section for draft-fair-ipdvb-req-04.txt > > Hi All, > > > However, subnetwork security is important [LINK] and should be > encouraged, on the principle that it is better than the default > situation, which all too often is no security at all. Users of > especially vulnerable subnets (such as radio/broadcast networks and /or > shared media Internet access) often have control over at most one > endpoint - usually a client and therefore cannot enforce the use of > end-to-end mechanisms. > AA> Just what is the alleged vulnerability? To what exactly? The vulnerability refers to two separate issues: 1. Satellite and wireless links are more vulnerable to attacks such as eavesdropping and traffic analysis due to the broadcast nature of these links. AA> Anyone can listen, true. So what? If a user wants to avoid traffic analysis they could send data all the time...the valid receiver will toss the filler as presumably the content would be important to protect at a higher level (IP->UDP->application). 2. End users might not have control on the overall link such as the link between the service provider and the satellite gateway. AA> Seems out of scope hypothetical... that is contribution control not emission transport control. End users=consumers to me, not a broadcaster. This is for an MPEG-2 stream, and if it is important to protect a contribution link, the entire stream can be scrambled for protection. > > > A related role for subnetwork security is to protect users against > traffic analysis, i.e., identifying the communicating parties and > determining their communication patterns and volumes even when their > actual contents are protected by strong end-to-end security mechanisms > (this is important for networks such broadacst/radio, were > eaves-dropping is easy). > AA> Let us explore this a bit. What communication pattern? All that I can > see is that the emission station sends x% of their packets using ULE. How is > a traffic analysis of any kind going to harm a broadcaster in any way? > Please describe how this a threat to the transmitter operator? > / Even if the information is encrypted, it is possible for intruders to identify communicating parties identities from IP addresses (if not encrypted) or satellite terminal MAC addresses. Therefore intruders can identify the satellite operator customers and this is really bad if the customer is a high profile organization (such as UK MoD or US DoD). AA> So the attack you think we need to protect against my this level scrambling is increased traffic FROM a particular IP address (or set) that is associated with a particular user that is being broadcast using RF to get to many locations? Further the amount of traffic need to matter to the sending org and the org does not want to pay for a steady data stream of IP-level protected material; constant flows are the only way to protect against traffic analysis. Or can we expect to hear next that ALL TS packets with ULE need this so that certain important packets are disguised Do you have a statement from any such organization that they want to use this means? As to MAC address, did I miss the requirement for a return channel to make this work? This is one-way only. > > > Finally an important role for subnetwork > security is the protection of the subnetwork itself. Possible threats > to subnetwork assets include theft of service > > AA> Please explain what service is protected from being stolen by this > addition. > If the contents are not usable, (and each service has many means to so > insure), what can one do with these packets? > / This point is really about source authentication to prevent intruders from high jacking a satellite link and pretending to be a legitimate user. AA> Protection against this attack is important, but hardly addressed by scrambling inside some of the transport packets. Contribution links need security, but not at this level, where it does nothing to protect the rest of the transport packets. As a broadcaster, I am concerned about my video being so attacked and replaced, not just the ULE packets in the TS - and therefore the entire link needs to be protected by means appropriate to the attack risk. > > > and denial of service; > shared media subnets tend to be especially vulnerable to such attacks > AA>I don't see this in the RF domain. Yes I agree it is difficult in the RF domain AA> I thought that ALL the intended use is in the RF domain. Wired networks have addressed this issue, of course. It makes zero sense to put MPEG-2 packets which have into IP packets and expect such buried security to prevent much of anything. > One way to deny service from a DTV > transmitter is to create interfering RF energy that prevents reception. > While possible, RF DFing works fine to track down and eliminate the attacker > were it to occur- and it wipes out all reception, not just some packets. I > fail to see a motive for anyone to make such an investment, the cost of > which is directly related to the number of receivers interfered with. For a > satellite service it is much harder to interrupt as one must get into the > aperture of the antenna. > > But you posit a even more complex and sophisticated attack... here is what I > think would be required to do selective denial of service at the MPEG packet > level: > One would have to demodulate the stream, then strip the packets that > contain the service to be denied, the re-emit the altered stream (replacing > the deleted packets with null or faked packets) and recreate the RF > modulation. And even then the attacker would only affect those where he > could achieve local undesired to desired signal levels (as he has to > override the desired stream with his undesired stream). > / > Yes agree. > > Security concerns not just the packet data being communicated, but also > the control protocols. > AA> Please explain how the control protocols could be altered in the real > word considering the RF systems. > / > This is a system issues not RF. Control protocol refer to two areas: * Connection establishment/termination messages * Network management and routing messages. If intruders can send bogus control/routing messages, then legitimate users might experience denial of service attacks. AA> Again, true but out of scope-- protection of contribution links is the job of the link not the job of some of the packets in the payload of that link. > > Appropriate security functions must therefore be > provided for ipdvb support protocols [LINK]. > > AA> Please provide additional information to show what risk is mitigated in > order to support your assertion that this 'must' be done. So far you have > not enabled me to see any concrete basis for this complexity, nor that there > is even a very small real attack risk. It is interesting to see that you have such optimistic views about security relating issues, where companies such as CANAL+ have paid a heavy price for smart card frauds (DVB-S Conditional Access). AA> And as to optimistic, well I learned at the CIA that one can be certain that attacks will occur if there is something to be gained by the attacker. And the something can just be pride in doing so. But all I see here is a push to get more technology into the draft that just increases complexity and provides no practical protection. The first step in deciding what security is appropriate is a risk analysis. I have not seen a case for an international recommendation to have this . Haitham > > > Art > ::{)> > Art Allison > Director Advanced Engineering > NAB > 1771 N St NW > Washington DC 20036 > 202 429 5418 -- 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 Mar 25 12:58:07 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 i2PCuMOU026787 for ; Thu, 25 Mar 2004 12:56:22 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2PCuM1u026786 for ip-dvb-subscribed-users; Thu, 25 Mar 2004 12:56: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 [192.168.1.102] (195-238-52-158.direcpceu.com [195.238.52.158]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i2PCrZOf026638 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 25 Mar 2004 12:54:01 GMT User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Thu, 25 Mar 2004 09:47:30 +0000 From: Gorry Fairhurst To: Message-ID: In-Reply-To: <405EC4EB.666F005A@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 Subject: Re: Security Considerations section for Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk I'm quite happy to try to summarise the security thread - or get someone else to - I'll leave it a few days to see if there are any comments/issues from other people to add. I have a small number of questions for clarifications... On 22/3/04 10:50 am, Haitham Cruickshank wrote: > The material in my previous email (Security Considerations section for > draft-fair-ipdvb-req-04.txt) are taken from two source: > > * draft-ietf-pilc-link-design-15.txt: This document has the consensus of many > people in the IETF,... Exactly what I would hope - the PILC WG wrote this to help collect wisdom on IETF aspects for links supporting IP, it should very soon be a BCP RFC. ---------------- Art Allison wrote: > Second, it seems out of scope to put elements in the RF emissions that > belong in the contribution process. It seems that you are concerned about > attacks on the data flow up to the RF emission. This is a valid and > important concern; but seemingly not relevant to a light weight emission > Protocol. Would such contribution feeds normally use MPEG-2 transmission? To what extent do you envisage these TV contribution feeds to carry IP packet data? ---------------- HC> The vulnerability refers to two separate issues: HC> 1. Satellite and wireless links are more vulnerable to attacks such as HC> eavesdropping and traffic analysis due to the broadcast nature of these HC >links. AA> Anyone can listen, true. So what? If a user wants to avoid traffic AA> analysis they could send data all the time...the valid receiver AA> will toss the filler as presumably the content would be important AA> to protect at a higher level (IP->UDP->application). I'm not sure what it is we are trying to hide by encryption to prevent traffic anaylsis of the IP service - Is it the volume of TS-Packets that are sent by the satellite operator per PID or the ability to measure the traffic per Receiver (i.e. Destination MAC/IP address of an individual ISP customer). Gorry Fairhurst From owner-ip-dvb@erg.abdn.ac.uk Thu Mar 25 16:10:39 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 i2PG6iZE005908 for ; Thu, 25 Mar 2004 16:06:44 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2PG6hTc005905 for ip-dvb-subscribed-users; Thu, 25 Mar 2004 16:06: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 [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 i2PG0sDQ005643 for ; Thu, 25 Mar 2004 16:00:55 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, 25 Mar 2004 11:00:56 -0500 Received: (private information removed) Message-ID: <5A659834E1607E4EBD72FCE2FE5C9CF102FEC0A3@mail.NAB.ORG> From: "Allison, Art" To: "'ip-dvb@erg.abdn.ac.uk'" Subject: RE: Security Considerations section for Date: Thu, 25 Mar 2004 11:00:53 -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-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk Sniped part and replied.. 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: Thursday, March 25, 2004 4:48 AM To: ip-dvb@erg.abdn.ac.uk Subject: Re: Security Considerations section for I'm quite happy to try to summarise the security thread - or get someone else to - I'll leave it a few days to see if there are any comments/issues from other people to add. I have a small number of questions for clarifications... ... Art Allison wrote: > Second, it seems out of scope to put elements in the RF emissions that > belong in the contribution process. It seems that you are concerned about > attacks on the data flow up to the RF emission. This is a valid and > important concern; but seemingly not relevant to a light weight emission > Protocol. Gorry Fairhurst asked: Would such contribution feeds normally use MPEG-2 transmission? AA responds> They generally do although not necessarily in strict compliance with the MPEG-2 transport standard. Often 45Mpbs per RF channel with higher profile and level is used so that the content can survive decoding and recoding. Some are distributing at payload rates. ATM is used by some (with MPEG-2 packet mapping onto the ATM cells). Gorry Fairhurst asked: To what extent do you envisage these TV contribution feeds to carry IP packet data? Art responds> Perhaps lots, perhaps little, but MUCH more importantly the contribution contains very valuable content to the broadcaster, that normally they are contractually bound to protect anyway. It contains the A/V programming and lots of folks would like to rip that off. So, I would specify that everything in the contribution link be protected with encryption and that further I would not want it to be standard as that increases the size of the target for attackers. The two ends of a contribution link have always worked best when they come from the same vendor anyway. There are several approaches to protect an entire link, but protection of this feed is not the job of the particular type of content embedded therein. If you assert that you should put protection on ULE content type, to be logically consistent you would have to assert that each content type have a protection scheme at this layer. If the threat is significant enough, (and for the contribution link I agree it is) protect it ALL. But that protection-for-it-all is out of scope here and is already being used today (I am not aware of any in-the-clear contribution links in the US.) From owner-ip-dvb@erg.abdn.ac.uk Fri Mar 26 12:16:28 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 i2QCEqgu025915 for ; Fri, 26 Mar 2004 12:14:52 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2QCEp0J025912 for ip-dvb-subscribed-users; Fri, 26 Mar 2004 12:14: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 [192.168.1.102] (195-238-52-158.direcpceu.com [195.238.52.158]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i2QCD5bc025809 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 26 Mar 2004 12:13:16 GMT User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Fri, 26 Mar 2004 12:13:11 +0000 Subject: Re: Scenarios for draft-fair-ipdvb-req-04.txt From: Gorry Fairhurst To: Message-ID: In-Reply-To: <40600D20.FDBA2A37@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 X-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk Trying to draw together the security inputs suggests a general need for more precise scenarios that exhibit different properties/requirements, this also will be useful when describing other protocols used to build the IP over MPEG service. Can I ask for inputs to help draw up this list of scenarios? Here is a start (from looking through the mailing list): 1) Art's recent inputs to the security thread seem oriented to TV-style networks ("contribution" and "broadcast"). In the broadcast context, transmission goes to many Receivers (unidirectional star) and IP packets can be integrated with TV/radio transmission channels. The broadcast part of the networks are characterised by a large population of receivers that may receive the same bit stream. 2) Laurent Claverotte's focus was oriented to two-way satellite IP provision - where the MPEG transmission network provides a physical & link technology for a two-way star IP network (DVB-RCS). Organisation is currently usually based around a star toplogy, in which a central hub station acts as the gateway to the wider Internet. Other scenarios include: 3) Point-to-point network links can be used to connect between Internet Service Providers - these typically have no TV content - and use MPEG as just a physical & link technology, many use the same technology (e.g. DVB-S) in both directions. Such networks are characterised by a small number of receivers for each transmitted bit stream. 4) Point-to-multipoint networks where the outbound link uses broadcast technology (possibly shared with TV/radio?) and the return link uses some other technology (e.g. Modem, LMDS, GPRS, ...). Such networks could utilise UDLR protocols for routing [RFC3077]. Are there more important cases, that I have missed? What about cable networks, cellular DVB-T, mobile DVB-T, mesh DVB-RCS? A typical usage could be: End-host<-->IP network<-->IP network | IP gateway<->MPEG-2 network<-> Receiver | End-host<-->IP network Where the middle line represents the "MPEG-2" part of the internet path, in this case the end users are the people using the end-hosts. Gorry Fairhurst. From owner-ip-dvb@erg.abdn.ac.uk Fri Mar 26 14:19: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 i2QEIBSR001031 for ; Fri, 26 Mar 2004 14:18:12 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2QEIBQJ001030 for ip-dvb-subscribed-users; Fri, 26 Mar 2004 14:18: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 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 i2QEHJTO000976 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 26 Mar 2004 14:17:20 GMT Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2QEHJu20469 for ; Fri, 26 Mar 2004 16:17:20 +0200 (EET) X-Scanned: Fri, 26 Mar 2004 16:16:43 +0200 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i2QEGhjF014255 for ; Fri, 26 Mar 2004 16:16:43 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00HMosmY; Fri, 26 Mar 2004 16:16:41 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2QEGes06053 for ; Fri, 26 Mar 2004 16:16:40 +0200 (EET) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 26 Mar 2004 16:16:28 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 26 Mar 2004 16:16:21 +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: Scenarios for draft-fair-ipdvb-req-04.txt Date: Fri, 26 Mar 2004 16:16:22 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Scenarios for draft-fair-ipdvb-req-04.txt Thread-Index: AcQTL20b5C0xc7EWT320o/48G6DYEQADPWBw From: To: X-OriginalArrivalTime: 26 Mar 2004 14:16:21.0769 (UTC) FILETIME=[E9FA7F90:01C4133C] 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 i2QEI85i001023 Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk Hi All As you are bringing together deployment scenarios, there are some fine use cases (aka scenarios) in: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-img-req-03.txt If these are of benefit feel free to reuse. 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: Friday, March 26, 2004 2:13 PM > To: ip-dvb@erg.abdn.ac.uk > Subject: Re: Scenarios for draft-fair-ipdvb-req-04.txt > > > > > Trying to draw together the security inputs suggests a > general need for more > precise scenarios that exhibit different > properties/requirements, this also > will be useful when describing other protocols used to build > the IP over > MPEG service. Can I ask for inputs to help draw up this list > of scenarios? > > > Here is a start (from looking through the mailing list): > > > 1) Art's recent inputs to the security thread seem oriented > to TV-style > networks ("contribution" and "broadcast"). In the broadcast context, > transmission goes to many Receivers (unidirectional star) and > IP packets can > be integrated with TV/radio transmission channels. The > broadcast part of the > networks are characterised by a large population of receivers that may > receive the same bit stream. > > 2) Laurent Claverotte's focus was oriented to two-way > satellite IP provision > - where the MPEG transmission network provides a physical & > link technology > for a two-way star IP network (DVB-RCS). Organisation is > currently usually > based around a star toplogy, in which a central hub station > acts as the > gateway to the wider Internet. > > Other scenarios include: > > 3) Point-to-point network links can be used to connect > between Internet > Service Providers - these typically have no TV content - and > use MPEG as > just a physical & link technology, many use the same > technology (e.g. DVB-S) > in both directions. Such networks are characterised by a > small number of > receivers for each transmitted bit stream. > > 4) Point-to-multipoint networks where the outbound link uses broadcast > technology (possibly shared with TV/radio?) and the return > link uses some > other technology (e.g. Modem, LMDS, GPRS, ...). Such > networks could utilise > UDLR protocols for routing [RFC3077]. > > Are there more important cases, that I have missed? > > What about cable networks, cellular DVB-T, mobile DVB-T, mesh DVB-RCS? > > > A typical usage could be: > > End-host<-->IP network<-->IP network > | > IP gateway<->MPEG-2 network<-> Receiver > | > End-host<-->IP network > > Where the middle line represents the "MPEG-2" part of the > internet path, in > this case the end users are the people using the end-hosts. > > > Gorry Fairhurst. > > > > From owner-ip-dvb@erg.abdn.ac.uk Fri Mar 26 14:59: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 i2QEvJ31002797 for ; Fri, 26 Mar 2004 14:57:19 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2QEvIAi002795 for ip-dvb-subscribed-users; Fri, 26 Mar 2004 14:57: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 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 i2QEskrl002644 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 26 Mar 2004 14:54:48 GMT Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2QEslu01182 for ; Fri, 26 Mar 2004 16:54:47 +0200 (EET) X-Scanned: Fri, 26 Mar 2004 16:54:12 +0200 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i2QEsCwX025206 for ; Fri, 26 Mar 2004 16:54:12 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00iDA4x8; Fri, 26 Mar 2004 16:50:28 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2QEoNF18922 for ; Fri, 26 Mar 2004 16:50:23 +0200 (EET) Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 26 Mar 2004 16:50:22 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 26 Mar 2004 16:50:23 +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: Security Considerations section for Date: Fri, 26 Mar 2004 16:50:23 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Security Considerations section for Thread-Index: AcQSh0jTfnUsTmIoRHacPMdINFlDdQAt/ISA From: To: X-OriginalArrivalTime: 26 Mar 2004 14:50:23.0417 (UTC) FILETIME=[AAE54290:01C41341] 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 i2QEvCL1002787 Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk I think it is a wonderful idea to properly consider IPDVB security requirements. I would just like a sanity check that I still understand the field of what the group would consider. Are these statements about right? * IP-layer/level security (IPsec, MSEC, etc) provides a handful of solutions. Use of these and further specification of IP-layer security is beyond the IPDVB solution scope. * security above IP-layer (DRM, SRTP, etc) are well beyond IPDVB solution scope. * security on MPEG-2 TS (CA, etc) is beyond IPDVB (and IETF) solution scope. * If necessary, ULE security mechanisms would be IPDVB solution scope. Am I roughly on target with these? If so, then the use of the IPDVB Security Requirements is clear to me: 1. assess whether any IPDVB security requirements should be met by the ULE-layer and the IPDVB deliverables that would be needed for this; 2. for other IPDVB security requirements determine whether additional work in other WGs is necessary. BTW, it may also help to describe any security problems MPE deployments currently leave open. (Currently I am ignorant of any in MPE-layer scope). Cheers, Rod. > -----Original Message----- > From: owner-ip-dvb@erg.abdn.ac.uk > [mailto:owner-ip-dvb@erg.abdn.ac.uk]On > Behalf Of ext Allison, Art > Sent: Thursday, March 25, 2004 6:01 PM > To: 'ip-dvb@erg.abdn.ac.uk' > Subject: RE: Security Considerations section for > > > > Sniped part and replied.. > > 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: Thursday, March 25, 2004 4:48 AM > To: ip-dvb@erg.abdn.ac.uk > Subject: Re: Security Considerations section for > > I'm quite happy to try to summarise the security thread - or > get someone > else to - I'll leave it a few days to see if there are any > comments/issues > from other people to add. > > I have a small number of questions for clarifications... > ... > > > Art Allison wrote: > > Second, it seems out of scope to put elements in the RF > emissions that > > belong in the contribution process. It seems that you are > concerned about > > attacks on the data flow up to the RF emission. This is a valid and > > important concern; but seemingly not relevant to a light > weight emission > > Protocol. > > Gorry Fairhurst asked: > Would such contribution feeds normally use MPEG-2 transmission? > AA responds> They generally do although not necessarily in > strict compliance > with the MPEG-2 transport standard. Often 45Mpbs per RF > channel with higher > profile and level is used so that the content can survive decoding and > recoding. Some are distributing at payload rates. ATM is used > by some (with > MPEG-2 packet mapping onto the ATM cells). > > Gorry Fairhurst asked: > To what extent do you envisage these TV contribution feeds to carry IP > packet data? > > Art responds> > Perhaps lots, perhaps little, but MUCH more importantly the > contribution > contains very valuable content to the broadcaster, that > normally they are > contractually bound to protect anyway. It contains the A/V > programming and > lots of folks would like to rip that off. So, I would specify that > everything in the contribution link be protected with > encryption and that > further I would not want it to be standard as that increases > the size of the > target for attackers. The two ends of a contribution link > have always worked > best when they come from the same vendor anyway. There are several > approaches to protect an entire link, but protection of this > feed is not the > job of the particular type of content embedded therein. If > you assert that > you should put protection on ULE content type, to be > logically consistent > you would have to assert that each content type have a > protection scheme at > this layer. > If the threat is significant enough, (and for the > contribution link I agree > it is) protect it ALL. > But that protection-for-it-all is out of scope here and is > already being > used today (I am not aware of any in-the-clear contribution > links in the > US.) > > From owner-ip-dvb@erg.abdn.ac.uk Mon Mar 29 09:36: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 i2T8ZRXO012352 for ; Mon, 29 Mar 2004 09:35:27 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2T8ZQFu012351 for ip-dvb-subscribed-users; Mon, 29 Mar 2004 09:35:26 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley-ipv6.erg.abdn.ac.uk [IPv6:2001:630:241:1:20a:95ff:fe7d:5f0c]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i2T8YFWP012282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 29 Mar 2004 09:34:17 +0100 (BST) Message-ID: <4067DF88.90406@erg.abdn.ac.uk> Date: Mon, 29 Mar 2004 09:34:16 +0100 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Re: Security Considerations section for 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-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk OK here is my take on the coping: Rod.Walsh@nokia.com wrote: >I think it is a wonderful idea to properly consider IPDVB security requirements. I would just like a sanity check that I still understand the field of what the group would consider. Are these statements about right? > >* IP-layer/level security (IPsec, MSEC, etc) provides a handful of solutions. Use of these and further specification of IP-layer security is beyond the IPDVB solution scope. > - These are IP-level solutions, it would be reasonable to advocate their use, both with MPE, ULE and any associated network protocols. I would suggets it *is* reaonable to discuss these in the context of this list - If there is (which I have no indication of) any further development work required to update the specs specifically for DVB/MPEG-2, the actual work would probably be done within a security area working group. >* security above IP-layer (DRM, SRTP, etc) are well beyond IPDVB solution scope. > - Agreed. >* security on MPEG-2 TS (CA, etc) is beyond IPDVB (and IETF) solution scope. > - The set of currently defined mechanisms will not be re-specified or developed within this WG under the Charter specified. It was my understanding that Conditional Access (CA) systems are generally proprietary, and few target IP services. >* If necessary, ULE security mechanisms would be IPDVB solution scope. > > - Yes, the transport of encrypted IP data is within scope. - Security also need to be considered in respect of the control protocols used to provide the IP service.... >Am I roughly on target with these? > > Yes, that's a useful summary. >If so, then the use of the IPDVB Security Requirements is clear to me: 1. assess whether any IPDVB security requirements should be met by the ULE-layer and the IPDVB deliverables that would be needed for this; 2. for other IPDVB security requirements determine whether additional work in other WGs is necessary. > >BTW, it may also help to describe any security problems MPE deployments currently leave open. (Currently I am ignorant of any in MPE-layer scope). > > - Any inputs from the list? >Cheers, Rod. > > > > > >>-----Original Message----- >>From: owner-ip-dvb@erg.abdn.ac.uk >>[mailto:owner-ip-dvb@erg.abdn.ac.uk]On >>Behalf Of ext Allison, Art >>Sent: Thursday, March 25, 2004 6:01 PM >>To: 'ip-dvb@erg.abdn.ac.uk' >>Subject: RE: Security Considerations section for >> >> >> >>Sniped part and replied.. >> >>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: Thursday, March 25, 2004 4:48 AM >>To: ip-dvb@erg.abdn.ac.uk >>Subject: Re: Security Considerations section for >> >>I'm quite happy to try to summarise the security thread - or >>get someone >>else to - I'll leave it a few days to see if there are any >>comments/issues >>from other people to add. >> >>I have a small number of questions for clarifications... >>... >> >> >>Art Allison wrote: >> >> >>>Second, it seems out of scope to put elements in the RF >>> >>> >>emissions that >> >> >>>belong in the contribution process. It seems that you are >>> >>> >>concerned about >> >> >>>attacks on the data flow up to the RF emission. This is a valid and >>>important concern; but seemingly not relevant to a light >>> >>> >>weight emission >> >> >>>Protocol. >>> >>> >>Gorry Fairhurst asked: >>Would such contribution feeds normally use MPEG-2 transmission? >>AA responds> They generally do although not necessarily in >>strict compliance >>with the MPEG-2 transport standard. Often 45Mpbs per RF >>channel with higher >>profile and level is used so that the content can survive decoding and >>recoding. Some are distributing at payload rates. ATM is used >>by some (with >>MPEG-2 packet mapping onto the ATM cells). >> >>Gorry Fairhurst asked: >>To what extent do you envisage these TV contribution feeds to carry IP >>packet data? >> >>Art responds> >>Perhaps lots, perhaps little, but MUCH more importantly the >>contribution >>contains very valuable content to the broadcaster, that >>normally they are >>contractually bound to protect anyway. It contains the A/V >>programming and >>lots of folks would like to rip that off. So, I would specify that >>everything in the contribution link be protected with >>encryption and that >>further I would not want it to be standard as that increases >>the size of the >>target for attackers. The two ends of a contribution link >>have always worked >>best when they come from the same vendor anyway. There are several >>approaches to protect an entire link, but protection of this >>feed is not the >>job of the particular type of content embedded therein. If >>you assert that >>you should put protection on ULE content type, to be >>logically consistent >>you would have to assert that each content type have a >>protection scheme at >>this layer. >>If the threat is significant enough, (and for the >>contribution link I agree >>it is) protect it ALL. >>But that protection-for-it-all is out of scope here and is >>already being >>used today (I am not aware of any in-the-clear contribution >>links in the >>US.) >> >> >> >> > > > > From owner-ip-dvb@erg.abdn.ac.uk Mon Mar 29 15:38:50 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 i2TEapZb028008 for ; Mon, 29 Mar 2004 15:36:51 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2TEaomP028006 for ip-dvb-subscribed-users; Mon, 29 Mar 2004 15:36:51 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from 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 i2TEZKDx027927 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 29 Mar 2004 15:35:20 +0100 (BST) 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 1B7xr5-0004Tx-00 for ip-dvb@erg.abdn.ac.uk; Mon, 29 Mar 2004 15:35:11 +0100 Message-ID: <4068341E.B4F0CED3@surrey.ac.uk> Date: Mon, 29 Mar 2004 15:35:10 +0100 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: Security Considerations section for References: 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 *1B7xr5-0004Tx-00*0s9t7PdP.co* (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 X-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk Hi Gorry, I am answering the last question. Gorry Fairhurst wrote: > I'm quite happy to try to summarise the security thread - or get someone > else to - I'll leave it a few days to see if there are any comments/issues > from other people to add. > > I have a small number of questions for clarifications... > > On 22/3/04 10:50 am, Haitham Cruickshank wrote: > > > > The material in my previous email (Security Considerations section for > > draft-fair-ipdvb-req-04.txt) are taken from two source: > > > > * draft-ietf-pilc-link-design-15.txt: This document has the consensus of many > > people in the IETF,... > > Exactly what I would hope - the PILC WG wrote this to help collect wisdom on > IETF aspects for links supporting IP, it should very soon be a BCP RFC. > > ---------------- > > > Art Allison wrote: > > Second, it seems out of scope to put elements in the RF emissions that > > belong in the contribution process. It seems that you are concerned about > > attacks on the data flow up to the RF emission. This is a valid and > > important concern; but seemingly not relevant to a light weight emission > > Protocol. > > Would such contribution feeds normally use MPEG-2 transmission? > > To what extent do you envisage these TV contribution feeds to carry IP > packet data? > > ---------------- > > > HC> The vulnerability refers to two separate issues: > HC> 1. Satellite and wireless links are more vulnerable to attacks such as > HC> eavesdropping and traffic analysis due to the broadcast nature of these > HC >links. > AA> Anyone can listen, true. So what? If a user wants to avoid traffic > AA> analysis they could send data all the time...the valid receiver > AA> will toss the filler as presumably the content would be important > AA> to protect at a higher level (IP->UDP->application). > > I'm not sure what it is we are trying to hide by encryption to prevent > traffic anaylsis of the IP service - Is it the volume of TS-Packets that are > sent by the satellite operator per PID or the ability to measure the traffic > per Receiver (i.e. Destination MAC/IP address of an individual ISP > customer). Yes. The volume of traffic and timing can give away some information about receiver/sender activities. In extremely important security situations and low activities, the traffic can be padded with random data (before encryption) to keep the traffic volume constant. I hope this answers the question. > > > Gorry Fairhurst -- 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 Mon Mar 29 15:33: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 i2TEUPpw027664 for ; Mon, 29 Mar 2004 15:30:25 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2TEUO4q027663 for ip-dvb-subscribed-users; Mon, 29 Mar 2004 15:30:24 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from 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 i2TEOMAU027325 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 29 Mar 2004 15:24:25 +0100 (BST) 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 1B7xgN-0003nR-00 for ip-dvb@erg.abdn.ac.uk; Mon, 29 Mar 2004 15:24:07 +0100 Message-ID: <40683186.77384BB2@surrey.ac.uk> Date: Mon, 29 Mar 2004 15:24:07 +0100 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: Security Considerations section for References: <4067DF88.90406@erg.abdn.ac.uk> 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 *1B7xgN-0003nR-00*orlohX3qgmc* (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 X-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk Hi Gorry and Rod, Here are some extra comments and I really hope they are helpful: Gorry Fairhurst wrote: > OK here is my take on the coping: > > Rod.Walsh@nokia.com wrote: > > >I think it is a wonderful idea to properly consider IPDVB security requirements. I would just like a sanity check that I still understand the field of what the group would consider. Are these statements about right? > > > >* IP-layer/level security (IPsec, MSEC, etc) provides a handful of solutions. Use of these and further specification of IP-layer security is beyond the IPDVB solution scope. > > > - These are IP-level solutions, it would be reasonable to advocate their > use, both with MPE, ULE and any associated network protocols. I would > suggets it *is* reaonable to discuss these in the context of this list - > If there is (which I have no indication of) any further development work > required to update the specs specifically for DVB/MPEG-2, the actual > work would probably be done within a security area working group. Yes that sound very good statement. > > > >* security above IP-layer (DRM, SRTP, etc) are well beyond IPDVB solution scope. > > > - Agreed. > > >* security on MPEG-2 TS (CA, etc) is beyond IPDVB (and IETF) solution scope. > > > - The set of currently defined mechanisms will not be re-specified or > developed within this WG under the Charter specified. It was my > understanding that Conditional Access (CA) systems are generally > proprietary, and few target IP services. The exact status of Conditional Access in DVB standards is: The DVB specification defines the algorithm to use to scramble a DVB stream: it is called the DVB Common Scrambling Algorithm (DVB-CSA). This algorithm is standardized but is not public. Technical details of the scrambling algorithm are only made available to bona-fide users upon signature of a Non-Disclosure Agreement (NDA) administered by the Custodian (ETSI). In plain english, you have to pay a large amount of money to see the DVB-CSA details. > > > >* If necessary, ULE security mechanisms would be IPDVB solution scope. > > > > > - Yes, the transport of encrypted IP data is within scope. > - Security also need to be considered in respect of the control > protocols used to provide the IP service.... Yes control protocols is a good point. > > > >Am I roughly on target with these? > > > > > Yes, that's a useful summary. > > >If so, then the use of the IPDVB Security Requirements is clear to me: 1. assess whether any IPDVB security requirements should be met by the ULE-layer and the IPDVB deliverables that would be needed for this; 2. for other IPDVB security requirements determine whether additional work in other WGs is necessary. > > > >BTW, it may also help to describe any security problems MPE deployments currently leave open. (Currently I am ignorant of any in MPE-layer scope). > > > > > - Any inputs from the list? Here is some limited input on the security problems with MPE deployments: DVB-CA is mainly implemented in the MPEG-TS layer. The MPE security procedures are defined in the current DVB-RCS standard (ETSI EN 301 790). The MPE security major problem is that security features are optional. Therefore (I think) many people do not implement them. Another problem is that there is not efficient support for secure multicast (secure group communication). > > > >Cheers, Rod. > > > > > > > > > > > >>-----Original Message----- > >>From: owner-ip-dvb@erg.abdn.ac.uk > >>[mailto:owner-ip-dvb@erg.abdn.ac.uk]On > >>Behalf Of ext Allison, Art > >>Sent: Thursday, March 25, 2004 6:01 PM > >>To: 'ip-dvb@erg.abdn.ac.uk' > >>Subject: RE: Security Considerations section for > >> > >> > >> > >>Sniped part and replied.. > >> > >>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: Thursday, March 25, 2004 4:48 AM > >>To: ip-dvb@erg.abdn.ac.uk > >>Subject: Re: Security Considerations section for > >> > >>I'm quite happy to try to summarise the security thread - or > >>get someone > >>else to - I'll leave it a few days to see if there are any > >>comments/issues > >>from other people to add. > >> > >>I have a small number of questions for clarifications... > >>... > >> > >> > >>Art Allison wrote: > >> > >> > >>>Second, it seems out of scope to put elements in the RF > >>> > >>> > >>emissions that > >> > >> > >>>belong in the contribution process. It seems that you are > >>> > >>> > >>concerned about > >> > >> > >>>attacks on the data flow up to the RF emission. This is a valid and > >>>important concern; but seemingly not relevant to a light > >>> > >>> > >>weight emission > >> > >> > >>>Protocol. > >>> > >>> > >>Gorry Fairhurst asked: > >>Would such contribution feeds normally use MPEG-2 transmission? > >>AA responds> They generally do although not necessarily in > >>strict compliance > >>with the MPEG-2 transport standard. Often 45Mpbs per RF > >>channel with higher > >>profile and level is used so that the content can survive decoding and > >>recoding. Some are distributing at payload rates. ATM is used > >>by some (with > >>MPEG-2 packet mapping onto the ATM cells). > >> > >>Gorry Fairhurst asked: > >>To what extent do you envisage these TV contribution feeds to carry IP > >>packet data? > >> > >>Art responds> > >>Perhaps lots, perhaps little, but MUCH more importantly the > >>contribution > >>contains very valuable content to the broadcaster, that > >>normally they are > >>contractually bound to protect anyway. It contains the A/V > >>programming and > >>lots of folks would like to rip that off. So, I would specify that > >>everything in the contribution link be protected with > >>encryption and that > >>further I would not want it to be standard as that increases > >>the size of the > >>target for attackers. The two ends of a contribution link > >>have always worked > >>best when they come from the same vendor anyway. There are several > >>approaches to protect an entire link, but protection of this > >>feed is not the > >>job of the particular type of content embedded therein. If > >>you assert that > >>you should put protection on ULE content type, to be > >>logically consistent > >>you would have to assert that each content type have a > >>protection scheme at > >>this layer. > >>If the threat is significant enough, (and for the > >>contribution link I agree > >>it is) protect it ALL. > >>But that protection-for-it-all is out of scope here and is > >>already being > >>used today (I am not aware of any in-the-clear contribution > >>links in the > >>US.) > >> > >> > >> > >> > > > > > > > > -- 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 Mon Mar 29 16:12: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 i2TFBdsP029671 for ; Mon, 29 Mar 2004 16:11:39 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2TFBdBq029670 for ip-dvb-subscribed-users; Mon, 29 Mar 2004 16:11:39 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from out003.verizon.net (out003pub.verizon.net [206.46.170.103]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i2TFAjAx029628 for ; Mon, 29 Mar 2004 16:10:45 +0100 (BST) Received: from copernicus ([68.163.208.178]) by out003.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040329151045.KCWB6671.out003.verizon.net@copernicus> for ; Mon, 29 Mar 2004 09:10:45 -0600 Message-ID: <075c01c415a0$0564a890$b402a8c0@copernicus> From: "Marie-Jose Montpetit" To: References: <4068341E.B4F0CED3@surrey.ac.uk> Subject: Re: Security Considerations section for Date: Mon, 29 Mar 2004 10:10:44 -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 out003.verizon.net from [68.163.208.178] at Mon, 29 Mar 2004 09:10:40 -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-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk > > Yes. The volume of traffic and timing can give away some information about > receiver/sender activities. In extremely important security situations and low > activities, the traffic can be padded with random data (before encryption) to keep > the traffic volume constant. I hope this answers the question. > Although in any transmission over wireless media padding will just reduce the ability to sell more bandwidth or to increase stat mux on the channel. I think want is needed IMHO is to get a list/table of what is needed in terms of security for the MPEG, what exists with plus and minuses, what is non-adressed right now and the costs or perceived costs to solve remaining problems. That's beyond just the requirement draft though. Marie-Jose From owner-ip-dvb@erg.abdn.ac.uk Wed Mar 31 07:08: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 i2V67Yil004025 for ; Wed, 31 Mar 2004 07:07:34 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i2V67YpO004024 for ip-dvb-subscribed-users; Wed, 31 Mar 2004 07:07:34 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from 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 i2V66q7a003992 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Wed, 31 Mar 2004 07:06:54 +0100 (BST) 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 i2V66nT07284 for ; Wed, 31 Mar 2004 09:06:49 +0300 (EET DST) X-Scanned: Wed, 31 Mar 2004 09:06:21 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i2V66LCG014988 for ; Wed, 31 Mar 2004 09:06:21 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00qiyJ1p; Wed, 31 Mar 2004 09:06:20 EEST 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 i2V66Is10437 for ; Wed, 31 Mar 2004 09:06:19 +0300 (EET DST) Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 31 Mar 2004 09:06:06 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 31 Mar 2004 09:06:06 +0300 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: Security Considerations section for Date: Wed, 31 Mar 2004 09:06:04 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Security Considerations section for Thread-Index: AcQVo5j/xz6ft7BJSPuFiMU7XGqN1wA2ohjA From: To: X-OriginalArrivalTime: 31 Mar 2004 06:06:06.0071 (UTC) FILETIME=[40EBF070:01C416E6] 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 i2V67WOK004021 Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk Hi Thanks for the responses, I think I'm reading from the same page. On one issue... > > >BTW, it may also help to describe any security problems > MPE deployments currently leave open. (Currently I am > ignorant of any in MPE-layer scope). > > > > > > > > - Any inputs from the list? > > Here is some limited input on the security problems with MPE > deployments: > > DVB-CA is mainly implemented in the MPEG-TS layer. The MPE > security procedures are defined in the current DVB-RCS > standard (ETSI EN 301 790). The MPE security major problem is > that security features are optional. Therefore (I think) many > people do not implement them. Another problem is that there > is not efficient > support for secure multicast (secure group communication). ..that problem is in the scope of two-way communications with RCS - right? What kind of TS, MPE, IP (or other) kinds of solutions would be appropriate? (e.g. are there any issues on the efficient support for secure multicast which would not be MSEC/IP-layer level issues?) Cheers, Rod.