[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