rfc2362.txt

中、英文RFC文档大全打包下载完全版 .

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


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 network
   layer 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
   packet. The router with the smallest numerical metric (with ties
   broken by highest address) will become the forwarder. All other





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


   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 network layer address), a
   timer (the Join/Prune-Suppression-timer) in the recipient's route
   entry may be started to suppress further Join/Prune messages. After
   this timer expires, the recipient triggers a Join/Prune message, and



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


   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 2362                         PIM-SM                        June 1998


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 network layer
   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 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 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 network layer 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.







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


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
   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.

   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
             flag cleared, and

           3 The oif list in the (S,G) entry is not null.