RE: Comments on ULE extension header....

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

Let me make it clear,

CASE 1:
-------
Satellite terminal has two interface Ethernet and DVB. The packet
received from Ethernet has to be forwarded in DVB interface, in that
case we choose to do in bridged format.. So just take the L2 information
from Ethernet packet and encapsulate with ULE and MPEG2-TS, without
modifying anything and forward the packet in satellite network. i.e. L2
Tunneling

NOTE: In this, L2 is IEEE 802.3 Encapsulation, might contain LLC and
SNAP as well.

CASE 2a:
-------
Satellite terminal has two interface Ethernet and DVB. The packet
received from Ethernet has to be forwarded in DVB interface, but bridged
format in ULE, the terminal strips out L2 information from Ethernet and
adds new L2 information i.e. SOURCE MAC as terminal which forwards the
packet, DEST MAC as the terminal to which the packet has to be forward (
immediate next hop ) and protocol type 

CASE 2b:
-------
Satellite terminal orginating a packet i.e. in this case it is not a
forwarder but a host. Example UDLR, DTCP announcement (HELLO packet).
If we wish to bridge the packet, exactly like CASE 2a we have to bridge
the packet.

Question:
--------
In both CASE 2a and 2b, we have protocol type, in Bridged information
and ULE Protocol Type, so something can be saved and some processing
overhead can be improved if we have a plain SOURCE MAC in direct ULE
optional header.

Thoughts??

-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 8:12 PM
> To: ipdvb@erg.abdn.ac.uk
> Cc: 'Bernhard Collini-Nocker'
> Subject: Re: Comments on ULE extension header....
> 
> 
> On Ethernet bridging...
> 
> 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:
> 
> <snip>
> 
> > 
> > 
> >>> 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.
> > 
> 
> So I'd guess if you wanted a source MAC address, an example is:
> 
> <base ULE header, (D=1)> <Bridging header><payload><crc-32>
> 
> I.e.:
> 
> 
> <Len,Type=bridging, (D=1)> 
> <MAC-dst;MAC-src;Ether-Type><payload><crc-32>
> 
> >> 
> >>> -William
> >>> 
> >>> 
> >>> 
> --------------------------------------------------------------------
> >>> mail2web - Check your email from the web at
> >>> http://mail2web.com/ .
> >>> 
> >> 
> >> Gorry Fairhurst
> >>> 
> >> 
> > 
>