Re: Comments on ULE extension header....

[Gorry Fairhurst <gorry@erg.abdn.ac.uk>]

More on version identification...

On 8/6/04 12:59 pm, "William StanisLaus" <williams@calsoft.co.in> wrote:

> Please see the comments inlined...
> 
> -William.
> 
>> -----Original Message-----
>> From: owner-ipdvb@erg.abdn.ac.uk
>> [mailto:owner-ipdvb@erg.abdn.ac.uk] On Behalf Of Gorry Fairhurst
>> Sent: Tuesday, June 08, 2004 3:20 PM
>> To: ipdvb@erg.abdn.ac.uk
>> Cc: Bernhard Collini-Nocker
>> Subject: Re: Comments on ULE extension header....
>> 
>> 
>> On 7/6/04 7:30 pm, "williams@calsoft.co.in"
>> <williams@calsoft.co.in> wrote:
>> 
>>> Thanks to Gorry for publishing the draft :)
>> 
>> This was a work of many discussions among many people...
>> 
>> 
>>> Few Comments
>>> Editorial :
>>> ---------
>>> In Section 2, Figure 1,2 and 3 D_bit is maked as ZERO. It
>> should be ONE
>>> Figure 3, T2 and H2 are interchanged.
>>> 
>>> Concept:
>>> ---------
>>> When we are talking about backward compatibility, it is
>> better to have
>>> version number in the ULE, so across the version it is
>> identified uniquely.
>> 
>> Yes - and this *could* have been in the ULE base header, but there are
>> significant disadvantages too - additional capacity would consumed.
>> 
>> My suggestion is to use one encapsulation method per PID
>> (MPEG-2 TS logical
>> channel) - if we do this other signaling protocols can associate a
>> particular PID with a particular encapsulation method.  The
>> descriptors
>> passed by the signaling protocol could also differentiate MPE
>> from ULE.
>> If we need a new format for ULE sometime in the future, we
>> could use this
>> method to identify this.
>> 
>> Are you suggestion a new OPTIONAL extension to give the
>> version of the ULE
>> protocol? - How do you see the additional benefits of this?
>> 
> 
> 
> William> I suggest to have it as a Mandatory header, Since different
> version of implementation of ULE can be differenciated with a version
> number. 
> Say for example, in ULE version 1 I have 4 Mandatory headers. And we
> decide to add 2 more Mandatory headers and come up with a new version of
> ULE. In that case, since we have added new mandatory header the older
> implementation will jst drop the packet/SNDU. BUT if you have an version
> number, we can make it backward compatibily based on version number and
> still process the packet/SNDU by avoiding those header processing and
> dropping the packets.
> 
 <snip>

This is the first time we've discussed the published XULE draft, but if I
understand correctly, the MANDATORY EXTENSION is one that MUST be processed
before a PDU is forwarded. It does NOT imply it MUST be implemented.

In the future, more MANDATORY EXTENSION headers could be added - if there
was a case for this - by simply allocating entries in the IANA registry
after publishing an RFC that defines the new extension header syntax.  Older
systems simply can not process these headers and discard the PDU when they
find an unrecognised MANDATORY type (and ignore any following parts of this
SNDU).

In contrast, unrecognised OPTIONAL extensions can be ignored, and don't
require the encapsulated PDU to be discarded.

Given these features, it seems that new extensions could be introduced if
new optimisations/requirements emerge.

> 
>> 
>>> -William
>>> 
>>> 
>>> --------------------------------------------------------------------
>>> mail2web - Check your email from the web at
>>> http://mail2web.com/ .
>>> 
>> 
>> Gorry Fairhurst
>>> 
>> 
> 

Gorry Fairhurst