[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ULE encryption Support.

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.