Subject: Re: Re: ULE encryption Support.

From: "William StanisLaus" <[email-masked]>
Date: 1 Mar 2004 05:34:20 -0000

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: Gorry Fairhurst <[email-masked]>
Date: Mon, 01 Mar 2004 13:26:10 +0000

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: Gorry Fairhurst <[email-masked]>
Date: Mon, 01 Mar 2004 13:41:36 +0000

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