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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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" <williams77@rediffmail.com>
To: "Alain RITOUX" <alain.ritoux@6wind.com>
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

<P>=0AHi Alain,<BR>=0A&nbsp; &nbsp;  Good day. please see the comments inli=
ned.<BR>=0A<BR>=0ARegards,<BR>=0AWilliam.<BR>=0A<BR>=0AOn Sun, 29 Feb 2004 =
Alain RITOUX wrote :<BR>=0A&gt;Hi William<BR>=0A&gt;<BR>=0A&gt;Yes, in defi=
nfin the behaviour un ULE base specs, we'll have backward compatibility<BR>=
=0A&gt;for future extension. My point for optional vs madatory extension, w=
as indeed not very<BR>=0A&gt;well explained : some other words should be ch=
osen, because all I had in mind was, to<BR>=0A&gt;define receiver's behavio=
ur when he doesn't know the extension header. So two examples<BR>=0A&gt;(on=
ly exmpales for the sake of extension headers, no opnion implide on the fct=
s).<BR>=0A&gt;<BR>=0A&gt;- encryption&nbsp; : if not known, of course the f=
ollowing payload cannot be decrypted, and<BR>=0A&gt;will be pure garbage. S=
o the best behaviour sugested by sender is drop it, you won't<BR>=0A&gt;und=
erstand what follows.<BR>=0A<BR>=0A&lt;William&gt; you are right, This case=
 is, if present MUST support optional header for any recevier :)<BR>=0A<BR>=
=0A&gt;- FEC : it can help to correct errors. If not known, it canot be use=
d, but th payload<BR>=0A&gt;that follows, still makes sense, so go on.<BR>=
=0A<BR>=0A&lt;William&gt; 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.<BR>=0A=
<BR>=0A&gt;<BR>=0A&gt;So it we change the terms &quot;Optional/Mandatory&qu=
ot; by &quot;Process-Next/Discard&quot; for the<BR>=0A&gt;exte header class=
ification, would it be more clear ?<BR>=0A&gt;<BR>=0A&gt;I agree with you t=
his encrypt (if needed) should be optional. Not everybodys needs<BR>=0A&gt;=
it to, be ULE-compliant. Of course those interested shiould by ULE-Encrypio=
n-compliant.<BR>=0A&gt;<BR>=0A&gt;<BR>=0A&gt;Regards.<BR>=0A&gt;Alain<BR>=
=0A&gt;<BR>=0A&gt;William StanisLaus wrote:<BR>=0A&gt;<BR>=0A&gt;&gt;Hi Ala=
in,<BR>=0A&gt;&gt;&nbsp; &nbsp; 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.<BR>=0A&gt;&gt;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.<BR>=0A&gt;&gt;<B=
R>=0A&gt;&gt;Best Regards,<BR>=0A&gt;&gt;William.<BR>=0A&gt;&gt;<BR>=0A&gt;=
&gt;<BR>=0A&gt;<BR>=0A=0A</P>=0A<br><br>=0A<A target=3D"_blank" HREF=3D"htt=
p://clients.rediff.com/signature/track_sig.asp"><IMG SRC=3D"http://ads.redi=
ff.com/RealMedia/ads/adstream_nx.cgi/www.rediffmail.com/inbox.htm@Bottom" B=
ORDER=3D0 VSPACE=3D0 HSPACE=3D0 HEIGHT=3D74 WIDTH=3D496></a>=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<William> 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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <gorry@erg.abdn.ac.uk>
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" <AAllison@nab.org>
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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <gorry@erg.abdn.ac.uk>
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 <alain.ritoux@6wind.com>
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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <gorry@erg.abdn.ac.uk>
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.
>>    
>>
>
><William> 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.
>>    
>>
>
><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 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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <gorry@erg.abdn.ac.uk>
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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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" <AAllison@nab.org>
To: "'ip-dvb@erg.abdn.ac.uk'" <ip-dvb@erg.abdn.ac.uk>
Cc: Alain RITOUX <alain.ritoux@6wind.com>
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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <alain.ritoux@6wind.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ip-dvb@erg.abdn.ac.uk
Subject: 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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <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: "Allison, Art" <AAllison@nab.org>
Cc: "'ip-dvb@erg.abdn.ac.uk'" <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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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" <AAllison@nab.org>
To: "'ip-dvb@erg.abdn.ac.uk'" <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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <alain.ritoux@6wind.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ip-dvb@erg.abdn.ac.uk
Subject: 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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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" <AAllison@nab.org>
To: "'ip-dvb@erg.abdn.ac.uk'" <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 <new> data, but can process
all Rev0 data.
With a series of bits, a Gen0 device cannot process the <new> 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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <gorry@erg.abdn.ac.uk>
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 <new> data, but can process
>all Rev0 data.
>With a series of bits, a Gen0 device cannot process the <new> 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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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" <AAllison@nab.org>
To: "'ip-dvb@erg.abdn.ac.uk'" <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 <should> 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 <new> data, but can process
>all Rev0 data.
>With a series of bits, a Gen0 device cannot process the <new> 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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; Mon, 1 Mar 2004 16:04:26 -0700
Message-ID: <005601c3ffea$ab0afcc0$79068a81@Clausen>
From: "HDClausen" <clausen@cosy.sbg.ac.at>
To: <ip-dvb@erg.abdn.ac.uk>
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 <should> 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 <new> data, but can
process
> >all Rev0 data.
> >With a series of bits, a Gen0 device cannot process the <new> 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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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: <D0299AFF29E01E478321564030AD69095394A0@trebe003.europe.nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: IPDVB bar-bof in Seoul
Thread-Index: AcQADBDggu8HXlXXTVaklwoMl7r7KgABqO8A
From: <Rod.Walsh@nokia.com>
To: <ip-dvb@erg.abdn.ac.uk>
Cc: <gorry@erg.abdn.ac.uk>, <jo@informatik.uni-bremen.de>, <Fritsche@iabg.de>,
        <margaret@thingmagic.com>, <juha-pekka.luoma@nokia.com>
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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; Tue, 2 Mar 2004 09:13:48 +0100 (MET)
From: "Bernhard Collini-Nocker" <bnocker@cosy.sbg.ac.at>
To: <ip-dvb@erg.abdn.ac.uk>
Subject: RE: ULE encryption Support.
Date: Tue, 2 Mar 2004 09:13:48 +0100
Message-ID: <HOEPKOKAJBEOAIPGLHOCGEFJEOAA.bnocker@cosy.sbg.ac.at>
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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <gorry@erg.abdn.ac.uk>
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: <HOEPKOKAJBEOAIPGLHOCGEFJEOAA.bnocker@cosy.sbg.ac.at>
In-Reply-To: <HOEPKOKAJBEOAIPGLHOCGEFJEOAA.bnocker@cosy.sbg.ac.at>
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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <h.v.r@easynet.be>
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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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" <Gessler@iabg.de>
To: <ip-dvb@erg.abdn.ac.uk>
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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 
    <T681ce89daacbc58c23324@fsnt.future.futsoft.com> for 
    <ip-dvb@erg.abdn.ac.uk>; 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 
    <ip-dvb@erg.abdn.ac.uk>; Wed, 3 Mar 2004 11:29:43 +0530
From: "William StanisLaus" <williams@future.futsoft.com>
To: <ip-dvb@erg.abdn.ac.uk>
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

<snip>
>>
>> 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 <should> 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 <new> data, but can process
>all Rev0 data.
>With a series of bits, a Gen0 device cannot process the <new> 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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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" <AAllison@nab.org>
To: "'ip-dvb@erg.abdn.ac.uk'" <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

<snip>
>>
>> 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 <should> 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 <new> data, but can process
>all Rev0 data.
>With a series of bits, a Gen0 device cannot process the <new> 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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <gorry@erg.abdn.ac.uk>
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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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" <AAllison@nab.org>
To: "'ip-dvb@erg.abdn.ac.uk'" <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 <effectively> 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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; Wed, 10 Mar 2004 11:17:04 -0600
Message-ID: <05f801c406c3$93c04fe0$b402a8c0@copernicus>
From: "Marie-Jose Montpetit" <mariejose.montpetit@verizon.net>
To: <ip-dvb@erg.abdn.ac.uk>
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" <AAllison@nab.org>
To: <ip-dvb@erg.abdn.ac.uk>
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 <effectively> 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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <alain.ritoux@6wind.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ip-dvb@erg.abdn.ac.uk
Subject: 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 <effectively> 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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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" <williams77@rediffmail.com>
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

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

<snip>
>(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.)
<snip>

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 <effectively>
>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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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" <AAllison@nab.org>
To: "'ip-dvb@erg.abdn.ac.uk'" <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<smile>.

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.

<snip>
>(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.)
<snip>

which has caused misunderstanding.. to define the structure for extension
bit 
is set.

Sorry for inconvenience again.

Best Regards,
William.
<snip>

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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; Wed, 10 Mar 2004 13:22:25 -0700
Message-ID: <006201c406e6$940b74c0$79068a81@Clausen>
From: "HDClausen" <clausen@cosy.sbg.ac.at>
To: <ip-dvb@erg.abdn.ac.uk>
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" <AAllison@nab.org>
To: <ip-dvb@erg.abdn.ac.uk>
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<smile>.
>
> 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.
>
> <snip>
> >(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.)
> <snip>
>
> which has caused misunderstanding.. to define the structure for extension
> bit
> is set.
>
> Sorry for inconvenience again.
>
> Best Regards,
> William.
> <snip>
>


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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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" <benoit.oger@thales-bm.com>
To: <ip-dvb@erg.abdn.ac.uk>
Subject: RE: ULE Extension Headers
Date: Thu, 11 Mar 2004 08:41:41 +0100
Message-ID: <NEBBIIDJEALBIGLMBGPFAELECNAA.benoit.oger@thales-bm.com>
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 <effectively> 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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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" <williams77@rediffmail.com>
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

<P>=0AHi everyone,<BR>=0A&nbsp; &nbsp; &nbsp; 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.<BR>=0A<BR>=0ANOTE: here Section is =
SNDU payload.<BR>=0A<BR>=0ABest Regards,<BR>=0AWilliam.=0A</P>=0A<br><br>=
=0A<A target=3D"_blank" HREF=3D"http://clients.rediff.com/signature/track_s=
ig.asp"><IMG SRC=3D"http://ads.rediff.com/RealMedia/ads/adstream_nx.cgi/www=
.rediffmail.com/inbox.htm@Bottom" BORDER=3D0 VSPACE=3D0 HSPACE=3D0 HEIGHT=
=3D74 WIDTH=3D496></a>=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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <gorry@erg.abdn.ac.uk>
To: <ip-dvb@erg.abdn.ac.uk>
Message-ID: <BC764415.45E%gorry@erg.abdn.ac.uk>
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" <alain.ritoux@6wind.com> 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 <effectively> 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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; Thu, 11 Mar 2004 11:37:58 -0600
Message-ID: <089d01c4078f$aa2a6780$b402a8c0@copernicus>
From: "Marie-Jose Montpetit" <mariejose.montpetit@verizon.net>
To: <ip-dvb@erg.abdn.ac.uk>
References: <BC764415.45E%gorry@erg.abdn.ac.uk>
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" <gorry@erg.abdn.ac.uk>
To: <ip-dvb@erg.abdn.ac.uk>
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" <alain.ritoux@6wind.com> 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 <effectively>
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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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" <AAllison@nab.org>
To: "'ip-dvb@erg.abdn.ac.uk'" <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" <alain.ritoux@6wind.com> 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 <effectively> 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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <williams77@mailandnews.com>
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" <alain.ritoux@6wind.com> 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 <effectively> 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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb>; 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 <gorry@erg.abdn.ac.uk>
To: <ip-dvb@erg.abdn.ac.uk>
Message-ID: <BC768DE4.474%gorry@erg.abdn.ac.uk>
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" <AAllison@nab.org> 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" <alain.ritoux@6wind.com> 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 <effectively> 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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <williams77@mailandnews.com>
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.


<snip>
     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
        <no change>

        4.4 End Indicator
        <no change>

        4.5 Type Field
        <no change>, 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
	<no change> will be moved on to 4.6 subsection at appropirate location.


<snip>



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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <alain.ritoux@6wind.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ip-dvb@erg.abdn.ac.uk
Subject: 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
>         <no change>, 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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; Fri, 12 Mar 2004 10:17:08 +0100 (MET)
From: "Bernhard Collini-Nocker" <bnocker@cosy.sbg.ac.at>
To: <ip-dvb@erg.abdn.ac.uk>
Subject: RE: ULE Extension Headers
Date: Fri, 12 Mar 2004 10:17:07 +0100
Message-ID: <HOEPKOKAJBEOAIPGLHOCKEHHEPAA.bnocker@cosy.sbg.ac.at>
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.
>
>
> <snip>
>      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
>         <no change>
>
>         4.4 End Indicator
>         <no change>
>
>         4.5 Type Field
>         <no change>, 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
> 	<no change> will be moved on to 4.6 subsection at
> appropirate location.
>
>
> <snip>
>
>


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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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: <OFE4B753F1.371C670D-ONC1256E55.00389333@netfr.alcatel.fr>
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" <bnocker@cosy.sbg.ac.at>@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 : <ip-dvb@erg.abdn.ac.uk>
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.
>
>
> <snip>
>      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
>         <no change>
>
>         4.4 End Indicator
>         <no change>
>
>         4.5 Type Field
>         <no change>, 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
>     <no change> will be moved on to 4.6 subsection at
> appropirate location.
>
>
> <snip>
>
>






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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <T684c4d4756cbc58c235a8@mail.future.futsoft.com> for 
    <ip-dvb@erg.abdn.ac.uk>; 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 
    <ip-dvb@erg.abdn.ac.uk>; Fri, 12 Mar 2004 16:23:21 +0530
From: "William StanisLaus" <williams@future.futsoft.com>
To: <ip-dvb@erg.abdn.ac.uk>
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
>         <no change>, 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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>
Subject: Re: ULE Extension Headers
References: <c2s1bc$2uf1$1@intranet.6wind.com>
In-Reply-To: <c2s1bc$2uf1$1@intranet.6wind.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



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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>
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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <gorry@erg.abdn.ac.uk>
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
>>         <no change>, 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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <T684cfe7176cbc58c235a8@mail.future.futsoft.com> for 
    <ip-dvb@erg.abdn.ac.uk>; 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 
    <ip-dvb@erg.abdn.ac.uk>; Fri, 12 Mar 2004 19:36:57 +0530
From: "William StanisLaus" <williams@future.futsoft.com>
To: <ip-dvb@erg.abdn.ac.uk>
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.

<snip>
     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
        <no change>

        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
        <no change>

        4.4 End Indicator
        <no change>

        4.5 Type Field
        <no change>, 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
	<no change>

        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.

<snip>









-----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
>         <no change>, 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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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" <AAllison@nab.org>
To: "'ip-dvb@erg.abdn.ac.uk'" <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" <AAllison@nab.org> 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" <alain.ritoux@6wind.com> 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 <effectively> 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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <alain.ritoux@6wind.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ip-dvb@erg.abdn.ac.uk
Subject: 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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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: <OF0E4FAA27.385EF48B-ONC1256E55.004E778C@netfr.alcatel.fr>
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 <ip-dvb@erg.abdn.ac.uk>
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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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: <OF6AA4F3DC.6355F38A-ON85256E55.006AD512@caci.com>
From: Henry Rausch <hrausch@caci.com>
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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <T685a867c91cbc58c23400@mail.future.futsoft.com> for 
    <ip-dvb@erg.abdn.ac.uk>; 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 
    <ip-dvb@erg.abdn.ac.uk>; Mon, 15 Mar 2004 10:43:33 +0530
From: "William StanisLaus" <williams@future.futsoft.com>
To: <ip-dvb@erg.abdn.ac.uk>
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"

<snip>
     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.

        <author note: new ULE type has to be defined to identify the request
        from receiver to transmitter to retransmit the requested Section/SN=
DU>


        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


<snip>




=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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <josep.martrat@barcelona.sema.slb.com>
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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <H.Cruickshank@eim.surrey.ac.uk>
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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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" <AAllison@nab.org>
To: "'ip-dvb@erg.abdn.ac.uk'" <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,
<snip>

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 <just> 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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; Thu, 18 Mar 2004 04:02:55 -0500 (EST)
From: "Vinay S." <vinay@innoviti.com>
To: <ip-dvb@erg.abdn.ac.uk>
Subject: Hepl required regarding the PAT table
Date: Thu, 18 Mar 2004 14:35:19 +0530
Message-ID: <LMELJJICJEIACEJAHPHACEOFCAAA.vinay@innoviti.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 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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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" <regisc@microsoft.com>
To: <ip-dvb@erg.abdn.ac.uk>
Cc: "Regis Crinon" <regisc@microsoft.com>
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

<html>

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:0 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Verdana;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 77.95pt 1.0in 77.95pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Hi Vinay:</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>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
&nbsp;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 &lt;=3D 253. </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>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.</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>The title is:</span></font></p>

<p class=3DMsoPlainText><b><font size=3D2 face=3DVerdana><span =
style=3D'font-size:10.0pt;
font-family:Verdana;font-weight:bold'>Data Broadcasting: Understanding =
the ATSC
Data Broadcast Standard</span></font></b></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText style=3D'margin-right:-47.9pt'><font size=3D2
face=3D"Courier New"><span style=3D'font-size:10.0pt'><a
href=3D"http://www.amazon.com/exec/obidos/tg/detail/-/0071375902/qid=3D10=
79602791/sr=3D1-2/ref=3Dsr_1_2/102-4421880-4066506?v=3Dglance&amp;s=3Dboo=
ks">http://www.amazon.com/exec/obidos/tg/detail/-/0071375902/qid=3D107960=
2791/sr=3D1-2/ref=3Dsr_1_2/102-4421880-4066506?v=3Dglance&amp;s=3Dbooks</=
a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Kind regards,</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Regis.</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Regis J. Crinon, Ph.D.</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Lead Program Manager, Core Media Processing =
Technologies</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Windows Digital Media Division</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Microsoft Corporation</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
  10.0pt'>One Microsoft Way</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Building 50 - Office 3509</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
  10.0pt'>Redmond</span></font> WA 98052-6399</p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
  10.0pt'>USA</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Tel: 425-707-3475</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Fax: 425-936-7329</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>-----Original Message-----<br>
From: owner-ip-dvb@erg.abdn.ac.uk [mailto:owner-ip-dvb@erg.abdn.ac.uk] =
On
Behalf Of Vinay S.<br>
Sent: Thursday, March 18, 2004 1:05 AM<br>
To: ip-dvb@erg.abdn.ac.uk<br>
Subject: Hepl required regarding the PAT table</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>hi</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;I m a newbie to DVB-RCS.While trying to get the Program =
map PIDs,
for the</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>different programs,from the PAT table,</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>a variable N is presented in the standard, saying that so many =
program</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>channels are present.But, I have not found any =
place/hint</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>indicating what this variable n might be? The exact context is =
given</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>below.(marked by the Arrow)</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>program_association_table</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>program_association_section()</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>{</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; table_id 8 =
uimsbf</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; section_syntax_indicator 1 =
bslbf</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; '0' 1 bslbf</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; reserved 2 =
bslbf</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; section_length 12 =
uimsbf</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; transport_stream_id 16 =
uimsbf</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; reserved 2 =
bslbf</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; version_number 5 =
uimsbf</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; current_next_indicator 1 =
bslbf</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; section_number 8 =
uimsbf</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; last_section_number 8 =
uimsbf</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; for (i =3D 0; i &lt; N; =
i++)&nbsp;
--------------------&gt;what is the value of N?</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; program_number
16 uimsbf</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; reserved
3 bslbf</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; if
(program_number =3D =3D '0')</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; {</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; network_PID
13 uimsbf</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; }</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; else</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; {</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; program_map_PID
13 uimsbf</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; }</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>CRC_32 32 rpchof</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>}</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>with warm regards,</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Vinay.S</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font></p>

</div>

</body>

</html>
=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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; Thu, 18 Mar 2004 11:02:34 +0100 (MET)
From: "Bernhard Collini-Nocker" <bnocker@cosy.sbg.ac.at>
To: <ip-dvb@erg.abdn.ac.uk>
Subject: RE: Hepl required regarding the PAT table
Date: Thu, 18 Mar 2004 11:02:33 +0100
Message-ID: <HOEPKOKAJBEOAIPGLHOCMECCFAAA.bnocker@cosy.sbg.ac.at>
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: <LMELJJICJEIACEJAHPHACEOFCAAA.vinay@innoviti.com>
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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; Thu, 18 Mar 2004 09:15:45 -0500 (EST)
From: "Vinay S." <vinay@innoviti.com>
To: "Ip-Dvb" <ip-dvb@erg.abdn.ac.uk>
Subject: PMT table
Date: Thu, 18 Mar 2004 19:48:11 +0530
Message-ID: <LMELJJICJEIACEJAHPHAKEOGCAAA.vinay@innoviti.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 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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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" <AAllison@nab.org>
To: "'ip-dvb@erg.abdn.ac.uk'" <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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <H.Cruickshank@eim.surrey.ac.uk>
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,
> <snip>
>
> 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 <just> 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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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" <AAllison@nab.org>
To: "'ip-dvb@erg.abdn.ac.uk'" <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. <the
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,
> <snip>
>
> 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 <this Rec IP packets> 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 <just> 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 <even for the contribution attacks
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/


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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <H.Cruickshank@eim.surrey.ac.uk>
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. <the
> 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,
> > <snip>
> >
> > 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 <this Rec IP packets> 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 <just> 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 <even for the contribution attacks
> 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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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: <OFA9BC0833.2A1EFAF9-ONC1256E60.003ACED5@netfr.alcatel.fr>
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" <AAllison@nab.org>@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'" <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. <the
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,
> <snip>
>
> 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 <this Rec IP packets> 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 <just> 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 <even for the contribution
attacks
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/












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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <gorry@erg.abdn.ac.uk>
To: <ip-dvb@erg.abdn.ac.uk>
Message-ID: <BC885B32.529%gorry@erg.abdn.ac.uk>
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:
<snip>

> 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.

----------------
<snip>

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?

----------------
<snip>

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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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" <AAllison@nab.org>
To: "'ip-dvb@erg.abdn.ac.uk'" <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...
...
<snip>

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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <gorry@erg.abdn.ac.uk>
To: <ip-dvb@erg.abdn.ac.uk>
Message-ID: <BC89CED7.578%gorry@erg.abdn.ac.uk>
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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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: <D0299AFF29E01E478321564030AD6909539503@trebe003.europe.nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Scenarios for  draft-fair-ipdvb-req-04.txt
Thread-Index: AcQTL20b5C0xc7EWT320o/48G6DYEQADPWBw
From: <Rod.Walsh@nokia.com>
To: <ip-dvb@erg.abdn.ac.uk>
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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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: <D0299AFF29E01E478321564030AD6909539504@trebe003.europe.nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Security Considerations section for
Thread-Index: AcQSh0jTfnUsTmIoRHacPMdINFlDdQAt/ISA
From: <Rod.Walsh@nokia.com>
To: <ip-dvb@erg.abdn.ac.uk>
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...
> ...
> <snip>
> 
> 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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <gorry@erg.abdn.ac.uk>
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: <D0299AFF29E01E478321564030AD6909539504@trebe003.europe.nokia.com>
In-Reply-To: <D0299AFF29E01E478321564030AD6909539504@trebe003.europe.nokia.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

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...
>>...
>><snip>
>>
>>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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <H.Cruickshank@eim.surrey.ac.uk>
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: <BC885B32.529%gorry@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 *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:
> <snip>
>
> > 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.
>
> ----------------
> <snip>
>
> 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?
>
> ----------------
> <snip>
>
> 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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <H.Cruickshank@eim.surrey.ac.uk>
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: <D0299AFF29E01E478321564030AD6909539504@trebe003.europe.nokia.com> <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...
> >>...
> >><snip>
> >>
> >>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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; Mon, 29 Mar 2004 09:10:45 -0600
Message-ID: <075c01c415a0$0564a890$b402a8c0@copernicus>
From: "Marie-Jose Montpetit" <mariejose.montpetit@verizon.net>
To: <ip-dvb@erg.abdn.ac.uk>
References: <BC885B32.529%gorry@erg.abdn.ac.uk> <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 <ip-dvb-subscribed-users@mavis.erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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 <ip-dvb@erg.abdn.ac.uk>; 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: <D0299AFF29E01E478321564030AD69097E1FDC@trebe003.europe.nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Security Considerations section for
Thread-Index: AcQVo5j/xz6ft7BJSPuFiMU7XGqN1wA2ohjA
From: <Rod.Walsh@nokia.com>
To: <ip-dvb@erg.abdn.ac.uk>
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.