Protocol Independent Multicast (pim)

Nikhil Ninan | 3 Apr 2006 12:25

Picon

Picon

PIM Join/Prune Messages

Hello there,
                Could someone tell me how does PIM combine group 
information, i.e. no. of joins and no. of prunes, on a group by group 
basis onto a single Join/Prune message.
Cheers
Nikhil

David McWalter | 3 Apr 2006 12:39

RE: PIM Join/Prune Messages

Hello again Nikhil.

The message format below is from the PIM spec.
http://www.ietf.org/internet-drafts/draft-ietf-pim-sm-v2-new-12.txt

If your question is about logic rather than message format, then you'll need to clarify it.

DMcW.

4.9.5.  Join/Prune Message Format
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type  |   Reserved    |           Checksum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Upstream Neighbor Address (Encoded-Unicast format)     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Reserved     | Num groups    |          Holdtime             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Multicast Group Address 1 (Encoded-Group format)      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Number of Joined Sources    |   Number of Pruned Sources    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Joined Source Address 1 (Encoded-Source format)        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             .                                 |
|                             .                                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Joined Source Address n (Encoded-Source format)        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

(Continue reading)

Nikhil Ninan | 3 Apr 2006 12:49

Picon

Picon

Re: PIM Join/Prune Messages

David McWalter wrote:
> Hello again Nikhil.
>
> The message format below is from the PIM spec.
> http://www.ietf.org/internet-drafts/draft-ietf-pim-sm-v2-new-12.txt
>
> If your question is about logic rather than message format, then you'll need to clarify it.
>
> DMcW.
>
> 4.9.5.  Join/Prune Message Format
>  0                   1                   2                   3
>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |PIM Ver| Type  |   Reserved    |           Checksum            |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |        Upstream Neighbor Address (Encoded-Unicast format)     |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |  Reserved     | Num groups    |          Holdtime             |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |         Multicast Group Address 1 (Encoded-Group format)      |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |   Number of Joined Sources    |   Number of Pruned Sources    |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |        Joined Source Address 1 (Encoded-Source format)        |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |                             .                                 |
> |                             .                                 |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |        Joined Source Address n (Encoded-Source format)        |

(Continue reading)

Christopher Thomas Brown | 3 Apr 2006 18:10

Re: PIM Join/Prune Messages

Nikhil Ninan wrote:
> >-----Original Message-----
> >From: Nikhil Ninan [mailto:nikhil <at> erg.abdn.ac.uk]
> >Sent: 03 April 2006 11:25
> >To: pim <at> ietf.org
> >Subject: [pim] PIM Join/Prune Messages
> >
> >
> >Hello there,
> >                Could someone tell me how does PIM combine group 
> >information, i.e. no. of joins and no. of prunes, on a group by group 
> >basis onto a single Join/Prune message.
> >Cheers
> >Nikhil
> >
> >_______________________________________________
> >pim mailing list
> >pim <at> ietf.org
> >https://www1.ietf.org/mailman/listinfo/pim
> >
> >
> >
> >  
> my question is about the logic not the format 
> Cheers
> Nikhil

The only logic that the PIM-SM specification requires is that (S,G,rpt)
prunes for a given group must be contained in the same message as the
(*,G) join for that group. The spec also says which prunes to include if

(Continue reading)

Dino Farinacci | 3 Apr 2006 19:23

Picon

Re: BSR update

>> Slide 6, Unicast BSMs
>> 
>> New revision says that they must be sent from the primary address,
>> and also only accepts them from the primary. I believe Dino said this
>> was problematic. But I must say now that I'm not sure why. Could you
>> clarify Dino? Or anyone else?

    The problem with unicast BSMs, as sent by the DR on a LAN when a new
    neighbor comes up, is if the ARP cache is not primed with the new 
    neighbor, then the BSM is *typically* dropped by the local system (when
    the ARP implementation does not queue packets). 

    Since the PIM neighbor adjacency and the unicast routing protocol adjacency
    are coming up at the same time, it is typically a race on which one sends 
    the first unicast packet to the newly booted router. And since there is 
    less chit-chat in PIM for bringing up an adjacency (versus OSPF or, IS-IS 
    which never sends a unicast packet), it's the BSM that triggers the ARP
    request.

    So I am questioning the probablistic usefulness of unicast BSMs. I think
    a simple solution is to link-local multicast them. But the new neighbor
    needs to not RPF-check these. So either:

    o The new neighbor accepts all BSMs within a short-time of discovering
      the DR, or

    o Set a bit in the BSM to unconditionally accept (and not forward) the
      BSM. This would be useful from another repsect in that the new neighbor
      wouldn't have to determine if the DR is sending it. Especially, in the
      case where the new neighbor is just becoming the DR.

(Continue reading)

Venu Hemige | 5 Apr 2006 23:01

Picon

RE: BSR update


Stig, 

Please see comments inline.

> 
> Slide 5, BSM Forwarding
> 
> New revision says that routers in C-BSRs state must forward
> non-preferred BSMs from elected BSR. The reasons for this are
> clear, and I believe everyone agrees.
> 
> New revision also says that P-BSRs should forward non-preferred BSMs.
> This is not so clear, but there are some advantages, and no real
> negative impacts.
>

There is benefit in doing this. I think we should keep it.

In addition, I think it would be useful to make the following changes to
BSM forwarding:

In Accept-Preferred state, if we receive a non-preferred BSM from E-BSR,
then we should perform the same actions as we would if a preferred BSM
was received. The important thing is that the BSM should be forwarded so
that other routers (some of which may be C-BSRs) also note that the
current E-BSR may no longer be E-BSR.

Regards,
-Venu

(Continue reading)

Stig Venaas | 9 Apr 2006 15:42

Picon

Picon

Re: BSR update

Dino Farinacci wrote:
>>> Slide 6, Unicast BSMs
>>>
>>> New revision says that they must be sent from the primary address,
>>> and also only accepts them from the primary. I believe Dino said this
>>> was problematic. But I must say now that I'm not sure why. Could you
>>> clarify Dino? Or anyone else?
> 
>     The problem with unicast BSMs, as sent by the DR on a LAN when a new
>     neighbor comes up, is if the ARP cache is not primed with the new 
>     neighbor, then the BSM is *typically* dropped by the local system (when
>     the ARP implementation does not queue packets). 
> 
>     Since the PIM neighbor adjacency and the unicast routing protocol adjacency
>     are coming up at the same time, it is typically a race on which one sends 
>     the first unicast packet to the newly booted router. And since there is 
>     less chit-chat in PIM for bringing up an adjacency (versus OSPF or, IS-IS 
>     which never sends a unicast packet), it's the BSM that triggers the ARP
>     request.
> 
>     So I am questioning the probablistic usefulness of unicast BSMs. I think
>     a simple solution is to link-local multicast them. But the new neighbor
>     needs to not RPF-check these. So either:
> 
>     o The new neighbor accepts all BSMs within a short-time of discovering
>       the DR, or
> 
>     o Set a bit in the BSM to unconditionally accept (and not forward) the
>       BSM. This would be useful from another repsect in that the new neighbor
>       wouldn't have to determine if the DR is sending it. Especially, in the

(Continue reading)

Stig Venaas | 9 Apr 2006 16:48

Picon

Picon

Re: BSR update

Venu Hemige wrote:
> Stig, 
> 
> Please see comments inline.
> 
>> Slide 5, BSM Forwarding
>>
>> New revision says that routers in C-BSRs state must forward
>> non-preferred BSMs from elected BSR. The reasons for this are
>> clear, and I believe everyone agrees.
>>
>> New revision also says that P-BSRs should forward non-preferred BSMs.
>> This is not so clear, but there are some advantages, and no real
>> negative impacts.
>>
> 
> There is benefit in doing this. I think we should keep it.
> 
> In addition, I think it would be useful to make the following changes to
> BSM forwarding:
> 
> In Accept-Preferred state, if we receive a non-preferred BSM from E-BSR,
> then we should perform the same actions as we would if a preferred BSM
> was received. The important thing is that the BSM should be forwarded so
> that other routers (some of which may be C-BSRs) also note that the
> current E-BSR may no longer be E-BSR.

I agree. I didn't mention this, but this was fixed in the previous 
revision. What we did was to add a paragraph to the description of the 
receive preferred event. It reads as follows:

(Continue reading)

Venu Hemige | 10 Apr 2006 01:20

Picon

RE: BSR update

Stig,

I see it now. But it is a little less intuitive. I think defining an
"Acceptable BSM from Elected BSR" and adding a specific FSM event into
the state machine would have been better. It goes well with the language
used in the draft (like Non-Preferred BSM from Elected BSR).

Regards,
-Venu

> -----Original Message-----
> From: Stig Venaas [mailto:stig.venaas <at> uninett.no]
> Sent: Sunday, April 09, 2006 7:48 AM
> To: venu.hemige <at> alcatel.com
> Cc: pim <at> ietf.org
> Subject: Re: [pim] BSR update
> 
> Venu Hemige wrote:
> > Stig,
> >
> > Please see comments inline.
> >
> >> Slide 5, BSM Forwarding
> >>
> >> New revision says that routers in C-BSRs state must forward
> >> non-preferred BSMs from elected BSR. The reasons for this are
> >> clear, and I believe everyone agrees.
> >>
> >> New revision also says that P-BSRs should forward non-preferred

(Continue reading)

Christopher Thomas Brown | 10 Apr 2006 19:05

Re: BSR update

Stig Venaas wrote:
> I would like to not change the draft more than necessary, but I must say 
> I like the idea of getting rid of unicast BSMs if possible.
> 
> I prefer your first alternative, i.e., not adding a new flag. However, I 
> would also like to avoid the complexity of finding out whether the BSM 
> came from the DR (the DR in this new routers absence). What about 
> skipping that check? Currently there is no check that the unicasted BSM 
> came from the DR either. However, the unicasted BSM is supposed to be 
> sent by the DR, so we should still say that this triggered multicasted 
> BSM is to be sent by the DR.
> 
> Do you see any problems with just saying that for a short time after 
> startup, the RPF check is not required?

I think it couldn't be required.  If the router is restarting it likely
doesn't have an MRIB with which to do an RPF check.

> Then there is the issue of forwarding. We could perhaps say that RPF 
> should still be performed. I wonder if it would be safe enough to just 
> forward it and have the neighbours perform RPF.
> 
> So, to conclude, how about saying that if no previous BSM has been 
> accepted (for the particular scope zone) and less than BS_Period has 
> elapsed since startup, then the RPF check should be skipped.
> 
> I believe this would greatly simplify the implementation (no unicast 
> BSMs, just a minor special case at startup). There is significant 
> complexity in securing unicast BSMs (e.g. Router Alerts or use of ttl 
> 255, verifying ttls and backwards compatibility) that would simply go away.

(Continue reading)

Group

gmane.ietf.pim.

Search Archive

Page

1 | 2 | 3 | 4 | 5 | 6 | 7 | 8

Articles in period: 74

April 2006

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane

Recent entries

pim WGLC for draft-ietf-pim-rfc4601-update-survey-report-00 (21 May 2013)
Trying to clean-up an SSM Errata Report (11 May 2013)
call for adoption: draft-zhou-pim-vrrp-01 (9 May 2013)
I-D Action: draft-ietf-pim-explicit-rpf-vector-00.txt (6 May 2013)
Biggest Fake Conference in Computer Science (27 Apr 2013)
I-D Action: draft-ietf-pim-rfc4601-update-survey-report-00.txt (24 Apr 2013)
Call for adoption: draft-asghar-pim-explicit-rpf-vector-01 (Mike McBri (7 Apr 2013)
Call for adoption: draft-asghar-pim-explicit-rpf-vector-01 (Mike McBri (5 Apr 2013)
call for adoption: draft-asghar-pim-explicit-rpf-vector-01 (5 Apr 2013)
call for adoption: draft-asghar-pim-explicit-rpf-vector-01 (4 Apr 2013)
call for adoption: draft-asghar-pim-explicit-rpf-vector-01 (4 Apr 2013)
In-Band Authentication Extension for PIM (31 Mar 2013)
Orlando meeting minutes (28 Mar 2013)
Request for presentation slides (6 Mar 2013)
problem related with flat network (6 Mar 2013)
Draft agenda for Orlando (1 Mar 2013)
I-D Action: draft-ietf-pim-drlb-02.txt (26 Feb 2013)
RV: New Version Notification for draft-contreras-multimob-multiple-ups (25 Feb 2013)
I-D Action: draft-ietf-pim-explicit-tracking-05.txt (25 Feb 2013)
multiple upstreams for igmp/mld proxy (25 Feb 2013)
Request for pim wg Orlando agenda items (20 Feb 2013)

Archives

29	May 2013
34	April 2013
13	March 2013
16	February 2013
17	January 2013
6	December 2012
9	November 2012
13	October 2012
11	September 2012
6	August 2012
11	July 2012
8	June 2012
19	May 2012
24	April 2012
41	March 2012
12	February 2012
12	January 2012
1	December 2011
13	November 2011
32	October 2011
38	September 2011
18	August 2011
15	July 2011
30	June 2011
25	May 2011
36	April 2011
22	March 2011
107	February 2011
17	January 2011
24	December 2010
14	November 2010
10	October 2010
3	September 2010
25	August 2010
11	July 2010
12	June 2010
29	May 2010
24	April 2010
12	March 2010
6	February 2010
2	January 2010
7	December 2009
13	November 2009
16	October 2009
2	September 2009
20	August 2009
22	July 2009
11	June 2009
1	May 2009
5	April 2009
14	March 2009
6	February 2009
7	January 2009
15	December 2008
4	November 2008
15	October 2008
21	September 2008
17	August 2008
41	July 2008
22	June 2008
23	May 2008
11	April 2008
4	March 2008
17	February 2008
30	January 2008
3	December 2007
13	November 2007
15	October 2007
52	September 2007
17	August 2007
17	July 2007
22	June 2007
23	May 2007
8	April 2007
8	March 2007
15	February 2007
24	January 2007
7	December 2006
20	November 2006
35	October 2006
3	September 2006
24	August 2006
34	July 2006
22	June 2006
20	May 2006
74	April 2006
33	March 2006
39	February 2006
38	January 2006
15	December 2005
122	November 2005
65	October 2005
5	September 2005
33	August 2005
9	July 2005
3	June 2005
42	May 2005
40	April 2005
27	March 2005
11	February 2005
28	January 2005
7	December 2004
44	November 2004
52	October 2004
40	September 2004
11	August 2004
20	July 2004
15	June 2004
32	May 2004
28	April 2004
39	March 2004
19	February 2004
21	January 2004
4	December 2003
18	November 2003
40	October 2003
25	September 2003
8	August 2003
16	July 2003
14	June 2003
58	May 2003
19	April 2003
76	March 2003
30	February 2003
7	January 2003
28	December 2002
8	November 2002
25	October 2002
33	September 2002
18	August 2002
33	July 2002
26	June 2002
41	May 2002
27	April 2002
1	October 2001

Design

Zawodny | Right Menu | Left Menu

Your Own Design

Paste the URL of your CSS below. Download CSS template