RE: Clarifications with RFC 3077

Hi Emmanuel,
     Yeah me too, agree with Virtual/Logical interface for Receiver, The main 
aim to provide virtual/logical interface to FEED is just to bring down the 
changes in DTCP packet and make more flexible in choosing the prefered 
bidirectional ip for FEED.

The "FL1" will always be Receive only interface for FEED and no packet will be 
routed or send via "FL1"

With Respect to Receiver, We don't really require such a logical interface, 
since we are not actually establishing a secure Tunnel or something similar to 
that. All we do is just send the encapsulated packet to the FEED ("FL1") based 
on our route table through which(physical interface) we can reach "FL1".

When we are talking about GRE, I still don't know the value for GRE Protocol 
Type for DSM-CC, Can anyone help me with DSM-CC value for GRE Protocol Type 
IE.

Thanks and Best Regards,
William.


>===== Original Message From Emmanuel Duros <[email protected]> =====
>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 **