draft-ietf-pim-sm-v2-new-11.txt

xorp源码hg

The function MRIB.next_hop( S ) returns an address of the next-hop PIM
neighbor toward the host S, as indicated by the current MRIB.  If S is
directly adjacent, then MRIB.next_hop( S ) returns NULL.  At the RP for
G, MRIB.next_hop( RP(G)) returns NULL.

The function NBR( I, A ) uses information gathered through PIM Hello
messages to map the IP address A of a directly connected PIM neighbor
router on interface I to the primary IP address of the same router
(Section 4.3.4). The primary IP address of a neighbor is the address
that it uses as the source of its PIM Hello messages. Note that a



Fenner/Handley/Holbrook/Kouvelas               Section 4.1.6.  [Page 25]

INTERNET-DRAFT             Expires: April 2005              October 2004


neighbor's IP address may be non-unique within the PIM neighbor database
due to scope issues. The address must however be unique amongst the
addresses of all the PIM neighbors on a specific interface.

I_Am_Assert_Loser(S, G, I) is true if the Assert state machine (in
Section 4.6.1) for (S,G) on Interface I is in "I am Assert Loser" state.

I_Am_Assert_Loser(*, G, I) is true if the Assert state machine (in
Section 4.6.2) for (*,G) on Interface I is in "I am Assert Loser" state.

4.2.  Data Packet Forwarding Rules

The PIM-SM packet forwarding rules are defined below in pseudocode.

     iif is the incoming interface of the packet.
     S is the source address of the packet.
     G is the destination address of the packet (group address).
     RP is the address of the Rendezvous Point for this group.
     RPF_interface(S) is the interface the MRIB indicates would be used
     to route packets to S.
     RPF_interface(RP) is the interface the MRIB indicates would be used
     to route packets to RP, except at the RP when it is the
     decapsulation interface (the "virtual" interface on which register
     packets are received).

First, we restart (or start) the Keepalive Timer if the source is on a
directly connected subnet.

Second, we check to see if the SPTbit should be set because we've now
switched from the RP tree to the SPT.

Next we check to see whether the packet should be accepted based on TIB
state and the interface that the packet arrived on.

If the packet should be forwarded using (S,G) state, we then build an
outgoing interface list for the packet.  If this list is not empty, then
we restart the (S,G) state Keepalive Timer.

If the packet should be forwarded using (*,*,RP) or (*,G) state, then we
just build an outgoing interface list for the packet. We also check if
we should initiate a switch to start receiving this source on a shortest
path tree.

Finally we remove the incoming interface from the outgoing interface
list we've created, and if the resulting outgoing interface list is not
empty, we forward the packet out of those interfaces.





Fenner/Handley/Holbrook/Kouvelas                 Section 4.2.  [Page 26]

INTERNET-DRAFT             Expires: April 2005              October 2004


On receipt of data from S to G on interface iif:
 if( DirectlyConnected(S) == TRUE AND iif == RPF_interface(S) ) {
      set KeepaliveTimer(S,G) to Keepalive_Period
      # Note: a register state transition or UpstreamJPState(S,G)
      # transition may happen as a result of restarting
      # KeepaliveTimer, and must be dealt with here.
 }


 if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined AND      |
    inherited_olist(S,G) != NULL ) {                                     |
        set KeepaliveTimer(S,G) to Keepalive_Period                      |
 }                                                                       |

 Update_SPTbit(S,G,iif)
 oiflist = NULL

 if( iif == RPF_interface(S) AND SPTbit(S,G) == TRUE ) {                 |
    oiflist = inherited_olist(S,G)
 } else if( iif == RPF_interface(RP(G)) AND SPTbit(S,G) == FALSE) {
   oiflist = inherited_olist(S,G,rpt)
   CheckSwitchToSpt(S,G)
 } else {
    # Note: RPF check failed
    # A transition in an Assert FSM, may cause an Assert(S,G)            |
    # or Assert(*,G) message to be sent out interface iif.               |
    # See section 4.6 for details.                                       |
    if ( SPTbit(S,G) == TRUE AND iif is in inherited_olist(S,G) ) {
       send Assert(S,G) on iif
    } else if ( SPTbit(S,G) == FALSE AND
                iif is in inherited_olist(S,G,rpt) {
       send Assert(*,G) on iif
    }
 }

 oiflist = oiflist (-) iif
 forward packet on all interfaces in oiflist

This pseudocode employs several "macro" definitions:

DirectlyConnected(S) is TRUE if the source S is on any subnet that is
directly connected to this router (or for packets originating on this
router).

inherited_olist(S,G) and inherited_olist(S,G,rpt) are defined in Section
4.1.





Fenner/Handley/Holbrook/Kouvelas                 Section 4.2.  [Page 27]

INTERNET-DRAFT             Expires: April 2005              October 2004


Basically inherited_olist(S,G) is the outgoing interface list for
packets forwarded on (S,G) state taking into account (*,*,RP) state,
(*,G) state, asserts, etc.

inherited_olist(S,G,rpt) is the outgoing interface for packets forwarded
on (*,*,RP) or (*,G) state taking into account (S,G,rpt) prune state,
and asserts, etc.

Update_SPTbit(S,G,iif) is defined in Section 4.2.2.

CheckSwitchToSpt(S,G) is defined in Section 4.2.1.

UpstreamJPState(S,G) is the state of the finite state machine in Section
4.5.7.

Keepalive_Period is defined in Section 4.10.

Data triggered PIM-Assert messages sent from the above forwarding code
should be rate-limited in a implementation-dependent manner.


4.2.1.  Last-hop Switchover to the SPT

In Sparse-Mode PIM, last-hop routers join the shared tree towards the
RP. Once traffic from sources to joined groups arrives at a last-hop
router it has the option of switching to receive the traffic on a
shortest path tree (SPT).

The decision for a router to switch to the SPT is controlled as follows:


     void
     CheckSwitchToSpt(S,G) {
       if ( ( pim_include(*,G) (-) pim_exclude(S,G)
              (+) pim_include(S,G) != NULL )
            AND SwitchToSptDesired(S,G) ) {
              # Note: Restarting the KAT will result in the SPT switch
              restart KeepaliveTimer(S,G);
       }
     }


SwitchToSptDesired(S,G) is a policy function that is implementation
defined. An "infinite threshold" policy can be implemented making
SwitchToSptDesired(S,G) return false all the time.  A "switch on first
packet" policy can be implemented by making SwitchToSptDesired(S,G)
return true once a single packet has been received for the source and
group.



Fenner/Handley/Holbrook/Kouvelas               Section 4.2.1.  [Page 28]

INTERNET-DRAFT             Expires: April 2005              October 2004


4.2.2.  Setting and Clearing the (S,G) SPTbit

The (S,G) SPTbit is used to distinguish whether to forward on
(*,*,RP)/(*,G) or on (S,G) state.  When switching from the RP tree to
the source tree, there is a transition period when data is arriving due
to upstream (*,*,RP)/(*,G) state while upstream (S,G) state is being
established during which time a router should continue to forward only
on (*,*,RP)/(*,G) state.  This prevents temporary black-holes that would
be caused by sending a Prune(S,G,rpt) before the upstream (S,G) state
has finished being established.

Thus, when a packet arrives, the (S,G) SPTbit is updated as follows:


     void
     Update_SPTbit(S,G,iif) {
       if ( iif == RPF_interface(S)
             AND JoinDesired(S,G) == TRUE
             AND ( DirectlyConnected(S) == TRUE
                   OR RPF_interface(S) != RPF_interface(RP(G))
                   OR inherited_olist(S,G,rpt) == NULL
                   OR ( ( RPF'(S,G) == RPF'(*,G) ) AND
                        ( RPF'(S,G) != NULL ) )
                   OR ( I_Am_Assert_Loser(S,G,iif) ) {
          Set SPTbit(S,G) to TRUE
       }
     }

Additionally a router can set SPTbit(S,G) to TRUE in other cases, such
as when it receives an Assert(S,G) on RPF_interface(S) (see Section
4.6.1).

JoinDesired(S,G) is defined in Section 4.5.7, and indicates whether we
have the appropriate (S,G) Join state to wish to send a Join(S,G)
upstream.

Basically Update_SPTbit will set the SPTbit if we have the appropriate
(S,G) join state and the packet arrived on the correct upstream
interface for S, and one or more of the following conditions applies:

1.   The source is directly connected, in which case the switch to the
     SPT is a no-op.

2.   The RPF interface to S is different from the RPF interface to the
     RP.  The packet arrived on RPF_interface(S), and so the SPT must
     have been completed.





Fenner/Handley/Holbrook/Kouvelas               Section 4.2.2.  [Page 29]

INTERNET-DRAFT             Expires: April 2005              October 2004


3.   No-one wants the packet on the RP tree.

4.   RPF'(S,G) == RPF'(*,G).  In this case the router will never be able
     to tell if the SPT has been completed, so it should just switch
     immediately.

In the case where the RPF interface is the same for the RP and for S,
but RPF'(S,G) and RPF'(*,G) differ, then we wait for an Assert(S,G)
which indicates that the upstream router with (S,G) state believes the
SPT has been completed.  However item (3) above is needed because there
may not be any (*,G) state to trigger an Assert(S,G) to happen.

The SPTbit is cleared in the (S,G) upstream state machine (see Section
4.5.7) when JoinDesired(S,G) becomes FALSE.


4.3.  Designated Routers (DR) and Hello Messages

A shared-media LAN like Ethernet may have multiple PIM-SM routers
connected to it. A single one of these routers, the DR, will act on
behalf of directly connected hosts with respect to the PIM-SM protocol.
Because the distinction between LANs and point-to-point interfaces can
sometimes be blurred, and because routers may also have multicast host
functionality, the PIM-SM specification makes no distinction between the
two.  Thus DR election will happen on all interfaces, LAN or otherwise.

DR election is performed using Hello messages.  Hello messages are also
the way that option negotiation takes place in PIM, so that additional
functionality can be enabled, or parameters tuned.


4.3.1.  Sending Hello Messages

PIM Hello messages are sent periodically on each PIM-enabled interface.
They allow a router to learn about the neighboring PIM routers on each
interface.  Hello messages are also the mechanism used to elect a
Designated Router (DR), and to negotiate additional capabilities.  A
router must record the Hello information received from each PIM
neighbor.

Hello messages MUST be sent on all active interfaces, including physical
point-to-point links, and are multicast to the `ALL-PIM-ROUTERS' group
address (`224.0.0.13' for IPv4 and `ff02::d' for IPv6).

     We note that some implementations do not send Hello messages
     on point-to-point interfaces.  This is non-compliant behavior.
     A compliant PIM router MUST send Hello messages, even on
     point-to-point interfaces.



Fenner/Handley/Holbrook/Kouvelas               Section 4.3.1.  [Page 30]

INTERNET-DRAFT             Expires: April 2005              October 2004


A per interface Hello Timer (HT(I)) is used to trigger sending Hello
messages on each active interface.  When PIM is enabled on an interface
or a router first starts, the Hello Timer of that interface is set to a
random value between 0 and Triggered_Hello_Delay.  This prevents
synchronization of Hello messages if multiple routers are powered on
simultaneously.  After the initial randomized interval, Hello messages
must be sent every Hello_Period seconds.  The Hello Timer should not be
reset except when it expires.

Note that neighbors will not accept Join/Prune or Assert messages from a
router unless they have first heard a Hello message from that router.
Thus if a router needs to send a Join/Prune or Assert message on an
interface on which it has not yet sent a Hello message with the
currently configured IP address, then it MUST immediately send the
relevant Hello message without waiting for the Hello Timer to expire,
followed by the Join/Prune or Assert message.

The DR_Priority Option allows a network administrator to give preference
to a particular router in the DR election process by giving it a
numerically larger DR Priority.  The DR_Priority Option SHOULD be
included in every Hello message, even if no DR Priority is explicitly
configured on that interface.  This is necessary because priority-based
DR election is only enabled when all neighbors on an interface advertise
that they are capable of using the DR_Priority Option.  The default
priority is 1.

The Generation_Identifier (GenID) Option SHOULD be included in all Hello
messages.  The GenID option contains a randomly generated 32-bit value
that is regenerated each time PIM forwarding is started or restarted on
the interface, including when the router itself restarts.  When a Hello
message with a new GenID is received from a neighbor, any old Hello
information about that neighbor SHOULD be discarded and superseded by
the information from the new Hello message.  This may cause a new DR to
be chosen on that interface.

The LAN Prune Delay Option SHOULD be included in all Hello messages sent
on multi-access LANs. This option advertises a router's capability to
use values other than the default for the Propagation_Delay and
Override_Interval which affect the setting of the Prune-Pending,
Upstream Join and Override Timers (defined in Section 4.10).

The Interface_Address_List Option advertises all the secondary addresses
associated with the source interface