rfc2117.txt

RFC 的详细文档！

                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



Estrin, et. al.               Experimental                     [Page 10]

RFC 2117                         PIM-SM                       June 1997


   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.

2.9 Operation over Multi-access Networks

   This section describes a few additional protocol mechanisms needed to
   operate PIM over multi-access networks: Designated Router election,
   Assert messages to resolve parallel paths, and the Join/Prune-
   Suppression-Timer to suppress redundant Joins on multi-access
   networks.

   * Designated router election

   When there are multiple routers connected to a multi-access network,
   one of them must be chosen to operate as the designated router (DR)
   at any point in time.  The DR is responsible for sending triggered
   Join/Prune and Register messages toward the RP.

   A simple designated router (DR) election mechanism is used for both
   SM and traditional IP multicast routing.  Neighboring routers send
   Hello messages to each other. The sender with the largest IP address
   assumes the role of DR. Each router connected to the multi-access LAN
   sends the Hellos periodically in order to adapt to changes in router
   status.

   * Parallel paths to a source or the RP--Assert process

   If a router receives a multicast datagram on a multi-access LAN from
   a source whose corresponding (S,G) outgoing interface list includes
   the interface to that LAN, the packet must be a duplicate.  In this
   case a single forwarder must be elected.  Using Assert messages
   addressed to `224.0.0.13' (ALL-PIM-ROUTERS group) on the LAN,
   upstream routers can resolve which one will act as the forwarder.
   Downstream routers listen to the Asserts so they know which one was
   elected, and therefore where to send subsequent Joins. Typically this
   is the same as the downstream router's RPF (Reverse Path Forwarding)
   neighbor; but there are circumstances where this might not be the
   case, e.g., when using multiple unicast routing protocols on that
   LAN. The RPF neighbor for a particular source (or RP) is the next-hop
   router to which packets are forwarded en route to that source (or
   RP); and therefore is considered a good path via which to accept
   packets from that source.

   The upstream router elected is the one that has the shortest distance
   to the source. Therefore, when a packet is received on an outgoing
   interface a router sends an Assert message on the multi-access LAN
   indicating what metric it uses to reach the source of the data



Estrin, et. al.               Experimental                     [Page 11]

RFC 2117                         PIM-SM                       June 1997


   packet.  The router with the smallest numerical metric (with ties
   broken by highest address) will become the forwarder. All other
   upstream routers will delete the interface from their outgoing
   interface list. The downstream routers also do the comparison in case
   the forwarder is different than the RPF neighbor.

   Associated with the metric is a metric preference value. This is
   provided to deal with the case where the upstream routers may run
   different unicast routing protocols. The numerically smaller metric
   preference is always preferred. The metric preference is treated as
   the high-order part of an assert metric comparison.  Therefore, a
   metric value can be compared with another metric value provided both
   metric preferences are the same.  A metric preference can be assigned
   per unicast routing protocol and needs to be consistent for all
   routers on the multi-access network.

   Asserts are also needed for (*,G) entries since an RP-Tree and an
   SP-Tree for the same group may both cross the same multi- access
   network. When an assert is sent for a (*,G) entry, the first bit in
   the metric preference (RPT-bit) is always set to 1 to indicate that
   this path corresponds to the RP tree, and that the match must be done
   on (*,G) if it exists. Furthermore, the RPT-bit is always cleared for
   metric preferences that refer to SP-tree entries; this causes an SP-
   tree path to always look better than an RP-tree path. When the SP-
   tree and RPtree cross the same LAN, this mechanism eliminates the
   duplicates that would otherwise be carried over the LAN.

   In case the packet, or the Assert message, matches  on  oif  for
   (*,*,RP) entry, a (*,G) entry is created, and asserts take place as
   if the matching state were (*,G).

   The DR may lose the (*,G) Assert process to another router on the LAN
   if there are multiple paths to the RP through the LAN.  From then on,
   the DR is no longer the last-hop router for local receivers and
   removes the LAN from its (*,G) oif list. The winning router becomes
   the last-hop router and is responsible for sending (*,G) join
   messages to the RP.

   * Join/Prune suppression

   Join/Prune suppression may be used on multi-access LANs to reduce
   duplicate control message overhead; it is not required for correct
   performance of the protocol. If a Join/Prune message arrives and
   matches on the incoming interface for an existing (S,G), (*,G), or
   (*,*,RP) route entry, and the Holdtime included in the Join/Prune
   message is greater than the recipient's own [Join/Prune-Holdtime]
   (with ties resolved in favor of the higher IP address), a timer (the
   Join/Prune-Suppression-timer) in the recipient's route entry may be



Estrin, et. al.               Experimental                     [Page 12]

RFC 2117                         PIM-SM                       June 1997


   started to suppress further Join/Prune messages.  After this timer
   expires, the recipient triggers a Join/Prune message, and resumes
   sending periodic Join/Prunes, for this entry. The Join/Prune-
   Suppression-timer should be restarted each time a Join/Prune message
   is received with a higher Holdtime.

2.10 Unicast Routing Changes

   When unicast routing changes, an RPF check is done on all active
   (S,G), (*,G) and (*,*,RP) entries, and all affected expected incoming
   interfaces are updated.  In particular, if the new incoming interface
   appears in the outgoing interface list, it is deleted from the
   outgoing interface list. The previous incoming interface may be added
   to the outgoing interface list by a subsequent Join/Prune from
   downstream.  Join/Prune messages received on the current incoming
   interface are ignored.  Join/Prune messages received on new
   interfaces or existing outgoing interfaces are not ignored. Other
   outgoing interfaces are left as is until they are explicitly pruned
   by downstream routers or are timed out due to lack of appropriate
   Join/Prune messages. If the router has a (S,G) entry with the SPT-bit
   set, and the updated iif(S,G) does not differ from iif(*,G) or
   iif(*,*,RP), then the router resets the SPT-bit.

   The router must send a Join/Prune message with S in the Join list out
   any new incoming interfaces to inform upstream routers that it
   expects multicast datagrams over the interface.  It may also send a
   Join/Prune message with S in the Prune list out the old incoming
   interface, if the link is operational, to inform upstream routers
   that this part of the distribution tree is going away.

2.11 PIM-SM for Inter-Domain Multicast

   Future documents will address the use of PIM-SM as a backbone inter-
   domain multicast routing protocol. Design choices center primarily
   around the distribution and usage of RP information for wide area,
   inter-domain groups.

2.12 Security

   All PIM control messages may use IPsec [6] to address security
   concerns.  Security mechanisms are likely to be enhanced in the near
   future.

3 Detailed Protocol Description

   This section describes the protocol operations from the perspective
   of an individual router implementation.  In particular, for each
   message type we describe how it is generated and processed.



Estrin, et. al.               Experimental                     [Page 13]

RFC 2117                         PIM-SM                       June 1997


3.1 Hello

   Hello messages are sent so neighboring routers can discover each
   other.

3.1.1 Sending Hellos

   Hello messages are sent periodically between PIM neighbors, every
   [Hello-Period] seconds.  This informs routers what interfaces have
   PIM neighbors.  Hello messages are multicast using address 224.0.0.13
   (ALL-PIM-ROUTERS group). The packet includes a Holdtime, set to
   [Hello-Holdtime], for neighbors to keep the information valid.
   Hellos are sent on all types of communication links.

3.1.2 Receiving Hellos

   When a router receives a Hello message, it stores the IP address for
   that neighbor, sets its Neighbor-timer for the Hello sender to the
   Holdtime included in the Hello, and determines the Designated Router
   (DR) for that interface.  The highest IP addressed system is elected
   DR. Each Hello received causes the DR's address to be updated.

   When a router that is the active DR receives a Hello from a new
   neighbor (i.e., from an IP address that is not yet in the DRs
   neighbor table), the DR unicasts its most recent RP-set information
   to the new neighbor.

3.1.3 Timing out neighbor entries

   A periodic process is run to time out PIM neighbors that have not
   sent Hellos. If the DR has gone down, a new DR is chosen by scanning
   all neighbors on the interface and selecting the new DR to be the one
   with the highest IP address. If an interface has gone down, the
   router may optionally time out all PIM neighbors associated with the
   interface.

3.2 Join/Prune

   Join/Prune messages are sent to join or prune a branch off of the
   multicast distribution tree. A single message contains both a join
   and prune list, either one of which may be null.  Each list contains
   a set of source addresses, indicating the source- specific trees or
   shared tree that the router wants to join or prune.

3.2.1 Sending Join/Prune Messages

   Join/Prune messages are merged such that a message sent to a
   particular upstream neighbor, N, includes all of the current joined



Estrin, et. al.               Experimental                     [Page 14]

RFC 2117                         PIM-SM                       June 1997


   and pruned sources that are reached via N; according to unicast
   routing Join/Prune messages are multicast to all routers on multi-
   access networks with the target address set to the next hop router
   towards S or RP. Join/Prune messages are sent every [Join/Prune-
   Period] seconds. In the future we will introduce mechanisms to rate-
   limit this control traffic on a hop by hop basis, in order to avoid
   excessive overhead on small links.  In addition, certain events cause
   triggered Join/Prune messages to be sent.

3.2.1.1 Periodic Join/Prune Messages

   A router sends a periodic Join/Prune message to each distinct RPF
   neighbor associated with each (S,G), (*,G) and (*,*,RP) entry.
   Join/Prune messages are only sent if the RPF neighbor is a PIM
   neighbor.  A periodic Join/Prune message sent to a particular RPF
   neighbor is constructed as follows:

   1    Each router determines the RP for a (*,G) entry by using
        the hash function described. The RP address (with RPT and
        WC bits set) is included in the join list of a periodic
        Join/Prune message under the following conditions:

        1    The Join/Prune message is being sent to the RPF
             neighbor toward the RP for an active (*,G) or (*,*,RP)
             entry, and

        2    The outgoing interface list in the (*,G) or (*,*,RP)
             entry is non-NULL, or the router is the DR on the same
             interface as the RPF neighbor.

   2    A particular source address, S, is included in the join
        list with the RPT and WC bits cleared under the following
        conditions:

        1    The Join/Prune message is being sent to the RPF
             neighbor toward S, and

        2    There exists an active (S,G) entry with the RPT-bit