draft-ietf-pim-rfc4601bis-03.txt   draft-ietf-pim-rfc4601bis-04.txt 
Network Working Group B. Fenner Network Working Group B. Fenner
Internet Draft AT&T Labs - Research Internet Draft AT&T Labs - Research
Intended Status: Internet Standard M. Handley Intended Status: Internet Standard M. Handley
Expires: Noveber 7, 2014 UCL Expires: August 27, 2015 UCL
H. Holbrook Obsoletes: 4601 H. Holbrook
Arastra Arastra
I. Kouvelas I. Kouvelas
R. Parekh R. Parekh
Cisco Systems, Inc. Cisco Systems, Inc.
Z. Zhang Z. Zhang
Juniper Networks Juniper Networks
L. Zheng L. Zheng
Huawei Technologies Huawei Technologies
May 7, 2014 February 23, 2015
Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised) Protocol Specification (Revised)
draft-ietf-pim-rfc4601bis-03 draft-ietf-pim-rfc4601bis-04
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 29, 2012. This Internet-Draft will expire on August 27, 2015.
Abstract Abstract
This document specifies Protocol Independent Multicast - Sparse Mode This document specifies Protocol Independent Multicast - Sparse Mode
(PIM-SM). PIM-SM is a multicast routing protocol that can use the (PIM-SM). PIM-SM is a multicast routing protocol that can use the
underlying unicast routing information base or a separate multicast- underlying unicast routing information base or a separate multicast-
capable routing information base. It builds unidirectional shared capable routing information base. It builds unidirectional shared
trees rooted at a Rendezvous Point (RP) per group, and optionally trees rooted at a Rendezvous Point (RP) per group, and optionally
creates shortest-path trees per source. creates shortest-path trees per source.
This document addresses errata filed against RFC 4601, and removes This document obsoletes RFC 4601 by replacing it, addresses the
the optional (*,*,RP) feature that lacks sufficient deployment errata filed against it, removes the optional (*,*,RP) and PIM
experience. Multicast Border Router features that lack sufficient deployment
experience (see Appendix A) and moves the PIM specification to
Internet Standard.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 20, line 47 skipping to change at page 20, line 47
o Override Timer (OT) o Override Timer (OT)
Local membership is the result of the local source-specific Local membership is the result of the local source-specific
membership mechanism (such as IGMPv3) running on that interface and membership mechanism (such as IGMPv3) running on that interface and
specifying that although there is (*,G) Include state, this specifying that although there is (*,G) Include state, this
particular source should be excluded. As stored here, this state is particular source should be excluded. As stored here, this state is
the resulting state after any IGMPv3 inconsistencies between LAN the resulting state after any IGMPv3 inconsistencies between LAN
members have been resolved. It need not be kept if this router is members have been resolved. It need not be kept if this router is
not the DR on that interface unless this router won a (*,G) assert on not the DR on that interface unless this router won a (*,G) assert on
this interface for this group. However, we recommend storing this this interface for this group. However, we RECOMMEND storing this
information if possible, as it reduces latency converging to stable information if possible, as it reduces latency converging to stable
operating conditions after a failure causing a change of DR. This operating conditions after a failure causing a change of DR. This
information is used by the pim_exclude(S,G) macro described in information is used by the pim_exclude(S,G) macro described in
Section 4.1.5. Section 4.1.5.
PIM (S,G,rpt) Join/Prune state is the result of receiving PIM PIM (S,G,rpt) Join/Prune state is the result of receiving PIM
(S,G,rpt) Join/Prune messages on this interface and is specified in (S,G,rpt) Join/Prune messages on this interface and is specified in
Section 4.5.3. The state is used by the macros that calculate the Section 4.5.3. The state is used by the macros that calculate the
outgoing interface list in Section 4.1.5, and in the rules for adding outgoing interface list in Section 4.1.5, and in the rules for adding
Prune(S,G,rpt) messages to Join(*,G) messages specified in Section Prune(S,G,rpt) messages to Join(*,G) messages specified in Section
skipping to change at page 42, line 21 skipping to change at page 42, line 21
Note (*): This may block traffic from S for Register_Suppression_Time Note (*): This may block traffic from S for Register_Suppression_Time
if the DR learned about a new group-to-RP mapping before the RP if the DR learned about a new group-to-RP mapping before the RP
did. However, this doesn't matter unless we figure out some way did. However, this doesn't matter unless we figure out some way
for the RP also to accept (*,G) joins when it doesn't yet realize for the RP also to accept (*,G) joins when it doesn't yet realize
that it is about to become the RP for G. This will all get sorted that it is about to become the RP for G. This will all get sorted
out once the RP learns the new group-to-rp mapping. We decided to out once the RP learns the new group-to-rp mapping. We decided to
do nothing about this and just accept the fact that PIM may suffer do nothing about this and just accept the fact that PIM may suffer
interrupted (*,G) connectivity following an RP change. interrupted (*,G) connectivity following an RP change.
Note (+): Implementations SHOULD NOT make this a special case, but to Note (+): Implementations SHOULD NOT make this a special case, but
arrange that this path rejoin the normal packet forwarding path. SHOULD arrange that this path rejoin the normal packet forwarding
All of the appropriate actions from the "On receipt of data from S path. All of the appropriate actions from the "On receipt of data
to G on interface iif" pseudocode in Section 4.2 should be from S to G on interface iif" pseudocode in Section 4.2 should be
performed. performed.
KeepaliveTimer(S,G) is restarted at the RP when packets arrive on the KeepaliveTimer(S,G) is restarted at the RP when packets arrive on the
proper tunnel interface and the RP desires to switch to the SPT or proper tunnel interface and the RP desires to switch to the SPT or
the SPTbit is already set. This may cause the upstream (S,G) state the SPTbit is already set. This may cause the upstream (S,G) state
machine to trigger a join if the inherited_olist(S,G) is not NULL. machine to trigger a join if the inherited_olist(S,G) is not NULL.
An RP should preserve (S,G) state that was created in response to a An RP should preserve (S,G) state that was created in response to a
Register message for at least ( 3 * Register_Suppression_Time ); Register message for at least ( 3 * Register_Suppression_Time );
otherwise, the RP may stop joining (S,G) before the DR for S has otherwise, the RP may stop joining (S,G) before the DR for S has
skipping to change at page 43, line 45 skipping to change at page 43, line 45
4.5.1. Receiving (*,G) Join/Prune Messages 4.5.1. Receiving (*,G) Join/Prune Messages
When a router receives a Join(*,G), it must first check to see When a router receives a Join(*,G), it must first check to see
whether the RP in the message matches RP(G) (the router's idea of who whether the RP in the message matches RP(G) (the router's idea of who
the RP is). If the RP in the message does not match RP(G), the the RP is). If the RP in the message does not match RP(G), the
Join(*,G) should be silently dropped. (Note that other source list Join(*,G) should be silently dropped. (Note that other source list
entries, such as (S,G,rpt) or (S,G), in the same Group-Specific Set entries, such as (S,G,rpt) or (S,G), in the same Group-Specific Set
should still be processed.) If a router has no RP information (e.g., should still be processed.) If a router has no RP information (e.g.,
has not recently received a BSR message), then it may choose to has not recently received a BSR message), then it may choose to
accept Join(*,G) and treat accept Join(*,G) and treat the RP in the message as RP(G). Received
the RP in the message as RP(G). Received Prune(*,G) messages are Prune(*,G) messages are processed even if the RP in the message does
processed even if the RP in the message does not match RP(G). not match RP(G).
The per-interface state machine for receiving (*,G) Join/Prune The per-interface state machine for receiving (*,G) Join/Prune
Messages is given below. There are three states: Messages is given below. There are three states:
NoInfo (NI) NoInfo (NI)
The interface has no (*,G) Join state and no timers running. The interface has no (*,G) Join state and no timers running.
Join (J) Join (J)
The interface has (*,G) Join state, which will cause the The interface has (*,G) Join state, which will cause the
router to forward packets destined for G from this interface router to forward packets destined for G from this interface
skipping to change at page 96, line 6 skipping to change at page 96, line 6
o Keepalive Timer o Keepalive Timer
o SPTbit (Section 4.2.2) o SPTbit (Section 4.2.2)
The Keepalive Timer should be treated as always running, and SPTbit The Keepalive Timer should be treated as always running, and SPTbit
should be treated as always being set for an SSM address. should be treated as always being set for an SSM address.
Additionally, the Packet forwarding rules of Section 4.2 can be Additionally, the Packet forwarding rules of Section 4.2 can be
simplified in a PIM-SSM-only router: simplified in a PIM-SSM-only router:
oiflist = NULL
if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined ) { if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined ) {
oiflist = inherited_olist(S,G) oiflist = inherited_olist(S,G)
} else if( iif is in inherited_olist(S,G) ) { } else if( iif is in inherited_olist(S,G) ) {
send Assert(S,G) on iif send Assert(S,G) on iif
} }
oiflist = oiflist (-) iif oiflist = oiflist (-) iif
forward packet on all interfaces in oiflist forward packet on all interfaces in oiflist
This is nothing more than the reduction of the normal PIM-SM This is nothing more than the reduction of the normal PIM-SM
skipping to change at page 110, line 8 skipping to change at page 110, line 8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . | | . |
| . | | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pruned Source Address n (Encoded-Source format) | | Pruned Source Address n (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Type, Reserved, Checksum PIM Version, Type, Reserved, Checksum
Described in Section 4.9. Described in Section 4.9.
Unicast Upstream Neighbor Address Unicast Upstream Neighbor Address
The address of the upstream neighbor that is the target of the The primary address of the upstream neighbor that is the target
message. The format for this address is given in the Encoded- of the message. The format for this address is given in the
Unicast address in Section 4.9.1. For IPv6 the source address Encoded-Unicast address in Section 4.9.1.
used for multicast messages is the link-local address of the
interface on which the message is being sent. For IPv4, the
source address is the primary address associated with that
interface.
Reserved Reserved
Transmitted as zero, ignored on receipt. Transmitted as zero, ignored on receipt.
Holdtime Holdtime
The amount of time a receiver MUST keep the Join/Prune state The amount of time a receiver MUST keep the Join/Prune state
alive, in seconds. If the Holdtime is set to '0xffff', the alive, in seconds. If the Holdtime is set to '0xffff', the
receiver of this message SHOULD hold the state until canceled by receiver of this message SHOULD hold the state until canceled by
the appropriate canceling Join/Prune message, or timed out the appropriate canceling Join/Prune message, or timed out
according to local policy. This may be used with dial-on-demand according to local policy. This may be used with dial-on-demand
skipping to change at page 116, line 11 skipping to change at page 116, line 11
The group address for which the router wishes to resolve the The group address for which the router wishes to resolve the
forwarding conflict. This is an Encoded-Group address, as forwarding conflict. This is an Encoded-Group address, as
specified in Section 4.9.1. specified in Section 4.9.1.
Source Address Source Address
Source address for which the router wishes to resolve the Source address for which the router wishes to resolve the
forwarding conflict. The source address MAY be set to zero for forwarding conflict. The source address MAY be set to zero for
(*,G) asserts (see below). The format for this address is given (*,G) asserts (see below). The format for this address is given
in Encoded-Unicast-Address in Section 4.9.1. in Encoded-Unicast-Address in Section 4.9.1.
R RPTbit is a 1-bit value. The RPTbit is set to 1 for R RPTbit is a 1-bit value. The RPTbit is set to 1 for Assert(*,G)
Assert(*,G) messages and 0 for Assert(S,G) messages. messages and 0 for Assert(S,G) messages.
Metric Preference Metric Preference
Preference value assigned to the unicast routing protocol that Preference value assigned to the unicast routing protocol that
provided the route to the multicast source or Rendezvous-Point. provided the route to the multicast source or Rendezvous-Point.
Metric Metric
The unicast routing table metric associated with the route used The unicast routing table metric associated with the route used
to reach the multicast source or Rendezvous-Point. The metric to reach the multicast source or Rendezvous-Point. The metric
is in units applicable to the unicast routing protocol used. is in units applicable to the unicast routing protocol used.
Assert messages can be sent to resolve a forwarding conflict for all Assert messages can be sent to resolve a forwarding conflict for all
traffic to a given group or for a specific source and group. traffic to a given group or for a specific source and group.
Assert(S,G) Assert(S,G)
Source-specific asserts are sent by routers forwarding a Source-specific asserts are sent by routers forwarding a
specific source on the shortest-path tree (SPTbit is TRUE). specific source on the shortest-path tree (SPTbit is TRUE).
(S,G) Asserts have the Group-Address field set to the group G (S,G) Asserts have the Group-Address field set to the group G
and the Source-Address field set to the source S. The RPTbit and the Source-Address field set to the source S. The RPTbit is
is set to 0, the Metric-Preference is set to MRIB.pref(S) and set to 0, the Metric-Preference is set to MRIB.pref(S) and the
the Metric is set to MRIB.metric(S). Metric is set to MRIB.metric(S).
Assert(*,G) Assert(*,G)
Group-specific asserts are sent by routers forwarding data for Group-specific asserts are sent by routers forwarding data for
the group and source(s) under contention on the shared tree. the group and source(s) under contention on the shared tree.
(*,G) asserts have the Group-Address field set to the group G. (*,G) asserts have the Group-Address field set to the group G.
For data-triggered Asserts, the Source-Address field MAY be set For data-triggered Asserts, the Source-Address field MAY be set
to the IP source address of the data packet that triggered the to the IP source address of the data packet that triggered the
Assert and is set to zero otherwise. The RPTbit is set to 1, Assert and is set to zero otherwise. The RPTbit is set to 1,
the Metric-Preference is set to MRIB.pref(RP(G)), and the Metric the Metric-Preference is set to MRIB.pref(RP(G)), and the Metric
is set to MRIB.metric(RP(G)). is set to MRIB.metric(RP(G)).
skipping to change at page 127, line 50 skipping to change at page 127, line 50
updated. updated.
6.3.2.2. Register-Stop Messages 6.3.2.2. Register-Stop Messages
Similarly, the Security Policy Database at each Rendezvous Point Similarly, the Security Policy Database at each Rendezvous Point
should be configured to choose an SA to use when sending Register- should be configured to choose an SA to use when sending Register-
Stop messages. Because Register-Stop messages are unicast to the Stop messages. Because Register-Stop messages are unicast to the
destination DR, a different SA and a potentially unique SPI are destination DR, a different SA and a potentially unique SPI are
required for each DR. required for each DR.
In order to simplify the management problem, it may be acceptable use In order to simplify the management problem, it may be acceptable to
the same authentication algorithm and authentication parameters, use the same authentication algorithm and authentication parameters,
regardless of the sending RP and regardless of the destination DR. regardless of the sending RP and regardless of the destination DR.
Although a unique SA is needed for each DR, the same authentication Although a unique SA is needed for each DR, the same authentication
algorithm and authentication algorithm parameters (secret key) can be algorithm and authentication algorithm parameters (secret key) can be
shared by all DRs and by all RPs. shared by all DRs and by all RPs.
6.4. Denial-of-Service Attacks 6.4. Denial-of-Service Attacks
There are a number of possible denial-of-service attacks against PIM There are a number of possible denial-of-service attacks against PIM
that can be caused by generating false PIM protocol messages or even that can be caused by generating false PIM protocol messages or even
by generating false traffic. Authenticating PIM protocol traffic by generating false traffic. Authenticating PIM protocol traffic
skipping to change at page 130, line 15 skipping to change at page 130, line 15
[15] Savola, P., Lehtonen, R., and D. Meyer, "Protocol Independent [15] Savola, P., Lehtonen, R., and D. Meyer, "Protocol Independent
Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Multicast - Sparse Mode (PIM-SM) Multicast Routing Security
Issues and Enhancements", RFC 4609, August 2006. Issues and Enhancements", RFC 4609, August 2006.
[16] Savola, P. and J. Lingard, "Host Threats to Protocol Independent [16] Savola, P. and J. Lingard, "Host Threats to Protocol Independent
Multicast (PIM)", RFC 5294, August 2008. Multicast (PIM)", RFC 5294, August 2008.
[17] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) [17] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP)
Address in an IPv6 Multicast Address", RFC 3956, November 2004. Address in an IPv6 Multicast Address", RFC 3956, November 2004.
[18] Zheng, L., Zhang, Z. and R. Parekh, "Survey Report on PIM-SM [18] Zheng, L., Zhang, Z. and R. Parekh, "Survey Report on Protocol
Implementations and Deployments", draft-ietf-pim-rfc4601-update- Independent Multicast - Sparse Mode (PIM-SM) Implementations and
survey-report-03.txt, September 2013. Deployments", RFC 7063, December 2013.
Appendix A. Functionality removed from RFC 4601 Appendix A. Functionality removed from RFC 4601
Based on a survey of PIM implementations and deployments [18], Based on a survey of PIM implementations and deployments [18],
conducted by IETF PIM working group, the following functionality of conducted by IETF PIM working group, the following functionality of
RFC 4601 has been removed due to lack of sufficient RFC 4601 has been removed due to lack of sufficient implementation
implementation and deployment experience. and deployment experience.
o (*,*,RP) State o (*,*,RP) State
o PIM Mulitcast Border Router (PMBR) o PIM Multicast Border Router (PMBR)
Authors' Addresses Authors' Addresses
Bill Fenner Bill Fenner
AT&T Labs - Research AT&T Labs - Research
1 River Oaks Place 1 River Oaks Place
San Jose, CA 95134 San Jose, CA 95134
EMail: fenner@research.att.com EMail: fenner@research.att.com
 End of changes. 17 change blocks. 
37 lines changed or deleted 37 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/