rfc2362.txt

RFC 的详细文档！

   for initiating and maintaining an SP-tree. Even when (*,G) and (S,G)
   overlap, both states are needed to trigger the source-specific
   Join/Prune messages.  (S,G) state is kept alive by data packets
   arriving from that source. A timer, Entry-timer, is set for the (S,G)



Estrin, et. al.               Experimental                      [Page 5]

RFC 2362                         PIM-SM                        June 1998


   entry and this timer is restarted whenever data packets for (S,G) are
   forwarded out at least one oif, or Registers are sent.  When the
   Entry-timer expires, the state is deleted. The last-hop router is the
   router that delivers the packets to their ultimate end-system
   destination.  This is the router that monitors if there is group
   membership and joins or prunes the appropriate distribution trees in
   response.  In general the last-hop router is the Designated Router
   (DR) for the LAN. However, under various conditions described later,
   a parallel router connected to the same LAN may take over as the
   last-hop router in place of the DR.

   Only the RP and routers with local members can initiate switching to
   the SP-tree; intermediate routers do not. Consequently, last-hop
   routers create (S,G) state in response to data packets from the
   source, S; whereas intermediate routers only create (S,G) state in
   response to Join/Prune messages from downstream that have S in the
   Join list.

   The (S,G) entry is initialized with the SPT-bit cleared, indicating
   that the shortest path tree branch from S has not yet been setup
   completely, and the router can still accept packets from S that
   arrive on the (*,G) entry's indicated incoming interface (iif). Each
   PIM multicast entry has an associated incoming interface on which
   packets are expected to arrive.

   When a router with a (S,G) entry and a cleared SPT-bit starts to
   receive packets from the new source S on the iif for the (S,G) entry,
   and that iif differs from the (*,G) entry's iif, the router sets the
   SPT-bit, and sends a Join/Prune message towards the RP, indicating
   that the router no longer wants to receive packets from S via the
   shared RP-tree. The Join/Prune message sent towards the RP includes S
   in the prune list, with the RPT-bit set indicating that S's packets
   must not be forwarded down this branch of the shared tree. If the
   router receiving the Join/Prune message has (S,G) state (with or
   without the route entry's RPT-bit flag set), it deletes the arriving
   interface from the (S,G) oif list.  If the router has only (*,G)
   state, it creates an entry with the RPT-bit flag set to 1. For
   brevity we refer to an (S,G) entry that has the RPT-bit flag set to 1
   as an (S,G)RPT-bit entry. This notational distinction is useful to
   point out the different actions taken for (S,G) entries depending on
   the setting of the RPT-bit flag. Note that a router can have no more
   than one active (S,G) entry for any particular S and G, at any
   particular time; whether the RPT-bit flag is set or not. In other
   words, a router never has both an (S,G) and an (S,G)RPT-bit entry for
   the same S and G at the same time. The Join/Prune message payload
   contains Multicast-Address=G, Join=NULL, Prune=S,RPT-bit.





Estrin, et. al.               Experimental                      [Page 6]

RFC 2362                         PIM-SM                        June 1998


   A new receiver may join an existing RP-tree on which source-specific
   prune state has been established (e.g., because downstream receivers
   have switched to SP-trees). In this case the prune state must be
   eradicated upstream of the new receiver to bring all sources' data
   packets down to the new receiver. Therefore, when a (*,G) Join
   arrives at a router that has any (Si,G)RPT-bit entries (i.e., entries
   that cause the router to send source-specific prunes toward the RP),
   these entries must be updated upstream of the router so as to bring
   all sources' packets down to the new member. To accomplish this, each
   router that receives a (*,G) Join/Prune message updates all existing
   (S,G)RPT-bit entries. The router may also trigger a (*,G) Join/Prune
   message upstream to cause the same updating of RPT-bit settings
   upstream and pull down all active sources' packets. If the arriving
   (*,G) join has some sources included in its prune list, then the
   corresponding (S,G)RPT-bit entries are left unchanged (i.e., the
   RPT-bit remains set and no oif is added).

2.5 Steady state maintenance of distribution tree (i.e., router state)}

   In the steady state each router sends periodic Join/Prune messages
   for each active PIM route entry; the Join/Prune messages are sent to
   the neighbor indicated in the corresponding entry. These messages are
   sent periodically to capture state, topology, and membership changes.
   A Join/Prune message is also sent on an event-triggered basis each
   time a new route entry is established for some new source (note that
   some damping function may be applied, e.g., a short delay to allow
   for merging of new Join information). Join/Prune messages do not
   elicit any form of explicit acknowledgment; routers recover from lost
   packets using the periodic refresh mechanism.

2.6 Obtaining RP information

   To obtain the RP information, all routers within a PIM domain collect
   Bootstrap messages. Bootstrap messages are sent hop-by-hop within the
   domain; the domain's bootstrap router (BSR) is responsible for
   originating the Bootstrap messages. Bootstrap messages are used to
   carry out a dynamic BSR election when needed and to distribute RP
   information in steady state.

   A domain in this context is a contiguous set of routers that all
   implement PIM and are configured to operate within a common boundary
   defined by PIM Multicast Border Routers (PMBRs). PMBRs connect each
   PIM domain to the rest of the internet.

   Routers use a set of available RPs (called the RP-Set) distributed in
   Bootstrap messages to get the proper Group to RP mapping. The
   following paragraphs summarize the mechanism; details of the
   mechanism may be found in Sections 3.6 and Appendix 6.2. A (small)



Estrin, et. al.               Experimental                      [Page 7]

RFC 2362                         PIM-SM                        June 1998


   set of routers, within a domain, are configured as candidate BSRs
   and, through a simple election mechanism, a single BSR is selected
   for that domain. A set of routers within a domain are also configured
   as candidate RPs (C-RPs); typically these will be the same routers
   that are configured as C-BSRs.  Candidate RPs periodically unicast
   Candidate-RP-Advertisement messages (C-RP-Advs) to the BSR of that
   domain. C-RP-Advs include the address of the advertising C-RP, as
   well as an optional group address and a mask length field, indicating
   the group prefix(es) for which the candidacy is advertised. The BSR
   then includes a set of these Candidate-RPs (the RP-Set), along with
   the corresponding group prefixes, in Bootstrap messages it
   periodically originates.  Bootstrap messages are distributed hop-by-
   hop throughout the domain.

   Routers receive and store Bootstrap messages originated by the BSR.
   When a DR gets a membership indication from IGMP for (or a data
   packet from) a directly connected host, for a group for which it has
   no entry, the DR uses a hash function to map the group address to one
   of the C-RPs whose Group-prefix includes the group (see Section 3.7).
   The DR then sends a Join/Prune message towards (or unicasts Registers
   to) that RP.

   The Bootstrap message indicates liveness of the RPs included therein.
   If an RP is included in the message, then it is tagged as `up' at the
   routers; while RPs not included in the message are removed from the
   list of RPs over which the hash algorithm acts. Each router continues
   to use the contents of the most recently received Bootstrap message
   until it receives a new Bootstrap message.

   If a PIM domain partitions, each area separated from the old BSR will
   elect its own BSR, which will distribute an RP-Set containing RPs
   that are reachable within that partition. When the partition heals,
   another election will occur automatically and only one of the BSRs
   will continue to send out Bootstrap messages. As is expected at the
   time of a partition or healing, some disruption in packet delivery
   may occur. This time will be on the order of the region's round-trip
   time and the bootstrap router timeout value.

2.7 Interoperation with dense mode  protocols such as DVMRP

   In order to interoperate with networks that run dense-mode, broadcast
   and prune, protocols, such as DVMRP, all packets generated within a
   PIM-SM region must be pulled out to that region's PIM Multicast
   Border Routers (PMBRs) and injected (i.e., broadcast) into the DVMRP
   network. A PMBR is a router that sits at the boundary of a PIM-SM
   domain and interoperates with other types of multicast routers such
   as those that run DVMRP.  Generally a PMBR would speak both protocols
   and implement interoperability functions not required by regular PIM



Estrin, et. al.               Experimental                      [Page 8]

RFC 2362                         PIM-SM                        June 1998


   routers. To support interoperability, a special entry type, referred
   to as (*,*,RP), must be supported by all PIM routers.  For this
   reason we include details about (*,*,RP) entry handling in this
   general PIM specification.

   A data packet will match on a (*,*,RP) entry if there is no more
   specific entry (such as (S,G) or (*,G)) and the destination group
   address in the packet maps to the RP listed in the (*,*,RP) entry. In
   this sense, a (*,*,RP) entry represents an aggregation of all the
   groups that hash to that RP. PMBRs initialize (*,*,RP) state for each
   RP in the domain's RPset. The (*,*,RP) state causes the PMBRs to send
   (*,*,RP) Join/Prune messages toward each of the active RPs in the
   domain.  As a result distribution trees are built that carry all data
   packets originated within the PIM domain (and sent to the RPs) down
   to the PMBRs.

   PMBRs are also responsible for delivering externally-generated
   packets to routers within the PIM domain. To do so, PMBRs initially
   encapsulate externally-originated packets (i.e., received on DVMRP
   interfaces) in Register messages and unicast them to the
   corresponding RP within the PIM domain. The Register message has a
   bit indicating that it was originated by a border router and the RP
   caches the originating PMBR's address in the route entry so that
   duplicate Registers from other PMBRs can be declined with a
   Register-Stop message.

   All PIM routers must be capable of supporting (*,*,RP) state and
   interpreting associated Join/Prune messages. We describe the handling
   of (*,*,RP) entries and messages throughout this document; however,
   detailed PIM Multicast Border Router (PMBR) functions will be
   specified in a separate interoperability document (see directory,
   http://catarina.usc.edu/pim/interop/).

2.8 Multicast data packet processing

   Data packets are processed in a manner similar to other multicast
   schemes.  A router first performs a longest match on the source and
   group address in the data packet. A (S,G) entry is matched first if
   one exists; a (*,G) entry is matched otherwise. If neither state
   exists, then a (*,*,RP) entry match is attempted as follows: the
   router hashes on G to identify the RP for group G, and looks for a
   (*,*,RP) entry that has this RP address associated with it. If none
   of the above exists, then the packet is dropped. If a state is
   matched, the router compares the interface on which the packet
   arrived to the incoming interface field in the matched route entry.
   If the iif check fails the packet is dropped, otherwise the packet is
   forwarded to all interfaces listed in the outgoing interface list.




Estrin, et. al.               Experimental                      [Page 9]

RFC 2362                         PIM-SM                        June 1998


   Some special actions are needed to deliver packets continuously while
   switching from the shared to shortest-path tree. In particular, when
   a (S,G) entry is matched, incoming packets are forwarded as follows:

      1 If the SPT-bit is set, then:

           1 if the incoming interface is the same as a matching
             (S,G) iif, the packet is forwarded to the oif-list of
             (S,G).

           2 if the incoming interface is different than a matching
             (S,G) iif , the packet is discarded.

      2 If the SPT-bit is cleared, then:

           1 if the incoming interface is the same as a matching
             (S,G) iif, the packet is forwarded to the oif-list of
             (S,G). In addition, the SPT bit is set for that entry if
             the incoming interface differs from the incoming interface
             of the (*,G) or (*,*,RP) entry.

           2 if the incoming interface is different than a matching
             (S,G) iif, the incoming interface is tested against a
             matching (*,G) or (*,*,RP) entry. If the iif is the same as
             one of those, the packet is forwarded to the oif-list of
             the matching entry.

           3 Otherwise the iif does not match any entry for G and
             the packet is discarded.

   Data packets never trigger prunes.  However, data packets may trigger
   actions that in turn trigger prunes. For example, when router B in
   figure 3 decides to switch to SP-tree at step 3, it creates a (S,G)
   entry with SPT-bit set to 0. When data packets from S arrive at
   interface 2 of B, B sets the SPT-bit to 1 since the iif for (*,G) is
   different than that for (S,G). This triggers the sending of prunes
   towards the RP.