draft-ietf-l2vpn-vpls-pim-snooping-06.txt   draft-ietf-l2vpn-vpls-pim-snooping-07.txt 
Layer 2 Virtual Private Networks O. Dornon Layer 2 Virtual Private Networks O. Dornon
Internet-Draft J. Kotalwar Internet-Draft J. Kotalwar
Intended status: Informational Alcatel-Lucent Intended status: Informational Alcatel-Lucent
Expires: October 31, 2014 V. Hemige Expires: April 25, 2015 V. Hemige
R. Qiu R. Qiu
Z. Zhang Z. Zhang
Juniper Networks, Inc. Juniper Networks, Inc.
April 29, 2014 October 22, 2014
PIM Snooping over VPLS Protocol Independent Multicast (PIM) over Virtual Private LAN Service
draft-ietf-l2vpn-vpls-pim-snooping-06 (VPLS)
draft-ietf-l2vpn-vpls-pim-snooping-07
Abstract Abstract
This document describes the procedures and recommendations for VPLS This document describes the procedures and recommendations for
PEs to facilitate replication of multicast traffic to only certain Virtual Private LAN Service (VPLS) Provider Edges (PEs) to facilitate
ports (behind which there are interested PIM routers and/or IGMP replication of multicast traffic to only certain ports (behind which
hosts) via PIM Snooping and PIM Proxy. there are interested Protocol Independent Multicast (PIM) routers
and/or Internet Group Management Protocol (IGMP) hosts) via Protocol
Independent Multicast (PIM) snooping and proxying.
With PIM Snooping, PEs passively listen to certain PIM control With PIM snooping, PEs passively listen to certain PIM control
messages to build control and forwarding states while transparently messages to build control and forwarding states while transparently
flooding those messages. With PIM Proxy, PEs do not flood PIM Join/ flooding those messages. With PIM proxying, Provider Edges (PEs) do
Prune messages but only generate their own and send out of certain not flood PIM Join/Prune messages but only generate their own and
ports, based on the control states built from downstream Join/Prune send out of certain ports, based on the control states built from
messages. PIM Proxy is required when PIM Join suppression is enabled downstream Join/Prune messages. PIM proxying is required when PIM
on the CE devices and useful to reduce PIM control traffic in a VPLS Join suppression is enabled on the Customer Equipment (CE) devices
domain. and useful to reduce PIM control traffic in a VPLS domain.
The document also describes PIM Relay, which can be viewed as light- The document also describes PIM relay, which can be viewed as light-
weight proxy, where all downstream Join/Prune messages are simply weight proxying, where all downstream Join/Prune messages are simply
forwarded out of certain ports but not flooded to avoid triggering forwarded out of certain ports but not flooded to avoid triggering
PIM Join suppression on CE devices. PIM Join suppression on CE devices.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
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 October 31, 2014. This Internet-Draft will expire on April 25, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Multicast Snooping in VPLS . . . . . . . . . . . . . . . . 5 1.1. Multicast Snooping in VPLS . . . . . . . . . . . . . . . 4
1.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
2. PIM Snooping for VPLS . . . . . . . . . . . . . . . . . . . . 7 2. PIM Snooping for VPLS . . . . . . . . . . . . . . . . . . . . 6
2.1. PIM protocol background . . . . . . . . . . . . . . . . . 7 2.1. PIM protocol background . . . . . . . . . . . . . . . . . 6
2.2. General Rules for PIM Snooping in VPLS . . . . . . . . . . 8 2.2. General Rules for PIM Snooping in VPLS . . . . . . . . . 7
2.2.1. Preserving Assert Trigger . . . . . . . . . . . . . . 8 2.2.1. Preserving Assert Trigger . . . . . . . . . . . . . . 7
2.3. Some Considerations for PIM Snooping . . . . . . . . . . . 9 2.3. Some Considerations for PIM Snooping . . . . . . . . . . 8
2.3.1. Scaling . . . . . . . . . . . . . . . . . . . . . . . 9 2.3.1. Scaling . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.3.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.3. PIM-SM (*,*,RP) . . . . . . . . . . . . . . . . . . . 10 2.3.3. PIM-SM (*,*,RP) . . . . . . . . . . . . . . . . . . . 9
2.4. PIM Snooping vs PIM Proxy . . . . . . . . . . . . . . . . 10 2.4. PIM Snooping vs PIM Proxying . . . . . . . . . . . . . . 9
2.4.1. Differences between PIM Snooping, Relay and Proxy . . 10 2.4.1. Differences between PIM Snooping, Relay and Proxying 9
2.4.2. PIM Control Message Latency . . . . . . . . . . . . . 11 2.4.2. PIM Control Message Latency . . . . . . . . . . . . . 10
2.4.3. When to Snoop and When to Proxy . . . . . . . . . . . 12 2.4.3. When to Snoop and When to Proxy . . . . . . . . . . . 11
2.5. Discovering PIM Routers . . . . . . . . . . . . . . . . . 13 2.5. Discovering PIM Routers . . . . . . . . . . . . . . . . . 12
2.6. PIM-SM and PIM-SSM . . . . . . . . . . . . . . . . . . . . 14 2.6. PIM-SM and PIM-SSM . . . . . . . . . . . . . . . . . . . 13
2.6.1. Building PIM-SM Snooping States . . . . . . . . . . . 14 2.6.1. Building PIM-SM Snooping States . . . . . . . . . . . 13
2.6.2. Explanation for per (S,G,N) states . . . . . . . . . . 17 2.6.2. Explanation for per (S,G,N) states . . . . . . . . . 16
2.6.3. Receiving (*,G) PIM-SM Join/Prune Messages . . . . . . 17 2.6.3. Receiving (*,G) PIM-SM Join/Prune Messages . . . . . 16
2.6.4. Receiving (S,G) PIM-SM Join/Prune Messages . . . . . . 19 2.6.4. Receiving (S,G) PIM-SM Join/Prune Messages . . . . . 18
2.6.5. Receiving (S,G,rpt) Join/Prune Messages . . . . . . . 21 2.6.5. Receiving (S,G,rpt) Join/Prune Messages . . . . . . . 20
2.6.6. Sending Join/Prune Messages Upstream . . . . . . . . . 21 2.6.6. Sending Join/Prune Messages Upstream . . . . . . . . 20
2.7. Bidirectional-PIM (PIM-BIDIR) . . . . . . . . . . . . . . 22 2.7. Bidirectional-PIM (BIDIR-PIM) . . . . . . . . . . . . . . 21
2.8. Interaction with IGMP Snooping . . . . . . . . . . . . . . 23 2.8. Interaction with IGMP Snooping . . . . . . . . . . . . . 22
2.9. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.9. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.9.1. Building PIM-DM Snooping States . . . . . . . . . . . 23 2.9.1. Building PIM-DM Snooping States . . . . . . . . . . . 22
2.9.2. PIM-DM Downstream Per-Port PIM(S,G,N) State Machine . 24 2.9.2. PIM-DM Downstream Per-Port PIM(S,G,N) State Machine . 23
2.9.3. Triggering ASSERT election in PIM-DM . . . . . . . . . 24 2.9.3. Triggering ASSERT election in PIM-DM . . . . . . . . 23
2.10. PIM Proxy . . . . . . . . . . . . . . . . . . . . . . . . 24 2.10. PIM Proxy . . . . . . . . . . . . . . . . . . . . . . . . 23
2.10.1. Upstream PIM Proxy behavior . . . . . . . . . . . . . 24 2.10.1. Upstream PIM Proxy behavior . . . . . . . . . . . . 23
2.11. Directly Connected Multicast Source . . . . . . . . . . . 25 2.11. Directly Connected Multicast Source . . . . . . . . . . . 24
2.12. Data Forwarding Rules . . . . . . . . . . . . . . . . . . 25 2.12. Data Forwarding Rules . . . . . . . . . . . . . . . . . . 24
2.12.1. PIM-SM Data Forwarding Rules . . . . . . . . . . . . . 26 2.12.1. PIM-SM Data Forwarding Rules . . . . . . . . . . . . 25
2.12.2. PIM-DM Data Forwarding Rules . . . . . . . . . . . . . 27 2.12.2. PIM-DM Data Forwarding Rules . . . . . . . . . . . . 26
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
4. Security Considerations . . . . . . . . . . . . . . . . . . . 28 4. Security Considerations . . . . . . . . . . . . . . . . . . . 27
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
7.1. Normative References . . . . . . . . . . . . . . . . . . . 29 7.1. Normative References . . . . . . . . . . . . . . . . . . 28
7.2. Informative References . . . . . . . . . . . . . . . . . . 29 7.2. Informative References . . . . . . . . . . . . . . . . . 28
Appendix A. PIM-BIDIR Thoughts . . . . . . . . . . . . . . . . . 30 Appendix A. BIDIR-PIM Thoughts . . . . . . . . . . . . . . . . . 29
A.1. PIM-BIDIR Data Forwarding Rules . . . . . . . . . . . . . 30 A.1. BIDIR-PIM Data Forwarding Rules . . . . . . . . . . . . . 29
Appendix B. Example Network Scenario . . . . . . . . . . . . . . 31 Appendix B. Example Network Scenario . . . . . . . . . . . . . . 30
B.1. Pim Snooping Example . . . . . . . . . . . . . . . . . . . 32 B.1. Pim Snooping Example . . . . . . . . . . . . . . . . . . 31
B.2. PIM Proxy Example with (S,G) / (*,G) interaction . . . . . 34 B.2. PIM Proxy Example with (S,G) / (*,G) interaction . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
In Virtual Private LAN Service (VPLS), the Provider Edge (PE) devices In Virtual Private LAN Service (VPLS), the Provider Edge (PE) devices
provide a logical interconnect such that Customer Edge (CE) devices provide a logical interconnect such that Customer Edge (CE) devices
belonging to a specific VPLS instance appear to be connected by a belonging to a specific VPLS instance appear to be connected by a
single LAN. Forwarding Information Base for a VPLS instance is single LAN. Forwarding Information Base for a VPLS instance is
populated dynamically by source MAC address learning. Once a unicast populated dynamically by source MAC address learning. Once a unicast
MAC address is learned and associated with a particular Attachment MAC address is learned and associated with a particular Attachment
Circuit (AC) or PseudoWire (PW), a frame destined to that MAC address Circuit (AC) or PseudoWire (PW), a frame destined to that MAC address
only needs to be sent on that AC or PW. only needs to be sent on that AC or PW.
For a frame not addressed to a known unicast MAC address, flooding For a frame not addressed to a known unicast MAC address, flooding
has to be used. This happen with the following so called BUM has to be used. This happens with the following so called BUM
traffic: (Broadcast Unknown Multicast) traffic:
o B: The destination MAC address is a broadcast address, o B: The destination MAC address is a broadcast address,
o U: The destination MAC address is unknown (has not been learned), o U: The destination MAC address is unknown (has not been learned),
o M: The destination MAC address is a multicast address. o M: The destination MAC address is a multicast address.
Multicast frames are flooded because a PE cannot know where multicast Multicast frames are flooded because a PE cannot know where
members reside. VPLS solutions (i.e., [VPLS-LDP] and [VPLS-BGP]) corresponding multicast group members reside. VPLS solutions (i.e.,
perform replication for multicast traffic at the ingress PE devices. [VPLS-LDP] and [VPLS-BGP]) perform replication for multicast traffic
As stated in the VPLS Multicast Requirements draft [VPLS-MCAST-REQ], at the ingress PE devices. As stated in the VPLS Multicast
there are two issues with VPLS Multicast today: Requirements draft [VPLS-MCAST-REQ], there are two issues with VPLS
multicast today:
o A. Multicast traffic is replicated to non-member sites. o A. Multicast traffic is replicated to non-member sites.
o B. Replication of PWs on shared physical path. o B. Replication on PWs on shared physical path.
Issue A can be solved by Multicast Snooping - PEs learn sites with Issue A can be solved by multicast snooping - PEs learn sites with
multicast members by snooping multicast protocol control messages and multicast group members by snooping multicast protocol control
forward IP multicast traffic only to member sites. This documents messages on ACs and forward IP multicast traffic only to member
describes the procedures to achieve that when PIM is running between sites. This document describes the procedures to achieve this when
the CE devices. Issue B is outside the scope of this document and CE devices are PIM adjacencies of each other. Issue B is outside the
discussed in[VPLS-MCAST-TREES]. scope of this document and discussed in[VPLS-MCAST-TREES].
While this document is in the context of VPLS, the procedures apply While this document is in the context of VPLS, the procedures apply
to regular layer-2 switches interconnected by physical connections as to regular layer-2 switches interconnected by physical connections as
well. In that case, the PW related concept/procedures are not well, albeit this is outside of the scope of this document. In that
applicable and that's all. case, the PW related concept/procedures are not applicable and that's
all.
1.1. Multicast Snooping in VPLS 1.1. Multicast Snooping in VPLS
IGMP Snooping procedures described in[IGMP-SNOOP] make sure that IP IGMP snooping procedures described in [IGMP-SNOOP] make sure that IP
multicast traffic is only sent out of the following: multicast traffic is only sent on the following:
o Attachment Circuits (ACs) connecting to hosts that report related o Attachment Circuits (ACs) connecting to hosts that report related
group membership group membership
o ACs connecting to routers o ACs connecting to routers that join related multicast groups
o PseudoWires (PWs) connecting to remote PEs that have the above o PseudoWires (PWs) connecting to remote PEs that have the above
described ACs described ACs
Notice that traffic is always sent out of ports connecting to Notice that traffic is always sent on ports that have point-to-point
routers, even those on which there are no snooped group memberships, connections to routers ot that are attached to a LAN on which there
because IGMP Snooping alone can not determine if there are interested is a router, even those on which there are no snooped group
receivers beyond those routers. To further restrict traffic sent to memberships, because IGMP snooping alone can not determine if there
those routers, PIM Snooping can be used, and this document describes are interested receivers beyond those routers. To further restrict
the procedures, including the rules when both IGMP and PIM are active traffic sent to those routers, PIM snooping can be used. This
in a VPLS instance. document describes the procedures for PIM snooping, including the
rules when both IGMP and PIM snooping are enabled in a VPLS instance,
which are elaborated in sections Section 2.8 and Section 2.11.
Note that for both IGMP and PIM, the term Snooping is used loosely, Note that for both IGMP and PIM, the term Snooping is used loosely,
referring to the fact that a layer-2 device peeks into layer-3 referring to the fact that a layer-2 device peeks into layer-3
routing protocol messages to build relevant control and forwarding routing protocol messages to build relevant control and forwarding
states. Depending on how the control messages are handled states. Depending on how the control messages are handled
(transparently flooded, selectively forwarded, or consumed and then (transparently flooded, selectively forwarded, or consumed and then
regenerated), the procedure/process may be called Snooping or Proxy regenerated), the procedure/process may be called Snooping or proxy
in different contexts. in different contexts.
Unless explicitly noted, the procedures in this document are used for Unless explicitly noted, the procedures in this document are used for
either PIM Snooping or PIM Proxy, and we will largely refer to PIM either PIM snooping or PIM proxying, and we will largely refer to PIM
"Snooping" in this document. The PIM Proxy specific procedures are snooping in this document. The PIM proxying specific procedures are
described in Section 2.6.6. Differences that need to be observed described in Section 2.6.6. Differences that need to be observed
while implementing one or the other and recommendations on which while implementing one or the other and recommendations on which
method to employ in different scenarios are noted in section method to employ in different scenarios are noted in section
Section 2.4. Section 2.4.
This document also describes PIM Relay, which can be viewed as light- This document also describes PIM relay, which can be viewed as light-
weight Proxy. Unless explicitly noted, in the rest of the document weight PIM proxying. Unless explicitly noted, in the rest of the
Proxy implicitly includes Relay as well. document proxying implicitly includes relay as well.
1.2. Assumptions 1.2. Assumptions
The document assumes that the reader has a good understanding of the This document assumes that the reader has good understanding of the
PIM protocols. The text in this draft is written in the same style PIM protocols. This document is written in the same style as the PIM
as the PIM RFCs to help correlate the concepts and to make it easier RFCs to help correlate the concepts and to make it easier to follow.
to follow. In order to avoid replicating the text relating to PIM In order to avoid replicating text related to PIM protocol handling
protocol handling here, this draft cross references into definitions from the PIM RFCs, this document cross references corresponding
of macros and procedures from the PIM RFCs, and assumes that the user definitions and procedures in these RFCs. Deviations in protocol
will infer such detail from those PIM RFCs. Deviations in protocol handling specific to PIM snooping are specified in this document.
handling specific to PIM Snooping are specified in this draft.
1.3. Definitions 1.3. Definitions
There are several definitions referenced in this document that are There are several definitions referenced in this document that are
well described in the PIM RFCs [PIM-SM], PIM-BIDIR, PIM-DM]. The well described in the PIM RFCs [PIM-SM], [BIDIR-PIM], [PIM-DM]. The
following definitions and abbreviations are used throughout this following definitions and abbreviations are used throughout this
document: document:
o A port is defined as either an attachment circuit (AC) or a o A port is defined as either an attachment circuit (AC) or a
Pseudo-Wire (PW). pseudowire (PW).
o When we say a PIM message is 'received' on a port, it means that a o When we say a PIM message is received on a PE port, it means that
PIM Snooping PE snooped the PIM message. the PE is processing the message for snooping/proxying or
relaying.
Abbreviations used in the document: Abbreviations used in the document:
o S: IP Address of the Multicast Source. o S: IP address of the multicast source.
o G: IP Address of the Multicast Group. o G: IP address of the multicast group.
o N: Upstream Neighbor field in a Join/Prune/Graft message. o N: Upstream neighbor field in a Join/Prune/Graft message.
o Rport(N): Port on which neighbor N is learnt. o Port(N): Port on which neighbor N is learnt.
o rpt : Rendezvous Point
o PIM-DM: Protocol Independent Multicast - Dense Mode.
o PIM-SM: Protocol Independent Multicast - Sparse Mode.
o PIM-SSM: Protocol Independent Multicast - Source Specific Mode.
Other definitions are explained in the sections where they are Other definitions are explained in the sections where they are
introduced. introduced.
2. PIM Snooping for VPLS 2. PIM Snooping for VPLS
2.1. PIM protocol background 2.1. PIM protocol background
PIM is a multicast routing protocol running between routers, which PIM is a multicast routing protocol running between routers, which
are CE devices in a VPLS. PIM shares many of the common are CE devices in a VPLS. PIM shares many of the common
characteristics of a routing protocol, such as discovery messages characteristics of a routing protocol, such as discovery messages
(e.g., neighbor discovery using Hello messages), topology information (e.g., neighbor discovery using Hello messages), topology information
(e.g., multicast tree), and error detection and notification (e.g., (e.g., multicast tree), and error detection and notification (e.g.,
dead timer and designated router election). PIM does not participate dead timer and designated router election). PIM does not participate
in exchange of unicast routing databases, but it uses the unicast in exchange of unicast routing databases, but it uses the unicast
routing table to provide reverse path information for building routing table to provide reverse path information for building
multicast trees. There are a few variants of PIM. In [PIM-DM], multicast trees. There are a few variants of PIM. In [PIM-DM],
multicast data is pushed towards the members similar to broadcast multicast datagrams are pushed towards downstream neighbors, similar
mechanism but routers without attached receivers will prune back to a broadcast mechanism, but in areas of the network where there are
no group members, routers prune back branches of the multicast tree
towards the source. Unlike PIM-DM, other PIM flavors (PIM-SM towards the source. Unlike PIM-DM, other PIM flavors (PIM-SM
[PIM-SM], PIM-SSM [PIM-SSM], and PIM-BIDIR [PIM-BIDIR]) employs a [PIM-SM], PIM-SSM [PIM-SSM], and BIDIR-PIM [BIDIR-PIM]) employ a pull
pull methodology via explicit joins instead of push technique. methodology via explicit joins instead of the push and prune
technique.
PIM routers periodically exchange Hello messages to discover and PIM routers periodically exchange Hello messages to discover and
maintain stateful sessions with neighbors. After neighbors are maintain stateful sessions with neighbors. After neighbors are
discovered, PIM routers can signal their intentions to join or prune discovered, PIM routers can signal their intentions to join or prune
specific multicast groups. This is accomplished by having downstream specific multicast groups. This is accomplished by having downstream
routers send an explicit Join/Prune message (for the sake of routers send an explicit Join/Prune message (for the sake of
generalization, consider Graft messages for PIM-DM as Join messages) generalization, consider Graft messages for PIM-DM as Join messages)
to the upstream routers. The Join/Prune message can be group to the upstream routers. The Join/Prune message can be group
specific (*,G) or group and source specific (S,G). specific (*,G) or group and source specific (S,G).
2.2. General Rules for PIM Snooping in VPLS 2.2. General Rules for PIM Snooping in VPLS
The following rules for the correct operation of PIM snooping MUST be The following rules for the correct operation of PIM snooping MUST be
followed. followed.
o PIM Snooping MUST NOT affect the operation of customer layer-2 o PIM snooping MUST NOT affect the operation of customer layer-2
protocols (e.g., BPDUs) or layer-3 protocols. protocols (e.g., BPDUs) or layer-3 protocols.
o PIM messages and multicast data traffic forwarded by PEs MUST o PIM messages and multicast data traffic forwarded by PEs MUST
follow the split-horizon rule for mesh PWs. follow the split-horizon rule for mesh PWs.
o PIM snooping states in a PE MUST be per VPLS instance. o PIM snooping states in a PE MUST be per VPLS instance.
o PIM assert triggers MUST be preserved to the extent necessary to o PIM assert triggers MUST be preserved to the extent necessary to
avoid sending duplicate traffic to the same PE (see avoid sending duplicate traffic to the same PE (see
Section 2.2.1). Section 2.2.1).
2.2.1. Preserving Assert Trigger 2.2.1. Preserving Assert Trigger
In PIM-SM/DM, there are scenarios where multiple routers could be In PIM-SM/DM, there are scenarios where multiple routers could be
forwarding the same multicast traffic on a LAN. When this happens, forwarding the same multicast traffic on a LAN. When this happens,
using PIM Assert Election process by sending PIM Assert Messages, using PIM Assert election process by sending PIM Assert messages,
routers ensure that only the Assert Winner forwards traffic on the routers ensure that only the Assert winner forwards traffic on the
LAN. The Assert Election is a data driven event and happens only if LAN. The Assert election is a data driven event and happens only if
a router sees traffic on the interface to which it should be a router sees traffic on the interface to which it should be
forwarding the traffic. In the case of VPLS with snooping, two forwarding the traffic. In the case of VPLS with PIM snooping, two
routers may forward the same flow at the same time but each copy may routers may forward the same multicast datagrams at the same time but
reach different set of PEs, and that is acceptable from the point of each copy may reach different set of PEs, and that is acceptable from
view of avoiding duplicate traffic. If the two copies may reach the the point of view of avoiding duplicate traffic. If the two copies
same PE then the sending routers must be able to see each other's may reach the same PE then the sending routers must be able to see
traffic, in order to trigger Assert Election and stop duplicate each other's traffic, in order to trigger Assert election and stop
traffic. duplicate traffic. To achieve that, PEs enabled with PIM-SSM/SM
snooping MUSTforward multicast traffic for an (S,G)/(*,G) not only on
To achieve that, PIM-SM Snooping MUST not only forward multicast the ports on which they snooped Joins(S,G)/Joins(*,G), but also
traffic for an (S,G) on the ports on which they snooped Joins(S,G)/ towards the upstream neighbor(s)). In other words, the ports on
Joins(*,G), but also towards the upstream neighbor(s)). In other which the upstream neighbors are learnt must be added to the outgoing
words, the ports on which the upstream neighbors are learnt must be port list along with the ports on which Joins are snooped.
added to the outgoing port list along with the ports on which Joins
are snooped.
Similarly, PIM-DM Snooping SHOULD make sure that asserts can be Similarly, PIM-DM snooping SHOULD make sure that asserts can be
triggered (Section 2.9.3). triggered (Section 2.9.3).
The above logic needs to be facilitated without breaking VPLS Split The above logic needs to be facilitated without breaking VPLS split-
Horizon Rules. i.e. traffic should not be forwarded on the port on horizon forwarding rules. That is, traffic should not be forwarded
which it was received, and traffic arriving on a PW MUST NOT be on the port on which it was received, and traffic arriving on a PW
forwarded onto other PW(s). MUST NOT be forwarded onto other PW(s).
2.3. Some Considerations for PIM Snooping 2.3. Some Considerations for PIM Snooping
The PIM Snooping solution described here requires a PE to examine and The PIM snooping solution described here requires a PE to examine and
operate on only PIM Hello and PIM Join/Prune packets. The PE does operate on only PIM Hello and PIM Join/Prune packets. The PE does
not need to examine any other PIM packets. not need to examine any other PIM packets.
Most of the procedures in PIM Snooping in the handling of PIM Hellos Most of the PIM snooping procedures for handling Hello/Join/Prune
and PIM Join/Prune packets are very similar to that of a PIM Router. messages are very similar to those executed in a PIM router.
However, the PE does not need to have any routing tables like as
However, the PE does not need to have any routing tables like is required in PIM multicast routing. It knows how to forward Join/
required in PIM Multicast Routing. It knows how to forward Join/ Prunes only by looking at the Upstream Neighbor field in the Join/
Prunes by looking at the Upstream Neighbor field in the Join/Prune Prune packets.
packets.
The PE does not need to know about Rendezvous Points (RP) and does The PE does not need to know about Rendezvous Points (RP) and does
not have to maintain any RP Set. All that is transparent to a PIM not have to maintain any RP Set. All that is transparent to a PIM
Snooping PE. snooping PE.
In the following sub-sections, we list some considerations and In the following sub-sections, we list some considerations and
observations for the implementation of PIM Snooping in VPLS. observations for the implementation of PIM snooping in VPLS.
2.3.1. Scaling 2.3.1. Scaling
Snooping needs to be employed on ACs at the downstream PEs to prevent PIM snooping needs to be employed on ACs at the downstream PEs (PEs
traffic from being sent out of ACs unnecessarily. Snooping receiving multicast traffic across the VPLS core) to prevent traffic
techniques can also be employed on PWs at the upstream PEs to prevent from being sent out of ACs unnecessarily. PIM snooping techniques
traffic from being sent to PEs unnecessarily. This may work well for can also be employed on PWs at the upstream PEs (PEs receiving
small to medium scale deployments. However, if there are a large traffic from local ACs in a hierarchical VPLS) to prevent traffic
number of VPLS instances with a large number of PEs per instances, from being sent to PEs unnecessarily. This may work well for small
then the amount of snooping required at the upstream PEs can to medium scale deployments. However, if there are a large number of
overwhelm the upstream PEs. VPLS instances with a large number of PEs per instance, then the
amount of snooping required at the upstream PEs can overwhelm the
upstream PEs.
There are two methods to reduce the burden on the upstream PEs. One There are two methods to reduce the burden on the upstream PEs. One
is to use PIM Proxy as described in Section 2.6.6, to reduce the is to use PIM proxying as described in Section 2.6.6, to reduce the
control messages forwarded by a PE. The other is not to snoop on the control messages forwarded by a PE. The other is not to snoop on the
PWs at all, but PEs signal the snooped states to other PEs out of PWs at all, but PEs signal the snooped states to other PEs out of
band via BGP, as described in [VPLS-MCAST-TREES]. In this document, band via BGP, as described in [VPLS-MCAST-TREES]. In this document,
it is assumed that Snooping is performed on PWs. it is assumed that snooping is performed on PWs.
2.3.2. IPv6 2.3.2. IPv6
In VPLS, PEs forward Ethernet frames received from CEs and as such In VPLS, PEs forward Ethernet frames received from CEs and as such
are agnostic of the layer-3 protocol used by the CEs. However, as an are agnostic of the layer-3 protocol used by the CEs. However, as a
IGMP and PIM snooping PE, the PE would have to look deeper into the PIM snooping PE, the PE would have to look deeper into the IP and PIM
IP and IGMP/PIM packets and build snooping state based on that. The packets and build snooping state based on that. The PIM Protocol
PIM Protocol specifications handle both IPv4 and IPv6. The specifications handle both IPv4 and IPv6. The specification for PIM
specification for PIM Snooping in this draft can be applied to both snooping in this draft can be applied to both IPv4 and IPv6 payloads.
IPv4 and IPv6 payloads.
2.3.3. PIM-SM (*,*,RP) 2.3.3. PIM-SM (*,*,RP)
This draft does not address (*,*,RP) states in the VPLS network. This document does not address (*,*,RP) states in the VPLS network.
Although [PIM-SM] specifies that routers MUST support (*,*,RP) Although [PIM-SM] specifies that routers must support (*,*,RP)
states, there are very few implementations that actually support it states, there are very few implementations that actually support it
in actual deployments, and it is being removed from the PIM protocol in actual deployments, and it is being removed from the PIM protocol
in its ongoing advancement process in IETF. Given that, this draft in its ongoing advancement process in IETF. Given that, this
omits the specification relating to (*,*,RP) support. document omits the specification relating to (*,*,RP) support.
2.4. PIM Snooping vs PIM Proxy 2.4. PIM Snooping vs PIM Proxying
The document has previously alluded to PIM Snooping/Relay/Proxy. This document has previously alluded to PIM snooping/relay/proxying.
Details on the PIM Proxy/Relay solution are discussed in Details on the PIM relay/proxying solution are discussed in
Section 2.6.6. In this section, a brief description and comparison Section 2.6.6. In this section, a brief description and comparison
are given. are given.
2.4.1. Differences between PIM Snooping, Relay and Proxy 2.4.1. Differences between PIM Snooping, Relay and Proxying
Differences between PIM Snooping and Proxy/Relay can be summarized as Differences between PIM snooping and relay/proxying can be summarized
the following: as the following:
+----------------------+---------------------+-----------------------+ +--------------------+---------------------+-----------------------+
| PIM Snooping | PIM Relay | PIM Proxy | | PIM snooping | PIM relay | PIM proxying |
+======================|=====================|=======================+ +====================|=====================|=======================+
| Join/Prune messages | Join/Prune messages | Join/Prune messages | | Join/Prune messages| Join/Prune messages | Join/Prune messages |
| snooped and flooded | snooped; forwarded | consumed. Regenerated | | snooped and flooded| snooped; forwarded | consumed. Regenerated |
| everywhere | as is out of certain| ones sent out of | | everywhere | as is out of certain| ones sent out of |
| | upstream ports | certain upstream ports| | | upstream ports | certain upstream ports|
+----------------------+---------------------+-----------------------+ +--------------------+---------------------+-----------------------+
| No PIM packets | No PIM packets | New Join/Prune | | No PIM packets | No PIM packets | New Join/Prune |
| generated. | generated | messages generated | | generated. | generated | messages generated |
+----------------------+---------------------+-----------------------+ +--------------------+---------------------+-----------------------+
| CE Join Suppression | CE Join Suppression | CE Join Suppression | | CE Join suppression| CE Join Suppression | CE Join suppression |
| not allowed | allowed | allowed | | not allowed | allowed | allowed |
+----------------------+---------------------+-----------------------+ +--------------------+---------------------+-----------------------+
Note that the differences apply only to PIM Join/Prune messages. PIM Note that the differences apply only to PIM Join/Prune messages. PIM
Hello messages are snooped and flooded in all cases. Hello messages are snooped and flooded in all cases.
Other than the above differences, most of the procedures are common Other than the above differences, most of the procedures are common
to PIM Snooping and PIM Proxy/Relay, unless specifically stated to PIM snooping and PIM relay/proxying, unless specifically stated
otherwise. otherwise.
Pure PIM Snooping PEs simply snoop on PIM packets as they are being Pure PIM snooping PEs simply snoop on PIM packets as they are being
forwarded in the VPLS. As such they truly provide transparent LAN forwarded in the VPLS. As such they truly provide transparent LAN
services since no customer packets are modified or consumed or new services since no customer packets are modified or consumed or new
packets introduced in the VPLS. It is also simpler to implement than packets introduced in the VPLS. It is also simpler to implement than
PIM Proxy. However for PIM Snooping to work correctly, it is a PIM proxying. However for PIM snooping to work correctly, it is a
requirement that CE routers MUST disable Join suppression in the requirement that CE routers MUST disable Join suppression in the
VPLS. VPLS.
Given that a large number of existing CE deployments do not support Given that a large number of existing CE deployments do not support
disabling of Join suppression and given the operational complexity disabling of Join suppression and given the operational complexity
for a provider to manage disabling of Join suppression in the VPLS, for a provider to manage disabling of Join suppression in the VPLS,
it becomes a difficult solution to deploy. Another disadvantage of it becomes a difficult solution to deploy. Another disadvantage of
PIM Snooping is that it does not scale as well as PIM Proxy. If PIM snooping is that it does not scale as well as PIM proxying. If
there are a large number of CEs in a VPLS, then every CE will see there are a large number of CEs in a VPLS, then every CE will see
every other CE's Join/Prune messages. every other CE's Join/Prune messages.
PIM Proxy/Relay has the advantage that it does not require Join PIM relay/proxying has the advantage that it does not require Join
suppression to be disabled in the VPLS. Multicast as a VPLS service suppression to be disabled in the VPLS. Multicast as a VPLS service
can be very easily provided without requiring any changes on the CE can be very easily provided without requiring any changes on the CE
routers. PIM Proxy/Relay helps scale VPLS Multicast since Join/Prune routers. PIM relay/proxying helps scale VPLS Multicast since Join/
messages are only sent to certain upstream ports instead of flooded, Prune messages are only sent to certain upstream ports instead of
and in case of full Proxy (vs. Relay) the PEs intelligently generate flooded, and in case of full proxying (vs. relay) the PEs
only one Join/Prune message for a given flow. intelligently generate only one Join/Prune message for a given
multicast stream.
PIM Proxy however loses the transparency argument since Join/Prunes PIM proxying however loses the transparency argument since Join/
could get modified or even consumed at a PE. Also, new packets could Prunes could get modified or even consumed at a PE. Also, new
get introduced in the VPLS. However, this loss of transparency is packets could get introduced in the VPLS. However, this loss of
limited to PIM Join/Prune packets. It is in the interest of transparency is limited to PIM Join/Prune packets. It is in the
optimizing multicast in the VPLS and helping a VPLS network scale interest of optimizing multicast in the VPLS and helping a VPLS
much better. Data traffic will still be completely transparent. network scale much better. Data traffic will still be completely
transparent.
2.4.2. PIM Control Message Latency 2.4.2. PIM Control Message Latency
A PIM Snooping/Proxy/Relay PE snoops on PIM Hello packets while A PIM snooping/relay/proxying PE snoops on PIM Hello packets while
transparently flooding them in the VPLS. As such there is no latency transparently flooding them in the VPLS. As such there is no latency
introduced by the VPLS in the delivery of PIM Hello packets to remote introduced by the VPLS in the delivery of PIM Hello packets to remote
CEs in the VPLS. CEs in the VPLS.
A PIM Snooping PE snoops on PIM Join/Prune packets while A PIM snooping PE snoops on PIM Join/Prune packets while
transparently flooding them in the VPLS. There is no latency transparently flooding them in the VPLS. There is no latency
introduced by the VPLS in the delivery of PIM Join/Prune packets when introduced by the VPLS in the delivery of PIM Join/Prune packets when
PIM Snooping is employed. PIM snooping is employed.
A PIM Proxy/Relay PE does not simply flood PIM Join/Prune packets. A PIM relay/proxying PE does not simply flood PIM Join/Prune packets.
This can result in additional latency for a downstream CE to receive This can result in additional latency for a downstream CE to receive
multicast traffic after it has sent a Join. When a downstream CE multicast traffic after it has sent a Join. When a downstream CE
prunes a multicast stream, the traffic should stop flowing to the CE prunes a multicast stream, the traffic SHOULD stop flowing to the CE
with no additional latency introduced by the VPLS. with no additional latency introduced by the VPLS.
Performing only proxy of Join/Prune and not Hello messages keeps the Performing only proxying of Join/Prune and not Hello messages keeps
PE behavior very similar to that of a PIM router without introducing the PE behavior very similar to that of a PIM router without
too much additional complexity. It keeps the PIM Proxy solution introducing too much additional complexity. It keeps the PIM
fairly simple. Since Join/Prunes are forwarded by a PE along the proxying solution fairly simple. Since Join/Prunes are forwarded by
slow-path and all other PIM packet types are forwarded along the a PE along the slow-path and all other PIM packet types are forwarded
fast-path, it is very likely that packets forwarded along the fast- along the fast-path, it is very likely that packets forwarded along
path will arrive "ahead" of Join/Prune packets at a CE router (note the fast-path will arrive "ahead" of Join/Prune packets at a CE
the stress on the fact that fast-path messages will never arrive router (note the stress on the fact that fast-path messages will
after Join/Prunes). Of particular importance are Hello packets sent never arrive after Join/Prunes). Of particular importance are Hello
along the fast-path. We can construct a variety of scenarios packets sent along the fast-path. We can construct a variety of
resulting in out of order delivery of Hellos and Join/Prune messages. scenarios resulting in out of order delivery of Hellos and Join/Prune
However, there should be no deviation from normal expected behavior messages. However, there should be no deviation from normal expected
observed at the CE router receiving these messages out of order. behavior observed at the CE router receiving these messages out of
order.
2.4.3. When to Snoop and When to Proxy 2.4.3. When to Snoop and When to Proxy
From the above descriptions, factors that affect the choice of From the above descriptions, factors that affect the choice of
Snooping/Relay/Proxy include: snooping/relay/proxying include:
o Whether CEs do Join Suppression or not o Whether CEs do Join Suppression or not
o Whether Join/Prune latency is critical or not o Whether Join/Prune latency is critical or not
o Whether the scale of PIM protocol message/states in a VPLS o Whether the scale of PIM protocol message/states in a VPLS
requires the scaling benefit of Proxy requires the scaling benefit of proxying
Of the above factors, Join Suppression is the hard one - pure Of the above factors, Join Suppression is the hard one - pure
Snooping can only be used when Join Suppression is disabled on all snooping can only be used when Join Suppression is disabled on all
CEs. The latency associated with Relay/Proxy is implementation CEs. The latency associated with relay/proxying is implementation
dependent and may not be a concern at all with a particular dependent and may not be a concern at all with a particular
implementation. The scaling benefit may not be important either, in implementation. The scaling benefit may not be important either, in
that on a real LAN with Explicit Tracking (ET) a PIM router will need that on a real LAN with Explicit Tracking (ET) a PIM router will need
to receive and process all PIM Join/Prune messages as well. to receive and process all PIM Join/Prune messages as well.
A PIM router indicates that Join Suppression is disabled if the T-bit A PIM router indicates that Join Suppression is disabled if the T-bit
is set in the LAN Prune Delay option of its Hello message. If all is set in the LAN Prune Delay option of its Hello message. If all
PIM routers on a LAN set the T-bit, Explicit Tracking is possible, PIM routers on a LAN set the T-bit, Explicit Tracking is possible,
allowing an upstream router to track all the downstream neighbors allowing an upstream router to track all the downstream neighbors
that have Join states for any (S,G) or (*,G). That has two benefits: that have Join states for any (S,G) or (*,G). That has two benefits:
o No need for PrunePending process - the upstream router may o No need for PrunePending process - the upstream router may
immediately stop forwarding data when it receives a Prune from the immediately stop forwarding data when it receives a Prune from the
last downstream neighbor, and immediately prune to its upstream if last downstream neighbor, and immediately prune to its upstream if
that's for the last downstream interface. that's for the last downstream interface.
o For management purpose, the upstream router knows exactly which o For management purpose, the upstream router knows exactly which
downstream routers exist for a particular Join State. downstream routers exist for a particular Join State.
While full Proxy can be used with or without Join Suppression on CEs While full proxying can be used with or without Join Suppression on
and does not interfere with an upstream CE's bypass of PrunePending CEs and does not interfere with an upstream CE's bypass of
process, it does proxy all its downstream CEs as a single one to the PrunePending process, it does proxy all its downstream CEs as a
upstream, removing the second benefit mentioned above. single one to the upstream, removing the second benefit mentioned
above.
Therefore, the general rule is that if Join Suppression is enabled on Therefore, the general rule is that if Join Suppression is enabled on
CEs then Proxy or Relay MUST be used and if Suppression is known to CEs then proxying or relay MUST be used and if Suppression is known
be disabled on all CEs then either Snooping, Relay, or Proxy MAY be to be disabled on all CEs then either snooping, relay, or proxying
used while Snooping or Relay SHOULD be used. MAY be used while snooping or relay SHOULD be used.
An implementation MAY choose dynamic determination of which mode to An implementation MAY choose dynamic determination of which mode to
use, through the tracking of the above mentioned T-bit in all snooped use, through the tracking of the above mentioned T-bit in all snooped
PIM Hello messages, or MAY simply require static provisioning. PIM Hello messages, or MAY simply require static provisioning.
2.5. Discovering PIM Routers 2.5. Discovering PIM Routers
A PIM Snooping PE MUST snoop on PIM Hellos received on ACs and PWs. A PIM snooping PE MUST snoop on PIM Hellos received on ACs and PWs.
i.e. the PE transparently floods the PIM Hello while snooping on it. i.e., the PE transparently floods the PIM Hello while snooping on it.
PIM Hellos are used by the snooping PE to discover PIM routers and PIM Hellos are used by the snooping PE to discover PIM routers and
their characteristics. their characteristics.
For each neighbor discovered by a PE, it includes an entry in the PIM For each neighbor discovered by a PE, it includes an entry in the PIM
Neighbor Database with the following fields: Neighbor Database with the following fields:
o Layer 2 encapsulation for the Router sending the PIM Hello. o Layer 2 encapsulation for the Router sending the PIM Hello.
o IP Address and address family of the Router sending the PIM Hello. o IP Address and address family of the Router sending the PIM Hello.
skipping to change at page 14, line 32 skipping to change at page 13, line 32
behavior. In this model, multicast traffic is only forwarded to behavior. In this model, multicast traffic is only forwarded to
locations that specifically request it. The root node of a tree is locations that specifically request it. The root node of a tree is
the Rendezvous Point (RP) in case of a shared tree (PIM-SM only) or the Rendezvous Point (RP) in case of a shared tree (PIM-SM only) or
the first hop router that is directly connected to the multicast the first hop router that is directly connected to the multicast
source in the case of a shortest path tree. All the procedures source in the case of a shortest path tree. All the procedures
described in this section apply to both PIM-SM and PIM-SSM, except described in this section apply to both PIM-SM and PIM-SSM, except
for the fact that there is no (*,G) state in PIM-SSM. for the fact that there is no (*,G) state in PIM-SSM.
2.6.1. Building PIM-SM Snooping States 2.6.1. Building PIM-SM Snooping States
PIM-SM and PIM-SSM Snooping states are built by snooping on the PIM-SM and PIM-SSM snooping states are built by snooping on the PIM-
PIM-SM Join/Prune messages received on AC/PWs. SM Join/Prune messages received on AC/PWs.
The downstream state machine of a PIM-SM snooping PE very closely The downstream state machine of a PIM-SM snooping PE very closely
resembles the downstream state machine of PIM-SM routers. The resembles the downstream state machine of PIM-SM routers. The
downstream state consists of: downstream state consists of:
Per downstream (Port, *, G): Per downstream (Port, *, G):
o DownstreamJPState: One of { "NoInfo" (NI), "Join" (J), "Prune o DownstreamJPState: One of { "NoInfo" (NI), "Join" (J), "Prune
Pending" (PP) } Pending" (PP) }
skipping to change at page 15, line 28 skipping to change at page 14, line 28
Per downstream (Port, S, G, rpt, N): Per downstream (Port, S, G, rpt, N):
o Prune Pending Timer (PPT(N)) o Prune Pending Timer (PPT(N))
o Join Expiry Timer (ET(N)) o Join Expiry Timer (ET(N))
Where S is the address of the multicast source, G is the Group Where S is the address of the multicast source, G is the Group
address and N is the upstream neighbor field in the Join/Prune address and N is the upstream neighbor field in the Join/Prune
message. Notice that unlike on PIM-SM routers where PPT and ET are message. Notice that unlike on PIM-SM routers where PPT and ET are
per (Interface, S, G), PIM Snooping PEs have to maintain PPT and ET per (Interface, S, G), PIM snooping PEs have to maintain PPT and ET
per (Port, S, G, N). The reasons for this are explained in per (Port, S, G, N). The reasons for this are explained in
Section 2.6.2. Section 2.6.2.
Apart from the above states, we define the following state Apart from the above states, we define the following state
summarization macros. summarization macros.
UpstreamNeighbors(*,G): If there is one or more Join(*,G) received on UpstreamNeighbors(*,G): If there is one or more Join(*,G) received on
any port with upstream neighbor N and ET(N) is active, then N is any port with upstream neighbor N and ET(N) is active, then N is
added to UpstreamNeighbors(*,G). This set is used to determine if a added to UpstreamNeighbors(*,G). This set is used to determine if a
Join(*,G) or a Prune(*,G) with upstream neighbor N needs to be sent Join(*,G) or a Prune(*,G) with upstream neighbor N needs to be sent
upstream. upstream.
UpstreamNeighbors(S,G): If there is one or more Join(S,G) received on UpstreamNeighbors(S,G): If there is one or more Join(S,G) received on
any port with upstream neighbor N and ET(N) is active, then N is any port with upstream neighbor N and ET(N) is active, then N is
added to UpstreamNeighbors(S,G). This set is used to determine if a added to UpstreamNeighbors(S,G). This set is used to determine if a
Join(S,G) or a Prune(S,G) with upstream neighbor N needs to be sent Join(S,G) or a Prune(S,G) with upstream neighbor N needs to be sent
upstream. upstream.
UpstreamPorts(*,G): This is the set of all Rport(N) ports where N is UpstreamPorts(*,G): This is the set of all Port(N) ports where N is
in the set UpstreamNeighbors(*,G). Multicast Streams forwarded using in the set UpstreamNeighbors(*,G). Multicast Streams forwarded using
a (*,G) match MUST be forwarded to these ports in addition to a (*,G) match MUST be forwarded to these ports. So
downstream ports. So UpstreamPorts(*,G) MUST be added to UpstreamPorts(*,G) MUST be added to OutgoingPortList(*,G).
OutgoingPortList(*,G).
UpstreamPorts(S,G): This is the set of all Rport(N) ports where N is UpstreamPorts(S,G): This is the set of all Port(N) ports where N is
in the set UpstreamNeighbors(S,G). UpstreamPorts(S,G) MUST be added in the set UpstreamNeighbors(S,G). UpstreamPorts(S,G) MUST be added
to OutgoingPortList(S,G). to OutgoingPortList(S,G).
InheritedUpstreamPorts(S,G): This is the union of UpstreamPorts(S,G) InheritedUpstreamPorts(S,G): This is the union of UpstreamPorts(S,G)
and UpstreamPorts(*,G). and UpstreamPorts(*,G).
UpstreamPorts(S,G,rpt): If PruneDesired(S,G,rpt) becomes true, then UpstreamPorts(S,G,rpt): If PruneDesired(S,G,rpt) becomes true, then
this set is set to UpstreamPorts(*,G). Otherwise, this set is empty. this set is set to UpstreamPorts(*,G). Otherwise, this set is empty.
UpstreamPorts(*,G) (-) UpstreamPorts(S,G,rpt) MUST be added to UpstreamPorts(*,G) (-) UpstreamPorts(S,G,rpt) MUST be added to
OutgoingPortList(S,G). OutgoingPortList(S,G).
UpstreamPorts(G): This set is the union of all the UpstreamPorts(S,G) UpstreamPorts(G): This set is the union of all the UpstreamPorts(S,G)
and UpstreamPorts(*,G) for a given G. Proxy (S,G) Join/Prune and and UpstreamPorts(*,G) for a given G. proxy (S,G) Join/Prune and
(*,G) Join/Prune messages MUST be sent to a subset of (*,G) Join/Prune messages MUST be sent to a subset of
UpstreamPorts(G) as specified in Section 2.6.6.1. UpstreamPorts(G) as specified in Section 2.6.6.1.
PWPorts: This is the set of all PWs. PWPorts: This is the set of all PWs.
OutgoingPortList(*,G): This is the set of all ports to which traffic OutgoingPortList(*,G): This is the set of all ports to which traffic
needs to be forwarded on a (*,G) match. needs to be forwarded on a (*,G) match.
OutgoingPortList(S,G): This is the set of all ports to which traffic OutgoingPortList(S,G): This is the set of all ports to which traffic
needs to be forwarded on an (S,G) match. needs to be forwarded on an (S,G) match.
skipping to change at page 17, line 10 skipping to change at page 16, line 10
copied to RpfVectorTlvs(S,G). copied to RpfVectorTlvs(S,G).
Since there are a few differences between the downstream state Since there are a few differences between the downstream state
machines of PIM-SM Routers and PIM-SM snooping PEs, we specify the machines of PIM-SM Routers and PIM-SM snooping PEs, we specify the
details of the downstream state machine of PIM-SM snooping PEs at the details of the downstream state machine of PIM-SM snooping PEs at the
risk of repeating most of the text documented in [PIM-SM]. risk of repeating most of the text documented in [PIM-SM].
2.6.2. Explanation for per (S,G,N) states 2.6.2. Explanation for per (S,G,N) states
In PIM Routing protocols, states are built per (S,G). On a router, In PIM Routing protocols, states are built per (S,G). On a router,
an (S,G) has only one RPF-Neighbor. However, a PIM Snooping PE does an (S,G) has only one RPF-Neighbor. However, a PIM snooping PE does
not have the Layer 3 routing information available to the routers in not have the Layer 3 routing information available to the routers in
order to determine the RPF-Neighbor for a multicast flow. It merely order to determine the RPF-Neighbor for a multicast flow. It merely
discovers it by snooping the Join/Prune message. A PE could have discovers it by snooping the Join/Prune message. A PE could have
snooped on two or more different Join/Prune messages for the same snooped on two or more different Join/Prune messages for the same
(S,G) that could have carried different Upstream-Neighbor fields. (S,G) that could have carried different Upstream-Neighbor fields.
This could happen during transient network conditions or due to dual- This could happen during transient network conditions or due to dual-
homed sources. A PE cannot make assumptions on which one to pick, homed sources. A PE cannot make assumptions on which one to pick,
but instead must facilitate the CE routers decide which Upstream but instead must facilitate the CE routers decide which Upstream
Neighbor gets elected the RPF-Neighbor. And for this purpose, the PE Neighbor gets elected the RPF-Neighbor. And for this purpose, the PE
will have to track downstream and upstream Join/Prune per (S,G,N). will have to track downstream and upstream Join/Prune per (S,G,N).
2.6.3. Receiving (*,G) PIM-SM Join/Prune Messages 2.6.3. Receiving (*,G) PIM-SM Join/Prune Messages
A Join(*,G) or Prune(*,G) is considered "received" if the following A Join(*,G) or Prune(*,G) is considered "received" if the following
conditions are met: conditions are met:
o The port on which it arrived is not Rport(N) where N is the o The port on which it arrived is not Port(N) where N is the
upstream-neighbor N of the Join/Prune(*,G), or, upstream-neighbor N of the Join/Prune(*,G), or,
o if both RPort(N) and the arrival port are PWs, then there exists o if both Port(N) and the arrival port are PWs, then there exists at
at least one other (*,G,Nx) or (Sx,G,Nx) state with an AC least one other (*,G,Nx) or (Sx,G,Nx) state with an AC
UpstreamPort. UpstreamPort.
For simplicity, the case where both RPort(N) and the arrival port are For simplicity, the case where both Port(N) and the arrival port are
PWs is referred to as PW-only Join/Prune in this document. The PW- PWs is referred to as PW-only Join/Prune in this document. The PW-
only Join/Prune handling is so that the RPort(N) PW can be added to only Join/Prune handling is so that the Port(N) PW can be added to
the related forwarding entries' OutgoingPortList to trigger Assert, the related forwarding entries' OutgoingPortList to trigger Assert,
but that is only needed for those states with AC UpstreamPort. Note but that is only needed for those states with AC UpstreamPort. Note
that in PW-only case, it is OK for the arrival port and RPort(N) to that in PW-only case, it is OK for the arrival port and Port(N) to be
be the same. See Appendix Appendix B for examples. the same. See Appendix B for examples.
When a router receives a Join(*,G) or a Prune(*,G) with upstream When a router receives a Join(*,G) or a Prune(*,G) with upstream
neighbor N, it must process the message as defined in the state neighbor N, it must process the message as defined in the state
machine below. Note that the macro computations of the various machine below. Note that the macro computations of the various
macros resulting from this state machine transition is exactly as macros resulting from this state machine transition is exactly as
specified in the PIM-SM RFC [PIM-SM]. specified in the PIM-SM RFC [PIM-SM].
We define the following per-port (*,G,N) macro to help with the state We define the following per-port (*,G,N) macro to help with the state
machine below. machine below.
skipping to change at page 19, line 7 skipping to change at page 18, line 7
Action PPTExpiry(N): Action PPTExpiry(N):
Same as Action ETExpiry(N) below, plus Send a Prune-Echo(*,G) with Same as Action ETExpiry(N) below, plus Send a Prune-Echo(*,G) with
upstream-neighbor N on the downstream port. upstream-neighbor N on the downstream port.
Action ETExpiry(N): Action ETExpiry(N):
Disable timers ET(N) and PPT(N). Delete neighbor state Disable timers ET(N) and PPT(N). Delete neighbor state
(Port,*,G,N). If there are no other (Port,*,G) states with (Port,*,G,N). If there are no other (Port,*,G) states with
NumETsActive(Port,*,G) > 0, transition DownstreamJPState to NumETsActive(Port,*,G) > 0, transition DownstreamJPState [PIM-SM]
NoInfo. If there are no other (Port,*,G,N) state (different ports to NoInfo. If there are no other (Port,*,G,N) state (different
but for the same N), remove N from UpstreamPorts(*,G) - this also ports but for the same N), remove N from UpstreamPorts(*,G) - this
serves as a trigger for US FSM (JoinDesired(*,G,N) becomes FALSE). also serves as a trigger for Upstream FSM (JoinDesired(*,G,N)
becomes FALSE).
2.6.4. Receiving (S,G) PIM-SM Join/Prune Messages 2.6.4. Receiving (S,G) PIM-SM Join/Prune Messages
A Join(S,G) or Prune(S,G) is considered "received" if the following A Join(S,G) or Prune(S,G) is considered "received" if the following
conditions are met: conditions are met:
o The port on which it arrived is not Rport(N) where N is the o The port on which it arrived is not Port(N) where N is the
upstream-neighbor N of the Join/Prune(S,G), or, upstream-neighbor N of the Join/Prune(S,G), or,
o if both RPort(N) and the arrival port are PWs, then there exists o if both Port(N) and the arrival port are PWs, then there exists at
at least one other (*,G,Nx) or (S,G,Nx) state with an AC least one other (*,G,Nx) or (S,G,Nx) state with an AC
UpstreamPort. UpstreamPort.
For simplicity, the case where both RPort(N) and the arrival port are For simplicity, the case where both Port(N) and the arrival port are
PWs is referred to as PW-only Join/Prune in this document. The PW- PWs is referred to as PW-only Join/Prune in this document. The PW-
only Join/Prune handling is so that the RPort(N) PW can be added to only Join/Prune handling is so that the Port(N) PW can be added to
the related forwarding entries' OutgoingPortList to trigger Assert, the related forwarding entries' OutgoingPortList to trigger Assert,
but that is only needed for those states with AC UpstreamPort. See but that is only needed for those states with AC UpstreamPort. See
Appendix Appendix B for examples. Appendix B for examples.
When a router receives a Join(S,G) or a Prune(S,G) with upstream When a router receives a Join(S,G) or a Prune(S,G) with upstream
neighbor N, it must process the message as defined in the state neighbor N, it must process the message as defined in the state
machine below. Note that the macro computations of the various machine below. Note that the macro computations of the various
macros resulting from this state machine transition is exactly as macros resulting from this state machine transition is exactly as
specified in the PIM-SM RFC [PIM-SM]. specified in [PIM-SM][PIM-SM].
Figure 2: Downstream per-port (S,G) state machine in tabular form Figure 2: Downstream per-port (S,G) state machine in tabular form
+---------------++----------------------------------------+ +---------------++----------------------------------------+
| || Previous State | | || Previous State |
| ++------------+--------------+------------+ | ++------------+--------------+------------+
| Event ||NoInfo (NI) | Join (J) | Prune-Pend | | Event ||NoInfo (NI) | Join (J) | Prune-Pend |
+---------------++------------+--------------+------------+ +---------------++------------+--------------+------------+
| Receive ||-> J state | -> J state | -> J state | | Receive ||-> J state | -> J state | -> J state |
| Join(S,G) || Action | Action | Action | | Join(S,G) || Action | Action | Action |
| || RxJoin(N) | RxJoin(N) | RxJoin(N) | | || RxJoin(N) | RxJoin(N) | RxJoin(N) |
+---------------++------------+--------------+------------+ +---------------++------------+--------------+------------+
|Receive || - | -> PP state | -> PP state| |Receive || - | -> PP state | - |
|Prune (S,G) and|| | Start PPT(N) | | |Prune (S,G) and|| | Start PPT(N) | |
|NumETsActive<=1|| | | | |NumETsActive<=1|| | | |
+---------------++------------+--------------+------------+ +---------------++------------+--------------+------------+
|Receive || - | -> J state | - | |Receive || - | -> J state | - |
|Prune(S,G) and || | Start PPT(N) | | |Prune(S,G) and || | Start PPT(N) | |
NumETsActive>1 || | | | NumETsActive>1 || | | |
+---------------++------------+--------------+------------+ +---------------++------------+--------------+------------+
|PPT(N) expires || - | -> J state | -> NI state| |PPT(N) expires || - | -> J state | -> NI state|
| || | Action | Action | | || | Action | Action |
| || | PPTExpiry(N) |PPTExpiry(N)| | || | PPTExpiry(N) |PPTExpiry(N)|
skipping to change at page 21, line 12 skipping to change at page 20, line 12
Same as Action ETExpiry(N) below, plus Send a Prune-Echo(S,G) with Same as Action ETExpiry(N) below, plus Send a Prune-Echo(S,G) with
upstream-neighbor N on the downstream port. upstream-neighbor N on the downstream port.
Action ETExpiry(N): Action ETExpiry(N):
Disable timers ET(N) and PPT(N). Delete neighbor state Disable timers ET(N) and PPT(N). Delete neighbor state
(Port,S,G,N). If there are no other (Port,S,G) states with (Port,S,G,N). If there are no other (Port,S,G) states with
NumETsActive(Port,S,G) > 0, transition DownstreamJPState to NumETsActive(Port,S,G) > 0, transition DownstreamJPState to
NoInfo. If there are no other (Port,S,G,N) state (different ports NoInfo. If there are no other (Port,S,G,N) state (different ports
but for the same N), remove N from UpstreamPorts(S,G) - this also but for the same N), remove N from UpstreamPorts(S,G) - this also
serves as a trigger for US FSM (JoinDesired(S,G,N) becomes FALSE). serves as a trigger for Upstream FSM (JoinDesired(S,G,N) becomes
FALSE).
2.6.5. Receiving (S,G,rpt) Join/Prune Messages 2.6.5. Receiving (S,G,rpt) Join/Prune Messages
A Join(S,G,rpt) or Prune(S,G,rpt) is "received" when the port on A Join(S,G,rpt) or Prune(S,G,rpt) is "received" when the port on
which it was received is not also the port on which the upstream- which it was received is not also the port on which the upstream-
neighbor N of the Join/Prune(S,G,rpt) was learnt. neighbor N of the Join/Prune(S,G,rpt) was learnt.
While it is important to ensure that the (S,G) and (*,G) state While it is important to ensure that the (S,G) and (*,G) state
machines allow for handling per (S,G,N) states, it is not as machines allow for handling per (S,G,N) states, it is not as
important for (S,G,rpt) states. It suffices to say that the important for (S,G,rpt) states. It suffices to say that the
downstream (S,G,rpt) state machine is the same as what is defined in downstream (S,G,rpt) state machine is the same as what is defined in
section 4.5.4 of the PIM-SM RFC [PIM-SM]. section 4.5.4 of the PIM-SM RFC [PIM-SM].
2.6.6. Sending Join/Prune Messages Upstream 2.6.6. Sending Join/Prune Messages Upstream
This section applies only to a PIM Proxy/Relay PE and not to a PIM This section applies only to a PIM relay/proxying PE and not to a PIM
Snooping PE. snooping PE.
A full PIM Proxy (not Relay) PE MUST implement the Upstream FSM for A full PIM proxying (not relay) PE MUST implement the Upstream FSM
which the procedures are similar to what is defined in section 4.5.6 for which the procedures are similar to what is defined in section
of [PIM-SM]. 4.5.6 of [PIM-SM].
For the purposes of the Upstream FSM, a Join or Prune message with For the purposes of the Upstream FSM, a Join or Prune message with
upstream neighbor N is "seen" on a PIM Snooping PE if the port on upstream neighbor N is "seen" on a PIM relay/proxying PE if the port
which the message was received is also Rport(N), and the port is an on which the message was received is also Port(N), and the port is an
AC. The AC requirement is needed because a Join received on the AC. The AC requirement is needed because a Join received on the
Rport(N) PW must not suppress this PE's Join on that PW. Port(N) PW must not suppress this PE's Join on that PW.
A PIM Relay PE does not implement the Upstream FSM. It simply A PIM relay PE does not implement the Upstream FSM. It simply
forwards received Join/Prune messages out of the same set of upstream forwards received Join/Prune messages out of the same set of upstream
ports as in the PIM Proxy case. ports as in the PIM proxying case.
In order to correctly facilitate assert among the CE routers, such In order to correctly facilitate assert among the CE routers, such
Join/Prunes need to sent not only towards the upstream neighbor, but Join/Prunes need to send not only towards the upstream neighbor, but
also on certain PWs as described below. also on certain PWs as described below.
If RpfVectorTlvs(*,G) is not empty, then it must be encoded in a If RpfVectorTlvs(*,G) is not empty, then it must be encoded in a
Join(*,G) message sent upstream. Join(*,G) message sent upstream.
If RpfVectorTlvs(S,G) is not empty, then it must be encoded in a If RpfVectorTlvs(S,G) is not empty, then it must be encoded in a
Join(S,G) message sent upstream. Join(S,G) message sent upstream.
2.6.6.1. Where to send Join/Prune messages 2.6.6.1. Where to send Join/Prune messages
The following rules apply, to both forwarded (in case of PIM Relay), The following rules apply, to both forwarded (in case of PIM relay),
refresh and triggered (in case of PIM Proxy) (S,G)/(*,G) Join/Prune refresh and triggered (in case of PIM proxying) (S,G)/(*,G) Join/
messages. Prune messages.
o The upstream neighbor field in the Join/Prune to be sent is set to o The upstream neighbor field in the Join/Prune to be sent is set to
the N in the corresponding Upstream FSM. the N in the corresponding Upstream FSM.
o if Rport(N) is an AC, send the message to Rport(N). o if Port(N) is an AC, send the message to Port(N).
o Additionally, if OutgoingPortList(X,G,N) contains at lease one AC, o Additionally, if OutgoingPortList(X,G,N) contains at least one AC,
then the message MUST be sent to at least all the PWs in then the message MUST be sent to at least all the PWs in
UpstreamPorts(G) (for (*,G)) or InheritedUpstreamPorts(S,G) (for UpstreamPorts(G) (for (*,G)) or InheritedUpstreamPorts(S,G) (for
(S,G)). Alternatively, the message MAY be sent to all PWs. (S,G)). Alternatively, the message MAY be sent to all PWs.
Sending to a subset of PWs as described above guarantees that if Sending to a subset of PWs as described above guarantees that if
traffic (of the same flow) from two upstream routers were to reach traffic (of the same flow) from two upstream routers were to reach
this PE, then the two routers will receive from each other, this PE, then the two routers will receive from each other,
triggering assert. triggering assert.
Sending to all PWs guarantees that if two upstream routers both send Sending to all PWs guarantees that if two upstream routers both send
traffic for the same flow (even if it is to different sets of traffic for the same flow (even if it is to different sets of
downstream PEs), then they'll receive from each other, triggering downstream PEs), then they'll receive from each other, triggering
assert. assert.
2.7. Bidirectional-PIM (PIM-BIDIR) 2.7. Bidirectional-PIM (BIDIR-PIM)
PIM-BIDIR is a variation of PIM-SM. The main differences between BIDIR-PIM is a variation of PIM-SM. The main differences between
PIM-SM and Bidirectional-PIM are as follows: PIM-SM and Bidirectional-PIM are as follows:
o There are no source-based trees, and source-specific multicast is o There are no source-based trees, and source-specific multicast is
not supported (i.e., no (S,G) states) in PIM- BIDIR. not supported (i.e., no (S,G) states) in PIM- BIDIR.
o Multicast traffic can flow up the shared tree in PIM-BIDIR. o Multicast traffic can flow up the shared tree in BIDIR-PIM.
o To avoid forwarding loops, one router on each link is elected as o To avoid forwarding loops, one router on each link is elected as
the Designated Forwarder (DF) for each RP in PIM-BIDIR. the Designated Forwarder (DF) for each RP in BIDIR-PIM.
The main advantage of PIM-BIDIR is that it scales well for many-to- The main advantage of BIDIR-PIM is that it scales well for many-to-
many applications. However, the lack of source-based trees means many applications. However, the lack of source-based trees means
that multicast traffic is forced to remain on the shared tree. that multicast traffic is forced to remain on the shared tree.
As described in [PIM-BIDIR], parts of a PIM-BIDIR enabled network may As described in [BIDIR-PIM], parts of a BIDIR-PIM enabled network may
forward traffic without exchanging Join/Prune messages, for instance forward traffic without exchanging Join/Prune messages, for instance
between DF's and the RPL. between DF's and the Rendezvous Point Link (RPL).
As the described procedures for Pim snooping rely on the presence of As the described procedures for PIM snooping rely on the presence of
Join/Prune messages, enabling Pim snooping on PIM-BIDIR networks Join/Prune messages, enabling PIM snooping on BIDIR-PIM networks
could break the PIM-BIDIR functionality. Deploying Pim snooping on could break the BIDIR-PIM functionality. Deploying PIM snooping on
PIM-BIDIR enabled networks will require some further study. Some BIDIR-PIM enabled networks will require some further study. Some
thoughts are gathered in Appendix A. thoughts are gathered in Appendix A.
2.8. Interaction with IGMP Snooping 2.8. Interaction with IGMP Snooping
Whenever IGMP Snooping is enabled in conjunction with PIM Snooping in Whenever IGMP snooping is enabled in conjunction with PIM snooping in
the same VPLS instance the PE SHOULD follow these rules: the same VPLS instance the PE SHOULD follow these rules:
o To maintain the list of multicast routers and ports on which they o To maintain the list of multicast routers and ports on which they
are attached, the PE SHOULD NOT use the rules as described in are attached, the PE SHOULD NOT use the rules as described in
RFC4541 [IGMP-SNOOP] but SHOULD rely on the neighbors discovered RFC4541 [IGMP-SNOOP] but SHOULD rely on the neighbors discovered
by PIM Snooping . This list SHOULD then be used to apply the by PIM snooping . This list SHOULD then be used to apply the
forwarding rule as described in 2.1.1.(1) of RFC4541 [IGMP-SNOOP]. forwarding rule as described in 2.1.1.(1) of RFC4541 [IGMP-SNOOP].
o If the PE supports proxy-reporting, an IGMP membership learned o If the PE supports proxy-reporting, an IGMP membership learned
only on a port to which a PIM neighbor is attached but not only on a port to which a PIM neighbor is attached but not
elsewhere SHOULD NOT be included in the summarized upstream report elsewhere SHOULD NOT be included in the summarized upstream report
sent to that port. sent to that port.
2.9. PIM-DM 2.9. PIM-DM
The characteristics of PIM-DM is flood and prune behavior. Shortest The characteristics of PIM-DM is flood and prune behavior. Shortest
path trees are built as a multicast source starts transmitting. path trees are built as a multicast source starts transmitting.
2.9.1. Building PIM-DM Snooping States 2.9.1. Building PIM-DM Snooping States
PIM-DM Snooping states are built by snooping on the PIM-DM Join, PIM-DM snooping states are built by snooping on the PIM-DM Join,
Prune, Graft and State Refresh messages received on AC/PWs and State- Prune, Graft and State Refresh messages received on AC/PWs and State-
Refresh Messages sent on AC/PWs. By snooping on these PIM-DM Refresh Messages sent on AC/PWs. By snooping on these PIM-DM
messages, a PE builds the following states per (S,G,N) where S is the messages, a PE builds the following states per (S,G,N) where S is the
address of the multicast source, G is the Group address and N is the address of the multicast source, G is the Group address and N is the
upstream neighbor to which Prunes/Grafts are sent by downstream CEs: upstream neighbor to which Prunes/Grafts are sent by downstream CEs:
Per PIM (S,G,N): Per PIM (S,G,N):
Port PIM (S,G,N) Prune State: Port PIM (S,G,N) Prune State:
skipping to change at page 24, line 4 skipping to change at page 23, line 6
upstream neighbor to which Prunes/Grafts are sent by downstream CEs: upstream neighbor to which Prunes/Grafts are sent by downstream CEs:
Per PIM (S,G,N): Per PIM (S,G,N):
Port PIM (S,G,N) Prune State: Port PIM (S,G,N) Prune State:
* DownstreamPState(S,G,N,Port): One of {"NoInfo" (NI), "Pruned" * DownstreamPState(S,G,N,Port): One of {"NoInfo" (NI), "Pruned"
(P), "PrunePending" (PP)} (P), "PrunePending" (PP)}
* Prune Pending Timer (PPT) * Prune Pending Timer (PPT)
* Prune Timer (PT) * Prune Timer (PT)
* Upstream Port (valid if the PIM(S,G,N) Prune State is * Upstream Port (valid if the PIM(S,G,N) Prune State is
"Pruned"). "Pruned").
2.9.2. PIM-DM Downstream Per-Port PIM(S,G,N) State Machine 2.9.2. PIM-DM Downstream Per-Port PIM(S,G,N) State Machine
The downstream per-port PIM(S,G,N) state machine is as defined in The downstream per-port PIM(S,G,N) state machine is as defined in
section 4.4.2 of [PIM-DM] with a few changes relevant to PIM section 4.4.2 of [PIM-DM] with a few changes relevant to PIM
Snooping. When reading section 4.4.2 of [PIM-DM] for the purposes of snooping. When reading section 4.4.2 of [PIM-DM] for the purposes of
PIM-Snooping please be aware that the downstream states are built per PIM-snooping please be aware that the downstream states are built per
(S, G, N, Downstream-Port} in PIM-Snooping and not per {Downstream- (S, G, N, Downstream-Port} in PIM-snooping and not per {Downstream-
Interface, S, G} as in a PIM-DM router. As noted in the previous Interface, S, G} as in a PIM-DM router. As noted in the previous
Section 2.9.1, the states (DownstreamPState) and timers (PPT and PT) Section 2.9.1, the states (DownstreamPState) and timers (PPT and PT)
are per (S,G,N,P). are per (S,G,N,P).
2.9.3. Triggering ASSERT election in PIM-DM 2.9.3. Triggering ASSERT election in PIM-DM
Since PIM-DM is a flood-and-prune protocol, traffic is flooded to all Since PIM-DM is a flood-and-prune protocol, traffic is flooded to all
routers unless explicitly pruned. Since PIM-DM routers do not prune routers unless explicitly pruned. Since PIM-DM routers do not prune
on non-RPF interfaces, PEs should typically not receive Prunes on on non-RPF interfaces, PEs should typically not receive Prunes on
Rport(RPF-neighbor). So the asserting routers should typically be in Port(RPF-neighbor). So the asserting routers should typically be in
pim_oiflist(S,G). In most cases, assert election should occur pim_oiflist(S,G). In most cases, assert election should occur
naturally without any special handling since data traffic will be naturally without any special handling since data traffic will be
forwarded to the asserting routers. forwarded to the asserting routers.
However, there are some scenarios where a prune might be received on However, there are some scenarios where a prune might be received on
a port which is also an upstream port (UP). If we prune the port a port which is also an upstream port (UP). If we prune the port
from pim_oiflist(S,G), then it would not be possible for the from pim_oiflist(S,G), then it would not be possible for the
asserting routers to determine if traffic arrived on their downstream asserting routers to determine if traffic arrived on their downstream
port. This can be fixed by adding pim_iifs(S,G) to pim_oiflist(S,G) port. This can be fixed by adding pim_iifs(S,G) to pim_oiflist(S,G)
so that data traffic flows to the UP ports. so that data traffic flows to the UP ports.
2.10. PIM Proxy 2.10. PIM Proxy
As noted earlier, PIM Snooping will work correctly only if Join As noted earlier, PIM snooping will work correctly only if Join
Suppression is disabled in the VPLS. If Join Suppression is enabled Suppression is disabled in the VPLS. If Join Suppression is enabled
in the VPLS, then PEs MUST do PIM Proxy/Relay for VPLS Multicast to in the VPLS, then PEs MUST do PIM relay/proxying for VPLS multicast
work correctly. This section applies specifically to the full Proxy to work correctly. This section applies specifically to the full
case and not Relay. proxying case and not relay.
2.10.1. Upstream PIM Proxy behavior 2.10.1. Upstream PIM Proxy behavior
A PIM Proxy PE consumes Join/Prune messages and regenerates PIM Join/ A PIM proxying PE consumes Join/Prune messages and regenerates PIM
Prune messages to be sent upstream by implementing Upstream FSM as Join/Prune messages to be sent upstream by implementing Upstream FSM
specified in the PIM RFC. This is the only difference from PIM as specified in the PIM RFC. This is the only difference from PIM
Relay. relay.
The source IP address in PIM packets sent upstream SHOULD be the The source IP address in PIM packets sent upstream SHOULD be the
address of a PIM downstream neighbor in the corresponding join/prune address of a PIM downstream neighbor in the corresponding join/prune
state. The address picked MUST NOT be the upstream neighbor field to state. The address picked MUST NOT be the upstream neighbor field to
be encoded in the packet. The layer 2 encapsulation for the selected be encoded in the packet. The layer 2 encapsulation for the selected
source IP address MUST be the encapsulation recorded in the PIM source IP address MUST be the encapsulation recorded in the PIM
Neighbor database for that IP address. Neighbor database for that IP address.
2.11. Directly Connected Multicast Source 2.11. Directly Connected Multicast Source
skipping to change at page 26, line 18 skipping to change at page 25, line 18
o Due to VPLS Split-Horizon rules, traffic ingressing on a PW MUST o Due to VPLS Split-Horizon rules, traffic ingressing on a PW MUST
NOT be forwarded to any other PW. NOT be forwarded to any other PW.
2.12.1. PIM-SM Data Forwarding Rules 2.12.1. PIM-SM Data Forwarding Rules
Per the rules in [PIM-SM] and per the additional rules specified in Per the rules in [PIM-SM] and per the additional rules specified in
this document, this document,
OutgoingPortList(*,G) = immediate_olist(*,G) (+) OutgoingPortList(*,G) = immediate_olist(*,G) (+)
UpstreamPorts(*,G) (+) UpstreamPorts(*,G) (+)
Rport(PimDR) Port(PimDR)
OutgoingPortList(S,G) = inherited_olist(S,G) (+) OutgoingPortList(S,G) = inherited_olist(S,G) (+)
UpstreamPorts(S,G) (+) UpstreamPorts(S,G) (+)
(UpstreamPorts(*,G) (-) (UpstreamPorts(*,G) (-)
UpstreamPorts(S,G,rpt)) (+) UpstreamPorts(S,G,rpt)) (+)
Rport(PimDR) Port(PimDR)
[PIM-SM] specifies how immediate_olist(*,G) and inherited_olist(S,G) [PIM-SM] specifies how immediate_olist(*,G) and inherited_olist(S,G)
are built. PimDR is the IP address of the PIM DR in the VPLS. are built. PimDR is the IP address of the PIM DR in the VPLS.
The PIM-SM Snooping forwarding rules are defined below in pseudocode: The PIM-SM snooping forwarding rules are defined below in pseudocode:
BEGIN BEGIN
iif is the incoming port of the multicast packet. iif is the incoming port of the multicast packet.
S is the Source IP Address of the multicast packet. S is the Source IP Address of the multicast packet.
G is the Destination IP Address of the multicast packet. G is the Destination IP Address of the multicast packet.
If there is (S,G) state on the PE If there is (S,G) state on the PE
Then Then
OutgoingPortList = OutgoingPortList(S,G) OutgoingPortList = OutgoingPortList(S,G)
Else if there is (*,G) state on the PE Else if there is (*,G) state on the PE
skipping to change at page 27, line 42 skipping to change at page 26, line 42
ports is OutgoingPortList(S,G). ports is OutgoingPortList(S,G).
Otherwise if there is (*,G) state on the PE, the set of outgoing Otherwise if there is (*,G) state on the PE, the set of outgoing
ports is OutgoingPortList(*,G). ports is OutgoingPortList(*,G).
The packet is forwarded to the selected set of outgoing ports while The packet is forwarded to the selected set of outgoing ports while
observing the general rules above in Section 2.12 observing the general rules above in Section 2.12
2.12.2. PIM-DM Data Forwarding Rules 2.12.2. PIM-DM Data Forwarding Rules
The PIM-DM Snooping data forwarding rules are defined below in The PIM-DM snooping data forwarding rules are defined below in
pseudocode: pseudocode:
BEGIN BEGIN
iif is the incoming port of the multicast packet. iif is the incoming port of the multicast packet.
S is the Source IP Address of the multicast packet. S is the Source IP Address of the multicast packet.
G is the Destination IP Address of the multicast packet. G is the Destination IP Address of the multicast packet.
If there is (S,G) state on the PE If there is (S,G) state on the PE
Then Then
OutgoingPortList = olist(S,G) OutgoingPortList = olist(S,G)
skipping to change at page 29, line 12 skipping to change at page 28, line 8
Yetik Serbest, Suresh Boddapati co-authored earlier versions. Yetik Serbest, Suresh Boddapati co-authored earlier versions.
Karl (Xiangrong) Cai and Princy Elizabeth made significant Karl (Xiangrong) Cai and Princy Elizabeth made significant
contributions to bring the specification to its current state, contributions to bring the specification to its current state,
especially in the area of Join forwarding rules. especially in the area of Join forwarding rules.
6. Acknowledgements 6. Acknowledgements
Many members of the L2VPN and PIM working groups have contributed to Many members of the L2VPN and PIM working groups have contributed to
and provided valuable comments and feedback to this draft, including and provided valuable comments and feedback to this document,
Vach Kompella, Shane Amante, Sunil Khandekar, Rob Nath, Marc Lassere, including Vach Kompella, Shane Amante, Sunil Khandekar, Rob Nath,
Yuji Kamite, Yiqun Cai, Ali Sajassi, Jozef Raets, Himanshu Shah Marc Lassere, Yuji Kamite, Yiqun Cai, Ali Sajassi, Jozef Raets,
(Ciena), Himanshu Shah (Alcatel-Lucent). Himanshu Shah (Ciena), Himanshu Shah (Alcatel-Lucent).
7. References 7. References
7.1. Normative References 7.1. Normative References
[PIM-BIDIR] [BIDIR-PIM]
Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bidirectional Protocol Independent Multicast (BIDIR- "Bidirectional Protocol Independent Multicast (BIDIR-
PIM)", RFC 5015, 2007. PIM)", RFC 5015, 2007.
[PIM-DM] Adams, A., Nicholas, J., and W. Siadak, "Protocol [PIM-DM] Adams, A., Nicholas, J., and W. Siadak, "Protocol
Independent Multicast Version 2 - Dense Mode Independent Multicast Version 2 - Dense Mode
Specification", RFC 3973, 2005. Specification", RFC 3973, 2005.
[PIM-SM] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, [PIM-SM] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast- Sparse Mode (PIM-SM): "Protocol Independent Multicast- Sparse Mode (PIM-SM):
skipping to change at page 29, line 48 skipping to change at page 28, line 44
Requirement Levels", BCP 14, RFC 2119, 1997. Requirement Levels", BCP 14, RFC 2119, 1997.
[RPF-VECTOR] [RPF-VECTOR]
Wijnands, I., Boers, A., and E. Rosen, "The Reverse Path Wijnands, I., Boers, A., and E. Rosen, "The Reverse Path
Forwarding (RPF) Vector TLV", RFC 5496, 2009. Forwarding (RPF) Vector TLV", RFC 5496, 2009.
7.2. Informative References 7.2. Informative References
[IGMP-SNOOP] [IGMP-SNOOP]
Christensen, M., Kimball, K., and F. Solensky, Christensen, M., Kimball, K., and F. Solensky,
"Considerations for IGMP and MLD Snooping PEs", RFC 4541, "Considerations for IGMP and MLD snooping PEs", RFC 4541,
2006. 2006.
[VPLS-BGP] [VPLS-BGP]
Kompella, K. and Y. Rekhter, "Virtual Private LAN Service Kompella, K. and Y. Rekhter, "Virtual Private LAN Service
using BGP for Auto-Discovery and Signaling", RFC 4761, using BGP for Auto-Discovery and Signaling", RFC 4761,
2007. 2007.
[VPLS-LDP] [VPLS-LDP]
Lasserre, M. and V. Kompella, "Virtual Private LAN Lasserre, M. and V. Kompella, "Virtual Private LAN
Services using LDP Signaling", RFC 4762, 2007. Services using LDP Signaling", RFC 4762, 2007.
[VPLS-MCAST-REQ] [VPLS-MCAST-REQ]
Kamite, Y., Wada, Y., Serbest, Y., Morin, T., and L. Fang, Kamite, Y., Wada, Y., Serbest, Y., Morin, T., and L. Fang,
"Requirements for Multicast Support in Virtual Private LAN "Requirements for Multicast Support in Virtual Private LAN
Services", RFC 5501, 2009. Services", RFC 5501, 2009.
[VPLS-MCAST-TREES] [VPLS-MCAST-TREES]
Aggarwal, R., Kamite, Y., Fang, L., and Y. Rekhter, Aggarwal, R., Kamite, Y., Fang, L., and Y. Rekhter,
"Multicast in VPLS", draft-ietf-l2vpn-vpls-mcast-11, Work "Multicast in VPLS", draft-ietf-l2vpn-vpls-mcast-11, Work
in Progress. in Progress.
Appendix A. PIM-BIDIR Thoughts Appendix A. BIDIR-PIM Thoughts
This section describes some guidelines that may be used to preserve This section describes some guidelines that may be used to preserve
PIM-BIDIR functionality in combination with Pim Snooping. BIDIR-PIM functionality in combination with Pim snooping.
In order to preserve PIM-BIDIR Pim snooping routers need to set up In order to preserve BIDIR-PIM Pim snooping routers need to set up
forwarding states so that : forwarding states so that :
o on the RPL all traffic is forwarded to all Rport(N) o on the RPL all traffic is forwarded to all Port(N)
o on any other interface traffic is always forwarded to the DF o on any other interface traffic is always forwarded to the DF
The information needed to setup these states may be obtained by : The information needed to setup these states may be obtained by :
o determining the mapping between group(range) and RP o determining the mapping between group(range) and RP
o snooping and storing DF election information o snooping and storing DF election information
o determining where the RPL is, this could be achieved by static o determining where the RPL is, this could be achieved by static
configuration, or by combining the information mentioned in configuration, or by combining the information mentioned in
previous bullets. previous bullets.
A.1. PIM-BIDIR Data Forwarding Rules A.1. BIDIR-PIM Data Forwarding Rules
The PIM-BIDIR Snooping forwarding rules are defined below in The BIDIR-PIM snooping forwarding rules are defined below in
pseudocode: pseudocode:
BEGIN BEGIN
iif is the incoming port of the multicast packet. iif is the incoming port of the multicast packet.
G is the Destination IP Address of the multicast packet. G is the Destination IP Address of the multicast packet.
If there is forwarding state for G If there is forwarding state for G
Then Then
OutgoingPortList = olist(G) OutgoingPortList = olist(G)
Else Else
skipping to change at page 31, line 30 skipping to change at page 30, line 30
## iif is a PW ## iif is a PW
OutgoingPortList = OutgoingPortList (-) PWPorts OutgoingPortList = OutgoingPortList (-) PWPorts
Endif Endif
Forward the packet to OutgoingPortList. Forward the packet to OutgoingPortList.
END END
If there is forwarding state for G, then forward the packet to If there is forwarding state for G, then forward the packet to
olist(G) while observing the general rules above in Section 2.12 olist(G) while observing the general rules above in Section 2.12
[PIM-BIDIR] specifies how olist(G) is constructed. [BIDIR-PIM] specifies how olist(G) is constructed.
Appendix B. Example Network Scenario Appendix B. Example Network Scenario
Let us consider the scenario in Figure 3. Let us consider the scenario in Figure 3.
An Example Network for Triggering Assert An Example Network for Triggering Assert
+------+ AC3 +------+ +------+ AC3 +------+
| PE2 |-----| CE3 | | PE2 |-----| CE3 |
/| | +------+ /| | +------+
skipping to change at page 32, line 38 skipping to change at page 31, line 38
+------+ +------+
In the examples below, JT(Port,S,G,N) is the downstream Join Expiry In the examples below, JT(Port,S,G,N) is the downstream Join Expiry
Timer on the specified Port for the (S,G) with upstream neighbor N. Timer on the specified Port for the (S,G) with upstream neighbor N.
B.1. Pim Snooping Example B.1. Pim Snooping Example
In the network depicted in Figure 3, S is the source of a multicast In the network depicted in Figure 3, S is the source of a multicast
stream (S,G). CE1 and CE2 both have two ECMP routes to reach the stream (S,G). CE1 and CE2 both have two ECMP routes to reach the
source. source.
1. CE1 Sends a Join(S,G) with Upstream Neighbor(S,G) = CE3. 1. CE1 Sends a Join(S,G) with Upstream Neighbor(S,G) = CE3.
2. PE1 snoops on the Join(S,G) and builds forwarding states since it 2. PE1 snoops on the Join(S,G) and builds forwarding states since it
is received on an AC. It also floods the Join(S,G) in the VPLS. PE2 is received on an AC. It also floods the Join(S,G) in the VPLS.
snoops on the Join(S,G) and builds forwarding state since the Join(S,G) PE2 snoops on the Join(S,G) and builds forwarding state since the
is targeting a neighbor residing on an AC. PE3 does not create Join(S,G)is targeting a neighbor residing on an AC. PE3 does not
forwarding state for (S,G) because this is a PW-only join and there is create forwarding state for (S,G) because this is a PW-only join
neither existing (*,G) state with an AC in UpstreamPorts(*,G) nor an and there is neither existing (*,G) state with an AC in
existing (S,G) state with an AC in UpstreamPorts(S,G). Both PE2 and PE3 UpstreamPorts(*,G) nor an existing (S,G) state with an AC in
will also flood the Join(S,G) in the VPLS UpstreamPorts(S,G). Both PE2 and PE3 will also flood the
Join(S,G) in the VPLS
The resulting states at the PEs is as follows: The resulting states at the PEs is as follows:
At PE1: At PE1:
JT(AC1,S,G,CE3) = JP_HoldTime JT(AC1,S,G,CE3) = JP_HoldTime
UpstreamNeighbors(S,G) = { CE3 } UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { PW12 } UpstreamPorts(S,G) = { PW12 }
OutgoingPortList(S,G) = { AC1, PW12 } OutgoingPortList(S,G) = { AC1, PW12 }
At PE2: At PE2:
JT(PW12,S,G,CE3) = JP_HoldTime JT(PW12,S,G,CE3) = JP_HoldTime
UpstreamNeighbors(S,G) = { CE3 } UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { AC3 } UpstreamPorts(S,G) = { AC3 }
OutgoingPortList(S,G) = { PW12, AC3 } OutgoingPortList(S,G) = { PW12, AC3 }
skipping to change at page 33, line 14 skipping to change at page 32, line 17
UpstreamPorts(S,G) = { PW12 } UpstreamPorts(S,G) = { PW12 }
OutgoingPortList(S,G) = { AC1, PW12 } OutgoingPortList(S,G) = { AC1, PW12 }
At PE2: At PE2:
JT(PW12,S,G,CE3) = JP_HoldTime JT(PW12,S,G,CE3) = JP_HoldTime
UpstreamNeighbors(S,G) = { CE3 } UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { AC3 } UpstreamPorts(S,G) = { AC3 }
OutgoingPortList(S,G) = { PW12, AC3 } OutgoingPortList(S,G) = { PW12, AC3 }
At PE3: At PE3:
No (S,G) state No (S,G) state
3. The multicast stream (S,G) flows along CE3 -> PE2 -> PE1 -> CE1 3. The multicast stream (S,G) flows along
CE3 -> PE2 -> PE1 -> CE1
4. Now CE2 sends a Join(S,G) with Upstream Neighbor(S,G) = CE4. 4. Now CE2 sends a Join(S,G) with Upstream Neighbor(S,G) = CE4.
5. All PEs snoop on the Join(S,G), build forwarding state and flood the 5. All PEs snoop on the Join(S,G), build forwarding state and
Join(S,G) in the VPLS. Note that for PE2 even though this is a PW-only flood the Join(S,G) in the VPLS. Note that for PE2 even though
join, forwarding state is built on this Join(S,G) since PE2 has existing this is a PW-only join, forwarding state is built on this Join(S,G)
(S,G) state with an AC in UpstreamPorts(S,G) since PE2 has existing (S,G) state with an AC in UpstreamPorts(S,G)
The resulting states at the PEs: The resulting states at the PEs:
At PE1: At PE1:
JT(AC1,S,G,CE3) = active JT(AC1,S,G,CE3) = active
JT(AC2,S,G,CE4) = JP_HoldTime JT(AC2,S,G,CE4) = JP_HoldTime
UpstreamNeighbors(S,G) = { CE3, CE4 } UpstreamNeighbors(S,G) = { CE3, CE4 }
UpstreamPorts(S,G) = { PW12, PW13 } UpstreamPorts(S,G) = { PW12, PW13 }
OutgoingPortList(S,G) = { AC1, PW12, AC2, PW13 } OutgoingPortList(S,G) = { AC1, PW12, AC2, PW13 }
skipping to change at page 34, line 28 skipping to change at page 33, line 30
UpstreamPorts(S,G) = { PW12 } UpstreamPorts(S,G) = { PW12 }
OutgoingPortList(S,G) = { AC1, AC2, PW12 } OutgoingPortList(S,G) = { AC1, AC2, PW12 }
At PE2: At PE2:
JT(PW12,S,G,CE3) = active JT(PW12,S,G,CE3) = active
UpstreamNeighbors(S,G) = { CE3 } UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { AC3 } UpstreamPorts(S,G) = { AC3 }
OutgoingPortList(S,G) = { PW12, AC3 } OutgoingPortList(S,G) = { PW12, AC3 }
At PE3: At PE3:
JT(PW13,S,G,CE3) = JP_HoldTime JT(PW13,S,G,CE3) = JP_HoldTime
UpstreamNeighbors(S,G) = { CE3 } UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { PW23 } UpstreamPorts(S,G) = { PW23 }
OutgoingPortList(S,G) = { PW13, PW23 } OutgoingPortList(S,G) = { PW13, PW23 }
Note that at this point at PE3, since there is no AC in Note that at this point at PE3, since there is no AC in
OutgoingPortList(S,G) and no (*,G) or (S,G) state with an AC in OutgoingPortList(S,G) and no (*,G) or (S,G) state with an AC in
UpstreamPorts(*,G) or UpstreamPorts(S,G) respectively, the existing UpstreamPorts(*,G) or UpstreamPorts(S,G) respectively, the existing
(S,G) state at PE3 can also be removed. So finally: (S,G) state at PE3 can also be removed. So finally:
At PE3: At PE3:
No (S,G) state No (S,G) state
Note that at the end of the assert election, there should be no Note that at the end of the assert election, there should be no
duplicate traffic forwarded downstream and traffic should flow only duplicate traffic forwarded downstream and traffic should flow only
on the desired path. Also note that there are no unnecessary (S,G) on the desired path. Also note that there are no unnecessary (S,G)
states on PE3 after the assert election. states on PE3 after the assert election.
B.2. PIM Proxy Example with (S,G) / (*,G) interaction B.2. PIM Proxy Example with (S,G) / (*,G) interaction
In the same network, let us assume CE4 is the Upstream Neighbor In the same network, let us assume CE4 is the Upstream Neighbor
towards the RP for G. towards the RP for G.
skipping to change at page 40, line 29 skipping to change at page 39, line 36
Email: jayant.kotalwar@alcatel-lucent.com Email: jayant.kotalwar@alcatel-lucent.com
Venu Hemige Venu Hemige
Email: vhemige@gmail.com Email: vhemige@gmail.com
Ray Qiu Ray Qiu
Juniper Networks, Inc. Juniper Networks, Inc.
1194 North Mathilda Avenue 1194 North Mathilda Avenue
Sunnyvale, CA 94089 Sunnyvale CA 94089
Email: rqiu@juniper.net Email: rqiu@juniper.net
Jeffrey Zhang Jeffrey Zhang
Juniper Networks, Inc. Juniper Networks, Inc.
10 Technology Park Drive 10 Technology Park Drive
Westford, MA 01886 Westford, MA 01886
Email: zzhang@juniper.net Email: zzhang@juniper.net
 End of changes. 144 change blocks. 
349 lines changed or deleted 375 lines changed or added

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