RE: Clarifications with RFC 3077

William,

On Wed, 2002-10-30 at 08:29, William StanisLaus wrote:
> Hi Emmanuel Duros,
>       Good Day. Thanks for your Clarifications.
> 
> Regarding Q 2)
> 
> Yep, Our Return Link is unidirectional, and TX and RX are 2 different 
> interfaces.
> 
> My Clarification now might be silly, but just to doubt check my understanding 
> :)
> 
> RCS System with both TX and RX port.
> 
> Scenario 1: RCS Sytem sends/response to Feeder (Send Only). The packet is 
> Encapsulated and based on the Routing table it chooses Tx Port(Return Link) or 
> RCS System bi-directional interface targeting Feeder bidirectional interface.
> 	In Case if Tx Port is selected, there should be a Gateway which receives the 
> Encapsulated packet from RCS System and forwards to the feeder bidirectional 
> interface, just IP Forward.
>
> Scenaio 2: RCS System sends/response to Feeder( Receive capable feeder). The 
> packet is not Encapsulated, just sends via the TX port(Return Link) to the 
> Feeder.
> 
> so Encapsulation Decisions are taken based on the DTCP table, "feeder type 
> information" in the RCS System..
> 
> Note: All the Scenarios are not IP forwarding
> 

My understanding is that the receiver has 2 physical interfaces: a
receive-only interface and a distinct interface used for the return link
(RCS, RTC, or whatever !). The decision for routing IP traffic is taken
at IP layer using routing tables and is *not* related to the type of
feed contained in the DTCP announcement.

Any IP packet sent through the receive-only interface is encapsulated in
GRE packet and sent to the feed via the return link. The feed (send-only
or receive-capable) that support UDLR will decapsulate the incoming GRE
packet (from whatever interface) and processes the payload as coming
from the "satellite" interface.

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

> Thanks and Best Regards,
> William StanisLaus.

Emmanuel

> 
> >===== Original Message From Emmanuel Duros <[email protected]> =====
> >Hello William,
> >
> >On Tue, 2002-10-29 at 12:01, William StanisLaus wrote:
> >> Hi all,
> >>
> >>     I am a newbee to UDLR technology. I have few clarifications with RFC 
> 3077.
> >>
> >> Can you help me in understanding the concept.
> >> here we go.....
> >>
> >> 1)
> >>
> >> In Section 7
> >> "The number of feeds is expected to be relatively small (Section 3),
> >> so at every feed the list of all feeds is configured manually."
> >>
> >> In Section 7.1
> >> When Feed multicasts the DTCP Hello Message, it passes the Feed Type
> >>
> >> i.e.
> >>    F (1 bit): bit indicating the type of feed:
> >>       0 = Send-only feed
> >>       1 = Receive-capable feed
> >>
> >>
> >> So the Reciever can maintain the Feed type in the DTCP routing table.
> >> In Such cases,
> >> for Scenario 2: "A receiver can send a broadcast/multicast packet on the
> >> link to all nodes (point-to-multipoint)"
> >>
> >> Section 6.2.2 (3)
> >> As of now, Receiver sends packets to be broadcasted/multicasted to the 
> default
> >> feed and the default feed broadcast/multicast the packet to the other Feed 
> &
> >> Receivers.
> >>
> >>
> >> Clarification :-
> >>
> >> When the Receiver maintains the Feed types, which is dynamic at any moment,
> >> why Receiver is not multicasting to all the Feeds which are Send only?
> >
> >The main reason I see is that it would be costly in term of bandwidth
> >for the receiving site. A copy of every multicast packet would have to
> >be tunneled from the receiver to each Send-only feed. It can get really
> >bad for the receiver if it has a low speed return link such as GSM or
> >RTC.
> >
> >It is easier for the operator to set up high speed links between the
> >feeds and let them make the duplication of packets...
> >
> >> It can also have a default Feed which forwards the packet to all receivers 
> and
> >> receive capable Feeds.
> >>
> >>
> >> The clarification is because, we have the overhead of encapulation at the
> >> receiver side and sending to the default feed which decapulate and again
> >> encapulate to send to Send only Feeds. Also in the Feeds the list of
> >> other feeds are manually configured i.e. Static. Might be broken at any 
> time.
> >>
> >>
> >> 2)
> >>
> >> In the RFC 3077 which explaines about the Feeds , i.e. Send only and 
> Recieve
> >> capable Feeds. But for receivers it is always targeted as Receive only. 
> Just
> >> imagine a RCST with send capable receivers i.e. which has both Tx and Rx 
> port.
> >>
> >> What are the configurations in the UDLR if the receiver happens to be send
> >> capable.
> >>
> >
> >The receiver you are describing is pretty much similar to a receiver
> >whose return link is unidirectional. Am I right ? It seems the TX and RX
> >are 2 differents interfaces...
> >
> >This situation can be handled by UDLR although RFC 3077 says the
> >receiver needs a bidirectional interface to send GRE to the feed. In
> >fact, as long as the return link can carry IP datagrams from the
> >receiver to the feed, the UDLR protocol will work. We've been using some
> >DVB-RCS systems with UDLR and it works pretty well.
> >
> >
> >>
> >>
> >> Thanks and Best Regards,
> >> William StanisLaus.
> >>
> >> _______________________________________________
> >> UDLR mailing list
> >> [email protected]
> >> http://www.udcast.com/mailman/listinfo/udlr
> >
> >Regards,
> >>
> >--
> >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 **