Re: Multicast Data

From: Carlos G Mendioroz <tron_at_huapi.ba.ar>
Date: Fri, 09 Apr 2010 08:58:26 -0300

I'd prefer you making the effort and ask what is that is unclear.
But there are lots of cases in multicast where things get fixed
after some timeout, and it happens to be 3 minutes by default.
The RP keeps no info on potential sources if there are no receivers
for a group, and will kill the registration attempt w/o joining in
that case.

Makes sense ?

Tharindu Rukshan Bamunuarachchi @ 9/04/2010 8:31 -0300 dixit:
> bit unclear about last point .... please clarify further if you can ....
> __
> btharindu.blogspot.com
>
>
>
> On Fri, Apr 9, 2010 at 4:01 PM, Carlos G Mendioroz <tron_at_huapi.ba.ar> wrote:
>
>> Adding to that that has been said:
>> -yes, you can loose first, second, third... any, cause Mcast runs
>> over UDP and there are no L4 delivery warranties. Actually, there
>> are very few L7 protocols that have assured delivery over mcast.
>>
>> -registration does not stop when S (source router) receives join from
>> RP, so there can be many packets going unicast to RP.
>> RP tells S to stop registration after it receives direct mcast from S,
>> so no packets lost in between.
>>
>> -sending can start before receivers have joined the RP, in which case
>> the RP will stop registration w/o joining the source. Then you it will
>> start a slow "flapping", trying to register every 3 mins, and being
>> call to silence untill a receiver shows up.
>>
>> I guess you can loose up to 3 minutes of the show if nobody was
>> listening and you are late to the start :)
>>
>> -Carlos
>>
>>
>>
>> Kambiz Agahian @ 9/04/2010 3:44 -0300 dixit:
>>> Hi Tharin,
>>>
>>> Good point!
>>> First off, I'm hoping that my interpretation of your question is correct
>>> anyway correct me if your question if not exactly this but actually the
>>> problem is that almost all resources (including most pages on cisco.comand
>>> juniper.com as well as the RFC!) focus on the "second" action taken by
>> the RP
>>> after receiving the registration request! and the first (but the less
>>> important action) is somehow ignored (or underestimated)....
>>>
>>> Here is the process (briefly):
>>>
>>> Your Windows 2003 Media server starts sending the Multicast packets of
>> (analog
>>> term : broadcasting) "The Family guy". The first Mcast packets hit their
>>> gateway and the DR of that segment tries to get a hold of the RP to kick
>> off
>>> the registration process. You know the encapsulation process (the actual
>> mcast
>>> content inside a unicast packet - right?) so the RP gets the first
>> capsule and
>>> "extracts" the multicast content. At this stage the RP has to take two
>>> actions:
>>>
>>> 1- It sends the extracted Multicast packet down the tree based on the
>> (*,G).
>>> Where did you get that from? my Visa client had talked to his DR and his
>> DR to
>>> his upstream then to his upstream...all the way up to the RP to indicate
>> his
>>> interest. So before getting the first packet (the capsule) as you
>> mentioned
>>> the RP does know that I'm waiting to watch Quagmire (there is a receiver
>> down
>>> there). In fact the (*,G) is on the RP waiting for the source to come up.
>>>
>>> 2- The RP then tries to join the group and now everyone knows what's
>> gonna
>>> happen afterwards...I save some key strokes.
>>>
>>> Well, as you see (the first action), even the first packet (probably the
>> first
>>> frame of the Fox ad!) is delivered by the RP to (*,G) to ensure nothing's
>>> going to be missed.
>>>
>>> HTH
>>>
>>>
>>>
>>>
>>> Kambiz Agahian
>>> CCIE (R&S)
>>> CCSI, WAASSE, RSSSE
>>> Technical Instructor
>>> CCBOOTCAMP - Cisco Learning Solutions Partner (CLSP)
>>> Email: kagahian_at_ccbootcamp.com
>>> Toll Free: 877-654-2243
>>> International: +1-702-968-5100
>>> Skype: skype:ccbootcamp?call
>>> FAX: +1-702-446-8012
>>> YES! We take Cisco Learning Credits!
>>> Training And Remote Racks: http://www.ccbootcamp.com
>>> OEQ Voice Waiver: http://www.ccbootcamp.com/noeqvoice.html
>>> OEQ R&S Waiver: http://www.ccbootcamp.com/noeqrs.html
>>> OEQ Commercial: http://www.ccbootcamp.com/noeq.mpg
>>>
>>>
>>> -----Original Message-----
>>> From: nobody_at_groupstudy.com on behalf of Tharindu Rukshan Bamunuarachchi
>>> Sent: Thu 4/8/2010 10:04 PM
>>> To: ccielab_at_groupstudy.com
>>> Subject: Multicast Data
>>>
>>> hi Experts,
>>>
>>> In sparse-mode, AFAIK first packet is forwarded to RP as unicast. (In
>>> Register Unicast process).
>>>
>>> Is there any possibility to lose first packet without being delivered to
>>> destination. (assuming destination is already subcribed to multicast
>> tree)?
>>>
>>> __
>>> btharindu.blogspot.com
>>>
>>>
>>> Blogs and organic groups at http://www.ccie.net
>>>
>>> _______________________________________________________________________
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>>>
>>>
>>> Blogs and organic groups at http://www.ccie.net
>>>
>>> _______________________________________________________________________
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>> --
>> Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>

-- 
Carlos G Mendioroz  <tron_at_huapi.ba.ar>  LW7 EQI  Argentina
Blogs and organic groups at http://www.ccie.net
Received on Fri Apr 09 2010 - 08:58:26 ART

This archive was generated by hypermail 2.2.0 : Sat May 01 2010 - 09:49:56 ART