RE: Clarifications with RFC 3077
"William StanisLaus" <[email protected]> Fri, 1 Nov 2002 17:58:20 +0530
| Newsgroups | gmane.ietf.udlr,gmane.spam.detected |
|---|---|
| Message-ID | <3DC27364.000001.03964@williams> |
--------------Boundary-00=_8BDWQL80000000000000 Content-Type: Multipart/Alternative; boundary="------------Boundary-00=_9BDWLVC0000000000000" --------------Boundary-00=_9BDWLVC0000000000000 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Emmanuel,=0D =0D Thanks for your clarification.=0D >For scenario 2, it is more of an implementation issue and there are many= =0D >question marks: Does the IP layer see both physical interfaces as a=0D >unique logical interface ? Is your receiver a router or a bridge ?...=0D =0D Yeah the IP Layer see both physical interfaces as one unique logial interface in our RCS System. Our receiver is a router.=0D =0D I have few more doubts Regarding Feeder unidirectional MAC Address=0D =0D 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 MA= C address, is there any generic procedure for UDLR??=0D =0D Section 7.3=0D " The FUMAC value for an active feed is needed for the operation of=0D this protocol. However, the method of discovery of this value is not=0D specified here.=0D =0D "=0D =0D Thanks in advance.=0D =0D Regards,=0D William.=0D =0D =0D -------Original Message-------=0D =0D From: Emmanuel Duros=0D Date: Wednesday, October 30, 2002 10:25:15 PM=0D To: William StanisLaus=0D Cc: udlr=0D Subject: RE: Clarifications with RFC 3077=0D =0D William,=0D =0D On Wed, 2002-10-30 at 08:29, William StanisLaus wrote:=0D > Hi Emmanuel Duros,=0D > Good Day. Thanks for your Clarifications.=0D > =0D > Regarding Q 2)=0D > =0D > Yep, Our Return Link is unidirectional, and TX and RX are 2 different =0D > interfaces.=0D > =0D > My Clarification now might be silly, but just to doubt check my understanding =0D > :)=0D > =0D > RCS System with both TX and RX port.=0D > =0D > Scenario 1: RCS Sytem sends/response to Feeder (Send Only). The packet = is =0D > Encapsulated and based on the Routing table it chooses Tx Port(Return Link) or =0D > RCS System bi-directional interface targeting Feeder bidirectional interface.=0D > In Case if Tx Port is selected, there should be a Gateway which receive= s the =0D > Encapsulated packet from RCS System and forwards to the feeder bidirectional =0D > interface, just IP Forward.=0D >=0D > Scenaio 2: RCS System sends/response to Feeder( Receive capable feeder)= =2E The =0D > packet is not Encapsulated, just sends via the TX port(Return Link) to = the =0D > Feeder.=0D > =0D > so Encapsulation Decisions are taken based on the DTCP table, "feeder t= ype =0D > information" in the RCS System..=0D > =0D > Note: All the Scenarios are not IP forwarding=0D > =0D =0D My understanding is that the receiver has 2 physical interfaces: a=0D receive-only interface and a distinct interface used for the return link=0D (RCS, RTC, or whatever !). The decision for routing IP traffic is taken=0D at IP layer using routing tables and is *not* related to the type of=0D feed contained in the DTCP announcement.=0D =0D Any IP packet sent through the receive-only interface is encapsulated in=0D GRE packet and sent to the feed via the return link. The feed (send-only=0D or receive-capable) that support UDLR will decapsulate the incoming GRE=0D packet (from whatever interface) and processes the payload as coming=0D from the "satellite" interface.=0D =0D For scenario 2, it is more of an implementation issue and there are many=0D question marks: Does the IP layer see both physical interfaces as a=0D unique logical interface ? Is your receiver a router or a bridge ?...=0D =0D > Thanks and Best Regards,=0D > William StanisLaus.=0D =0D Emmanuel=0D =0D > =0D > >=3D=3D=3D=3D=3D Original Message From Emmanuel Duros <emmanuel.duros@u= dcast.com> =3D=3D=3D=3D=3D=0D > >Hello William,=0D > >=0D > >On Tue, 2002-10-29 at 12:01, William StanisLaus wrote:=0D > >> Hi all,=0D > >>=0D > >> I am a newbee to UDLR technology. I have few clarifications with RFC= =0D > 3077.=0D > >>=0D > >> Can you help me in understanding the concept.=0D > >> here we go.....=0D > >>=0D > >> 1)=0D > >>=0D > >> In Section 7=0D > >> "The number of feeds is expected to be relatively small (Section 3),= =0D > >> so at every feed the list of all feeds is configured manually."=0D > >>=0D > >> In Section 7.1=0D > >> When Feed multicasts the DTCP Hello Message, it passes the Feed Type= =0D > >>=0D > >> i.e.=0D > >> F (1 bit): bit indicating the type of feed:=0D > >> 0 =3D Send-only feed=0D > >> 1 =3D Receive-capable feed=0D > >>=0D > >>=0D > >> So the Reciever can maintain the Feed type in the DTCP routing table= =2E=0D > >> In Such cases,=0D > >> for Scenario 2: "A receiver can send a broadcast/multicast packet on the=0D > >> link to all nodes (point-to-multipoint)"=0D > >>=0D > >> Section 6.2.2 (3)=0D > >> As of now, Receiver sends packets to be broadcasted/multicasted to t= he =0D > default=0D > >> feed and the default feed broadcast/multicast the packet to the othe= r Feed =0D > &=0D > >> Receivers.=0D > >>=0D > >>=0D > >> Clarification :-=0D > >>=0D > >> When the Receiver maintains the Feed types, which is dynamic at any moment,=0D > >> why Receiver is not multicasting to all the Feeds which are Send onl= y?=0D > >=0D > >The main reason I see is that it would be costly in term of bandwidth=0D > >for the receiving site. A copy of every multicast packet would have to= =0D > >be tunneled from the receiver to each Send-only feed. It can get reall= y=0D > >bad for the receiver if it has a low speed return link such as GSM or=0D > >RTC.=0D > >=0D > >It is easier for the operator to set up high speed links between the=0D > >feeds and let them make the duplication of packets...=0D > >=0D > >> It can also have a default Feed which forwards the packet to all receivers =0D > and=0D > >> receive capable Feeds.=0D > >>=0D > >>=0D > >> The clarification is because, we have the overhead of encapulation a= t the=0D > >> receiver side and sending to the default feed which decapulate and again=0D > >> encapulate to send to Send only Feeds. Also in the Feeds the list of= =0D > >> other feeds are manually configured i.e. Static. Might be broken at = any =0D > time.=0D > >>=0D > >>=0D > >> 2)=0D > >>=0D > >> In the RFC 3077 which explaines about the Feeds , i.e. Send only and= =0D > Recieve=0D > >> capable Feeds. But for receivers it is always targeted as Receive on= ly. =0D > Just=0D > >> imagine a RCST with send capable receivers i.e. which has both Tx an= d Rx =0D > port.=0D > >>=0D > >> What are the configurations in the UDLR if the receiver happens to b= e send=0D > >> capable.=0D > >>=0D > >=0D > >The receiver you are describing is pretty much similar to a receiver=0D > >whose return link is unidirectional. Am I right ? It seems the TX and = RX=0D > >are 2 differents interfaces...=0D > >=0D > >This situation can be handled by UDLR although RFC 3077 says the=0D > >receiver needs a bidirectional interface to send GRE to the feed. In=0D > >fact, as long as the return link can carry IP datagrams from the=0D > >receiver to the feed, the UDLR protocol will work. We've been using so= me=0D > >DVB-RCS systems with UDLR and it works pretty well.=0D > >=0D > >=0D > >>=0D > >>=0D > >> Thanks and Best Regards,=0D > >> William StanisLaus.=0D > >>=0D > >> _______________________________________________=0D > >> UDLR mailing list=0D > >> [email protected]=0D > >> http://www.udcast.com/mailman/listinfo/udlr=0D > >=0D > >Regards,=0D > >>=0D > >--=0D > >Emmanuel Duros http://www.udcast.com=0D > >2455 Route des Dolines BP355 | Tel : +33 (0)4 93 00 16 60=0D > >06906 Sophia Antipolis France | Fax : +33 (0)4 93 00 16 61=0D > > ** Full IP over Broadcast Media **=0D > >=0D > >_______________________________________________=0D > >UDLR mailing list=0D > >[email protected]=0D > >http://www.udcast.com/mailman/listinfo/udlr=0D > =0D > =0D -- =0D Emmanuel Duros http://www.udcast.com=0D 2455 Route des Dolines BP355 | Tel : +33 (0)4 93 00 16 60=0D 06906 Sophia Antipolis France | Fax : +33 (0)4 93 00 16 61=0D ** Full IP over Broadcast Media **=0D =0D _______________________________________________=0D UDLR mailing list=0D [email protected]=0D http://www.udcast.com/mailman/listinfo/udlr=0D =2E=20 --------------Boundary-00=_9BDWLVC0000000000000 Content-Type: Text/HTML; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-= 1"> <META content=3D"IncrediMail 1.0" name=3DGENERATOR> <!--IncrdiXMLRemarkStart> <IncrdiX-Info> <X-FID>BA285063-5BCE-11D4-AF8D-0050DAC67E11</X-FID> <X-FVER></X-FVER> <X-FIT></X-FIT> <X-FCOL></X-FCOL> <X-FCAT></X-FCAT> <X-FDIS></X-FDIS> <X-BG>3C625157-D76B-44AB-BEF8-939566119DEB</X-BG> <X-BGT>repeat</X-BGT> <X-BGC>#eff3f7</X-BGC> <X-BGPX>left</X-BGPX> <X-BGPY>0px</X-BGPY> <X-ASN>ANIM3D00-NONE-0000-0000-000000000000</X-ASN> <X-ASNF>0</X-ASNF> <X-ASH>ANIM3D00-NONE-0000-0000-000000000000</X-ASH> <X-ASHF>1</X-ASHF> <X-AN>6486DDE0-3EFD-11D4-BA3D-0050DAC68030</X-AN> <X-ANF>0</X-ANF> <X-AP>6486DDE0-3EFD-11D4-BA3D-0050DAC68030</X-AP> <X-APF>1</X-APF> <X-AD>C3C52140-4147-11D4-BA3D-0050DAC68030</X-AD> <X-ADF>0</X-ADF> <X-AUTO>X-ASN,X-ASH,X-AN,X-AP,X-AD</X-AUTO> <X-CNT>;</X-CNT> </IncrdiX-Info> <IncrdiXMLRemarkEnd--> </HEAD> <BODY style=3D"BACKGROUND-POSITION: left 0px; FONT-SIZE: 12pt; MARGIN: 0p= x 10px 10px; BACKGROUND-REPEAT: repeat; FONT-FAMILY: Arial" text=3D#00005= b bgColor=3D#eff3f7 background=3Dcid:3C625157-D76B-44AB-BEF8-939566119DEB= scroll=3Dyes SIGCOLOR=3D"0" X-ADF=3D"0" X-AD=3D"C3C52140-4147-11D4-BA3D-= 0050DAC68030" X-APF=3D"1" X-AP=3D"6486DDE0-3EFD-11D4-BA3D-0050DAC68030" X= -ANF=3D"0" X-AN=3D"6486DDE0-3EFD-11D4-BA3D-0050DAC68030" X-ASHF=3D"1" X-A= SH=3D"ANIM3D00-NONE-0000-0000-000000000000" X-ASNF=3D"0" X-ASN=3D"ANIM3D0= 0-NONE-0000-0000-000000000000" X-FVER=3D"2.0" X-FID=3D"BA285063-5BCE-11D4= -AF8D-0050DAC67E11" X-FIT=3D"Letter" X-FCOL=3D"Elegant Paper" X-FCAT=3D"E= legant Paper" X-FDIS=3D"Rice Fields" ORGYPOS=3D"0"> <TABLE id=3DINCREDIMAINTABLE cellSpacing=3D0 cellPadding=3D2 width=3D"100= %" border=3D0> <TBODY> <TR> <TD id=3DINCREDITEXTREGION style=3D"FONT-SIZE: 12pt; CURSOR: auto; FONT-F= AMILY: Arial" vAlign=3Dtop width=3D"100%"> <DIV>Hi Emmanuel,</DIV> <DIV> </DIV> <DIV>Thanks for your clarification.</DIV> <DIV>>For scenario 2, it is more of an implementation issue and there = are many<BR>>question marks: Does the IP layer see both physical inter= faces as a<BR>>unique logical interface ? Is your receiver a router or= a bridge ?...</DIV> <DIV> </DIV> <DIV>Yeah the IP Layer see both physical interfaces as one unique logial = interface in our RCS System. Our receiver is a router.</DIV> <DIV> </DIV> <DIV>I have few more doubts Regarding Feeder unidirectional MAC Address</= DIV> <DIV> </DIV> <DIV>In our RCS System we don't get Feeder MAC address in the MPEG-2 pack= ets, it contains only the Destination MAC address. So how do we get the F= eeder MAC address, is there any generic procedure for UDLR??</DIV> <DIV> </DIV> <P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN style=3D"mso-= fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT color=3D#000000><F= ONT face=3D"Courier New"><SPAN style=3D"mso-spacerun: yes">Section 7.3</S= PAN></FONT></FONT></FONT></SPAN></P> <P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN style=3D"mso-= fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT color=3D#000000><F= ONT face=3D"Courier New"><SPAN style=3D"mso-spacerun: yes">" = </SPAN>The FUMAC value for an active feed is needed for the operation of<= BR><SPAN style=3D"mso-spacerun: yes"> </SPAN>this protocol.<S= PAN style=3D"mso-spacerun: yes"> </SPAN>However, the method of disc= overy of this value is not<BR><SPAN style=3D"mso-spacerun: yes"> &nb= sp; </SPAN>specified here.</FONT></FONT></FONT><BR></P> <DIV></SPAN>"<BR></DIV> <DIV>Thanks in advance.</DIV> <DIV> </DIV> <DIV>Regards,</DIV> <DIV>William.</DIV> <DIV><BR> </DIV> <DIV id=3DIncrediOriginalMessage><I>-------Original Message-------</I></D= IV> <DIV> </DIV> <DIV id=3Dreceivestrings> <DIV dir=3Dltr style=3D"FONT-SIZE: 11pt" <i><B>From:</B></I> <A href=3D"m= ailto:[email protected]">Emmanuel Duros</A></DIV> <DIV dir=3Dltr style=3D"FONT-SIZE: 11pt" <i><B>Date:</B></I> Wednesday, O= ctober 30, 2002 10:25:15 PM</DIV> <DIV dir=3Dltr style=3D"FONT-SIZE: 11pt" <i><B>To:</B></I> <A href=3D"mai= lto:[email protected]">William StanisLaus</A></DIV> <DIV dir=3Dltr style=3D"FONT-SIZE: 11pt" <i><B>Cc:</B></I> <A href=3D"mai= lto:[email protected]">udlr</A></DIV> <DIV dir=3Dltr style=3D"FONT-SIZE: 11pt" <i><B>Subject:</B></I> RE: Clari= fications with RFC 3077</DIV></DIV> <DIV> </DIV>William,<BR><BR>On Wed, 2002-10-30 at 08:29, William Sta= nisLaus wrote:<BR>> Hi Emmanuel Duros,<BR>> Good Day. Thanks for yo= ur Clarifications.<BR>> <BR>> Regarding Q 2)<BR>> <BR>> Yep, = Our Return Link is unidirectional, and TX and RX are 2 different <BR>>= interfaces.<BR>> <BR>> My Clarification now might be silly, but ju= st to doubt check my understanding <BR>> :)<BR>> <BR>> RCS Syste= m with both TX and RX port.<BR>> <BR>> Scenario 1: RCS Sytem sends/= response to Feeder (Send Only). The packet is <BR>> Encapsulated and b= ased on the Routing table it chooses Tx Port(Return Link) or <BR>> RCS= System bi-directional interface targeting Feeder bidirectional interface= =2E<BR>> In Case if Tx Port is selected, there should be a Gateway whi= ch receives the <BR>> Encapsulated packet from RCS System and forwards= to the feeder bidirectional <BR>> interface, just IP Forward.<BR>>= <BR>> Scenaio 2: RCS System sends/response to Feeder( Receive capable = feeder). The <BR>> packet is not Encapsulated, just sends via the TX p= ort(Return Link) to the <BR>> Feeder.<BR>> <BR>> so Encapsulatio= n Decisions are taken based on the DTCP table, "feeder type <BR>> info= rmation" in the RCS System..<BR>> <BR>> Note: All the Scenarios are= not IP forwarding<BR>> <BR><BR>My understanding is that the receiver = has 2 physical interfaces: a<BR>receive-only interface and a distinct int= erface used for the return link<BR>(RCS, RTC, or whatever !). The decisio= n for routing IP traffic is taken<BR>at IP layer using routing tables and= is *not* related to the type of<BR>feed contained in the DTCP announceme= nt.<BR><BR>Any IP packet sent through the receive-only interface is encap= sulated in<BR>GRE packet and sent to the feed via the return link. The fe= ed (send-only<BR>or receive-capable) that support UDLR will decapsulate t= he incoming GRE<BR>packet (from whatever interface) and processes the pay= load as coming<BR>from the "satellite" interface.<BR><BR>For scenario 2, = it is more of an implementation issue and there are many<BR>question mark= s: Does the IP layer see both physical interfaces as a<BR>unique logical = interface ? Is your receiver a router or a bridge ?...<BR><BR>> Thanks= and Best Regards,<BR>> William StanisLaus.<BR><BR>Emmanuel<BR><BR>>= ; <BR>> >=3D=3D=3D=3D=3D Original Message From Emmanuel Duros <<= A href=3D"mailto:[email protected]">[email protected]</A>= > =3D=3D=3D=3D=3D<BR>> >Hello William,<BR>> ><BR>> >= On Tue, 2002-10-29 at 12:01, William StanisLaus wrote:<BR>> >> H= i all,<BR>> >><BR>> >> I am a newbee to UDLR technology= =2E I have few clarifications with RFC <BR>> 3077.<BR>> >><BR= >> >> Can you help me in understanding the concept.<BR>> >= > here we go.....<BR>> >><BR>> >> 1)<BR>> >>= ;<BR>> >> In Section 7<BR>> >> "The number of feeds is = expected to be relatively small (Section 3),<BR>> >> so at every= feed the list of all feeds is configured manually."<BR>> >><BR>= > >> In Section 7.1<BR>> >> When Feed multicasts the DT= CP Hello Message, it passes the Feed Type<BR>> >><BR>> >&g= t; i.e.<BR>> >> F (1 bit): bit indicating the type of feed:<BR>&= gt; >> 0 =3D Send-only feed<BR>> >> 1 =3D Receive-capable = feed<BR>> >><BR>> >><BR>> >> So the Reciever c= an maintain the Feed type in the DTCP routing table.<BR>> >> In = Such cases,<BR>> >> for Scenario 2: "A receiver can send a broad= cast/multicast packet on the<BR>> >> link to all nodes (point-to= -multipoint)"<BR>> >><BR>> >> Section 6.2.2 (3)<BR>>= >> As of now, Receiver sends packets to be broadcasted/multicasted= to the <BR>> default<BR>> >> feed and the default feed broad= cast/multicast the packet to the other Feed <BR>> &<BR>> >&g= t; Receivers.<BR>> >><BR>> >><BR>> >> Clarific= ation :-<BR>> >><BR>> >> When the Receiver maintains th= e Feed types, which is dynamic at any moment,<BR>> >> why Receiv= er is not multicasting to all the Feeds which are Send only?<BR>> >= <BR>> >The main reason I see is that it would be costly in term of = bandwidth<BR>> >for the receiving site. A copy of every multicast p= acket would have to<BR>> >be tunneled from the receiver to each Sen= d-only feed. It can get really<BR>> >bad for the receiver if it has= a low speed return link such as GSM or<BR>> >RTC.<BR>> ><BR>= > >It is easier for the operator to set up high speed links between= the<BR>> >feeds and let them make the duplication of packets...<BR= >> ><BR>> >> It can also have a default Feed which forward= s the packet to all receivers <BR>> and<BR>> >> receive capab= le Feeds.<BR>> >><BR>> >><BR>> >> The clarific= ation is because, we have the overhead of encapulation at the<BR>> >= ;> receiver side and sending to the default feed which decapulate and = again<BR>> >> encapulate to send to Send only Feeds. Also in the= Feeds the list of<BR>> >> other feeds are manually configured i= =2Ee. Static. Might be broken at any <BR>> time.<BR>> >><BR>&= gt; >><BR>> >> 2)<BR>> >><BR>> >> In the= RFC 3077 which explaines about the Feeds , i.e. Send only and <BR>> R= ecieve<BR>> >> capable Feeds. But for receivers it is always tar= geted as Receive only. <BR>> Just<BR>> >> imagine a RCST with= send capable receivers i.e. which has both Tx and Rx <BR>> port.<BR>&= gt; >><BR>> >> What are the configurations in the UDLR if = the receiver happens to be send<BR>> >> capable.<BR>> >>= ;<BR>> ><BR>> >The receiver you are describing is pretty much= similar to a receiver<BR>> >whose return link is unidirectional. A= m I right ? It seems the TX and RX<BR>> >are 2 differents interface= s...<BR>> ><BR>> >This situation can be handled by UDLR altho= ugh RFC 3077 says the<BR>> >receiver needs a bidirectional interfac= e to send GRE to the feed. In<BR>> >fact, as long as the return lin= k can carry IP datagrams from the<BR>> >receiver to the feed, the U= DLR protocol will work. We've been using some<BR>> >DVB-RCS systems= with UDLR and it works pretty well.<BR>> ><BR>> ><BR>> &g= t;><BR>> >><BR>> >> Thanks and Best Regards,<BR>>= >> William StanisLaus.<BR>> >><BR>> >> _________= ______________________________________<BR>> >> UDLR mailing list= <BR>> >> <A href=3D"mailto:[email protected]">[email protected]</A><= BR>> >> <A href=3D"http://www.udcast.com/mailman/listinfo/udlr">= http://www.udcast.com/mailman/listinfo/udlr</A><BR>> ><BR>> >= Regards,<BR>> >><BR>> >--<BR>> >Emmanuel Duros <A hr= ef=3D"http://www.udcast.com">http://www.udcast.com</A><BR>> >2455 R= oute des Dolines BP355 | Tel : +33 (0)4 93 00 16 60<BR>> >06906 Sop= hia Antipolis France | Fax : +33 (0)4 93 00 16 61<BR>> > ** Full IP= over Broadcast Media **<BR>> ><BR>> >_______________________= ________________________<BR>> >UDLR mailing list<BR>> &<A hr= ef=3D"mailto:gt;[email protected]">gt;[email protected]</A><BR>> ><A hr= ef=3D"http://www.udcast.com/mailman/listinfo/udlr">http://www.udcast.com/= mailman/listinfo/udlr</A><BR>> <BR>> <BR>-- <BR>Emmanuel Duros <A h= ref=3D"http://www.udcast.com">http://www.udcast.com</A><BR>2455 Route des= Dolines BP355 | Tel : +33 (0)4 93 00 16 60<BR>06906 Sophia Antipolis Fra= nce | Fax : +33 (0)4 93 00 16 61<BR>** Full IP over Broadcast Media **<BR= ><BR>_______________________________________________<BR>UDLR mailing list= <BR><A href=3D"mailto:[email protected]">[email protected]</A><BR><A href=3D"= http://www.udcast.com/mailman/listinfo/udlr">http://www.udcast.com/mailma= n/listinfo/udlr</A><BR>. </TD></TR> <TR> <TD id=3DINCREDIFOOTER width=3D"100%"> <TABLE cellSpacing=3D0 cellPadding=3D0 width=3D"100%"> <TBODY> <TR> <TD width=3D"100%"></TD> <TD id=3DINCREDISOUND vAlign=3Dbottom align=3Dmiddle></TD> <TD id=3DINCREDIANIM vAlign=3Dbottom align=3Dmiddle></TD></TR></TBODY></T= ABLE></TD></TR></TBODY></TABLE><SPAN id=3DIncrediStamp><SPAN dir=3Dltr><F= ONT face=3D"Arial, Helvetica, sans-serif" size=3D2>______________________= ______________________________<BR><FONT face=3D"Comic Sans MS" size=3D2><= A href=3D"http://www.incredimail.com/redir.asp?ad_id=3D309&lang=3D9">= <IMG alt=3D"" hspace=3D0 src=3D"cid:B94583B2-8527-4DC7-A959-2550EBD0519E"= align=3Dbaseline border=3D0></A> <I>IncrediMail</I> - <B>Email has= finally evolved</B> - </FONT><A href=3D"http://www.incredimail.com/redir= =2Easp?ad_id=3D309&lang=3D9"><FONT face=3D"Times New Roman" size=3D3>= <B><U>Click Here</U></B></FONT></A></SPAN></SPAN></FONT></BODY></HTML> --------------Boundary-00=_9BDWLVC0000000000000-- --------------Boundary-00=_8BDWQL80000000000000 Content-Type: image/gif; name="IMSTP.gif" Content-Transfer-Encoding: base64 Content-ID: <B94583B2-8527-4DC7-A959-2550EBD0519E> R0lGODlhFAAPALMIAP9gAM9gAM8vAM9gL/+QL5AvAGAvAP9gL////wAAAAAAAAAAAAAAAAAAAAAA AAAAACH/C05FVFNDQVBFMi4wAwEAAAAh+QQJFAAIACwAAAAAFAAPAAAEVRDJSaudJuudrxlEKI6B URlCUYyjKpgYAKSgOBSCDEuGDKgrAtC3Q/R+hkPJEDgYCjpKr5A8WK9OaPFZwHoPqm3366VKyeRt E30tVVRscMHDqV/u+AgAIfkEBWQACAAsAAAAABQADwAABBIQyUmrvTjrzbv/YCiOZGmeaAQAIfkE CRQACAAsAgABABAADQAABEoQIUOrpXIOwrsPxiQUheeRAgUA49YNhbCqK1kS9grQhXGAhsDBUJgZ AL2Dcqkk7ogFpvRAokSn0p4PO6UIuUsQggSmFjKXdAgRAQAh+QQFCgAIACwAAAAAFAAPAAAEEhDJ Sau9OOvNu/9gKI5kaZ5oBAAh+QQJFAAIACwCAAEAEAANAAAEShAhQ6ulcg7Cuw/GJBSF55ECBQDj 1g2FsKorWRL2CtCFcYCGwMFQmBkAvYNyqSTuiAWm9ECiRKfSng87pQi5SxCCBKYWMpd0CBEBACH5 BAVkAAgALAAAAAAUAA8AAAQSEMlJq7046827/2AojmRpnmgEADs= --------------Boundary-00=_8BDWQL80000000000000 Content-Type: Image/jpeg; name="BackGrnd.jpg" Content-ID: <3C625157-D76B-44AB-BEF8-939566119DEB> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAHgAA/+4AIUFkb2JlAGTAAAAAAQMA EAMCAwYAAAHbAAAC1gAABZX/2wCEABALCwsMCxAMDBAXDw0PFxsUEBAUGx8XFxcXFx8eFxoaGhoX Hh4jJSclIx4vLzMzLy9AQEBAQEBAQEBAQEBAQEABEQ8PERMRFRISFRQRFBEUGhQWFhQaJhoaHBoa JjAjHh4eHiMwKy4nJycuKzU1MDA1NUBAP0BAQEBAQEBAQEBAQP/CABEIAGUAcwMBIgACEQEDEQH/ xACAAAEBAQEAAAAAAAAAAAAAAAAAAQIGAQEBAAAAAAAAAAAAAAAAAAAAARABAAICAwEAAgMAAAAA AAAAAQARIQIxQRIiQDIQMFARAAICAgIBBAIDAQEAAAAAAAERACExQVFhcYGRobECEsHhMtHxEgEA AAAAAAAAAAAAAAAAAABQ/9oADAMBAAIRAxEAAADtRZYE1ASghQFgUZoCkKSwLmhcllAEqkSkqFAl hUomoAS3IoJqFlDNpFEAQFE1AIVYAWIVKAJRNZpYCwVmmshKACA0CBAUCBYGwf/aAAgBAgABBQD8 B/yP/9oACAEDAAEFAPz6/or8H//aAAgBAQABBQC2+ZeHjbD+saX6hwXeDW1Rg4xLLTa+m7ZiIEsI 1MTiHP1dYpvFADiFM1/X6nq9byuwdPPz5oFofWlEMQ9ULKrWq2ppG9Y2J6INQma9lVTRdlUKgHzX XSEECw1SYu5WsGoJPkisZYpx31GvXZQ/JM3VwShzVTsp1EZbBI8LcaUSih86+s2Zl4Wp6+lAZnVs Dkjdku5m+lJTdXDG2SHM9M2wKX1YxsaZTTwmoVrYnqsMrM652yjs01K0mtbGAz6Y5dpfqNz06qpq 5QNjiIjiZtbhtceNuf0jyeqGgu6rXMvI4omPWbPMYzEfMI+axHnFvOP4/9oACAECAgY/AGP/2gAI AQMCBj8AY//aAAgBAQEGPwB72Yucb1BfIhFEaeZ+xRXFQELN+HEUQdjU0Xn4g9gRCQcpw1yajGYs P/kFvUzvjUBWrIMFHI2OJQNEAjiEEFdTmfG/MTHq5RFOnpTV3kzCBx7x4YOD1AV5uYJvnqMA0hep jfwpYCwC4Bx3q55zeZRBCw9TkoIuHw78RdczSNH2mgqcLpRC+RASAkA3B13mcYd5mR84c/yOx4lW tRAZ6mGDhiP9WgXVyhWA+xDgMOWGMsTg/wBTz8SjjXrP8hHIlX1MZ6mDzgc/cIV/iyN1GBR0MQMK jnEzvvMz8mUkErKlfqU63iV+IKNH7mNZBLFQEpEDeDOV32IVn8WR4caoywqI2p695mbZzNUQIcKf k0bo+0NpCqn7CiQiNGXkdQen1DpjGeZ7WNw3pK+I93maCPc16+Zkf6XxMCsFwAkaiIB57vc/IAhZ /HqZBBbB0ZokAEOGxsYqBgPp8agQBu4VSMJdqx6SwDsGBrTmAR93uZGX6KePowEADAIjoX8gw459 CICaW/MLGvodQfkDW71zBxRHtB3j3jC4PMIYoAgKNfPMCQNN7jCzvlzXPopzhQvNZY3CRya9ZrEF fRE0iCB5mscZuVYfKmAi94uE3Q8qfytQ7xD0svmFcmaxNPI8iMjh3pmF2HbzqeUi+YkiD/MrOl5L mbwPuWVfmXpv3hDH8qAjPpiZHXkRnSd6ZhB53mejzKV6US0K9TCCLyCeIhtETX5MsHBGJkD/ANiF kMCE2qGoCdZ8Q8AMGpYFqEhdhRIYH3CF3d1M/Mexma+4CwdQ2Ddcx0exAlmj04QUQd8QWLB/iB5G xmEg5TENVZqPYzFV8eHAy9T/AEc8a4n3Ov6g/VwvE6lpQ4VNysXzhS8esOO8w/rlF/rypjV3B5H1 Knr8T//Z --------------Boundary-00=_8BDWQL80000000000000--