draft-ietf-pim-v2-dm-02.txt   draft-ietf-pim-v2-dm-03.txt 
skipping to change at page 5, line 20 skipping to change at page 5, line 20
It should be noted that a non-leaf router in PIM dense-mode is not It should be noted that a non-leaf router in PIM dense-mode is not
necessarily a non-leaf node on a particular multicast forwarding tree. necessarily a non-leaf node on a particular multicast forwarding tree.
There are topologies where two parallel routers are connected to a There are topologies where two parallel routers are connected to a
common LAN where none of the routers uses the other one to reach a common LAN where none of the routers uses the other one to reach a
source. Therefore both routers will be leaves of the shortest path source. Therefore both routers will be leaves of the shortest path
tree rooted at the source. When there are no group members on this tree rooted at the source. When there are no group members on this
LAN, both routers must not forward packets onto it. This is achieved LAN, both routers must not forward packets onto it. This is achieved
by an assert process. See section 5.5 for more details. by an assert process. See section 5.5 for more details.
A dense mode PIM implementation must take proper actions when a non- A dense mode PIM implementation MUST take proper actions when a non-
leaf router becomes a leaf router. When the last PIM neighbor on an leaf router becomes a leaf router. When the last PIM neighbor on an
interface goes away and turns the connected subnet into a leaf interface goes away and turns the connected subnet into a leaf
network, the router should delete that interface from the outgoing network, the router SHOULD delete that interface from the outgoing
interface lists of all groups without attached group members. interface lists of all groups without attached group members.
5.2 Pruning of branches 5.2 Pruning of branches
5.2.1 Pruning on multi-access LANs and prune-override 5.2.1 Pruning on multi-access LANs and prune-override
To avoid PIM Prune message storms, PIM Prune messages must not be sent PIM prune message storms can be generated if an implementation
on LANs in response to each received multicast packet that is responds to received multicast packets aggressively, e.g. by sending
associated with an existing negative cache entry. one prune for each data packet matching a negative cache entry. An
implementation SHOULD either respond to such packets in a very
conservative rate-limited manner, or not responding to such packets at
all, and rely on the expiration and recreation of the entry to
generate a prune. The latter is sufficient in most cases when the
probability of prune message loss is low.
A prune is sent upstream when a router creates a (S,G) negative cache A prune is sent upstream when a router creates a (S,G) negative cache
entry, or when the entry turns into a negative cache. Prune entry, or when the entry turns into a negative cache. Prune
information is flushed periodically. This causes multicast datagrams information is flushed periodically. This causes multicast datagrams
to be sent in RPF mode again which in turn triggers prune messages. to be sent in RPF mode again which in turn triggers prune messages.
When a prune message is sent onto an upstream LAN, it is data link When a prune message is sent onto an upstream LAN, it is data link
multicast and IP addressed to the all PIM routers group address multicast and IP addressed to the all PIM routers group address
224.0.0.13. The router to process the prune will be indicated by 224.0.0.13. The router to process the prune will be indicated by
inclusion of its address in the "Address" field of the message. This inclusion of its address in the "Address" field of the message. This
_________________________
its topology discovery (or ``unicast routing'')
protocol.
address is obtained by an RPF look up for the source. When the prune address is obtained by an RPF look up for the source. When the prune
message is sent, the expected upstream router will schedule a prune message is sent, the expected upstream router will schedule a prune
request of the LAN from its outgoing interfaces for the (S,G) entry. request of the LAN from its outgoing interfaces for the (S,G) entry.
The suggested default delay time before deletion is 3 seconds. The suggested default delay time before deletion is 3 seconds.
_________________________
its topology discovery (or ``unicast routing'')
protocol.
Other routers on the LAN will hear the prune message and respond with Other routers on the LAN will hear the prune message and respond with
a join if they still expect multicast datagrams from the expected a join if they still expect multicast datagrams from the expected
upstream router. The Join message is data link multicast and IP upstream router. The Join message is data link multicast and IP
addressed to the all PIM routers group address 224.0.0.13. The router addressed to the all PIM routers group address 224.0.0.13. The router
to process the join will be indicated by inclusion of its address in to process the join will be indicated by inclusion of its address in
the "Address" field of the message. The address is determined by an the "Address" field of the message. The address is determined by an
RPF lookup for the source. When the expected router receives the join RPF lookup for the source. When the expected router receives the join
message, it will cancel the prune request. This process is called message, it will cancel the prune request. This process is called
prune-override. prune-override.
Routers that need to send prune-override joins will randomly generate Routers that need to send prune-override joins will randomly generate
a join message delay timer. If a join is heard from another router a join message delay timer. If a join is heard from another router
before a router sends its own, it will cancel sending its own join. before a router sends its own, it will cancel sending its own join.
This will reduce control traffic on the LAN. The maximum join delay This will reduce control traffic on the LAN. The maximum join delay
timer should be equal to or smaller than the prune delay timer value. timer should be equal to or smaller than the prune delay timer value.
The default is 3 seconds. The default is 3 seconds.
If the expected upstream router does not receive any PIM Join messages If the expected upstream router does not receive any PIM Join messages
before the scheduled expiration time for the deletion request, it before the scheduled expiration time for the deletion request, it
prunes the outgoing LAN interface from the (S,G) multicast forwarding prunes the outgoing LAN interface from the (S,G) multicast forwarding
entry. entry. The prune timer SHOULD take into account the 3 seconds delay
after the prune was scheduled. At the time of the prune, by default,
the timer SHOULD expire in [Data-Timeout - 3 seconds]. This reduces
the chance of join latency in case a new member immediately joined
after the last prune.
However, if the prune-override join message is lost, the deletion will However, if the prune-override join message is lost, the prune will
occur and there will be no data delivery for the amount of time the occur and there will be no data delivery for the amount of time the
interface remains in prune state. To reduce the probability of this interface remains in prune state. To reduce the probability of this
occurence, a router that has scheduled to prune the interface off occurence, a router that has scheduled to prune the interface off
should immediately send a prune onto the interface. This gives other should immediately send a prune onto the interface. This gives other
routers another chance to hear the prune, and to respond with a join. routers another chance to hear the prune, and to respond with a join.
Additionally, equal-cost paths leading to a LAN presents a special
case for join/prune processing. When an upstream router is chosen by
an RPF lookup there may be equal-cost paths to reach the source. The
higher IP addressed system is always chosen. If the unicast routing
protocol does not store all available equal-cost paths in the routing
table, the "Address" field may contain the address of the wrong
upstream router. To avoid this situation, the "Address" field may
optionally be set to 0.0.0.0 which means that all upstream routers
(the ones that have the LAN as an outgoing interface for the (S,G)
entry) may process the packet.
5.2.2 Pruning a Point-to-point link 5.2.2 Pruning a Point-to-point link
Prune messages received on a point to point link are not delayed Prune messages received on a point to point link are not delayed
before processing as they are in the LAN procedure. If the prune is before processing as they are in the LAN procedure. If the prune is
received on an interface in the outgoing interface list, it is pruned received on an interface in the outgoing interface list, it is pruned
immediately. immediately.
Prunes may be rate-limited on point-to-point interfaces when a Prunes may be rate-limited on point-to-point interfaces when a
multicast datagram is received for a negative cache entry, or if the multicast datagram is received for a negative cache entry, or if the
point-to-point interface receiving the datagram is not the RPF point-to-point interface receiving the datagram is not the RPF
skipping to change at page 11, line 19 skipping to change at page 11, line 19
If the prune timers on different outgoing interfaces are different, If the prune timers on different outgoing interfaces are different,
the pruned interface with the shortest remaining timer may expire the pruned interface with the shortest remaining timer may expire
first and turn the negative cache entry into forwarding state. When first and turn the negative cache entry into forwarding state. When
this happens, a graft should be triggered upstream. When a negative this happens, a graft should be triggered upstream. When a negative
cache entry turns into a forward entry, the entry timer should be cache entry turns into a forward entry, the entry timer should be
restarted with the default expiration timer. Once the (S,G) entry restarted with the default expiration timer. Once the (S,G) entry
times out, it will be recreated when the next multicast packet or join times out, it will be recreated when the next multicast packet or join
arrives. arrives.
If the prune timer expires at the exactly same time as the (S,G) entry
timer, a graft should still be triggered upstream.
The prune message sent upstream contains a holdtime. Its default value The prune message sent upstream contains a holdtime. Its default value
is [Data-Timeout], except when the Assert timer is also running, the is [Data-Timeout], except when the Assert timer is also running, the
holdtime in the prune message is set to the smaller value between the holdtime in the prune message is set to the smaller value between the
prune holdtime the system uses, and the remaining assert timer value prune holdtime the system uses, and the remaining assert timer value
before its expiration. The Assert Timer is started with a default before its expiration. The Assert Timer is started with a default
value of 210 seconds. value of 210 seconds.
5.7 Adapting to unicast route changes 5.7 Adapting to unicast route changes
When unicast route changes occur, the RPF interface for many (S,G) When unicast route changes occur, the RPF interface for many (S,G)
skipping to change at page 14, line 32 skipping to change at page 14, line 32
7.2 PIM-SM-Register Message 7.2 PIM-SM-Register Message
Used in sparse-mode. Refer to PIM sparse-mode specification. Used in sparse-mode. Refer to PIM sparse-mode specification.
7.3 PIM-SM-Register-Stop Message 7.3 PIM-SM-Register-Stop Message
Used in sparse-mode. Refer to PIM sparse-mode specification. Used in sparse-mode. Refer to PIM sparse-mode specification.
7.4 Join/Prune Message 7.4 Join/Prune Message
It is sent by routers toward upstream sources. A join creates Joins are sent by routers toward upstream sources. A join creates or
forwarding state and a prune destroys forwarding state. Refer to PIM refreshes forwarding state and a prune negates forwarding state. It is
sparse-mode specification. processed as if a graft is received, except no ack packet is required.
Refer to PIM sparse-mode specification.
7.5 PIM-SM-Bootstrap Message 7.5 PIM-SM-Bootstrap Message
Used in sparse-mode. Refer to PIM sparse-mode specification. Used in sparse-mode. Refer to PIM sparse-mode specification.
7.6 PIM-Assert Message 7.6 PIM-Assert Message
The PIM-Assert message is sent when a multicast data packet is The PIM-Assert message is sent when a multicast data packet is
received on an outgoing interface corresponding to the (S,G) or (*,G) received on an outgoing interface corresponding to the (S,G) or (*,G)
associated with the source. This message is used in both dense-mode associated with the source. This message is used in both dense-mode
skipping to change at page 15, line 16 skipping to change at page 15, line 17
This message is sent by a downstream router to a neighboring upstream This message is sent by a downstream router to a neighboring upstream
router to reinstate a previously pruned branch of a source tree. This router to reinstate a previously pruned branch of a source tree. This
is done for dense-mode groups only. The format is the same as a is done for dense-mode groups only. The format is the same as a
Join/Prune message, except that the value in the type field is 6. The Join/Prune message, except that the value in the type field is 6. The
source address should be included in the join section of the message. source address should be included in the join section of the message.
The holdtime field is unused, and is ignored when a graft is received. The holdtime field is unused, and is ignored when a graft is received.
7.8 PIM-Graft-Ack Message 7.8 PIM-Graft-Ack Message
Sent in response to a received Graft message. The Graft-Ack is only Sent in response to a received Graft message. This message is sent for
sent if the interface in which the Graft was received is not the dense-mode groups only. The format is the same as Join/Prune message,
incoming interface for the respective (S,G). This is done for dense- except that the value of the message type field is 7. The ``Encoded-
mode groups only. The format is the same as Join/Prune message, except Unicast-Upstream Neighbor Address'' field is unused and needs not be
that the value of the message type field is 7. The ``Encoded-Unicast- checked when this message is received. The holdtime field in the
Upstream Neighbor Address'' field is unused and needs not be checked packet is ignored when received.
when this message is received. The holdtime field in the packet is
ignored when received.
8 Security Considerations 8 Security Considerations
Security issues are discussed in detail in the companion document Security issues are discussed in detail in the companion document
``Authenticating PIM Version 2 Messages'' [PIMAU]. ``Authenticating PIM Version 2 Messages'' [PIMAU].
9 Acknowledgement 9 Acknowledgement
Thanks to Manoj Leelanivas, Sangeeta Mukherjee, Nitin Jain and many Thanks to Manoj Leelanivas, Sangeeta Mukherjee, Nitin Jain, Bill
members of the PIM/IDMR working group for their helpful comments. Fenner and many members of the PIM/IDMR working group for their
helpful comments.
10 References 10 References
[Deering91] S.E. Deering. Multicast Routing in a Datagram [Deering91] S.E. Deering. Multicast Routing in a Datagram
Internetwork. PhD thesis, Electrical Engineering Dept., Stanford Internetwork. PhD thesis, Electrical Engineering Dept., Stanford
University, December 1991. University, December 1991.
[DVMRP] RFC 1075, Distance Vector Multicast Routing Protocol. [DVMRP] RFC 1075, Distance Vector Multicast Routing Protocol.
Waitzman, D., Partridge, C., Deering, S.E, November 1988 Waitzman, D., Partridge, C., Deering, S.E, November 1988
skipping to change at line 673 skipping to change at page 17, line 16
cisco Systems, Inc cisco Systems, Inc
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA95134 San Jose, CA95134
meyer@cisco.com meyer@cisco.com
Liming Wei Liming Wei
cisco Systems Inc cisco Systems Inc
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
lwei@cisco.com lwei@cisco.com
12 Appendix. Changes Since The Last Revision
* Section 5.2.1 Deleted the paragraph about use of 0.0.0.0 in the
prune message.
* Section 5.6 Made it explicit that graft needs to be sent even when
prune timer and entry timer all expire at the same time.
* Section 7.8. Deleted sentence saying graft-ack is sent only if it
is received on a non-RPF interface.
* Section 5.2.1. Reworded the ``rate-limiting prunes'' paragraph.
Made it more explicit what actions are permitted.
* Section 7.4. Reworded and added clarification for join processing:
``A join creates or refreshes forwarding state and a prune negates
forwarding state. It is processed as if a graft is received,
except no ack packet is required.''
* Section 5.2.1. Added sentence to deal with 3 seconds join latency
immediately after prune over a multi-access LAN: ``The prune timer
SHOULD take into account the 3 seconds delay after the prune was
scheduled. At the time of the prune, by default, the timer SHOULD
expire in [Data-Timeout - 3 seconds]. This reduces the chance of
join latency in case a new member immediately joined after the
last prune.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/