RE: Clarifications with RFC 3077

Hi Emmanuel,

     Few More Clarifications with UDLR implementation... I just came accross 
an interesting thing and like to share the idea with you... Might be it is not 
worth, But can you explain why we are not doing this way.


-----------------------------------------------

	Creation of the logical/virtual interface for UDLR, such a way that all the 
bi-directional interfaces are mapped to this logical interface. Hence the 
change in the bi-directional interfaces is within the FEED or RECEIVER, 
doesn't have any impact on one another.

For example:
-----------

FEED has Four Bi-directional IPs, say FB1, FB2, FB3 and FB4, which is 
taged/mapped to one logical interface "FL1". Ofcourse, route is added for this 
logical interface for every Bi-Directional Interface of Feed.
FEED announces this logical interface "FL1" in the DTCP Message.
So that the Tunnel end-point of the RECEIVER is the FEED logicial interface 
"FL1".


RECEIVER also has such logical interface "RL1" exactly as we have for FEED.
So that the GRE encapsulated packet will have the tunnel start point as 
RECEIVER logicial interface "RL1" and the tunnel end point as FEED logicial 
interface "FL1".


Advantages:
---------
1) DTCP Message packet is reduced by just announcing one 
bidirectional(Logical) IP address. So  number of Feed bidirectional ip etc can 
be removed from the DTCP announcement packet.
2) It is not required to update always the tunnel end point for the receiver, 
since mostly we are mapping to Logicial IP and it is static for the Particular 
FEED. Unless there is a change required.
3) Since we are using logicial interface, even when one of the FEED physical 
bi-directional interface is down, there is no update in the DTCP message. The 
FEED bidirectional logical link will be down only when all the FEED physical 
bi-directional interfaces are down.

Disadvantages:
-------------
1) Maintainance of the Logical IP and mapping it with all available Physical 
bi-directional interface.
2) Route addition for logicial ip.
--But all these is a one time work when the udlr link comes up. And requires 
changes if there is a change in the Physical Bi-directional interfaces

Please Clarify tunnel implementation for UDLR in this approach.

Thanks and Best Regards,
William.

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On Behalf Of
> Emmanuel Duros
> Sent: Monday, 4 November 2002 11:53 PM
> To: William StanisLaus
> Cc: [email protected]; Gorry Fairhurst
> Subject: RE: Clarifications with RFC 3077
>
>
> William,
>
> On Fri, 2002-11-01 at 13:28, William StanisLaus wrote:
> > Hi Emmanuel,
> >
> > Thanks for your clarification.
> > >For scenario 2, it is more of an implementation issue and
> there are many
> > >question marks: Does the IP layer see both physical interfaces as a
> > >unique logical interface ? Is your receiver a router or a
> bridge ?...
> >
> > Yeah the IP Layer see both physical interfaces as one unique logial
> > interface in our RCS System. Our receiver is a router.
> >
> > I have few more doubts Regarding Feeder unidirectional MAC Address
> >
> > In our RCS System we don't get Feeder MAC address in the
> MPEG-2 packets, it
> > contains only the Destination MAC address. So how do we get
> the Feeder MAC
> > address, is there any generic procedure for UDLR??
>
> More precisely, it is the MPE header that does not contain the source
> MAC address (!). Note that, in general, the MAC source
> address contained
> in a layer 2 frame header is not use by layer 2 protocols... Only the
> destination address is used for filtering purposes.
>
> To obtain the feed MAC address, you can use an address resolution
> protocol over UDLR. There is a draft that just got submitted with a
> section on this subject. You may check it here:
> http://www.ietf.org/internet-drafts/draft-ietf-udlr-experiments-00.txt
>
> If you have interests in IP over DVB (e.g. source MAC address issues),
> you may have a look at http://www.erg.abdn.ac.uk/ip-dvb/archive/
>
>
> > Section 7.3
> > "   The FUMAC value for an active feed is needed for the
> operation of
> >    this protocol.  However, the method of discovery of this
> value is not
> >    specified here.
> >
> > "
> >
> > Thanks in advance.
> >
> > Regards,
> > William.
> >
> >
> Regards,
> Emmanuel
>
> --
> Emmanuel Duros                  http://www.udcast.com
> 2455 Route des Dolines BP355  | Tel : +33 (0)4 93 00 16 60
> 06906 Sophia Antipolis France | Fax : +33 (0)4 93 00 16 61
>             ** Full IP over Broadcast Media **
>
> _______________________________________________
> UDLR mailing list
> [email protected]
> http://www.udcast.com/mailman/listinfo/udlr
>