RE: Clarifications with RFC 3077

William,

On Wed, 2002-11-20 at 06:13, William StanisLaus wrote:
> 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".

I do not see any problem for implementing this with UDLR. It is mainly
an implementation issue and seems inline with RFC3077. Your feed will
announce an IP address through which it can be reached... 

> 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.

Right.

> 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.

Right.

> 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.

Right.

> Disadvantages:
> -------------
> 1) Maintainance of the Logical IP and mapping it with all available Physical 
> bi-directional interface.

Right.

> 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

3) The logical IP address given to a receiver must be tolerate by the
local ISP which would see gre packets whose source IP address is unkown.
In other word, the ISP that owns the forward link must have some sort of
agreement with the ISP which provides the IP address of the return link.
But in your case, the owner of the forward link and the return link is
probably the same ISP ?

> 
> Please Clarify tunnel implementation for UDLR in this approach.

I do not see any pb, except for the logical IP for the receiver, for
implementing this.

> Thanks and Best Regards,
> William.

Regards,
Emmanuel

> 
> > -----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
> > 
-- 
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 **