As per Relevance of the word multicast, we have this rfc below:
Network Working Group D.
Request for Comments: 2362
Obsoletes: 2117 D.
Category: Experimental
A.
D.
S.
M.
V.
C.
P.
L.
June 1998
Protocol Independent Multicast-Sparse Mode (PIM-SM):
Status of this
This memo defines an Experimental Protocol for the
community. It does not specify an Internet standard of any kind
Discussion and suggestions for improvement are requested
Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
Estrin, et. al. Experimental [Page 1]
RFC 2362 PIM-SM June 1998
1
This document describes a protocol for efficiently routing
multicast groups that may span wide-area (and inter-domain
internets. We refer to the approach as Protocol
Multicast--Sparse Mode (PIM-SM) because it is not dependent on
particular unicast routing protocol, and because it is designed
support sparse groups as defined in [1][2]. This document
the protocol details. For the motivation behind the design and
description of the architecture, see [1][2]. Section 2
PIM-SM operation. It describes the protocol from a
perspective, in particular, how the participating routers interact
create and maintain the multicast distribution tree. Section 3
describes PIM-SM operations from the perspective of a single
implementing the protocol; this section constitutes the main body
the protocol specification. It is organized according to PIM-
message type; for each message type we describe its contents,
generation, and its processing
Sections 3.8 and 3.9 summarize the timers and flags referred
throughout this document. Section 4 provides packet format details
The most significant functional changes since the January '95
involve the Rendezvous Point-related mechanisms, several
simplifications to the protocol, and removal of the PIM-DM
details to a separate document [3] (for clarity).
2 PIM-SM Protocol
In this section we provide an overview of the
components of PIM-SM
A router receives explicit Join/Prune messages from those
routers that have downstream group members. The router then
data packets addressed to a multicast group, G, only onto
interfaces on which explicit joins have been received. Note that
routers mentioned in this document are assumed to be PIM-SM capable
unless otherwise specified
A Designated Router (DR) sends periodic Join/Prune messages toward
group-specific Rendezvous Point (RP) for each group for which it
active members. Each router along the path toward the RP builds
wildcard (any-source) state for the group and sends Join/
messages on toward the RP. We use the term route entry to refer
the state maintained in a router to represent the distribution tree
A route entry may include such fields as the source address,
group address, the incoming interface from which packets
accepted, the list of outgoing interfaces to which packets are sent
Estrin, et. al. Experimental [Page 2]
RFC 2362 PIM-SM June 1998
timers, flag bits, etc. The wildcard route entry's incoming
points toward the RP; the outgoing interfaces point to
neighboring downstream routers that have sent Join/Prune
toward the RP. This state creates a shared, RP-centered,
tree that reaches all group members. When a data source first
to a group, its DR unicasts Register messages to the RP with
source's data packets encapsulated within. If the data rate is high
the RP can send source-specific Join/Prune messages back towards
source and the source's data packets will follow the
forwarding state and travel unencapsulated to the RP. Whether
arrive encapsulated or natively, the RP forwards the source'
decapsulated data packets down the RP-centered distribution
toward group members. If the data rate warrants it, routers
local receivers can join a source-specific, shortest path
distribution tree, and prune this source's packets off of the
RP-centered tree. For low data rate sources, neither the RP,
last-hop routers need join a source-specific shortest path tree
data packets can be delivered via the shared, RP-tree
The following subsections describe SM operation in more detail,
particular, the control messages, and the actions they trigger
2.1 Local hosts joining a
In order to join a multicast group, G, a host conveys its
information through the Internet Group Management Protocol (IGMP),
specified in [4][5], (see figure 1). From this point on we refer
such a host as a receiver, R, (or member) of the group G
Note that all figures used in this section are for illustration
are not intended to be complete. For complete and detailed
action see Section 3.
[Figures are present only in the postscript version
Fig. 1 Example: how a receiver joins, and sets up shared
When a DR (e.g., router A in figure 1) gets a membership
from IGMP for a new group, G, the DR looks up the associated RP.
DR creates a wildcard multicast route entry for the group,
to here as a (*,G) entry; if there is no more specific match for
particular source, the packet will be forwarded according to
entry
The RP address is included in a special field in the route entry
is included in periodic upstream Join/Prune messages. The
interface is set to that included in the IGMP membership
for the new member. The incoming interface is set to the
used to send unicast packets to the RP
Estrin, et. al. Experimental [Page 3]
RFC 2362 PIM-SM June 1998
When there are no longer directly connected members for the group
IGMP notifies the DR. If the DR has neither local members
downstream receivers, the (*,G) state is deleted
2.2 Establishing the RP-rooted shared
Triggered by the (*,G) state, the DR creates a Join/Prune
with the RP address in its join list and the the wildcard bit (WC
bit) and RP-tree bit (RPT-bit) set to 1. The WC-bit indicates
any source may match and be forwarded according to this entry
there is no longer match; the RPT-bit indicates that this join
being sent up the shared, RP-tree. The prune list is left empty.
the RPT-bit is set to 1 it indicates that the join is associated
the shared RP-tree and therefore the Join/Prune message is
along the RP-tree. When the WC-bit is set to 1 it indicates that
address is an RP and the downstream receivers expect to
packets from all sources via this (shared tree) path. The term RPT
bit is used to refer to both the RPT-bit flags associated with
entries, and the RPT-bit included in each encoded address in
Join/Prune message
Each upstream router creates or updates its multicast route entry
(*,G) when it receives a Join/Prune with the RPT-bit and WC-bit set
The interface on which the Join/Prune message arrived is added to
list of outgoing interfaces (oifs) for (*,G). Based on this
each upstream router between the receiver and the RP sends
Join/Prune message in which the join list includes the RP. The
payload contains Multicast-Address=G, Join=RP,WC-bit,RPT-bit
Prune=NULL
2.3 Hosts sending to a
When a host starts sending multicast data packets to a group
initially its DR must deliver each packet to the RP for
down the RP-tree (see figure 2). The sender's DR
encapsulates each data packet in a Register message and unicasts
to the RP for that group. The RP decapsulates each Register
and forwards the enclosed data packet natively to downstream
on the shared RP-tree
[Figures are present only in the postscript version
Fig. 2 Example: a host sending to a
If the data rate of the source warrants the use of a source-
shortest path tree (SPT), the RP may construct a new multicast
entry that is specific to the source, hereafter referred to as (S,G
state, and send periodic Join/Prune messages toward the source.
that over time, the rules for when to switch can be modified
Estrin, et. al. Experimental [Page 4]
RFC 2362 PIM-SM June 1998
global coordination. When and if the RP does switch to the SPT,
routers between the source and the RP build and maintain (S,G)
in response to these messages and send (S,G) messages upstream
the source
The source's DR must stop encapsulating data packets in
when (and so long as) it receives Register-Stop messages from the RP
The RP triggers Register-Stop messages in response to Registers,
the RP has no downstream receivers for the group (or for
particular source), or if the RP has already joined the (S,G)
and is receiving the data packets natively. Each source's
maintains, per (S,G), a Register-Suppression-timer. The Register
Suppression-timer is started by the Register-Stop message;
expiration, the source's DR resumes sending data packets to the RP
encapsulated in Register messages
2.4 Switching from shared tree (RP-tree) to shortest path
(SP-tree)}
A router with directly-connected members first joins the shared RP
tree. The router can switch to a source's shortest path tree (SP
tree) after receiving packets from that source over the shared RP
tree. The recommended policy is to initiate the switch to the SP-
after receiving a significant number of data packets during
specified time interval from a particular source. To realize
policy the router can monitor data packets from sources for which
has no source-specific multicast route entry and initiate such
entry when the data rate exceeds the configured threshold. As
in figure 3, router `A' initiates a (S,G) state
[Figures are present only in the postscript version
Fig. 3 Example: Switching from shared tree to shortest path
When a (S,G) entry is activated (and periodically so long as
state exists), a Join/Prune message is sent upstream towards
source, S, with S in the join list. The payload contains Multicast
Address=G, Join=S, Prune=NULL. When the (S,G) entry is created,
outgoing interface list is copied from (*,G), i.e., all local
tree branches are replicated in the new shortest path tree. In
way when a data packet from S arrives and matches on this entry,
receivers will continue to receive the source's packets along
path. (In more complicated scenarios, other entries in the
have to be considered, as described in Section 3). Note that (S,G
state must be maintained in each last-hop router that is
for initiating and maintaining an SP-tree. Even when (*,G) and (S,G
overlap, both states are needed to trigger the source-
Join/Prune messages. (S,G) state is kept alive by data
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)
forwarded out at least one oif, or Registers are sent. When
Entry-timer expires, the state is deleted. The last-hop router is
router that delivers the packets to their ultimate end-
destination. This is the router that monitors if there is
membership and joins or prunes the appropriate distribution trees
response. In general the last-hop router is the Designated
(DR) for the LAN. However, under various conditions described later
a parallel router connected to the same LAN may take over as
last-hop router in place of the DR
Only the RP and routers with local members can initiate switching
the SP-tree; intermediate routers do not. Consequently, last-
routers create (S,G) state in response to data packets from
source, S; whereas intermediate routers only create (S,G) state
response to Join/Prune messages from downstream that have S in
Join list
The (S,G) entry is initialized with the SPT-bit cleared,
that the shortest path tree branch from S has not yet been
completely, and the router can still accept packets from S
arrive on the (*,G) entry's indicated incoming interface (iif).
PIM multicast entry has an associated incoming interface on
packets are expected to arrive
When a router with a (S,G) entry and a cleared SPT-bit starts
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
SPT-bit, and sends a Join/Prune message towards the RP,
that the router no longer wants to receive packets from S via
shared RP-tree. The Join/Prune message sent towards the RP includes
in the prune list, with the RPT-bit set indicating that S's
must not be forwarded down this branch of the shared tree. If
router receiving the Join/Prune message has (S,G) state (with
without the route entry's RPT-bit flag set), it deletes the
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.
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
point out the different actions taken for (S,G) entries depending
the setting of the RPT-bit flag. Note that a router can have no
than one active (S,G) entry for any particular S and G, at
particular time; whether the RPT-bit flag is set or not. In
words, a router never has both an (S,G) and an (S,G)RPT-bit entry
the same S and G at the same time. The Join/Prune message
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-
prune state has been established (e.g., because downstream
have switched to SP-trees). In this case the prune state must
eradicated upstream of the new receiver to bring all sources'
packets down to the new receiver. Therefore, when a (*,G)
arrives at a router that has any (Si,G)RPT-bit entries (i.e.,
that cause the router to send source-specific prunes toward the RP),
these entries must be updated upstream of the router so as to
all sources' packets down to the new member. To accomplish this,
router that receives a (*,G) Join/Prune message updates all
(S,G)RPT-bit entries. The router may also trigger a (*,G) Join/
message upstream to cause the same updating of RPT-bit
upstream and pull down all active sources' packets. If the
(*,G) join has some sources included in its prune list, then
corresponding (S,G)RPT-bit entries are left unchanged (i.e.,
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
for each active PIM route entry; the Join/Prune messages are sent
the neighbor indicated in the corresponding entry. These messages
sent periodically to capture state, topology, and membership changes
A Join/Prune message is also sent on an event-triggered basis
time a new route entry is established for some new source (note
some damping function may be applied, e.g., a short delay to
for merging of new Join information). Join/Prune messages do
elicit any form of explicit acknowledgment; routers recover from
packets using the periodic refresh mechanism
2.6 Obtaining RP
To obtain the RP information, all routers within a PIM domain
Bootstrap messages. Bootstrap messages are sent hop-by-hop within
domain; the domain's bootstrap router (BSR) is responsible
originating the Bootstrap messages. Bootstrap messages are used
carry out a dynamic BSR election when needed and to distribute
information in steady state
A domain in this context is a contiguous set of routers that
implement PIM and are configured to operate within a common
defined by PIM Multicast Border Routers (PMBRs). PMBRs connect
PIM domain to the rest of the internet
Routers use a set of available RPs (called the RP-Set) distributed
Bootstrap messages to get the proper Group to RP mapping.
following paragraphs summarize the mechanism; details of
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
and, through a simple election mechanism, a single BSR is
for that domain. A set of routers within a domain are also
as candidate RPs (C-RPs); typically these will be the same
that are configured as C-BSRs. Candidate RPs periodically
Candidate-RP-Advertisement messages (C-RP-Advs) to the BSR of
domain. C-RP-Advs include the address of the advertising C-RP,
well as an optional group address and a mask length field,
the group prefix(es) for which the candidacy is advertised. The
then includes a set of these Candidate-RPs (the RP-Set), along
the corresponding group prefixes, in Bootstrap messages
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
packet from) a directly connected host, for a group for which it
no entry, the DR uses a hash function to map the group address to
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
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
routers; while RPs not included in the message are removed from
list of RPs over which the hash algorithm acts. Each router
to use the contents of the most recently received Bootstrap
until it receives a new Bootstrap message
If a PIM domain partitions, each area separated from the old BSR
elect its own BSR, which will distribute an RP-Set containing
that are reachable within that partition. When the partition heals
another election will occur automatically and only one of the
will continue to send out Bootstrap messages. As is expected at
time of a partition or healing, some disruption in packet
may occur. This time will be on the order of the region's round-
time and the bootstrap router timeout value
2.7 Interoperation with dense mode protocols such as
In order to interoperate with networks that run dense-mode,
and prune, protocols, such as DVMRP, all packets generated within
PIM-SM region must be pulled out to that region's PIM
Border Routers (PMBRs) and injected (i.e., broadcast) into the
network. A PMBR is a router that sits at the boundary of a PIM-
domain and interoperates with other types of multicast routers
as those that run DVMRP. Generally a PMBR would speak both
and implement interoperability functions not required by regular
Estrin, et. al. Experimental [Page 8]
RFC 2362 PIM-SM June 1998
routers. To support interoperability, a special entry type,
to as (*,*,RP), must be supported by all PIM routers. For
reason we include details about (*,*,RP) entry handling in
general PIM specification
A data packet will match on a (*,*,RP) entry if there is no
specific entry (such as (S,G) or (*,G)) and the destination
address in the packet maps to the RP listed in the (*,*,RP) entry.
this sense, a (*,*,RP) entry represents an aggregation of all
groups that hash to that RP. PMBRs initialize (*,*,RP) state for
RP in the domain's RPset. The (*,*,RP) state causes the PMBRs to
(*,*,RP) Join/Prune messages toward each of the active RPs in
domain. As a result distribution trees are built that carry all
packets originated within the PIM domain (and sent to the RPs)
to the PMBRs
PMBRs are also responsible for delivering externally-
packets to routers within the PIM domain. To do so, PMBRs
encapsulate externally-originated packets (i.e., received on
interfaces) in Register messages and unicast them to
corresponding RP within the PIM domain. The Register message has
bit indicating that it was originated by a border router and the
caches the originating PMBR's address in the route entry so
duplicate Registers from other PMBRs can be declined with
Register-Stop message
All PIM routers must be capable of supporting (*,*,RP) state
interpreting associated Join/Prune messages. We describe the
of (*,*,RP) entries and messages throughout this document; however
detailed PIM Multicast Border Router (PMBR) functions will
specified in a separate interoperability document (see directory
http://catarina.usc.edu/pim/interop/).
2.8 Multicast data packet
Data packets are processed in a manner similar to other
schemes. A router first performs a longest match on the source
group address in the data packet. A (S,G) entry is matched first
one exists; a (*,G) entry is matched otherwise. If neither
exists, then a (*,*,RP) entry match is attempted as follows:
router hashes on G to identify the RP for group G, and looks for
(*,*,RP) entry that has this RP address associated with it. If
of the above exists, then the packet is dropped. If a state
matched, the router compares the interface on which the
arrived to the incoming interface field in the matched route entry
If the iif check fails the packet is dropped, otherwise the packet
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
switching from the shared to shortest-path tree. In particular,
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
(S,G) iif, the packet is forwarded to the oif-list
(S,G).
2 if the incoming interface is different than a
(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
(S,G) iif, the packet is forwarded to the oif-list
(S,G). In addition, the SPT bit is set for that entry
the incoming interface differs from the incoming
of the (*,G) or (*,*,RP) entry
2 if the incoming interface is different than a
(S,G) iif, the incoming interface is tested against
matching (*,G) or (*,*,RP) entry. If the iif is the same
one of those, the packet is forwarded to the oif-list
the matching entry
3 Otherwise the iif does not match any entry for G
the packet is discarded
Data packets never trigger prunes. However, data packets may
actions that in turn trigger prunes. For example, when router B
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
interface 2 of B, B sets the SPT-bit to 1 since the iif for (*,G)
different than that for (S,G). This triggers the sending of
towards the RP
Estrin, et. al. Experimental [Page 10]
RFC 2362 PIM-SM June 1998
2.9 Operation over Multi-access
This section describes a few additional protocol mechanisms needed
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-
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
Join/Prune and Register messages toward the RP
A simple designated router (DR) election mechanism is used for
SM and traditional IP multicast routing. Neighboring routers
Hello messages to each other. The sender with the largest
layer address assumes the role of DR. Each router connected to
multi-access LAN sends the Hellos periodically in order to adapt
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
a source whose corresponding (S,G) outgoing interface list
the interface to that LAN, the packet must be a duplicate. In
case a single forwarder must be elected. Using Assert
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
elected, and therefore where to send subsequent Joins. Typically
is the same as the downstream router's RPF (Reverse Path Forwarding
neighbor; but there are circumstances where this might not be
case, e.g., when using multiple unicast routing protocols on
LAN. The RPF neighbor for a particular source (or RP) is the next-
router to which packets are forwarded en route to that source (
RP); and therefore is considered a good path via which to
packets from that source
The upstream router elected is the one that has the shortest
to the source. Therefore, when a packet is received on an
interface a router sends an Assert message on the multi-access
indicating what metric it uses to reach the source of the
packet. The router with the smallest numerical metric (with
broken by highest address) will become the forwarder. All
Estrin, et. al. Experimental [Page 11]
RFC 2362 PIM-SM June 1998
upstream routers will delete the interface from their
interface list. The downstream routers also do the comparison in
the forwarder is different than the RPF neighbor
Associated with the metric is a metric preference value. This
provided to deal with the case where the upstream routers may
different unicast routing protocols. The numerically smaller
preference is always preferred. The metric preference is treated
the high-order part of an assert metric comparison. Therefore,
metric value can be compared with another metric value provided
metric preferences are the same. A metric preference can be
per unicast routing protocol and needs to be consistent for
routers on the multi-access network
Asserts are also needed for (*,G) entries since an RP-Tree and
SP-Tree for the same group may both cross the same multi-
network. When an assert is sent for a (*,G) entry, the first bit
the metric preference (RPT-bit) is always set to 1 to indicate
this path corresponds to the RP tree, and that the match must be
on (*,G) if it exists. Furthermore, the RPT-bit is always cleared
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
duplicates that would otherwise be carried over the LAN
In case the packet, or the Assert message, matches on oif
(*,*,RP) entry, a (*,G) entry is created, and asserts take place
if the matching state were (*,G).
The DR may lose the (*,G) Assert process to another router on the
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
removes the LAN from its (*,G) oif list. The winning router
the last-hop router and is responsible for sending (*,G)
messages to the RP
Join/Prune suppression
Join/Prune suppression may be used on multi-access LANs to
duplicate control message overhead; it is not required for
performance of the protocol. If a Join/Prune message arrives
matches on the incoming interface for an existing (S,G), (*,G),
(*,*,RP) route entry, and the Holdtime included in the Join/
message is greater than the recipient's own [Join/Prune-Holdtime
(with ties resolved in favor of the higher network layer address),
timer (the Join/Prune-Suppression-timer) in the recipient's
entry may be started to suppress further Join/Prune messages.
this timer expires, the recipient triggers a Join/Prune message,
Estrin, et. al. Experimental [Page 12]
RFC 2362 PIM-SM June 1998
resumes sending periodic Join/Prunes, for this entry.
Join/Prune-Suppression-timer should be restarted each time
Join/Prune message is received with a higher Holdtime
2.10 Unicast Routing
When unicast routing changes, an RPF check is done on all
(S,G), (*,G) and (*,*,RP) entries, and all affected expected
interfaces are updated. In particular, if the new incoming
appears in the outgoing interface list, it is deleted from
outgoing interface list. The previous incoming interface may be
to the outgoing interface list by a subsequent Join/Prune
downstream. Join/Prune messages received on the current
interface are ignored. Join/Prune messages received on
interfaces or existing outgoing interfaces are not ignored.
outgoing interfaces are left as is until they are explicitly
by downstream routers or are timed out due to lack of
Join/Prune messages. If the router has a (S,G) entry with the SPT-
set, and the updated iif(S,G) does not differ from iif(*,G)
iif(*,*,RP), then the router resets the SPT-bit
The router must send a Join/Prune message with S in the Join list
any new incoming interfaces to inform upstream routers that
expects multicast datagrams over the interface. It may also send
Join/Prune message with S in the Prune list out the old
interface, if the link is operational, to inform upstream
that this part of the distribution tree is going away
2.11 PIM-SM for Inter-Domain
Future documents will address the use of PIM-SM as a backbone inter
domain multicast routing protocol. Design choices center
around the distribution and usage of RP information for wide area
inter-domain groups
2.12
All PIM control messages may use IPsec [6] to address
concerns. Security mechanisms are likely to be enhanced in the
future
3 Detailed Protocol
This section describes the protocol operations from the
of an individual router implementation. In particular, for
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 messages are sent so neighboring routers can discover
other
3.1.1 Sending
Hello messages are sent periodically between PIM neighbors,
[Hello-Period] seconds. This informs routers what interfaces
PIM neighbors. Hello messages are multicast using address 224.0.0.13
(ALL-PIM-ROUTERS group). The packet includes a Holdtime, set
[Hello-Holdtime], for neighbors to keep the information valid.
are sent on all types of communication links
3.1.2 Receiving
When a router receives a Hello message, it stores the network
address for that neighbor, sets its Neighbor-timer for the
sender to the Holdtime included in the Hello, and determines
Designated Router (DR) for that interface. The highest
system is elected DR. Each Hello received causes the DR's address
be updated
When a router that is the active DR receives a Hello from a
neighbor (i.e., from an address that is not yet in the DRs
table), the DR unicasts its most recent RP-set information to the
neighbor
3.1.3 Timing out neighbor
A periodic process is run to time out PIM neighbors that have
sent Hellos. If the DR has gone down, a new DR is chosen by
all neighbors on the interface and selecting the new DR to be the
with the highest network layer address. If an interface has
down, the router may optionally time out all PIM neighbors
with the interface
3.2 Join/
Join/Prune messages are sent to join or prune a branch off of
multicast distribution tree. A single message contains both a
and prune list, either one of which may be null. Each list
a set of source addresses, indicating the source-specific trees
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
Join/Prune messages are merged such that a message sent to
particular upstream neighbor, N, includes all of the current
and pruned sources that are reached via N; according to
routing Join/Prune messages are multicast to all routers on multi
access networks with the target address set to the next hop
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
excessive overhead on small links. In addition, certain events
triggered Join/Prune messages to be sent
Periodic Join/Prune Messages
A router sends a periodic Join/Prune message to each distinct
neighbor associated with each (S,G), (*,G) and (*,*,RP) entry
Join/Prune messages are only sent if the RPF neighbor is a
neighbor. A periodic Join/Prune message sent to a particular
neighbor is constructed as follows
1 Each router determines the RP for a (*,G) entry by
the hash function described. The RP address (with RPT and
bits set) is included in the join list of a periodic Join/
message under the following conditions
1 The Join/Prune message is being sent to the
neighbor toward the RP for an active (*,G) or (*,*,RP
entry,
2 The outgoing interface list in the (*,G) or (*,*,RP
entry is non-NULL, or the router is the DR on the
interface as the RPF neighbor
2 A particular source address, S, is included in the
list with the RPT and WC bits cleared under the
conditions
1 The Join/Prune message is being sent to the
neighbor toward S,
2 There exists an active (S,G) entry with the RPT-
flag cleared,
3 The oif list in the (S,G) entry is not null
Estrin, et. al. Experimental [Page 15]
RFC 2362 PIM-SM June 1998
3 A particular source address, S, is included in the
list with the RPT and WC bits cleared under the
conditions
1 The Join/Prune message is being sent to the
neighbor toward S,
2 There exists an active (S,G) entry with the RPT-
flag cleared,
3 The oif list in the (S,G) entry is null
4 A particular source address, S, is included in the
list with the RPT-bit set and the WC bit cleared under
following conditions
1 The Join/Prune message is being sent to the
neighbor toward the RP and there exists a (S,G) entry
the RPT-bit flag set and null oif list,
2 The Join/Prune message is being sent to the
neighbor toward the RP, there exists a (S,G) entry with
RPT-bit flag cleared and SPT-bit set, and the
interface toward S is different than the incoming
toward the RP,
3 The Join/Prune message is being sent to the
neighbor toward the RP, and there exists a (*,G) entry
(S,G) entry for a directly connected source
5 The RP address (with RPT and WC bits set) is included
the prune list if
1 The Join/Prune message is being sent to the
neighbor toward the RP and there exists a (*,G) entry
a null oif list (see Section 3.5.2).
Triggered Join/Prune Messages
In addition to periodic messages, the following events
trigger Join/Prune messages if as a result, a) a new entry
created, or b) the oif list changes from null to non-null or non
null to null. The contents of triggered messages are the same
the periodic, described above
1 Receipt of an indication from IGMP that the state
directly-connected-membership has changed (i.e., new
have just joined `membership indication' or all members
Estrin, et. al. Experimental [Page 16]
RFC 2362 PIM-SM June 1998
left), for a group G, may cause the last-hop router to build
modify corresponding (*,G) state. When IGMP indicates
there are no longer directly connected members, the oif
removed from the oif list if the oif-timer is not running.
Join/Prune message is triggered if and only if a) a new entry
created, or b) the oif list changes from null to non-null
non-null to null, as follows
1 If the receiving router does not have a route
for G the router creates a (*,G) entry, copies the oif
from the corresponding (*,*,RP) entry (if it exists),
includes the interface included in the IGMP
indication in the oif list; as always, the router
includes the entry's iif in the oif list. The router
a Join/Prune message towards the RP with the RP address
RPT-bit and WC-bits set in the join list. Or
2 If a (S,G)RPT-bit or (*,G) entry already exists,
interface included in the IGMP membership indication
added to the oif list (if it was not included already).
2 Receipt of a Join/Prune message for (S,G), (*,G)
(*,*,RP) will cause building or modifying corresponding state
and subsequent triggering of upstream Join/Prune messages,
the following cases
1 When there is no current route entry, the RP
included in the Join/Prune message is checked against
local RP-Set information. If it matches, an entry will
created and the new entry will in turn trigger an
Join/Prune message. If the router has no RP-Set
it may discard the message, or optionally use the
address included in the message
2 When the outgoing interface list of an (S,G)RPT-
entry becomes null, the triggered Join/Prune message
contain S in the prune list
3 When there exists a (S,G)RPT-bit with null oif list
and an (*,G) Join/Prune message is received, the
interface is added to the oif list and a (*,G) Join/
message is triggered upstream
4 When there exists a (*,G) with null oif list, and
(*,*,RP) Join/Prune message is received, the
interface is added to the oif list and a (*,*,RP
Join/Prune message is triggered upstream
Estrin, et. al. Experimental [Page 17]
RFC 2362 PIM-SM June 1998
3 Receipt of a packet that matches on a (S,G) entry
SPT-bit is cleared triggers the following if the packet
on the correct incoming interface and there is a (*,G)
(*,*,RP) entry with a different incoming interface: a)
router sets the SPT-bit on the (S,G) entry, and b) the
sends a Join/Prune message towards the RP with S in the
list and the RPT-bit set
4 Receipt of a packet at the DR from a directly
source S, on the subnet containing the address S, triggers
Join/Prune message towards the RP with S in the prune list
the RPT-bit set under the following conditions: a) there is
matching (S,G) state, and b) there exists a (*,G) or (*,*,RP
for which the DR is not the RP
5 When a Join/Prune message is received for a group G,
prune list is checked. If the prune list contains a source or
for which the receiving router has a corresponding active (S,G),
(*,G) or (*,*,RP) entry, and whose iif is that on which
Join/Prune was received, then a join for (S,G), (*,G)
(*,*,RP) is triggered to override the prune, respectively. (
is necessary in the case of parallel downstream
connected to a multi-access network.)
6 When the RP fails, the RP will not be included in
Bootstrap messages sent to all routers in that domain.
triggers the DRs to send (*,G) Join/Prune messages towards
new RP for the group, as determined by the RP-Set and the
function. As described earlier, PMBRs trigger (*,*,RP)
towards each RP in the RP-Set
7 When an entry's Join/Prune-Suppression timer expires,
Join/Prune message is triggered upstream corresponding to
entry, even if the outgoing interface has not
between null and non-null states
8 When the RPF neighbor changes (whether due to an Assert
changes in unicast routing), the router sets a random
timer (the Random-Delay-Join-Timer) whose expiration
sending of a Join/Prune message for the asserted route entry
the Assert winner (if the Join/Prune Suppression timer
expired.)
We do not trigger prunes onto interfaces based on data packets.
packets that arrive on the wrong incoming interface are
dropped. However, on point-to-point interfaces triggered prunes
be sent as an optimization
Estrin, et. al. Experimental [Page 18]
RFC 2362 PIM-SM June 1998
aragraphFragmentation It is possible that a Join/Prune
constructed according to the preceding rules could exceed the MTU
a network. In this case, the message can undergo
fragmentation whereby information corresponding to different
can be sent in different messages. However, if a Join/Prune
must be fragmented the complete prune list corresponding to a group
must be included in the same Join/Prune message as the
RP-tree Join for G. If such semantic fragmentation is not possible
IP fragmentation should be used between the two neighboring hops
3.2.2 Receiving Join/Prune Messages When a router
Join/Prune message, it processes it as follows
The receiver of the Join/Prune notes the interface on which the
message arrived, call it I. The receiver then checks to see if
Join/Prune message was addressed to the receiving router
(i.e., the router's address appears in the Unicast Upstream
Router field of the Join/Prune message). (If the router is
to a multiaccess LAN, the message could be intended for a
router.) If the Join/Prune is for this router the following
are taken
For each group address G, in the Join/Prune message, the
join list is processed as follows. We refer to each address in
join list as Sj; Sj refers to the RP if the RPT-bit and WC-bit
both set. For each Sj in the join list of the Join/Prune message
1 If an address, Sj, in the join list of the Join/
message has the RPT-bit and WC-bit set, then Sj is the
address used by the downstream router(s) and the
actions are taken
1 If Sj is not the same as the receiving router's
mapping for G, the receiving router may ignore
Join/Prune message with respect to that group entry.
the router does not have any RP-Set information, it may
the address Sj included in the Join/Prune message as the
for the group
2 If Sj is the same as the receiving router's RP
for G, the receiving router adds I to the
interface list of the (*,G) route entry (if there is
(*,G) entry, the router creates one first) and sets
Oif-timer for that interface to the Holdtime specified
the Join/Prune message. In addition, the Oif-Deletion-
for that interface is set to 1/3rd the Holdtime
Estrin, et. al. Experimental [Page 19]
RFC 2362 PIM-SM June 1998
in the Join/Prune message. If a (*,*,RP) entry exists,
the RP associated with G, then the oif list of the
created (*,G) entry is copied from that (*,*,RP) entry
3 For each (Si,G) entry associated with group G: i)
Si is not included in the prune list, ii) if I is not
the same subnet as the address Si, and iii) if I is not
iif, then interface I is added to the oif list and
Oif-timer for that interface in each affected entry
increased (never decreased) to the Holdtime included in
Join/Prune message. In addition, if the Oif-timer for
interface is increased, the Oif-Deletion-Delay for
interface is set to 1/3rd the Holdtime specified in
Join/Prune message
If the group address in the Join/Prune message is `*'
every (*,G) and (S,G) entry, whose group address hashes
the RP indicated in the (*,*,RP) Join/Prune message,
updated accordingly. A `*' in the group field of
Join/Prune is represented by a group address 224.0.0.0
a group mask length of 4, indicating a (*,*,RP) Join
4 If the (Si,G) entry has its RPT-bit flag set to 1,
its oif list is the same as the (*,G) oif list, then
(Si,G)RPT-bit entry is deleted
5 The incoming interface is set to the interface used
send unicast packets to the RP in the (*,G) route entry
i.e., RPF interface toward the RP
2 For each address, Sj, in the join list whose RPT-bit
WC-bit are not set, and for which there is no existing (Sj,G
route entry, the router initiates one. The router creates
(S,G) entry and copies all outgoing interfaces from
(S,G)RPT-bit entry, if it exists. If there is no (S,G) entry
the oif list is copied from the (*,G) entry; and if there is
(*,G) entry, the oif list is copied from the (*,*,RP) entry,
it exists. In all cases, the iif of the (S,G) entry is
excluded from the oif list
1 The outgoing interface for (Sj,G) is set to I.
incoming interface for (Sj,G) is set to the interface
to send unicast packets to Sj (i.e., the RPF neighbor).
2 If the interface used to reach Sj, is the same as I
this represents an error (or a unicast routing change)
the Join/Prune must not be processed
Estrin, et. al. Experimental [Page 20]
RFC 2362 PIM-SM June 1998
3 For each address, Sj, in the join list of the Join/
message, for which there is an existing (Sj,G) route entry
1 If the RPT-bit is not set for Sj listed in
Join/Prune message, but the RPT-bit flag is set on
existing (Sj,G) entry, the router clears the RPT-bit
on the (Sj,G) entry, sets the incoming interface to
towards Sj for that (Sj,G) entry, and sends a Join/
message corresponding to that entry through the
incoming interface;
2 If I is not the same as the existing
interface, the router adds I to the list of
interfaces
3 The Oif-timer for I is increased (never decreased)
the Holdtime included in the Join/Prune message.
addition, if the Oif-timer for that interface is increased
the Oif-Deletion-Delay for that interface is set to 1/3
the Holdtime specified in the Join/Prune message
4 The (Sj,G) entry's SPT bit is cleared until data
down the shortest path tree
For each group address G, in the Join/Prune message,
associated prune list is processed as follows. We refer to
address in the prune list as Sp; Sp refers to the RP if the RPT
bit and WC-bit are both set. For each Sp in the prune list of
Join/Prune message
1 For each address, Sp, in the prune list whose RPT-bit
WC-bit are cleared
1 If there is an existing (Sp,G) route entry, the
lowers the entry's Oif-timer for I to its Oif-Deletion
Delay, allowing for other downstream routers on a multi
access LAN to override the prune. However, on point-to
point links, the oif-timer is expired immediately
2 If the router has a current (*,G), or (*,*,RP),
entry, and if the existing (Sp,G) entry has its RPT-
flag set to 1, then this (Sp,G)RPT-bit entry is
(not deleted) even if its outgoing interface list is null
2 For each address, Sp, in the prune list whose RPT-bit
set and whose WC-bit cleared
Estrin, et. al. Experimental [Page 21]
RFC 2362 PIM-SM June 1998
1 If there is an existing (Sp,G) route entry, the
lowers the entry's Oif-timer for I to its Oif-Deletion
Delay, allowing for other downstream routers on a multi
access LAN to override the prune. However, on point-to
point links, the oif-timer is expired immediately
2 If the router has a current (*,G), or (*,*,RP),
entry, and if the existing (Sp,G) entry has its RPT-
flag set to 1, then this (Sp,G)RPT-bit entry is
deleted, and the Entry-timer is restarted, even if
outgoing interface list is null
3 If (*,G), or corresponding (*,*,RP), state exists,
there is no (Sp,G) entry, an (Sp,G)RPT-bit entry is
. The outgoing interface list is copied from the (*,G),
(*,*,RP), entry, with the interface, I, on which the
was received, is deleted. Packets from the pruned source
Sp, match on this state and are not forwarded toward
pruned receivers
4 If there exists a (Sp,G) entry, with or without
RPT-bit set, the oif-timer for I is expired, and
Entry-timer is restarted
3 For each address, Sp, in the prune list whose RPT-bit
WC-bit are both set
1 If there is an existing (*,G) entry, with Sp as the
for G, the router lowers the entry's Oif-timer for I to
Oif-Deletion-Delay, allowing for other downstream
on a multi-access LAN to override the prune. However,
point-to-point links, the oif-timer is expired immediately
2 If the corresponding (*,*,RP) state exists, but
is no (*,G) entry, a (*,G) entry is created. The
interface list is copied from (*,*,RP) entry, with
interface, I, on which the prune was received, deleted
For any new (S,G), (*,G) or (*,*,RP) entry created by
incoming Join/Prune message, the SPT-bit is cleared (and if
Join/Prune-Suppression timer is used, it is left off.)
If the entry has a Join/Prune-Suppression timer associated with it
and if the received Join/Prune does not indicate the router as
target, then the receiving router examines the join and prune
to see if any addresses in the list `completely-match'
(S,G), (*,G), or (*,*,RP) state for which the receiving
currently schedules Join/Prune messages. An element on the join
Estrin, et. al. Experimental [Page 22]
RFC 2362 PIM-SM June 1998
prune list `completely-matches' a route entry only if both
addresses and RPT-bit flag are the same. If the incoming Join/
message completely matches an existing (S,G), (*,G), or (*,*,RP
entry and the Join/Prune arrived on the iif for that entry, then
router compares the Holdtime included in the Join/Prune message,
its own [Join/Prune-Holdtime]. If its own [Join/Prune-Holdtime]
lower, the Join/Prune-Suppression-timer is started at
[Join/Prune-Suppression-Timeout]. If the [Join/Prune-Holdtime]
equal, the tie is resolved in favor of the Join/Prune
originator that has the higher network layer address. When
Join/Prune timer expires, the router triggers a Join/Prune
for the corresponding entry(ies).
3.3 Register and Register-
When a source first starts sending to a group its packets
encapsulated in Register messages and sent to the RP. If the
rate warrants source-specific paths, the RP sets up source
state and starts sending (S,G) Join/Prune messages toward the source
with S in the join list
3.3.1 Sending Registers and Receiving Register-
Register messages are sent as follows
1 When a DR receives a packet from a directly
source, S, on the subnet containing the address S
1 If there is no corresponding (S,G) entry, and
router has RP-Set information, and the DR is not the RP
G, the DR creates an (S,G) entry with the Register
Suppression-timer turned off and the RP address
according to the hash function mapping for
corresponding group. The oif list is copied from
(*,G) or (*,*,RP) entries, if they exist. The iif of
(S,G) entry is always excluded from the oif list. If
exists a (*,G) or (*,*,RP) entry, the DR sends a Join/
message towards the RP with S in the prune list and
RPT-bit set
2 If there is a (S,G) entry in existence, the DR
restarts the corresponding Entry-timer
When a PMBR (e.g., a router that connects the PIM-SM
to a dense mode region running DVMRP or PIM-DM) receives
packet from a source in the dense mode region, the
Estrin, et. al. Experimental [Page 23]
RFC 2362 PIM-SM June 1998
treats the packet as if it were from a directly
source. A separate document will describe the details
interoperability
2 If the new or previously-existing (S,G) entry's Register
Suppression-timer is not running, the data packet
encapsulated in a Register message and unicast to the RP
that group. The data packet is also forwarded according to (S,G
state in the DR if the oif list is not null; since a
may join the SP-tree while the DR is still registering to
RP
3 If the (S,G) entry's Register-Suppression-timer is running
the data packet is not sent in a Register message, it is
forwarded according to the (S,G) oif list
When the DR receives a Register-Stop message, it restarts
Register-Suppression-timer in the corresponding (S,G) entry(ies)
[Register-Suppression-Timeout] seconds. If there is data to
registered, the DR may send a null Register (a Register message
a zero-length data portion in the inner packet) to the RP, [Probe
Time] seconds before the Register-Suppression-timer expires, to
sending occasional bursts of traffic to an RP unnecessarily
3.3.2 Receiving Register Messages and Sending Register-
When a router (i.e., the RP) receives a Register message, the
does the following
1 Decapsulates the data packet, and checks for
corresponding (S,G) entry
1 If a (S,G) entry with cleared (0) SPT bit exists,
the received Register does not have the Null-Register-
set to 1, the packet is forwarded; and the SPT bit is
cleared (0). If the SPT bit is 1, the packet is dropped
and Register-Stop messages are triggered. Register-
should be rate-limited (in an implementation-
manner) so that no more than a few are sent per round
time. This prevents a high datarate stream of packets
triggering a large number of Register-Stop messages
the time that the first packet is received and the
when the source receives the first Register-Stop
2 If there is no (S,G) entry, but there is a (*,G
entry, and the received Register does not have the Null
Register-Bit set to 1, the packet is forwarded according
the (*,G) entry
Estrin, et. al. Experimental [Page 24]
RFC 2362 PIM-SM June 1998
3 If there is a (*,*,RP) entry but no (*,G) entry,
the Register received does not have the Null-Register-
set to 1, a (*,G) or (S,G) entry is created and the
list is copied from the (*,*,RP) entry to the new entry
The packet is forwarded according to the created entry
4 If there is no G or (*,*,RP) entry corresponding to G
the packet is dropped, and a Register-Stop is triggered
5 A "Border bit" bit is added to the Register message
to facilitate interoperability mechanisms. PMBRs set
bit when registering for external sources (see
2.7). If the "Border bit" is set in the Register
the RP does the following
1 If there is no matching (S,G) state, but
exists (*,G) or (*,*,RP) entry, the RP creates a (S,G
entry, with a `PMBR' field. This field holds
source of the Register (i.e. the outer network
address of the register packet). The RP triggers
(S,G) join towards the source of the data packet,
clears the SPT bit for the (S,G) entry. If
received Register is not a `null Register' the
is forwarded according to the created state. Else
2 If the `PMBR' field for the corresponding (S,G
entry matches the source of the Register packet,
the received Register is not a `null Register',
decapsulated packet is forwarded to the oif list
that entry. Else
3 If the `PMBR' field for the corresponding (S,G
entry matches the source of the Register packet,
decapsulated packet is forwarded to the oif list
that entry,
4 The packet is dropped, and a Register-stop
triggered towards the source of the Register
The (S,G) Entry-timer is restarted by Registers arriving
that source to that group
2 If the matching (S,G) or (*,G) state contains a null
list, the RP unicasts a Register-Stop message to the source
the Register message; in the latter case, the source-
field, within the Register-Stop message, is set to the
Estrin, et. al. Experimental [Page 25]
RFC 2362 PIM-SM June 1998
value (all 0's). This message is not processed by
routers, hence no (S,G) state is constructed between the RP
the source
3 If the Register message arrival rate warrants it and
is no existing (S,G) entry, the RP sets up a (S,G) route
with the outgoing interface list, excluding iif(S,G),
from the (*,G) outgoing interface list, its SPT-bit
initialized to 0. If a (*,G) entry does not exist, but
exists a (*,*,RP) entry with the RP corresponding to G , the
list for (S,G) is copied - excluding the iif - from
(*,*,RP) entry
A timer (Entry-timer) is set for the (S,G) entry and this
is restarted by receipt of data packets for (S,G). The (S,G
entry causes the RP to send a Join/Prune message for
indicated group towards the source of the register message
If the (S,G) oif list becomes null, Join/Prune messages will
be sent towards the source, S
3.4 Multicast Data Packet
Processing a multicast data packet involves the following steps
1 Lookup route state based on a longest match of the
address, and an exact match of the destination address in
data packet. If neither S, nor G, find a longest match entry
and the RP for the packet's destination group address has
corresponding (*,*,RP) entry, then the longest match does
require an exact match on the destination group address.
summary, the longest match is performed in the following order
(1) (S,G), (2) (*,G). If neither is matched, then a lookup
performed on (*,*,RP) entries
2 If the packet arrived on the interface found in
matching-entry's iif field, and the oif list is not null
1 Forward the packet to the oif list for that entry
excluding the subnet containing S, and restart the Entry
timer if the matching entry is (S,G). Optionally,
(S,G) Entry-timer may be restarted by periodic checking
the matching packet count
Estrin, et. al. Experimental [Page 26]
RFC 2362 PIM-SM June 1998
2 If the entry is a (S,G) entry with a cleared SPT-bit
and a (*,G) or associated (*,*,RP) also exists
incoming interface is different than that for (S,G),
the SPT-bit for the (S,G) entry and trigger an (S,G) RPT
bit prune towards the RP
3 If the source of the packet is a directly-
host and the router is the DR on the receiving interface
check the Register-Suppression-timer associated with
(S,G) entry. If it is not running, then the
encapsulates the data packet in a register message
sends it to the RP
This covers the common case of a packet arriving on the
interface to the source or RP and being forwarded to
joined branches. It also detects when packets arrive on
SP-tree, and triggers their pruning from the RP-tree. If
is the DR for the source, it sends data
encapsulated in Registers to the RPs
3 If the packet matches to an entry but did not arrive on
interface found in the entry's iif field, check the SPT-
of the entry. If the SPT-bit is set, drop the packet.
the SPT-bit is cleared, then lookup the (*,G), or (*,*,RP),
entry for G. If the packet arrived on the iif found
(*,G), or the corresponding (*,*,RP), forward the packet
the oif list of the matching entry. This covers the
when a data packet matches on a (S,G) entry for which
SP-tree has not yet been completely established upstream
4 If the packet does not match any entry, but the source
the data packet is a local, directly-connected host,
the router is the DR on a multi-access LAN and has RP-
information, the DR uses the hash function to determine
RP associated with the destination group, G. The DR
a (S,G) entry, with the Register-Suppression-timer
running, encapsulates the data packet in a Register
and unicasts it to the RP
5 If the packet does not match to any entry, and it is not
local host or the router is not the DR, drop the packet
3.4.1 Data triggered switch to shortest path tree (SP-tree
Different criteria can be applied to trigger switching over from
RP-based shared tree to source-specific, shortest path trees
Estrin, et. al. Experimental [Page 27]
RFC 2362 PIM-SM June 1998
One proposed example is to do so based on data rate. For example
when a (*,G), or corresponding (*,*,RP), entry is created, a
rate counter may be initiated at the last-hop routers. The
is incremented with every data packet received for directly
members of an SM group, if the longest match is (*,G) or (*,*,RP).
and whe