[Xorp-users] Change in RP vs change in next-hop for RP

Pavlin Radoslavov pavlin at icir.org
Tue Feb 13 10:52:57 PST 2007


>  Please see below..
> 
> pavlin>>   Specifically, where are the conditions addressed when the RP itself 
> pavlin>> changes for the (*,G) and (*,*,RP) state. Not the next hop changes, but 
> pavlin>> the RP changes when the group is active. Is the protocol designed to 
> pavlin>> handle this ?
> pavlin>> 
> pavlin>>From the perspective of transmitting the Join/Prune messages toward
> pavlin>the RP it is important to send the messages in the right direction
> pavlin>(i.e., next-hop router), and the downstream routers don't really
> pavlin>care about the particular RP address. In fact, if we ignore the PIM
> pavlin>Register mechanism, then the RP address doesn't even have to belong
> pavlin>to a real host, and this is exactly how Bidir-PIM works.
> pavlin>
> pavlin>That said, it is important to notice only if the next-hop router
> pavlin>toward the RP changes, regardless whether the change is because the
> pavlin>underlying RPF information changed or because the RP address was
> pavlin>changed. In other words, the RP change will translate eventually in
> pavlin>same handling as the RPF(*,G) change.
> pavlin>
> pavlin>Note that even though the (*,G) Join message conains the RP address
> pavlin>for group G, there is no need to trigger immediately a new (*,G)
> pavlin>Join message with the new RP address if the next-hop router hasn't
> pavlin>changed. The new RP address will be included with the next periodic
> pavlin>(*,G) Join message.
> 
> Is this the current handling in XORP ? Can you point to the section of the 
> code where I can see this happen ? Thanks for your help in advance

Yes. The relevant code for handling various RPF-related events is in
pim/pim_mre_rpf.cc. Note that each PimMre::recompute_FOO() method is
a single action (per multicast routing entry).

However, handling the event "RP changed" might require a number of
actions (even per same multicast routing entry).
FYI, those actions are listed in human-readable format (in the order
they are executed) inside pim/docs/pim_track_state_name.txt:

Input = INPUT_STATE_RP_CHANGED
        OUTPUT_STATE_MRIB_RP_RP                                    (*,*,RP)
        OUTPUT_STATE_NBR_MRIB_NEXT_HOP_RP_RP                       (*,*,RP)
        OUTPUT_STATE_RP_WC                                            (*,G)
        OUTPUT_STATE_MRIB_RP_WC                                       (*,G)
        OUTPUT_STATE_IS_JOIN_DESIRED_WC                               (*,G)
        OUTPUT_STATE_NBR_MRIB_NEXT_HOP_RP_WC                          (*,G)
        OUTPUT_STATE_RPFP_NBR_WC_NOT_ASSERT                           (*,G)
        OUTPUT_STATE_COULD_ASSERT_WC                                  (*,G)
        OUTPUT_STATE_ASSERT_TRACKING_DESIRED_WC                       (*,G)
        OUTPUT_STATE_MY_ASSERT_METRIC_WC                              (*,G)
        OUTPUT_STATE_RP_SG                                            (S,G)
        OUTPUT_STATE_RP_SG_RPT                                    (S,G,rpt)
        OUTPUT_STATE_MRIB_RP_SG                                       (S,G)
        OUTPUT_STATE_MRIB_RP_SG_RPT                               (S,G,rpt)
        OUTPUT_STATE_INHERITED_OLIST_SG_RPT                       (S,G,rpt)
        OUTPUT_STATE_IS_JOIN_DESIRED_SG                               (S,G)
        OUTPUT_STATE_IS_RPT_JOIN_DESIRED_G                        (S,G,rpt)
        OUTPUT_STATE_IS_PRUNE_DESIRED_SG_RPT                      (S,G,rpt)
        OUTPUT_STATE_IS_PRUNE_DESIRED_SG_RPT_SG                       (S,G)
        OUTPUT_STATE_IS_COULD_REGISTER_SG                             (S,G)
        OUTPUT_STATE_ASSERT_TRACKING_DESIRED_SG                       (S,G)
        OUTPUT_STATE_COULD_ASSERT_SG                                  (S,G)
        OUTPUT_STATE_MY_ASSERT_METRIC_SG                              (S,G)
        OUTPUT_STATE_RPFP_NBR_SG_RPT                              (S,G,rpt)
        OUTPUT_STATE_RPFP_NBR_SG_RPT_SG                               (S,G)
        OUTPUT_STATE_SET_KEEPALIVE_TIMER_SG                           (S,G)
        OUTPUT_STATE_RP_MFC                                           (MFC)
        OUTPUT_STATE_IIF_OLIST_MFC                                    (MFC)
        OUTPUT_STATE_MONITORING_SWITCH_TO_SPT_DESIRED_MFC             (MFC)
        OUTPUT_STATE_UPDATE_SPTBIT_MFC                                (MFC)

If you are curious about the mapping between OUTPUT_STATE_FOO and
the corresponding PimMre C++ method, please check (both) methods
PimMreAction::perform_action() inside pim/pim_mre_track_state.cc.
FYI, the above list was generated automatically by the event
dependency tracking mechanism implemented in XORP.

Regards,
Pavlin



More information about the Xorp-users mailing list