RE: Comments on ULE extension header....

["William StanisLaus" <williams@calsoft.co.in>]

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.



> > 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> In case of UDLR, it is not a packet forwarding, the orginator
of the packet is the FEED itself i.e. satellite terminal. My understand
with bridged format packets is sending the ethernet packets along with
L2 information in satellite network, i.e. L2 tunneling. In that you
still have outer ULE and MPEG headers.
Please correct if I'm wrong.

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