Re: Comments on ULE extension header....

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

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?

> In Optional headers, Wish to add Source mac address... In case of
> UDLR(RFC3077), during DTCP announcement, ULE can take the source mac i.e.
> FUMAC makes simple in address resolution. -UDLR is jst an example.
> otherthings are security filters can be implemented based on source MAC.
> 

Yes - this is true.

We had a discussion on this topic at the Vienna BoF, and at that time I
don't recall a need for a MAC source without a MAC destination address. If
that is still the case, then maybe the bridging format extension would
satisfy this requirement?

Thoughts?

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

Gorry Fairhurst
>