draft-ietf-l2vpn-vpls-pim-snooping-01.txt   draft-ietf-l2vpn-vpls-pim-snooping-02.txt 
INTERNET DRAFT Venu Hemige Layer 2 Virtual Private Networks O. Dornon
Alcatel-Lucent Internet-Draft J. Kotalwar
Internet Engineering Task Force Yetik Serbest Intended status: Informational Alcatel-Lucent
Document: AT&T Expires: January 17, 2013 J. Zhang
draft-ietf-l2vpn-vpls-pim-snooping-01.txt Ray Qiu Juniper Networks, Inc.
Suresh Boddapati V. Hemige
Alcatel-Lucent Alcatel-Lucent
March 2007 July 16, 2012
Category: Informational
Expires: September 2007
PIM Snooping over VPLS PIM Snooping over VPLS
draft-ietf-l2vpn-vpls-pim-snooping-02
Status of this memo Abstract
By submitting this Internet-Draft, each author represents that any In Virtual Private LAN Service (VPLS), as also in IEEE Bridged
applicable patent or other IPR claims of which he or she is aware Networks, the switches simply flood multicast traffic on all ports in
have been or will be disclosed, and any of which he or she becomes the LAN by default. IGMP Snooping is commonly deployed to ensure
aware will be disclosed, in accordance with Section 6 of BCP 79. multicast traffic is not forwarded on ports without IGMP receivers.
The procedures and recommendations for IGMP Snooping are defined in
[IGMP-SNOOP]. But when any protocol other than IGMP is used, the
common practice is to simply flood multicast traffic to all ports.
PIM-SM, PIM-SSM, PIM-BIDIR are widely deployed routing protocols.
PIM Snooping procedures are important to restrict multicast traffic
to only the routers interested in receiving such traffic.
This document is an Internet-Draft and is in full conformance with While most of the PIM Snooping procedures defined here also apply to
Sections 5 and 6 of RFC 3667 and Section 5 of RFC 3668. IEEE Bridged Networks, VPLS demands certain special procedures due to
the split-horizon rules that require the Provider Edge (PE) devices
to co-operate. This document describes the procedures and
recommendations for PIM-Snooping in VPLS to facilitate replication to
only those ports behind which there are interested PIM routers and/or
IGMP hosts. This document also describes procedures for PIM Proxy.
PIM Proxy is required on PEs for VPLS Multicast to work correctly
when Join suppression is enabled in the VPLS. PIM Proxy also helps
scale VPLS Multicast much better than just PIM Snooping.
Internet-Drafts are working documents of the Internet Engineering Requirements Language
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
and may be updated, replaced, or obsoleted by other documents at any "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
time. It is inappropriate to use Internet-Drafts as reference document are to be interpreted as described in [RFC2119].
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Status of this Memo
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at This Internet-Draft is submitted in full conformance with the
http://www.ietf.org/shadow.html. provisions of BCP 78 and BCP 79.
Abstract Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
In Virtual Private LAN Service (VPLS), as also in IEEE Bridged Internet-Drafts are draft documents valid for a maximum of six months
Networks, the switches simply flood multicast traffic on all ports in and may be updated, replaced, or obsoleted by other documents at any
the LAN by default. IGMP Snooping is commonly deployed to ensure time. It is inappropriate to use Internet-Drafts as reference
multicast traffic is not forwarded on ports without IGMP receivers. material or to cite them other than as "work in progress."
The procedures and recommendations for IGMP Snooping are defined in
[IGMP-SNOOP]. But when any protocol other than IGMP is used, the
common practice is to simply flood multicast traffic to all ports.
PIM-SM, PIM-SSM, PIM-BIDIR are widely deployed routing protocols. PIM
Snooping procedures are important to restrict multicast traffic to
only the routers interested in receiving such traffic.
While most of the PIM Snooping procedures defined here also apply to This Internet-Draft will expire on January 17, 2013.
IEEE Bridged Networks, VPLS demands certain special procedures due to
the split-horizon rules that require the Provider Edge (PE) devices
to co-operate. This document describes the procedures and
recommendations for PIM-Snooping in VPLS to facilitate replication to
only those ports behind which there are interested PIM routers and/or
IGMP hosts.
This document also describes procedures for PIM Proxy. PIM Proxy is Copyright Notice
required on PEs for VPLS Multicast to work correctly when Join
suppression is enabled in the VPLS. PIM Proxy also helps scale VPLS
Multicast much better than just PIM Snooping.
Conventions used in this document Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", This document is subject to BCP 78 and the IETF Trust's Legal
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this Provisions Relating to IETF Documents
document are to be interpreted as described in RFC 2119 [RFC 2119]. (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction .............................................3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Assumptions...............................................4 1.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 6
1.2. PIM Snooping and PIM Proxy Complexity.....................4 1.2. PIM Snooping and PIM Proxy Complexity . . . . . . . . . . 6
1.3. Definitions...............................................5 1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6
2. Multicast Traffic over VPLS...............................6 2. Multicast Traffic over VPLS . . . . . . . . . . . . . . . . . 7
2.1. Constraining of IP Multicast in a VPLS....................6 2.1. Constraining of IP Multicast in a VPLS . . . . . . . . . . 8
2.2. IPv6 Considerations.......................................7 2.2. IPv6 Considerations . . . . . . . . . . . . . . . . . . . 9
2.3. PIM-SM (*,*,RP) Considerations............................7 2.3. PIM-SM (*,*,RP) Considerations . . . . . . . . . . . . . . 9
2.4. PIM Packet Types to Snoop.................................8 2.4. PIM Packet Types to Snoop . . . . . . . . . . . . . . . . 9
2.5. PIM Snooping vs PIM Proxy.................................8 2.5. PIM Snooping vs PIM Proxy . . . . . . . . . . . . . . . . 9
2.5.1. Differences between PIM Snooping and PIM Proxy............9 2.5.1. Differences between PIM Snooping and PIM Proxy . . . . 10
2.5.2. PIM Control Message Latency...............................9 2.5.2. PIM Control Message Latency . . . . . . . . . . . . . 11
2.5.3. When to Snoop and When to Proxy......................... 10 2.5.3. When to Snoop and When to Proxy . . . . . . . . . . . 11
3. PIM Snooping for VPLS................................... 10 3. PIM Snooping for VPLS . . . . . . . . . . . . . . . . . . . . 12
3.1. General Rules for PIM Snooping in VPLS.................. 11 3.1. General Rules for PIM Snooping in VPLS . . . . . . . . . . 13
3.1.1. Snooping PIM Packets ................................... 11 3.1.1. Snooping PIM Packets . . . . . . . . . . . . . . . . . 13
3.2. Discovering PIM Routers................................. 11 3.1.2. Preserving Assert Trigger . . . . . . . . . . . . . . 13
3.3. PIM-SM and PIM-SSM...................................... 12 3.2. Discovering PIM Routers . . . . . . . . . . . . . . . . . 14
3.3.1. Building PIM-SM Snooping States......................... 13 3.3. PIM-SM and PIM-SSM . . . . . . . . . . . . . . . . . . . . 15
3.3.2. Explanation for per (S,G,N) states...................... 15 3.3.1. Building PIM-SM Snooping States . . . . . . . . . . . 15
3.3.3. Receiving (*,G) PIM-SM Join/Prune Messages.............. 15 3.3.2. Explanation for per (S,G,N) states . . . . . . . . . . 17
3.3.4. Receiving (S,G) PIM-SM Join/Prune Messages.............. 18 3.3.3. Receiving (*,G) PIM-SM Join/Prune Messages . . . . . . 18
3.3.5. Receiving (S,G,rpt) Join/Prune Messages................. 19 3.3.4. Receiving (S,G) PIM-SM Join/Prune Messages . . . . . . 20
3.3.6. Sending (*,G) Join/Prune Messages....................... 19 3.3.5. Receiving (S,G,rpt) Join/Prune Messages . . . . . . . 22
3.3.7. Sending (S,G) Join/Prune Messages....................... 20 3.3.6. Sending Join/Prune Messages Upstream . . . . . . . . . 22
3.3.8. Sending PIM Join/Prune message upstream................. 20 3.4. Bidirectional-PIM (PIM-BIDIR) . . . . . . . . . . . . . . 23
3.3.8.1. Sending Triggered vs Refresh Join/Prune messages....... 20 3.5. Interaction with IGMP Snooping . . . . . . . . . . . . . . 24
3.3.9. Triggering ASSERT Election in PIM-SM.................... 21 3.6. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4. Bidirectional-PIM (PIM-BIDIR)........................... 21 3.6.1. Building PIM-DM Snooping States . . . . . . . . . . . 24
3.4.1. Building PIM-BIDIR Snooping States...................... 22 3.6.2. PIM-DM Downstream Per-Port PIM(S,G,N) State Machine . 25
3.5. PIM-DM.................................................. 22 3.6.3. Triggering ASSERT election in PIM-DM . . . . . . . . . 25
3.5.1. Building PIM-DM Snooping States......................... 23 3.7. PIM Proxy . . . . . . . . . . . . . . . . . . . . . . . . 25
3.5.2. PIM-DM Downstream Per-Port PIM(S,G,N) State Machine .... 23 3.7.1. Downstream PIM Proxy behavior . . . . . . . . . . . . 26
3.5.3. Triggering ASSERT election in PIM-DM.................... 23 3.7.2. Upstream PIM Proxy behavior . . . . . . . . . . . . . 26
3.6. PIM Proxy............................................... 24 3.7.3. Source IP Address in Proxy PIM Join/Prune Packets . . 26
3.6.1. Downstream PIM Proxy behavior........................... 24 3.8. Directly Connected Multicast Source . . . . . . . . . . . 27
3.6.2. Upstream PIM Proxy behavior............................. 25 3.9. Data Forwarding Rules . . . . . . . . . . . . . . . . . . 27
3.6.3. Source IP Address in Proxy PIM Join/Prune Packets....... 25 3.9.1. PIM-SM Data Forwarding Rules . . . . . . . . . . . . . 28
3.7. Directly Connected Multicast Source .................... 25 3.9.2. PIM-BIDIR Data Forwarding Rules . . . . . . . . . . . 29
3.8. Data Forwarding Rules................................... 26 3.9.3. PIM-DM Data Forwarding Rules . . . . . . . . . . . . . 30
3.8.1. PIM-SM Data Forwarding Rules ........................... 26 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
3.8.2. PIM-BIDIR Data Forwarding Rules......................... 27 5. Security Considerations . . . . . . . . . . . . . . . . . . . 31
3.8.3. PIM-DM Data Forwarding Rules............................ 28 6. Contributers . . . . . . . . . . . . . . . . . . . . . . . . . 31
4. IANA Considerations..................................... 28 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
5. Security Considerations................................. 29 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6. Acknowledgements........................................ 29 8.1. Normative References . . . . . . . . . . . . . . . . . . . 32
7. References.............................................. 29 8.2. Informative References . . . . . . . . . . . . . . . . . . 32
7.1. Normative References ................................... 29 Appendix A. PIM-BIDIR Thoughts . . . . . . . . . . . . . . . . . 33
7.2. Informative References.................................. 29 Appendix B. Example Network Scenario . . . . . . . . . . . . . . 33
Appendix A. Example Network Scenario............................ 31 B.1. Pim Snooping Example . . . . . . . . . . . . . . . . . . . 34
Appendix A.1 PIM-Snooping Example............................... 31 B.2. PIM Proxy Example with (S,G) / (*,G) interaction . . . . . 36
Appendix A.2 PIM Proxy Example with (S,G) / (*,G) interaction... 33 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 particular VPLS instance single LAN. Forwarding information base for particular VPLS instance
is populated dynamically by source MAC address learning. This is a is populated dynamically by source MAC address learning. This is a
straightforward solution to support unicast traffic, with reasonable straightforward solution to support unicast traffic, with reasonable
flooding for unicast unknown traffic. Since a VPLS provides LAN flooding for unicast unknown traffic. Since a VPLS provides LAN
emulation for IEEE bridges as wells as for routers, the unicast and emulation for IEEE bridges as wells as for routers, the unicast and
multicast traffic need to follow the same path for layer-2 protocols multicast traffic need to follow the same path for layer-2 protocols
to work properly. As such, multicast traffic is treated as broadcast to work properly. As such, multicast traffic is treated as broadcast
traffic and is flooded to every site in the VPLS instance. traffic and is flooded to every site in the VPLS instance. VPLS
solutions (i.e., [VPLS-LDP] and [VPLS-BGP]) perform replication for
multicast traffic at the ingress PE devices. As stated in the VPLS
Multicast Requirements draft [VPLS-MCAST-REQ], there are two issues
with VPLS Multicast today: A. Multicast traffic is replicated to non-
member sites. B. Replication of PWs on shared physical path.
VPLS solutions (i.e., [VPLS-LDP] and [VPLS-BGP]) perform replication This document solves Issue A of [VPLS-MCAST-REQ] by ensuring that IP
for multicast traffic at the ingress PE devices. As stated in the multicast traffic is not forwarded to non-member sites. Issue B is
VPLS Multicast Requirements draft [VPLS-MCAST-REQ], there are two outside the scope of this document. The different mechanisms to
issues with VPLS Multicast today: tunnel IP multicast traffic in a VPLS from the ingress PE to the
A. Multicast traffic is replicated to non-member sites. egress PEs are discussed in[VPLS-MCAST-TREES]. The solution in this
B. Replication of PWs on shared physical path. document when combined with the solutions proposed in the working
group to solve Issue B will provide a complete VPLS Multicast
solution set.
This document solves Issue A of [VPLS-MCAST-REQ] by ensuring that IP Using IGMP/PIM Snooping in VPLS has the following advantages:
multicast traffic is not forwarded to non-member sites. Issue B is
outside the scope of this document. The different mechanisms to
tunnel IP multicast traffic in a VPLS from the ingress PE to the
egress PEs are discussed in [VPLS-MCAST-TREES]. The solution in this
document when combined with the solutions proposed in the working
group to solve Issue B will provide a complete VPLS Multicast
solution set.
Using IGMP/PIM Snooping in VPLS has the following advantages: o It improves IP Multicast bandwidth usage in the VPLS core by
- It improves IP Multicast bandwidth usage in the VPLS core by ensuring traffic is replicated only to PEs with member sites.
ensuring traffic is replicated only to PEs with member sites. Note that this is not necessarily optimum, as there can still be
Note that this is not necessarily optimum, as there can still be bandwidth waste if traffic from a PE to other PE(s) is not
bandwidth waste if traffic from a PE to other PE(s) is not forwarded along a minimum cost spanning tree.
forwarded along a minimum cost spanning tree.
- It prevents sending multicast traffic to non-member sites.
Procedures for IGMP Snooping are specified in [IGMP-SNOOP]. This o It prevents sending multicast traffic to non-member sites.
document describes the procedures for Protocol Independent Multicast
(PIM) snooping over VPLS for efficient distribution of IP multicast
traffic. It also describes the rules when both IGMP and PIM are
active in a VPLS instance.
This document also describes procedures for PIM Proxy. PIM Proxy is Procedures for IGMP Snooping are specified in[IGMP-SNOOP]. This
required on PEs for VPLS Multicast to work correctly when Join document describes the procedures for Protocol Independent Multicast
suppression is enabled in the VPLS. PIM Proxy also helps scale VPLS (PIM) snooping over VPLS for efficient distribution of IP multicast
Multicast much better than just PIM Snooping. traffic. It also describes the rules when both IGMP and PIM are
active in a VPLS instance.
1.1. Assumptions This document also describes procedures for PIM Proxy. PIM Proxy is
required on PEs for VPLS Multicast to work correctly when Join
suppression is enabled in the VPLS. PIM Proxy also helps scale VPLS
Multicast much better than just PIM Snooping.
Since this draft describes the procedures for PIM Snooping and PIM 1.1. Assumptions
Proxy, the draft assumes that the reader has a good understanding of
the PIM protocols. The text in this draft is written in the same
style as the PIM RFCs to help correlate the concepts and to make it
easier to follow. In order to avoid replicating the text relating to
PIM protocol handling here, this draft assumes that the user will
infer such detail from the PIM RFC referenced in this document.
Deviations in protocol handling specific to PIM Snooping and PIM
Proxy are specified in this draft. There could be cross references
into definitions of macros and procedures from the PIM RFCs.
1.2. PIM Snooping and PIM Proxy Complexity Since this draft describes the procedures for PIM Snooping and PIM
Proxy, the draft assumes that the reader has a good understanding of
the PIM protocols. The text in this draft is written in the same
style as the PIM RFCs to help correlate the concepts and to make it
easier to follow. In order to avoid replicating the text relating to
PIM protocol handling here, this draft assumes that the user will
infer such detail from the PIM RFC referenced in this document.
Deviations in protocol handling specific to PIM Snooping and PIM
Proxy are specified in this draft. There could be cross references
into definitions of macros and procedures from the PIM RFCs.
The PIM Snooping and PIM Proxy solutions described here requires a 1.2. PIM Snooping and PIM Proxy Complexity
switch to examine and operate on only PIM Hello and PIM Join/Prune
packets. The switch does not need to examine any other PIM packets.
The switch does not need to have any routing tables like is required The PIM Snooping and PIM Proxy solutions described here requires a
in PIM Multicast Routing. It knows how to forward Join/Prunes by switch to examine and operate on only PIM Hello and PIM Join/Prune
looking at the Upstream Neighbor field in the Join/Prune packets. packets. The switch does not need to examine any other PIM packets.
The switch does not need to know about Rendezvous Points (RP) and The switch does not need to have any routing tables like is required
does not have to maintain any RP Set. All that is transparent to a in PIM Multicast Routing. It knows how to forward Join/Prunes by
PIM Snooping switch. looking at the Upstream Neighbor field in the Join/Prune packets.
Most of the procedures in PIM Snooping and PIM Proxy in the handling The switch does not need to know about Rendezvous Points (RP) and
of PIM Hellos and PIM Join/Prune packets are very similar to that of does not have to maintain any RP Set. All that is transparent to a
a PIM Router. PIM Snooping switch.
The solutions described here provide complete separation of control Most of the procedures in PIM Snooping and PIM Proxy in the handling
and data planes. of PIM Hellos and PIM Join/Prune packets are very similar to that of
a PIM Router.
A PIM Proxy solution minimizes the control plane messages received at The solutions described here provide complete separation of control
CE routers by proxying one message upstream on behalf of a large and data planes.
number of downstream CEs. As such control plane messaging is very
similar to that of a PIM Router.
1.3. Definitions A PIM Proxy solution minimizes the control plane messages received at
CE routers by proxying one message upstream on behalf of a large
number of downstream CEs. As such control plane messaging is very
similar to that of a PIM Router.
There are several definitions referenced in this document that are 1.3. Definitions
well described in the PIM RFCs [PIM-SM, PIM-BIDIR, PIM-DM].
The following definitions and abbreviations are used throughout this There are several definitions referenced in this document that are
document: well described in the PIM RFCs [PIM-SM], PIM-BIDIR, PIM-DM]. The
following definitions and abbreviations are used throughout this
document:
- 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). Pseudo-Wire (PW).
- When we say a PIM message is 'received' on a port, it means
any one of the following:
o that a PIM Snooping switch snooped the PIM message.
o that a PIM message was received via LDP on a PW if LDP (as
defined in [VPLS-MCAST-LDP]) is used for propogating
multicast states among the PEs.
Abbreviations used in the document: o When we say a PIM message is 'received' on a port, it means that a
PIM Snooping switch snooped the PIM message.
- S: IP Address of the Multicast Source. Abbreviations used in the document:
- G: IP Address of the Multicast Group.
- N: Upstream Neighbor field in a Join/Prune/Graft message.
- Rport(N): Port on which neighbor N is learnt
Other definitions are explained in the sections where they are o S: IP Address of the Multicast Source.
introduced.
2. Multicast Traffic over VPLS o G: IP Address of the Multicast Group.
In VPLS, if a PE receives a frame from an Attachment Circuit (AC) o N: Upstream Neighbor field in a Join/Prune/Graft message.
with no matching entry in the forwarding information base for that
particular VPLS instance, it floods the frame to all other PEs (which
are part of this VPLS instance) and to directly connected ACs (other
than the one that the frame is received from). The flooding of a
frame occurs when:
- The destination MAC address has not been learned,
- The destination MAC address is a broadcast address,
- The destination MAC address is a multicast address.
Malicious attacks (e.g., receiving unknown frames constantly) aside, o Rport(N): Port on which neighbor N is learnt
the first situation is handled by VPLS solutions as long as
destination MAC address can be learned. After that point on, the
frames will not be flooded. A PE is REQUIRED to have safeguards,
such as unknown unicast limiting and MAC table limiting, against
malicious unknown unicast attacks.
There is no way around flooding broadcast frames. To prevent runaway Other definitions are explained in the sections where they are
broadcast traffic from adversely affecting the VPLS service and the introduced.
SP network, a PE is REQUIRED to have tools to rate limit the
broadcast traffic as well.
Similar to broadcast frames, multicast frames are flooded as well, as 2. Multicast Traffic over VPLS
a PE cannot know where multicast members reside. Rate limiting
multicast traffic, while possible, should be should be done carefully
since several network control protocols relies on multicast. For one
thing, layer-2 and layer-3 protocols utilize multicast for their
operation. For instance, Bridge Protocol Data Units (BPDUs) use an
IEEE assigned all bridges multicast MAC address, and OSPF is
multicast to all OSPF routers multicast MAC address. If the rate-
limiting of multicast traffic is not done properly, the customer
network will experience instability and poor performance. For the
other, it is not straightforward to determine the right rate limiting
parameters for multicast.
A VPLS solution MUST NOT affect the operation of customer layer-2 In VPLS, if a PE receives a frame from an Attachment Circuit (AC)
protocols (e.g., BPDUs). Additionally, a VPLS solution MUST NOT with no matching entry in the forwarding information base for that
affect the operation of layer-3 protocols. particular VPLS instance, it floods the frame to all other PEs (which
are part of this VPLS instance) and to directly connected ACs (other
than the one that the frame is received from). The flooding of a
frame occurs when:
In the following section, we describe procedures to constrain the o The destination MAC address has not been learned,
flooding of IP multicast traffic in a VPLS.
2.1. Constraining of IP Multicast in a VPLS o The destination MAC address is a broadcast address,
For a PE in a VPLS (a layer-2 device) to constrain IP multicast o The destination MAC address is a multicast address.
traffic, it needs to be able to learn which CEs are interested in
receiving multicast traffic for what flows.
The most obvious solution is to snoop IP multicast control traffic at Malicious attacks (e.g., receiving unknown frames constantly) aside,
the PEs. Snooping as a solution to constrain multicast traffic makes the first situation is handled by VPLS solutions as long as
sense under the following circumstances: destination MAC address can be learned. After that point on, the
frames will not be flooded. A PE is REQUIRED to have safeguards,
such as unknown unicast limiting and MAC table limiting, against
malicious unknown unicast attacks.
- The CE-CE protocol the PEs snoop is a popular and widely There is no way around flooding broadcast frames. To prevent runaway
deployed protocol. broadcast traffic from adversely affecting the VPLS service and the
- It does not require any changes on the CEs and it should be SP network, a PE is REQUIRED to have tools to rate limit the
completely transparent to the CEs. broadcast traffic as well.
IGMP/MLD and PIM are the popular IP Multicast Routing protocols Similar to broadcast frames, multicast frames are flooded as well, as
today. Other routing protocols such as DVMRP or MOSPF are outside the a PE cannot know where multicast members reside. Rate limiting
scope of this document. multicast traffic, while possible, should be done carefully since
several network control protocols relies on multicast. For one
thing, layer-2 and layer-3 protocols utilize multicast for their
operation. For instance, Bridge Protocol Data Units (BPDUs) use an
IEEE assigned all bridges multicast MAC address, and OSPF is
multicast to all OSPF routers multicast MAC address. If the rate-
limiting of multicast traffic is not done properly, the customer
network will experience instability and poor performance. For the
other, it is not straightforward to determine the right rate limiting
parameters for multicast.
This document describes the guidelines for PIM Snooping and PIM Proxy A VPLS solution MUST NOT affect the operation of customer layer-2
in VPLS. The specifications in this document could be used for either protocols (e.g., BPDUs). Additionally, a VPLS solution MUST NOT
PIM Snooping or PIM Proxy. The PIM Proxy solution is described in affect the operation of layer-3 protocols.
section 3.6 Differences that need to be observed while implementing
one or the other and recommendations on which method to employ in
different scenarios are noted in section 2.5We will largely refer to
PIM "Snooping" in this document. Unless specifically specified, the
same procedures should apply to a Proxy solution as well.
In the following sub-sections, we provide some guidelines for the In the following section, we describe procedures to constrain the
implementation of PIM snooping in VPLS. Snooping techniques need to flooding of IP multicast traffic in a VPLS.
be employed on ACs at the downstream PEs. Snooping techniques can
also be employed on PWs at the upstream PEs. This may work well for
small to medium scale deployments. However, if there are a large
number of VPLS instances with a large number of PEs per instances,
then the amount of snooping required at the upstream PEs can
overwhelm the upstream PEs. In [VPLS-MCAST-LDP] and [VPLS-MCAST-BGP],
procedures are defined to exchange multicast membership information
between the PEs using LDP or BGP. Using a reliable mechanism like LDP
or BGP allows the upstream PEs to eliminate the requirement to snoop
on PWs. It also eliminates the need to refresh multicast states on
the upstream PEs.
2.2. IPv6 Considerations 2.1. Constraining of IP Multicast in a VPLS
In VPLS, PEs forward Ethernet frames received from CEs and as such For a PE in a VPLS (a layer-2 device) to constrain IP multicast
are agnostic of the layer-3 protocol used by the CEs. However, as an traffic, it needs to be able to learn which CEs are interested in
IGMP and PIM snooping switch, the PE would have to look deeper into receiving multicast traffic for what flows.
the IP and IGMP/PIM packets and build snooping state based on that.
The PIM Protocol specifications handle both IPv4 and IPv6. The
specification for PIM Snooping in this draft can be applied to both
IPv4 and IPv6 payloads.
2.3. PIM-SM (*,*,RP) Considerations The most obvious solution is to snoop IP multicast control traffic at
the PEs. Snooping as a solution to constrain multicast traffic makes
sense under the following circumstances:
This draft does not address (*,*,RP) states in the VPLS network. o The CE-CE protocol the PEs snoop is a popular and widely deployed
Although [PIM-SM] specifies that routers MUST support (*,*,RP) protocol.
states, there are very few implementations that actually support it
in actual deployments. Given the complexity of supporting (*,*,RP)
states and knowing that there is little to no use to supporting it,
this draft omits the specification relating to (*,*,RP) support.
2.4. PIM Packet Types to Snoop o It does not require any changes on the CEs and it should be
completely transparent to the CEs.
A PIM Snooping switch need only snoop on PIM Hellos and PIM IGMP/MLD and PIM are the popular IP Multicast Routing protocols
Join/Prune packets. All other PIM packets can be transparently today. Other routing protocols such as DVMRP or MOSPF are outside
flooded unexamined. the scope of this document.
2.5. PIM Snooping vs PIM Proxy This document describes the guidelines for PIM Snooping and PIM Proxy
in VPLS. The specifications in this document could be used for
either PIM Snooping or PIM Proxy. The PIM Proxy solution is
described in section Section 3.7. Differences that need to be
observed while implementing one or the other and recommendations on
which method to employ in different scenarios are noted in section
Section 2.5. We will largely refer to PIM "Snooping" in this
document. Unless specifically specified, the same procedures should
apply to a Proxy solution as well.
PIM Snooping switches simply snoop on PIM packets as they are being In the following sub-sections, we provide some guidelines for the
forwarded in the VPLS. As such it truly provides transparent LAN implementation of PIM snooping in VPLS. Snooping techniques need to
services since no customer packets are modified or consumed or new be employed on ACs at the downstream PEs. Snooping techniques can
packets introduced in the VPLS. It is also slightly simpler to also be employed on PWs at the upstream PEs. This may work well for
implement than PIM Proxy. However for PIM Snooping to work correctly, small to medium scale deployments. However, if there are a large
it is a requirement that CE routers MUST disable Join suppression in number of VPLS instances with a large number of PEs per instances,
the VPLS. then the amount of snooping required at the upstream PEs can
overwhelm the upstream PEs.
Given that a large number of existing CE deployments do not support 2.2. IPv6 Considerations
disabling of Join suppression and given the operational complexity
for a provider to manage disabling of Join suppression in the VPLS,
it becomes a difficult solution to deploy. Another disadvantage of
PIM Snooping as a solution is that it does not scale as well as PIM
Proxy. If there are a large number of CEs in a VPLS, then every CE
will see every other CE's Join/Prune messages.
PIM Proxy on the PEs has the advantage that it does not require Join In VPLS, PEs forward Ethernet frames received from CEs and as such
suppression to be disabled in the VPLS. Multicast as a VPLS service are agnostic of the layer-3 protocol used by the CEs. However, as an
can be very easily be provided without requiring any changes on the IGMP and PIM snooping switch, the PE would have to look deeper into
CE routers. It also helps scale VPLS Multicast very well since the the IP and IGMP/PIM packets and build snooping state based on that.
PEs intelligently forward only one Join/Prune message for a given The PIM Protocol specifications handle both IPv4 and IPv6. The
flow and only to the upstream CE. specification for PIM Snooping in this draft can be applied to both
IPv4 and IPv6 payloads.
PIM Proxy as a solution however loses the transparency argument since 2.3. PIM-SM (*,*,RP) Considerations
Join/Prunes could get modified or even consumed at a PE. Also, new
packets could get introduced in the VPLS. However, this loss of
transparency is limited to PIM Join/Prune packets. It is in the
interest of optimizing multicast in the VPLS and helping a VPLS
network scale much better. Data traffic will still be completely
transparent.
Both PIM Snooping and PIM Proxy procedures can be used in conjunction This draft does not address (*,*,RP) states in the VPLS network.
with [VPLS-MCAST-LDP] for propogating multicast states among the PEs. Although [PIM-SM] specifies that routers MUST support (*,*,RP)
If [VPLS-MCAST-LDP] is used for propogating multicast states among states, there are very few implementations that actually support it
the PEs, then both PIM Snooping and PIM Proxy switches do not process in actual deployments. Given the complexity of supporting (*,*,RP)
any PIM packets arriving on a PW. states and knowing that there is little to no use to supporting it,
this draft omits the specification relating to (*,*,RP) support.
2.5.1. Differences between PIM Snooping and PIM Proxy 2.4. PIM Packet Types to Snoop
For PIM-SM and PIM-BIDIR, a PIM Snooping/Proxy Switch only needs to A PIM Snooping switch need only snoop on PIM Hellos and PIM Join/
examine PIM Hello and Join/Prune messages. PIM Proxy for PIM-DM is Prune packets. All other PIM packets can be transparently flooded
for future study and is not currently specified in this draft. unexamined.
The proxy proposal is to perform proxy of only the Join/Prune 2.5. PIM Snooping vs PIM Proxy
messages. PIM Hello messages are snooped by both PIM Snooping and PIM
Proxy switches.
Details on the PIM Proxy solution are discussed in section 3.6 This PIM Snooping switches simply snoop on PIM packets as they are being
section is presented here to say that most of the procedures to forwarded in the VPLS. As such it truly provides transparent LAN
follow (unless explicitly specified) are common to both PIM Snooping services since no customer packets are modified or consumed or new
and PIM Proxy. packets introduced in the VPLS. It is also slightly simpler to
implement than PIM Proxy. However for PIM Snooping to work
correctly, it is a requirement that CE routers MUST disable Join
suppression in the VPLS.
Differences between a PIM Snooping switch and a PIM Proxy switch can Given that a large number of existing CE deployments do not support
be summarized as the following: disabling of Join suppression and given the operational complexity
for a provider to manage disabling of Join suppression in the VPLS,
it becomes a difficult solution to deploy. Another disadvantage of
PIM Snooping as a solution is that it does not scale as well as PIM
Proxy. If there are a large number of CEs in a VPLS, then every CE
will see every other CE's Join/Prune messages.
+------------------------------|--------------------------------+ PIM Proxy on the PEs has the advantage that it does not require Join
| PIM Snooping | PIM Proxy | suppression to be disabled in the VPLS. Multicast as a VPLS service
+==============================|================================+ can be very easily be provided without requiring any changes on the
| 1. PIM Snooping switches | 1. PIM Proxy switches also | CE routers. It also helps scale VPLS Multicast very well since the
| snoop Hello and Join/Prune| snoop PIM Hello messages | PEs intelligently forward only one Join/Prune message for a given
| messages while they are | while they are transparently| flow and only to the upstream CE.
| transparently flooded in | flooded in the VPLS. But |
| the VPLS. | they consume PIM Join/Prune |
| | messages and do not flood |
| | them as is in the VPLS. |
+------------------------------|--------------------------------+
| 2. PIM Snooping switches do | 2. PIM Proxy switches may |
| not originate any PIM | originate new or modified |
| packets. They may however | PIM Hello and Join/Prune |
| originate PIM messages to | packets. |
| be sent via LDP on PWs. | |
+------------------------------|--------------------------------+
Other than the above simple differences, most of the procedures are PIM Proxy as a solution however loses the transparency argument since
common to PIM Snooping and PIM Proxy. There are additional Join/Prunes could get modified or even consumed at a PE. Also, new
simplifications to PIM Snooping that can be made if [VPLS-MCAST-LDP] packets could get introduced in the VPLS. However, this loss of
is not used for PE-PE communication, but otherwise the procedures for transparency is limited to PIM Join/Prune packets. It is in the
PIM Snooping and PIM Proxy are mostly the same. In the text to interest of optimizing multicast in the VPLS and helping a VPLS
follow, we describe the procedures for PIM "Snooping". Unless network scale much better. Data traffic will still be completely
specifically stated otherwise, such procedures apply to PIM Proxy as transparent.
well.
2.5.2. PIM Control Message Latency 2.5.1. Differences between PIM Snooping and PIM Proxy
A PIM Snooping or PIM Proxy switch snoops on PIM Hello packets while For PIM-SM and PIM-BIDIR, a PIM Snooping/Proxy Switch only needs to
transparently flooding it in the VPLS. As such there is no latency examine PIM Hello and Join/Prune messages. PIM Proxy for PIM-DM is
introduced by the VPLS in the delivery of PIM Hello packets to remote for future study and is not currently specified in this draft.
CEs in the VPLS.
A PIM Proxy switch consumes PIM Join/Prune packets and generates A proxy switch performs proxy only for the Join/Prune messages. PIM
proxy Join/Prune packets to be sent upstream. This can result in Hello messages are snooped by both PIM Snooping and PIM Proxy
additional latency for a downstream CE to receive multicast traffic switches.
after it has sent a Join. When a downstream CE prunes a multicast
stream, the traffic should stop flowing to the CE with no additional
latency introduced by the VPLS.
A PIM Snooping switch snoops on PIM Join/Prune packets while Details on the PIM Proxy solution are discussed in section
transparently flooding them in the VPLS. There is no latency Section 3.7. This section is presented here to say that most of the
introduced by the VPLS in the delivery of PIM Join/Prune packets when procedures to follow (unless explicitly specified) are common to both
PIM Snooping is employed. PIM Snooping and PIM Proxy. Differences between a PIM Snooping
switch and a PIM Proxy switch can be summarized as the following:
2.5.3. When to Snoop and When to Proxy +------------------------------|--------------------------------+
| PIM Snooping | PIM Proxy |
+==============================|================================+
| 1. PIM Snooping switches | 1. PIM Proxy switches also |
| snoop Hello and Join/Prune| snoop PIM Hello messages |
| messages while they are | while they are transparently|
| transparently flooded in | flooded in the VPLS. But |
| the VPLS. | they consume PIM Join/Prune |
| | messages and do not flood |
| | them as is in the VPLS. |
+------------------------------|--------------------------------+
| 2. PIM Snooping switches do | 2. PIM Proxy switches may |
| not originate any PIM | originate new or modified |
| packets. | Join/Prune packets. |
+------------------------------|--------------------------------+
Explicit Tracking (ET) is enabled in a VPLS when all PIM CE Routers Other than the above simple differences, most of the procedures are
in the VPLS advertise Tracking Support in their PIM Hello messages. common to PIM Snooping and PIM Proxy. In the text to follow, we
If even one does not advertise Tracking Support, then all PIM CE describe the procedures for PIM "Snooping". Unless specifically
routers disable ET in the VPLS. When ET is enabled, it implies that stated otherwise, such procedures apply to PIM Proxy as well.
Join Suppression is disabled and vice versa.
PIM Snooping PEs can determine if ET is enabled or disabled in a VPLS 2.5.2. PIM Control Message Latency
by examining PIM Hellos. If ET is disabled, PIM Proxy MUST be used.
If ET is enabled, PIM Snooping SHOULD be used.
3. PIM Snooping for VPLS A PIM Snooping or PIM Proxy switch snoops on PIM Hello packets while
transparently flooding it in the VPLS. As such there is no latency
introduced by the VPLS in the delivery of PIM Hello packets to remote
CEs in the VPLS.
IGMP snooping procedures described in [IGMP-SNOOP] provide efficient A PIM Proxy switch consumes PIM Join/Prune packets and generates
delivery of IP multicast traffic in a given VPLS service when end proxy Join/Prune packets to be sent upstream. This can result in
stations are connected to the VPLS. However, when VPLS is offered as additional latency for a downstream CE to receive multicast traffic
a WAN service it is likely that the CE devices are routers and would after it has sent a Join. When a downstream CE prunes a multicast
run PIM between them. To provide efficient IP multicasting in such stream, the traffic should stop flowing to the CE with no additional
cases, it is necessary that the PE routers offering the VPLS service latency introduced by the VPLS.
do PIM snooping.
PIM is a multicast routing protocol, which runs exclusively between A PIM Snooping switch snoops on PIM Join/Prune packets while
routers. PIM shares many of the common characteristics of a routing transparently flooding them in the VPLS. There is no latency
protocol, such as discovery messages (e.g., neighbor discovery using introduced by the VPLS in the delivery of PIM Join/Prune packets when
Hello messages), topology information (e.g., multicast tree), and PIM Snooping is employed.
error detection and notification (e.g., dead timer and designated
router election). On the other hand, PIM does not participate in any
kind of exchange of databases, as it uses the unicast routing table
to provide reverse path information for building multicast trees.
There are a few variants of PIM. In PIM-DM ([PIM-DM]), multicast
data is pushed towards the members similar to broadcast mechanism.
PIM-DM constructs a separate delivery tree for each multicast group.
As opposed to PIM-DM, other PIM flavors (PIM-SM [PIM-SM], PIM-SSM
[PIM-SSM], and PIM-BIDIR [PIM-BIDIR]) invoke a pull methodology
instead of push technique.
PIM routers periodically exchange Hello messages to discover and 2.5.3. When to Snoop and When to Proxy
maintain stateful sessions with neighbors. After neighbors are
discovered, PIM routers can signal their intentions to join or prune
specific multicast groups. This is accomplished by having downstream
routers send an explicit Join/Prune message (for the sake of
generalization, consider Graft messages for PIM-DM as Join messages)
to the upstream routers. The Join/Prune message can be group
specific (*,G) or group and source specific (S,G).
In PIM snooping, a PE snoops on the PIM message exchanged between Explicit Tracking (ET) is enabled in a VPLS when all PIM CE Routers
routers, and builds its multicast states. in the VPLS advertise Tracking Support in their PIM Hello messages.
If even one does not advertise Tracking Support, then all PIM CE
routers disable ET in the VPLS. When ET is enabled, it implies that
Join Suppression is disabled and vice versa.
Based on the multicast states, it forwards IP multicast traffic PIM Snooping PEs can determine if ET is enabled or disabled in a VPLS
accordingly to avoid unnecessary flooding. by examining PIM Hellos. If ET is disabled, PIM Proxy MUST be used.
If ET is enabled, either PIM Snooping or PIM Proxy can be used,
unless the PIM control message latency due to proxy is a concern, in
which case PIM Snooping SHOULD be used.
In the following sub-sections, snooping mechanisms for each variety 3. PIM Snooping for VPLS
of PIM are specified.
3.1. General Rules for PIM Snooping in VPLS IGMP snooping procedures described in [IGMP-SNOOP] provide efficient
delivery of IP multicast traffic in a given VPLS service when end
stations are connected to the VPLS. However, when VPLS is offered as
a WAN service it is likely that the CE devices are routers and would
run PIM between them. To provide efficient IP multicasting in such
cases, it is necessary that the PE routers offering the VPLS service
do PIM snooping.
The following rules for the correct operation of PIM snooping MUST be PIM is a multicast routing protocol, which runs exclusively between
followed. routers. PIM shares many of the common characteristics of a routing
protocol, such as discovery messages (e.g., neighbor discovery using
Hello messages), topology information (e.g., multicast tree), and
error detection and notification (e.g., dead timer and designated
router election). On the other hand, PIM does not participate in any
kind of exchange of databases, as it uses the unicast routing table
to provide reverse path information for building multicast trees.
There are a few variants of PIM. In [PIM-DM], multicast data is
pushed towards the members similar to broadcast mechanism. PIM-DM
constructs a separate delivery tree for each multicast group. As
opposed to PIM-DM, other PIM flavors (PIM-SM [PIM-SM], PIM-SSM
[PIM-SSM], and PIM-BIDIR [PIM-BIDIR]) invoke a pull methodology
instead of push technique.
- PIM messages and multicast data traffic forwarded by PEs MUST PIM routers periodically exchange Hello messages to discover and
follow the split-horizon rule for mesh PWs as defined in maintain stateful sessions with neighbors. After neighbors are
[VPLS-LDP]. discovered, PIM routers can signal their intentions to join or prune
- PIM snooping states in a PE MUST be per VPLS instance. specific multicast groups. This is accomplished by having downstream
- Multicast traffic MUST be replicated per PW and AC basis, routers send an explicit Join/Prune message (for the sake of
i.e., even if there are more than one PIM neighbor behind a generalization, consider Graft messages for PIM-DM as Join messages)
PW/AC, only one replication MUST be sent to that PW/AC. to the upstream routers. The Join/Prune message can be group
specific (*,G) or group and source specific (S,G).
3.1.1. Snooping PIM Packets In PIM snooping, a PE snoops on the PIM message exchanged between
routers, and builds its multicast states.
PIM-SM and PIM-BIDIR snooping PEs need to snoop on just the PIM Hello Based on the multicast states, it forwards IP multicast traffic
and PIM Join/Prune messages to build its multicast states. accordingly to avoid unnecessary flooding.
- PIM-DM snooping PEs have to also snoop on PIM Graft and PIM In the following sub-sections, snooping mechanisms for each variety
State Refresh messages. of PIM are specified.
3.2. Discovering PIM Routers 3.1. General Rules for PIM Snooping in VPLS
A PIM Snooping PE MUST snoop on PIM Hellos received on ACs and PWs. The following rules for the correct operation of PIM snooping MUST be
i.e. the PE transparently floods the PIM Hello while snooping on it. followed.
PIM Hellos are used by the snooping switch to discover PIM routers
and their characteristics.
For each neighbor discovered by a PE, it includes an entry in the PIM o PIM messages and multicast data traffic forwarded by PEs MUST
Neighbor Database with the following fields: follow the split-horizon rule for mesh PWs.
- Layer 2 encapsulation for the Router sending the PIM Hello. o PIM snooping states in a PE MUST be per VPLS instance.
- IP Address and address family of the Router sending the PIM
Hello.
- Port (AC / PW) on which the PIM Hello was received.
- Hello TLVs
The PE should be able to interpret and act on Hello TLVs currently o PIM assert triggers MUST be preserved to the extent necessary to
defined in the PIM RFCs. The TLVs of particular interest in this avoid sending duplicate traffic to the same PE (see
document are: Section 3.1.2).
- Hello-Hold-Time 3.1.1. Snooping PIM Packets
- Tracking Support
- DR Priority
Please refer to [PIM-SM] for a list of the Hello TLVs. PIM-SM snooping PEs need to snoop on just the PIM Hello and PIM Join/
Prune messages to build its multicast states.
When a PIM Hello is received, the PE MUST reset the neighbor-expiry- o PIM-DM snooping PEs have to also snoop on PIM Graft and PIM State
timer to Hello-Hold-Time. If a PE does not receive a Hello message Refresh messages.
from a router within Hello-Hold-Time, the PE MUST remove that
neighbor from its PIM Neighbor Database. If a PE receives a Hello
message from a router with Hello-Hold-Time value set to zero, the PE
MUST remove that router from the PIM snooping state immediately.
From the PIM Neighbor Database, a PE MUST be able to use the 3.1.2. Preserving Assert Trigger
procedures defined in [PIM-SM] to identify the PIM Designated Router
in the VPLS instance. It should also be able to determine if Tracking
Support is active in the VPLS instance.
3.3. PIM-SM and PIM-SSM In PIM-SM/DM, there are scenarios where multiple routers could be
forwarding the same multicast traffic on a LAN. When this happens,
using PIM Assert Election process by sending PIM Assert Messages,
routers ensure that only the Assert Winner forwards traffic on the
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
forwarding the traffic. In the case of VPLS with snooping, two
routers may forward the same flow at the same time but each copy may
reach different set of PEs, and that is acceptable from the point of
view of avoiding duplicate traffic. If the two copies may reach the
same PE then the sending routers must be able to see each other's
traffic, in order to trigger Assert Election and stop duplicate
traffic.
The key characteristic of PIM-SM and PIM-SSM is explicit join To achieve that, PIM-SM Snooping MUST not only forward multicast
behavior. In this model, multicast traffic is only forwarded to traffic for an (S,G) on the ports on which they snooped Joins(S,G)/
locations that specifically request it. The root node of a tree is Joins(*,G), but also towards the upstream neighbor(s)). In other
the Rendezvous Point (RP) in case of a shared tree (PIM-SM only) or words, the ports on which the upstream neighbors are learnt must be
the first hop router that is directly connected to the multicast added to the outgoing port list along with the ports on which Joins
source in the case of a shortest path tree. All the procedures are snooped.
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.
The procedures to discover PIM-SM routers in a VPLS instance are as Similarly, PIM-DM Snooping SHOULD make sure that asserts can be
described in section 3.2 triggered (Section 3.6.3).
3.3.1. Building PIM-SM Snooping States The above logic needs to be facilitated without breaking VPLS Split
Horizon Rules. i.e. traffic should not be forwarded on the port on
which it was received, and traffic arriving on a PW MUST NOT be
forwarded onto other PW(s).
PIM-SM and PIM-SSM Snooping states are built by snooping on the PIM- 3.2. Discovering PIM Routers
SM Join/Prune messages received on AC/PWs.
The downstream state machine of a PIM-SM snooping switch very closely
resembles the downstream state machine of PIM-SM routers. The
downstream state consists of:
Per downstream (Port, *, G): A PIM Snooping PE MUST snoop on PIM Hellos received on ACs and PWs.
- DownstreamJPState: One of { "NoInfo" (NI), "Join" (J), "Prune i.e. the PE transparently floods the PIM Hello while snooping on it.
Pending" (PP) } PIM Hellos are used by the snooping switch to discover PIM routers
and their characteristics.
Per downstream (Port, *, G, N): For each neighbor discovered by a PE, it includes an entry in the PIM
- Prune Pending Timer (PPT(N)) Neighbor Database with the following fields:
- Join Expiry Timer (ET(N))
Per downstream (Port, S, G): o Layer 2 encapsulation for the Router sending the PIM Hello.
- DownstreamJPState: One of { "NoInfo" (NI), "Join" (J), "Prune
Pending" (PP) }
Per downstream (Port, S, G, N): o IP Address and address family of the Router sending the PIM Hello.
- Prune Pending Timer (PPT(N))
- Join Expiry Timer (ET(N))
Per downstream (Port, S, G, rpt): o Port (AC / PW) on which the PIM Hello was received.
- DownstreamJPRptState: One of { "NoInfo" (NI), "Pruned" (P),
"Prune Pending" (PP) }
Per downstream (Port, S, G, rpt, N): o Hello TLVs
- Prune Pending Timer (PPT(N))
- Join Expiry Timer (ET(N))
Where S is the address of the multicast source, G is the Group The PE should be able to interpret and act on Hello TLVs currently
address and N is the upstream neighbor field in the Join/Prune defined in the PIM RFCs. The TLVs of particular interest in this
message. Notice that unlike on PIM-SM routers where PPT and ET are document are:
per (Interface, S, G), PIM Snooping switches have to maintain PPT and
ET per (Port, S, G, N). The reasons for this are explained in section
3.3.2
Apart from the above states, we define the following state o Hello-Hold-Time
summarization macros.
UpstreamNeighbors(*,G): If there is one or more Join(*,G) received on o Tracking Support
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
Join(*,G) or a Prune(*,G) with upstream neighbor N needs to be sent
upstream.
UpstreamNeighbors(S,G): If there is one or more Join(S,G) received on o DR Priority
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
Join(S,G) or a Prune(S,G) with upstream neighbor N needs to be sent
upstream.
UpstreamPorts(*,G): This is the set of all Rport(N) ports where N is Please refer to [PIM-SM] for a list of the Hello TLVs. When a PIM
in the set UpstreamNeighbors(*,G). Multicast Streams forwarded using Hello is received, the PE MUST reset the neighbor-expiry- timer to
a (*,G) match MUST be forwarded to these ports in addition to Hello-Hold-Time. If a PE does not receive a Hello message from a
downstream ports. So UpstreamPorts(*,G) MUST be added to router within Hello-Hold-Time, the PE MUST remove that neighbor from
OutgoingPortList(*,G). its PIM Neighbor Database. If a PE receives a Hello message from a
router with Hello-Hold-Time value set to zero, the PE MUST remove
that router from the PIM snooping state immediately.
UpstreamPorts(S,G): This is the set of all Rport(N) ports where N is From the PIM Neighbor Database, a PE MUST be able to use the
in the set UpstreamNeighbors(S,G). UpstreamPorts(S,G) MUST be added procedures defined in [PIM-SM] to identify the PIM Designated Router
to OutgoingPortList(S,G). in the VPLS instance. It should also be able to determine if
Tracking Support is active in the VPLS instance.
UpstreamPorts(S,G,rpt): If PruneDesired(S,G,rpt) becomes true, then 3.3. PIM-SM and PIM-SSM
this set is set to UpstreamPorts(*,G). Otherwise, this set is empty.
UpstreamPorts(*,G) (-) UpstreamPorts(S,G,rpt) MUST be added to
OutgoingPortList(S,G).
See section 3.8.1 on Data Forwarding Rules for the specification on The key characteristic of PIM-SM and PIM-SSM is explicit join
how OutgoingPortList(S,G) is calculated. behavior. In this model, multicast traffic is only forwarded to
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 first hop router that is directly connected to the multicast
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
for the fact that there is no (*,G) state in PIM-SSM.
UpstreamPorts(G): This set is the union of all the UpstreamPorts(S,G) 3.3.1. Building PIM-SM Snooping States
and UpstreamPorts(*,G) for a given G. Proxy (S,G) Join/Prune and
(*,G) Join/Prune messages MUST be sent to a subset of
UpstreamPorts(G) as specified in section 3.3.8.
PWPorts: This is the set of all PWs. PIM-SM and PIM-SSM Snooping states are built by snooping on the PIM-
SM Join/Prune messages received on AC/PWs.
OutgoingPortList(*,G): This is the set of all ports to which traffic The downstream state machine of a PIM-SM snooping switch very closely
needs to be forwarded on a (*,G) match. Split Horizon rules apply as resembles the downstream state machine of PIM-SM routers. The
noted in section 3.8 downstream state consists of:
OutgoingPortList(S,G): This is the set of all ports to which traffic Per downstream (Port, *, G):
needs to be forwarded on an (S,G) match. Split Horizon rules apply as
noted in section 3.8
NumETsActive(Port,*,G): Number of (Port,*,G,N) entries that have o DownstreamJPState: One of { "NoInfo" (NI), "Join" (J), "Prune
Expiry Timer running. This macro keeps track of the number of Pending" (PP) }
Join(*,G)s that are received on this Port with different upstream
neighbors.
NumETsActive(Port,S,G): Number of (Port,S,G,N) entries that have Per downstream (Port, *, G, N):
Expiry Timer running. This macro keeps track of the number of
Join(*,G)s that are received on this Port with different upstream
neighbors.
RpfVectorTlvs(*,G): RPF Vectors [RPF-VECTOR] are TLVs that may be o Prune Pending Timer (PPT(N))
present in received Join(*,G) messages. If present, they must be
copied to RpfVectorTlvs(*,G).
RpfVectorTlvs(S,G): RPF Vectors [RPF-VECTOR] are TLVs that may be o Join Expiry Timer (ET(N))
present in received Join(S,G) messages. If present, they must be
copied to RpfVectorTlvs(S,G).
Since there are a few differences between the downstream state Per downstream (Port, S, G):
machines of PIM-SM Routers and PIM-SM snooping switches, we specify
the details of the downstream state machine of PIM-SM snooping
switches at the risk of repeating most of the text documented in
[PIM-SM].
3.3.2. Explanation for per (S,G,N) states o DownstreamJPState: One of { "NoInfo" (NI), "Join" (J), "Prune
Pending" (PP) }
In PIM Routing protocols, states are built per (S,G). On a router, an Per downstream (Port, S, G, N):
(S,G) has only one RPF-Neighbor. However, a PIM Snooping switch does
not have the Layer 3 routing information available to the routers in
order to determine the RPF-Neighbor for a multicast flow. It merely
discovers it by snooping the Join/Prune message. A PE could have
snooped on two or more different Join/Prune messages for the same
(S,G) that could have carried different Upstream-Neighbor fields.
This could happen during transient network conditions or due to dual-
homed sources. A PE cannot make assumptions on which one to pick, but
instead must facilitate the CE routers decide which Upstream Neighbor
gets elected the RPF-Neighbor. And for this purpose, the PE will have
to track downstream and upstream Join/Prune states per (S,G,N).
3.3.3. Receiving (*,G) PIM-SM Join/Prune Messages o Prune Pending Timer (PPT(N))
A Join(*,G) or Prune(*,G) is "received" when the port on which it was o Join Expiry Timer (ET(N))
received is not also the port on which the upstream-neighbor N of the
Join/Prune(*,G) was learnt.
When a router receives a Join(*,G) or a Prune(*,G) with upstream Per downstream (Port, S, G, rpt):
neighbor N, it must process the message as defined in the state
machine below. Note that the macro computations of the various macros
resulting from this state machine transition is exactly as specified
in the PIM-SM RFC [PIM-SM].
We define the following per-port (*,G,N) macro to help with the state o DownstreamJPRptState: One of { "NoInfo" (NI), "Pruned" (P), "Prune
machine below. Pending" (PP) }
Figure 1: Downstream per-port (*,G) state machine in tabular form Per downstream (Port, S, G, rpt, N):
+---------------++----------------------------------------+ o Prune Pending Timer (PPT(N))
| || Previous State |
| ++------------+--------------+------------+
| Event ||NoInfo (NI) | Join (J) | Prune-Pend |
+---------------++------------+--------------+------------+
| Receive ||-> J state | -> J state | -> J state |
| Join(*,G) || Action | Action | Action |
| || RxJoin(N) | RxJoin(N) | RxJoin(N) |
+---------------++------------+--------------+------------+
|Receive || - | -> PP state | -> PP state|
|Prune(*,G) and || | Start PPT(N) | |
|NumETsActive<=1|| | | |
+---------------++------------+--------------+------------+
|Receive || - | -> J state | - |
|Prune(*,G) and || | Start PPT(N) | |
NumETsActive>1 || | | |
+---------------++------------+--------------+------------+
|PPT(N) expires || - | -> J state | -> NI state|
| || | Action | Action |
| || | PPTExpiry(N) |PPTExpiry(N)|
+---------------++------------+--------------+------------+
|ET(N) expires || - | -> NI state | -> NI state|
|and || | Action | Action |
|NumETsActive<=1|| | ETExpiry(N) | ETExpiry(N)|
+---------------++------------+--------------+------------+
|ET(N) expires || - | -> J state | -> NI state|
|and || | Action | Action |
|NumETsActive>1 || | ETExpiry(N) | ETExpiry(N)|
+---------------++------------+--------------+------------+
Action RxJoin(N): o Join Expiry Timer (ET(N))
If ET(N) is not already running, then start ET(N). Otherwise restart Where S is the address of the multicast source, G is the Group
ET(N). address and N is the upstream neighbor field in the Join/Prune
If N is not already in UpstreamNeighbors(*,G), then add N to message. Notice that unlike on PIM-SM routers where PPT and ET are
UpstreamNeighbors(*,G) and trigger a Join(*,G) with upstream neighbor per (Interface, S, G), PIM Snooping switches have to maintain PPT and
N to be forwarded upstream as specified in section 3.3.8 ET per (Port, S, G, N). The reasons for this are explained in
Record N as RPF_Neighbor(*,G). section Section 3.3.2
If there are RPF Vector TLVs in the received (S,G) message and if
they are different from the recorded RpfVectorTlvs(S,G), then copy
them into RpfVectorTlvs(S,G). Also trigger a Join(S,G) with upstream
neighbor N to be forwarded upstream as specified in section 3.3.8
Action PPTExpiry(N): Apart from the above states, we define the following state
summarization macros.
Disable timers ET(N) and PPT(N). If there are no other (Port,*,G) UpstreamNeighbors(*,G): If there is one or more Join(*,G) received on
states with NumETsActive(Port,*,G) > 0, then trigger a Prune(*,G) any port with upstream neighbor N and ET(N) is active, then N is
with upstream neighbor N to be forwarded upstream as specified in added to UpstreamNeighbors(*,G). This set is used to determine if a
section 3.3.8 Then delete N from UpstreamNeighbors(*,G). Join(*,G) or a Prune(*,G) with upstream neighbor N needs to be sent
upstream.
Send a Prune-Echo(*,G) with upstream-neighbor N on the downstream UpstreamNeighbors(S,G): If there is one or more Join(S,G) received on
port. 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
Join(S,G) or a Prune(S,G) with upstream neighbor N needs to be sent
upstream.
Action ETExpiry(N): UpstreamPorts(*,G): This is the set of all Rport(N) ports where N is
in the set UpstreamNeighbors(*,G). Multicast Streams forwarded using
a (*,G) match MUST be forwarded to these ports in addition to
downstream ports. So UpstreamPorts(*,G) MUST be added to
OutgoingPortList(*,G).
Disable timers ET(N) and PPT(N). If there are no other (Port,*,G) UpstreamPorts(S,G): This is the set of all Rport(N) ports where N is
states with NumETsActive(Port,*,G) > 0, then trigger a Prune(*,G) in the set UpstreamNeighbors(S,G). UpstreamPorts(S,G) MUST be added
with upstream neighbor N to be forwarded upstream as specified in to OutgoingPortList(S,G).
section 3.3.8 Then delete N from UpstreamNeighbors(*,G).
3.3.4. Receiving (S,G) PIM-SM Join/Prune Messages InheritedUpstreamPorts(S,G): This is the union of UpstreamPorts(S,G)
and UpstreamPorts(*,G).
A Join(S,G) or Prune(S,G) is "received" when the port on which it was UpstreamPorts(S,G,rpt): If PruneDesired(S,G,rpt) becomes true, then
received is not also the port on which the upstream-neighbor N of the this set is set to UpstreamPorts(*,G). Otherwise, this set is empty.
Join/Prune(S,G) was learnt. UpstreamPorts(*,G) (-) UpstreamPorts(S,G,rpt) MUST be added to
OutgoingPortList(S,G).
When a router receives a Join(S,G) or a Prune(S,G) with upstream UpstreamPorts(G): This set is the union of all the UpstreamPorts(S,G)
neighbor N, it must process the message as defined in the state and UpstreamPorts(*,G) for a given G. Proxy (S,G) Join/Prune and
machine below. Note that the macro computations of the various macros (*,G) Join/Prune messages MUST be sent to a subset of
resulting from this state machine transition is exactly as specified UpstreamPorts(G) as specified in section Section 3.3.6.1.
in the PIM-SM RFC [PIM-SM].
PWPorts: This is the set of all PWs.
OutgoingPortList(*,G): This is the set of all ports to which traffic
needs to be forwarded on a (*,G) match.
OutgoingPortList(S,G): This is the set of all ports to which traffic
needs to be forwarded on an (S,G) match.
See section Section 3.9 on Data Forwarding Rules for the
specification on how OutgoingPortList is calculated.
NumETsActive(Port,*,G): Number of (Port,*,G,N) entries that have
Expiry Timer running. This macro keeps track of the number of
Join(*,G)s that are received on this Port with different upstream
neighbors.
NumETsActive(Port,S,G): Number of (Port,S,G,N) entries that have
Expiry Timer running. This macro keeps track of the number of
Join(*,G)s that are received on this Port with different upstream
neighbors.
RpfVectorTlvs(*,G): RPF Vectors [RPF-VECTOR] are TLVs that may be
present in received Join(*,G) messages. If present, they must be
copied to RpfVectorTlvs(*,G).
RpfVectorTlvs(S,G): RPF Vectors [RPF-VECTOR] are TLVs that may be
present in received Join(S,G) messages. If present, they must be
copied to RpfVectorTlvs(S,G).
Since there are a few differences between the downstream state
machines of PIM-SM Routers and PIM-SM snooping switches, we specify
the details of the downstream state machine of PIM-SM snooping
switches at the risk of repeating most of the text documented in
[PIM-SM].
3.3.2. Explanation for per (S,G,N) states
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 switch
does not have the Layer 3 routing information available to the
routers in order to determine the RPF-Neighbor for a multicast flow.
It merely discovers it by snooping the Join/Prune message. A PE
could have snooped on two or more different Join/Prune messages for
the same (S,G) that could have carried different Upstream-Neighbor
fields. This could happen during transient network conditions or due
to dual- homed sources. A PE cannot make assumptions on which one to
pick, but instead must facilitate the CE routers decide which
Upstream Neighbor gets elected the RPF-Neighbor. And for this
purpose, the PE will have to track downstream and upstream Join/Prune
states per (S,G,N).
3.3.3. Receiving (*,G) PIM-SM Join/Prune Messages
A Join(*,G) or Prune(*,G) is considered "received" if the following
conditions are met:
o The port on which it arrived is not Rport(N) where N is the
upstream-neighbor N of the Join/Prune(*,G), or,
o if both RPort(N) and the arrival port are PWs, then there exists
at least one other (*,G,Nx) or (Sx,G,Nx) state with an AC
UpstreamPort.
For simplicity, the case where both RPort(N) and the arrival port are
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
the related forwarding entries' OutgoingPortList to trigger Assert,
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
be the same. See Appendix Appendix B for examples.
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
machine below. Note that the macro computations of the various
macros resulting from this state machine transition is exactly as
specified in the PIM-SM RFC [PIM-SM].
We define the following per-port (*,G,N) macro to help with the state
machine below.
Figure 1 : Downstream per-port (*,G) state machine in tabular form
+---------------++----------------------------------------+
| || Previous State |
| ++------------+--------------+------------+
| Event ||NoInfo (NI) | Join (J) | Prune-Pend |
+---------------++------------+--------------+------------+
| Receive ||-> J state | -> J state | -> J state |
| Join(*,G) || Action | Action | Action |
| || RxJoin(N) | RxJoin(N) | RxJoin(N) |
+---------------++------------+--------------+------------+
|Receive || - | -> PP state | -> PP state|
|Prune(*,G) and || | Start PPT(N) | |
|NumETsActive<=1|| | | |
+---------------++------------+--------------+------------+
|Receive || - | -> J state | - |
|Prune(*,G) and || | Start PPT(N) | |
|NumETsActive>1 || | | |
+---------------++------------+--------------+------------+
|PPT(N) expires || - | -> J state | -> NI state|
| || | Action | Action |
| || | PPTExpiry(N) |PPTExpiry(N)|
+---------------++------------+--------------+------------+
|ET(N) expires || - | -> NI state | -> NI state|
|and || | Action | Action |
|NumETsActive<=1|| | ETExpiry(N) | ETExpiry(N)|
+---------------++------------+--------------+------------+
|ET(N) expires || - | -> J state | -> NI state|
|and || | Action | Action |
|NumETsActive>1 || | ETExpiry(N) | ETExpiry(N)|
+---------------++------------+--------------+------------+
Action RxJoin(N):
If ET(N) is not already running, then start ET(N). Otherwise
restart ET(N). If N is not already in UpstreamNeighbors(*,G),
then add N to UpstreamNeighbors(*,G) and trigger a Join(*,G) with
upstream neighbor N to be forwarded upstream. If there are RPF
Vector TLVs in the received (*,G) message and if they are
different from the recorded RpfVectorTlvs(*,G), then copy them
into RpfVectorTlvs(*,G).
Action PPTExpiry(N):
Same as Action ETExpiry(N) below, plus Send a Prune-Echo(*,G) with
upstream-neighbor N on the downstream port.
Action ETExpiry(N):
Disable timers ET(N) and PPT(N). Delete neighbor state
(Port,*,G,N). If there are no other (Port,*,G) states with
NumETsActive(Port,*,G) > 0, transition DownstreamJPState to
NoInfo. If there are no other (Port,*,G,N) state (different ports
but for the same N), remove N from UpstreamPorts(*,G) - this also
serves as a trigger for US FSM (JoinDesired(*,G,N) becomes FALSE).
3.3.4. Receiving (S,G) PIM-SM Join/Prune Messages
A Join(S,G) or Prune(S,G) is considered "received" if the following
conditions are met:
o The port on which it arrived is not Rport(N) where N is the
upstream-neighbor N of the Join/Prune(S,G), or,
o if both RPort(N) and the arrival port are PWs, then there exists
at least one other (*,G,Nx) or (S,G,Nx) state with an AC
UpstreamPort.
For simplicity, the case where both RPort(N) and the arrival port are
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
the related forwarding entries' OutgoingPortList to trigger Assert,
but that is only needed for those states with AC UpstreamPort. See
Appendix Appendix B for examples.
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
machine below. Note that the macro computations of the various
macros resulting from this state machine transition is exactly as
specified in the PIM-SM RFC [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 |
| ++------------+--------------+------------+
| Event ||NoInfo (NI) | Join (J) | Prune-Pend |
+---------------++------------+--------------+------------+
| Receive ||-> J state | -> J state | -> J state |
| Join(S,G) || Action | Action | Action |
| || RxJoin(N) | RxJoin(N) | RxJoin(N) |
+---------------++------------+--------------+------------+
|Receive || - | -> PP state | -> PP state|
|Prune (S,G) and|| | Start PPT(N) | |
|NumETsActive<=1|| | | |
+---------------++------------+--------------+------------+
|Receive || - | -> J state | - |
|Prune(S,G) and || | Start PPT(N) | |
NumETsActive>1 || | | |
+---------------++------------+--------------+------------+
|PPT(N) expires || - | -> J state | -> NI state|
| || | Action | Action |
| || | PPTExpiry(N) |PPTExpiry(N)|
+---------------++------------+--------------+------------+
|ET(N) expires || - | -> NI state | -> NI state|
|and || | Action | Action |
|NumETsActive<=1|| | ETExpiry(N) | ETExpiry(N)|
+---------------++------------+--------------+------------+
|ET(N) expires || - | -> J state | -> NI state|
|and || | Action | Action |
|NumETsActive>1 || | ETExpiry(N) | ETExpiry(N)|
+---------------++------------+--------------+------------+
+---------------++----------------------------------------+ Action RxJoin(N):
| || Previous State |
| ++------------+--------------+------------+
| Event ||NoInfo (NI) | Join (J) | Prune-Pend |
+---------------++------------+--------------+------------+
| Receive ||-> J state | -> J state | -> J state |
| Join(S,G) || Action | Action | Action |
| || RxJoin(N) | RxJoin(N) | RxJoin(N) |
+---------------++------------+--------------+------------+
|Receive || - | -> PP state | -> PP state|
|Prune (S,G) and|| | Start PPT(N) | |
|NumETsActive<=1|| | | |
+---------------++------------+--------------+------------+
|Receive || - | -> J state | - |
|Prune(S,G) and || | Start PPT(N) | |
NumETsActive>1 || | | |
+---------------++------------+--------------+------------+
|PPT(N) expires || - | -> J state | -> NI state|
| || | Action | Action |
| || | PPTExpiry(N) |PPTExpiry(N)|
+---------------++------------+--------------+------------+
|ET(N) expires || - | -> NI state | -> NI state|
|and || | Action | Action |
|NumETsActive<=1|| | ETExpiry(N) | ETExpiry(N)|
+---------------++------------+--------------+------------+
|ET(N) expires || - | -> J state | -> NI state|
|and || | Action | Action |
|NumETsActive>1 || | ETExpiry(N) | ETExpiry(N)|
+---------------++------------+--------------+------------+
Action RxJoin(N): If ET(N) is not already running, then start ET(N). Otherwise,
restart ET(N).
If ET(N) is not already running, then start ET(N). Otherwise, restart If N is not already in UpstreamNeighbors(S,G), then add N to
ET(N). UpstreamNeighbors(S,G) and trigger a Join(S,G) with upstream
neighbor N to be forwarded upstream. If there are RPF Vector TLVs
in the received (S,G) message and if they are different from the
recorded RpfVectorTlvs(S,G), then copy them into
RpfVectorTlvs(S,G).
If N is not already in UpstreamNeighbors(S,G), then add N to Action PPTExpiry(N):
UpstreamNeighbors(S,G) and trigger a Join(S,G) with upstream neighbor
N to be forwarded upstream as specified in section 3.3.8
Record N as RPF_Neighbor(S,G).
If there are RPF Vector TLVs in the received (S,G) message and if
they are different from the recorded RpfVectorTlvs(S,G), then copy
them into RpfVectorTlvs(S,G). Also trigger a Join(S,G) with upstream
neighbor N to be forwarded upstream as specified in section 3.3.8
Action PPTExpiry(N): Same as Action ETExpiry(N) below, plus Send a Prune-Echo(S,G) with
upstream-neighbor N on the downstream port.
Disable timers ET(N) and PPT(N). If there are no other (Port,S,G) Action ETExpiry(N):
states with NumETsActive(Port,S,G) > 0, then trigger a Prune(S,G)
with upstream neighbor N to be forwarded upstream as specified in
section 3.3.8Then delete N from UpstreamNeighbors(S,G).
Send a Prune-Echo(S,G) with upstream-neighbor N on the downstream Disable timers ET(N) and PPT(N). Delete neighbor state
port. (Port,S,G,N). If there are no other (Port,S,G) states with
NumETsActive(Port,S,G) > 0, transition DownstreamJPState to
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
serves as a trigger for US FSM (JoinDesired(S,G,N) becomes FALSE).
Action ETExpiry(N): 3.3.5. Receiving (S,G,rpt) Join/Prune Messages
Disable timers ET(N) and PPT(N). If there are no other (Port,S,G) A Join(S,G,rpt) or Prune(S,G,rpt) is "received" when the port on
states with NumETsActive(Port,S,G) > 0, then trigger a Prune(S,G) which it was received is not also the port on which the upstream-
with upstream neighbor N to be forwarded upstream as specified in neighbor N of the Join/Prune(S,G,rpt) was learnt.
section 3.3.8 Then delete N from UpstreamNeighbors(S,G).
3.3.5. Receiving (S,G,rpt) Join/Prune Messages 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
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
section 4.5.4 of the PIM-SM RFC [PIM-SM].
A Join(S,G,rpt) or Prune(S,G,rpt) is "received" when the port on which 3.3.6. Sending Join/Prune Messages Upstream
it was received is not also the port on which the upstream-neighbor N
of the Join/Prune(S,G,rpt) was learnt.
While it is important to ensure that the (S,G) and (*,G) state machines This section applies only to a PIM Proxy Switch and not to a PIM
allow for handling per (S,G,N) states, it is not as important for Snooping Switch.
(S,G,rpt) states. It suffices to say that the 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].
3.3.6. Sending (*,G) Join/Prune Messages A PIM Proxy PE MUST implement the Upstream FSM for which the
procedures are similar to what is defined in section 4.5.6 of
[PIM-SM]. Similar to Downstream FSM described above, the Upstream
FSM is also per Upstream Neighbor.
A PIM Proxy PE MUST implement the Upstream (*,G) state machine for For the purposes of the Upstream FSM, a Join or Prune message with
which the procedures are similar to what is defined in section 4.5.6 upstream neighbor N is "seen" on a PIM Snooping switch if the port on
of [PIM-SM]. Section 3.3.8of this draft specifies how the message which the message was received is also Rport(N), and the port is an
should be sent. 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.
For the purposes of the Upstream (*,G) state machine, a Join(*,G) or In order to correctly facilitate assert among the CE routers, such
Prune(*,G) message with upstream neighbor N is "seen" on a PIM Join/Prunes need to sent not only towards the upstream neighbor, but
Snooping switch if the port on which the message was received is also also on certain PWs as described below.
the port on which the upstream neighbor N was learnt.
3.3.7. Sending (S,G) Join/Prune Messages If RpfVectorTlvs(*,G) is not empty, then it must be encoded in a
Join(*,G) message sent upstream.
A PIM Proxy PE MUST implement the Upstream (S,G) state machine for If RpfVectorTlvs(S,G) is not empty, then it must be encoded in a
which the procedures are similar to what is defined in section 4.5.6 Join(S,G) message sent upstream.
of [PIM-SM]. Section 3.3.8of this draft specifies how the message
should be sent.
For the purposes of the Upstream (S,G) state machine, a Join(*,G) or 3.3.6.1. Where to send Join/Prune messages
Prune(*,G) message with upstream neighbor N is "seen" on a PIM
Snooping switch if the port on which the message was received is also
the port on which the upstream neighbor N was learnt.
3.3.8. Sending PIM Join/Prune message upstream. The following rules apply, to both refresh and triggered (S,G)/(*,G)
Join/Prune messages.
Sending of PIM Join/Prune messages upstream is only required on a PIM o The upstream neighbor field N in the Join/Prune to be sent is set
Proxy Switch and not on a PIM Snooping Switch. This section applies to the N in the corresponding Upstream FSM.
only to a PIM Proxy Switch.
The downstream Join/Prune state machines above describe when PIM o if Rport(N) is an AC, send the message to Rport(N).
Join/Prune packets must be forwarded upstream and with what upstream
neighbor field. In order to correctly facilitate assert among the CE
routers, such Join/Prunes need to sent not only towards the upstream
neighbor, but also on certain PWs as described below. It is important
to note that Join/Prune packets are sent to a subset of the ports in
UpstreamPorts(G) and is not simply flooded to all PWs.
If RpfVectorTlvs(*,G) is not empty, then it must be encoded in a
Join(*,G) message sent upstream.
If RpfVectorTlvs(S,G) is not empty, then it must be encoded in a o Additionally, if OutgoingPortList(X,G,N) contains at lease one AC,
Join(S,G) message sent upstream. then the message MUST be sent to at least all the PWs in
UpstreamPorts(G) (for (*,G)) or InheritedUpstreamPorts(S,G) (for
(S,G)). Alternatively, the message MAY be sent to all PWs.
3.3.8.1. Sending Triggered vs Refresh Join/Prune messages Sending to a subset of PWs as described above guarantees that if
traffic (of the same flow) from two upstream routers were to reach
this PE, then the two routers will receive from each other,
triggering assert.
A Join is a refresh join if it is being sent as a result of upstream Sending to all PWs guarantees that if two upstream routers both send
join timer expiry. If the join is being sent because there was a traffic for the same flow (even if it is to different set of
change in the downstream join/prune state machine, then it is a downstream PEs), then they'll receive from each other, triggering
triggered join. assert.
If the Join/Prune message being sent out is a refresh Join(*,G) 3.4. Bidirectional-PIM (PIM-BIDIR)
message, then send the refresh Join(*,G) on all ports in
UpstreamPorts(G). The Upstream Neighbor field should be the recorded
RPF_Neighbor(*,G).
If the Join/Prune message being sent out is a refresh Join(S,G)
message, then send the refresh Join(S,G) on all ports in
UpstreamPorts(G). The Upstream Neighbor field should be the recorded
RPF_Neighbor(S,G).
If the Join/Prune message being sent out is a triggered Join/Prune PIM-BIDIR is a variation of PIM-SM. The main differences between
message (due to an event in the downstream Join/Prune state machine), PIM-SM and Bidirectional-PIM are as follows:
then the following rules apply. These rules apply to both (S,G) and
(*,G) Join/Prune messages to be sent out:
- The upstream neighbor field N in the Join/Prune to be sent is o There are no source-based trees, and source-specific multicast is
dictated by the downstream Join/Prune state machine not supported (i.e., no (S,G) states) in PIM- BIDIR.
transition.
- If the downstream Join/Prune event was on an AC port, then
send the upstream Join/Prune message to all PWs in
UpstreamPorts(G). Send the Join/Prune message to Rport(N)
also.
- If the downstream Join/Prune event was on a PW port and if
Rport(N) is a PW, then silently discard the Join/Prune
message without sending it. If Rport(N) is an AC, then send
the Join/Prune message on that AC.
3.3.9. Triggering ASSERT Election in PIM-SM o Multicast traffic can flow up the shared tree in PIM-BIDIR.
In PIM-SM, there are scenarios where multiple routers could be o To avoid forwarding loops, one router on each link is elected as
forwarding the same multicast traffic on a LAN. When this happens, the Designated Forwarder (DF) for each RP in PIM-BIDIR.
using PIM Assert Election process by sending PIM Assert Messages,
routers ensure that only the Assert Winner forwards traffic on the
LAN. In a typical 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 forwarding the traffic. Therefore, in the case of VPLS, in
order to trigger Assert Election and stop duplicate traffic, it is
necessary that two routers that are forwarding duplicate traffic for
an (S,G)/(*,G) see each other's traffic.
PIM Snooping switches must hence ensure that they not only forward The main advantage of PIM-BIDIR is that it scales well for many-to-
multicast traffic for an (S,G) on the ports on which they snooped many applications. However, the lack of source-based trees means
Joins(S,G)/Joins(*,G), but also on the ports on which such Joins were that multicast traffic is forced to remain on the shared tree.
forwarded (i.e. towards the upstream neighbor(s)). So if two or more
Joins(S,G) each carrying a different upstream neighbor field were
snooped at a PE, then the ports on which such Joins were snooped
along with the ports on which the upstream neighbors were learnt must
be added to the outgoing port list.
The above logic needs to be facilitated without breaking VPLS Split As described in [PIM-BIDIR], parts of a PIM-BIDIR enabled network may
Horizon Rules. i.e. traffic should not be forwarded on the port on forward traffic without exchanging Join/Prune messages, for instance
which it was received. And traffic arriving on a PW MUST NOT be between DF's and the RPL.
forwarded onto other PW(s). The rules specified above in calculating
the outgoing port list ensures this.
An example network scenario is discussed in Appendix A with possible As the described procedures for Pim snooping rely on the presence of
ASSERT Election scenarios. Join/Prune messages, enabling Pim snooping on PIM-BIDIR networks
could break the PIM-BIDIR functionality. Deploying Pim snooping on
PIM-BIDIR enabled networks will require some further study, some
thoughts are gathered in Appendix A.
3.4. Bidirectional-PIM (PIM-BIDIR) 3.5. Interaction with IGMP Snooping
PIM-BIDIR is a variation of PIM-SM. The main differences between Whenever IGMP Snooping is enabled in conjunction with PIM Snooping in
PIM-SM and Bidirectional-PIM are as follows: the same VPLS instance the switch SHOULD follow these rules:
- There are no source-based trees, and source-specific o To maintain the list of multicast routers and ports on which they
multicast is not supported (i.e., no (S,G) states) in PIM- are attached, the switch SHOULD NOT use the rules as described in
BIDIR. section 2.1.1.(1) of RFC4541 [IGMP-SNOOP] but SHOULD rely on the
- Multicast traffic can flow up the shared tree in PIM-BIDIR. neighbors discovered by PIM Snooping . This list SHOULD then be
- To avoid forwarding loops, one router on each link is elected used to apply the forwarding rule as described in 2.1.1.(1) of
as the Designated Forwarder (DF) for each RP in PIM-BIDIR. RFC4541 [IGMP-SNOOP].
The main advantage of PIM-BIDIR is that it scales well for many-to- o If the switch supports proxy-reporting, as described in section
many applications. However, the lack of source-based trees means 2.1.1.(2) of RFC4541 [IGMP-SNOOP], all IGMP membership information
that multicast traffic is forced to remain on the shared tree. learned on a port to which a PIM neighbor is attached SHOULD NOT
be included in the summarized upstream report.
The procedures to discover PIM-SM routers in a VPLS instance are as 3.6. PIM-DM
described in section 3.2 For PIM-BIDIR to work properly, all routers
within the domain must know the address of the RP. During RP
discovery time, PIM routers elect DF per subnet for each RP. The
algorithm to elect the DF is as follows: all PIM neighbors in a
subnet advertise their unicast route to elect the RP and the router
with the best route is elected.
Snooping for PIM-BIDIR is much simpler than it is for PIM-SM. The The characteristics of PIM-DM is flood and prune behavior. Shortest
complexity resulting from various combinations of (S,G), (*,G), IGMP path trees are built as a multicast source starts transmitting.
and assert states makes PIM-SM procedures fairly complex. PIM-BIDIR
has none of those issues since PIM-BIDIR builds only (*,G) states and
all routers on a LAN agree on who the upstream neighbor, i.e. DF(RP)
is. So the snooping procedures for PIM-BIDIR is very much like that
on a PIM-BIDIR router [PIM-BIDIR].
3.4.1. Building PIM-BIDIR Snooping States 3.6.1. Building PIM-DM Snooping States
The PEs MUST snoop on PIM Hello and PIM-BIDIR Join/Prune packets and PIM-DM Snooping states are built by snooping on the PIM-DM Join,
build states as described in [PIM-BIDIR]. The PEs SHOULD simply Prune, Graft and State Refresh messages received on AC/PWs and State-
flood all other PIM packet types without examining them. 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
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:
PIM Proxy Rules specified in section 2.5can be applied to PIM-BIDR Per PIM (S,G,N):
also. Only additional requirement is that if the Upstream Port of a
PIM-BIDIR group is a PW, then the proxy PIM Join/Prune packet MUST
be sent on all PWs.
3.5. PIM-DM Port PIM (S,G,N) Prune State:
The characteristics of PIM-DM is flood and prune behavior. Shortest * DownstreamPState(S,G,N,Port): One of {"NoInfo" (NI), "Pruned"
path trees are built as a multicast source starts transmitting. (P), "PrunePending" (PP)}
The procedures to discover PIM-DM routers are as explained in section * Prune Pending Timer (PPT)
3.2
3.5.1. Building PIM-DM Snooping States * Prune Timer (PT)
* Upstream Port (valid if the PIM(S,G,N) Prune State is
"Pruned").
PIM-DM Snooping states are built by snooping on the PIM-DM Join, 3.6.2. PIM-DM Downstream Per-Port PIM(S,G,N) State Machine
Prune, Graft and State Refresh messages received on AC/PWs and State-
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
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:
Per PIM (S,G,N): 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
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
(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
section Section 3.6.1, the states (DownstreamPState) and timers (PPT
and PT) are per (S,G,N,P).
Per Port PIM (S,G,N) Prune State: 3.6.3. Triggering ASSERT election in PIM-DM
- DownstreamPState(S,G,N,Port): One of {"NoInfo" (NI), "Pruned"
(P), "PrunePending" (PP)}
- Prune Pending Timer (PPT)
- Prune Timer (PT)
- Upstream Port (valid if the PIM(S,G,N) Prune State is
"Pruned").
3.5.2. PIM-DM Downstream Per-Port PIM(S,G,N) State Machine 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
on non-RPF interfaces, PEs should typically not receive Prunes on
Rport(RPF-neighbor). So the asserting routers should typically be in
pim_oiflist(S,G). In most cases, assert election should occur
naturally without any special handling since data traffic will be
forwarded to the asserting routers.
The downstream per-port PIM(S,G,N) state machine is as defined in However, there are some scenarios where a prune might be received on
section 4.4.2 of [PIM-DM] with a few changes relevant to PIM a port which is also an upstream port (UP). If we prune the port
Snooping. When reading section 4.4.2 of [PIM-DM] for the purposes of from pim_oiflist(S,G), then it would not be possible for the
PIM-Snooping please be aware that the downstream states are built per asserting routers to determine if traffic arrived on their downstream
(S, G, N, Downstream-Port} in PIM-Snooping and not per {Downstream- port. This can be fixed by adding pim_iifs(S,G) to pim_oiflist(S,G)
Interface, S, G} as in a PIM-DM router. As noted in the previous so that data traffic flows to the UP ports.
section 3.5.1, the states (DownstreamPState) and timers (PPT and PT)
are per (S,G,N,P).
3.5.3. Triggering ASSERT election in PIM-DM 3.7. PIM Proxy
Since PIM-DM is a flood-and-prune protocol, traffic is flooded to all As noted earlier, PIM Snooping will work correctly only if Join
routers unless explicitly pruned. Since PIM-DM routers do not prune Suppression is disabled in the VPLS. If Join Suppression is enabled
on non-RPF interfaces, PEs should typically not receive Prunes on in the VPLS, then PEs MUST do PIM Proxy for VPLS Multicast to work
Rport(RPF-neighbor). So the asserting routers should typically be in correctly.
pim_oiflist(S,G). In most cases, assert election should occur
naturally without any special handling since data traffic will be
forwarded to the asserting routers.
However, there are some scenarios where a prune might be received on A PIM Proxy switch behaves like a PIM Router by doing most of the
a port which is also an upstream port (UP). If we prune the port from functionality of a PIM Router. The complexity however is much lesser
pim_oiflist(S,G), then it would not be possible for the asserting on a switch since many of the issues that a PIM Router has to deal
routers to determine if traffic arrived on their downstream port. with are not relevant on a switch. A PIM Router needs to be able to
This can be fixed by adding pim_iifs(S,G) to pim_oiflist(S,G) so that build and maintain RP-Sets. They also have to deal with the Register
data traffic flows to the UP ports. and Assert State Machines. There are other complexities for a PIM
Router resulting from inter-domain multicast. A PIM Snooping or PIM
Proxy switch can be agnostic of all of this. All that a PIM Proxy
switch cares about is building multicast states using PIM Hellos and
PIM Join/Prune message. As such it's complexity is greatly reduced.
3.6. PIM Proxy Other than the procedures defined here, the rest of the procedures
that apply to PIM Snooping apply to PIM Proxy as well.
As noted earlier in section 2.5, PIM Snooping will work correctly 3.7.1. Downstream PIM Proxy behavior
only if Join Suppression is disabled in the VPLS. If Join Suppression
is enabled in the VPLS, then PEs MUST do PIM Proxy for VPLS Multicast
to work correctly.
A PIM Proxy switch behaves like a PIM Router by doing most of the Only PIM Join/Prune messages are proxied. Hellos MUST be snooped
functionality of a PIM Router. The complexity however is much lesser while being flooded in the VPLS. i.e. PIM Hellos MUST NOT be
on a switch since many of the issues that a PIM Router has to deal consumed at a PE and regenerated.
with are not relevant on a switch. A PIM Router needs to be able to
build and maintain RP-Sets. They also have to deal with the Register
and Assert State Machines. There are other complexities for a PIM
Router resulting from inter-domain multicast. A PIM Snooping or PIM
Proxy switch can be agnostic of all of this. All that a PIM Proxy
switch cares about is building multicast states using PIM Hellos and
PIM Join/Prune message. As such it's complexity is greatly reduced.
Other than the procedures defined here, the rest of the procedures All other PIM packet types are flooded in the VPLS without any
that apply to PIM Snooping apply to PIM Proxy as well. processing.
3.6.1. Downstream PIM Proxy behavior Performing only proxy of Join/Prune messages keeps the switch
behavior very similar to that of a PIM router without introducing too
much additional complexity. It keeps the PIM Proxy solution fairly
simple. Since Join/Prunes are forwarded by a PE along the slow-path
and all other PIM packet types are forwarded along the fast-path, it
is very likely that packets forwarded along the fast-path will arrive
"ahead" of Join/Prune packets at a CE router (note the stress on the
fact that fast-path messages will never arrive after Join/Prunes).
Of particular importance are Hello packets sent along the fast-path.
We can construct a variety of scenarios resulting in out of order
delivery of Hellos and Join/Prune messages. However, there should be
no deviation from normal expected behavior observed at the CE router
receiving these messages out of order.
A PIM-SM or PIM-BIDIR Proxy PE is interested in the Hello and The other option for a PIM Proxy solution is to proxy both Hello and
Join/Prune messages. The proposed PIM Proxy solution for PIM-SM and Join/Prune messages that a PE is interested in building states for.
PIM-BIDIR is to proxy only Join/Prune messages. PIM Proxy for PIM-DM If Hellos are being proxied, then it becomes necessary that the PE
is for future study. proxy all other PIM packet types also. Because if Hellos are
received after other packet types are received at a CE router, then
bad things will happen. That means every PIM packet has to be sent
along the slow-path. This greatly increases the complexity on the CE
router, it is very compute intensive and does not scale well. Also,
proxying Hellos will result in added latency to delivery of Hello
messages to a CE and that affects multicast convergence in the VPLS.
PIM Hellos MUST be snooped while being flooded in the VPLS. i.e. PIM 3.7.2. Upstream PIM Proxy behavior
Hellos MUST NOT be consumed at a PE and regenerated.
PIM Join/Prune messages arriving at an AC MUST be consumed. If [VPLS- Since a PIM Proxy switch consumes Join/Prune messages, it must also
MCAST-LDP] is not used to distribute multicast states among the PEs, originate PIM Join/Prune messages to be sent upstream. On ACs, both
then PIM Join/Prune messages arriving at a PW MUST also be consumed. triggered and refresh Join/Prunes are forwarded as PIM packets.
All other PIM packet types are flooded in the VPLS without needing 3.7.3. Source IP Address in Proxy PIM Join/Prune Packets
observation.
Performing only proxy of Join/Prune messages keeps the switch The source IP address in PIM packets sent upstream SHOULD be the
behavior very similar to that of a PIM router without introducing too address of a PIM downstream neighbor in the corresponding join/prune
much additional complexity. It keeps the PIM Proxy solution fairly state. The address picked MUST NOT be the upstream neighbor field to
simple. Since Join/Prunes are forwarded by a PE along the slow-path be encoded in the packet. The layer 2 encapsulation for the selected
and all other PIM packet types are forwarded along the fast-path, it source IP address MUST be the encapsulation recorded in the PIM
is very likely that packets forwarded along the fast-path will arrive Neighbor database for that IP address.
"ahead" of Join/Prune packets at a CE router (note the stress on the
fact that fast-path messages will never arrive after Join/Prunes). Of
particular importance are Hello packets sent along the fast-path. We
can construct a variety of scenarios resulting in out of order
delivery of Hellos and Join/Prune messages. However, there should be
no deviation from normal expected behavior observed at the CE router
receiving these messages out of order.
The other option for a PIM Proxy solution is to proxy both Hello and If Explicit Tracking (ET) is disabled in the VPLS, then it does not
Join/Prune messages that a PE is interested in building states for. matter what Source IP Address is picked in the packets sent upstream
If Hellos are being proxied, then it becomes necessary that the PE as long as we adhere to the rule in the previous paragraph.
proxy all other PIM packet types also. Because if Hellos are received
after other packet types are received at a CE router, then bad things
will happen. That means every PIM packet has to be sent along the
slow-path. This greatly increases the complexity on the CE router, it
is very compute intensive and does not scale well. Also, proxying
Hellos will result in added latency to delivery of Hello messages to
a CE and that affects multicast convergence in the VPLS.
3.6.2. Upstream PIM Proxy behavior If ET is enabled, it means that a CE router is interested in tracking
every CE that wishes to join a stream. If a PE determines that ET is
enabled, then it SHOULD use PIM Snooping procedures instead of PIM
Proxy.
Since a PIM Proxy switch consumes Join/Prune messages, it must also 3.8. Directly Connected Multicast Source
originate PIM Join/Prune messages to be sent upstream. If [VPLS-
MCAST-LDP] is employed, then triggered Join/Prune messages are sent
via LDP to forward PIM Join/Prunes on PWs. Join/Prune messages need
not be refreshed on PWs when [VPLS-MCAST-LDP] is employed. On ACs,
both triggered and refresh Join/Prunes are forwarded as PIM packets.
3.6.3. Source IP Address in Proxy PIM Join/Prune Packets If there is a source in the CE network that connects directly into
the VPLS instance, then multicast traffic from that source MUST be
sent to all PIM routers on the VPLS instance apart from the igmp
receivers in the VPLS. If there is already (S,G) or (*,G) snooping
state that is formed on any PE, this will not happen per the current
forwarding rules and guidelines. So, in order to determine if
traffic needs to be flooded to all routers, a PE must be able to
determine if the traffic came from a host on that LAN. There are
three ways to address this problem:
The source IP address in PIM packets sent upstream SHOULD be the o The PE would have to do ARP snooping to determine if a source is
address of a PIM neighbor in the VPLS. The address picked MUST NOT be directly connected.
the upstream neighbor field to be encoded in the packet. The layer 2
encapsulation for the selected source IP address MUST be the
encapsulation recorded in the PIM Neighbor database for that IP
address.
If Explicit Tracking (ET) is disabled in the VPLS, then it does not o Another option is to have configuration on all PEs to say there
matter what Source IP Address is picked in the packets sent upstream are CE sources that are directly connected to the VPLS instance
as long as we adhere to the rule in the previous paragraph. and disallow snooping for the groups for which the source is going
to send traffic. This way traffic from that source to those
groups will always be flooded within the provider network.
If ET is enabled, it means that a CE router is interested in tracking o A third option is to require that sources of CE multicast routers
every CE that wishes to join a stream. If a PE determines that ET is must appear behind a router.
enabled, then it SHOULD use PIM Snooping procedures instead of PIM
Proxy.
3.7. Directly Connected Multicast Source 3.9. Data Forwarding Rules
If there is a source in the CE network that connects directly into First we define the rules that are common to PIM-SM, PIM-BIDIR and
the VPLS instance, then multicast traffic from that source MUST be PIM-DM PEs. Forwarding rules for each protocol type is specified in
sent to all PIM routers on the VPLS instance apart from the igmp the sub-sections.
receivers in the VPLS. If there is already (S,G) or (*,G) snooping
state that is formed on any PE, this will not happen per the current
forwarding rules and guidelines. So, in order to determine if
traffic needs to be flooded to all routers, a PE must be able to
determine if the traffic came from a host on that LAN. There are
three ways to address this problem:
- The PE would have to do ARP snooping to determine if a source If there is no matching forwarding state, then the PE MAY either
is directly connected. discard the packet or send it towards all the snooped PIM CE routers
- Another option is to have configuration on all PEs to say or to a configured set of ports. How this is determined is outside
there are CE sources that are directly connected to the VPLS the scope of this document.
instance and disallow snooping for the groups for which the
source is going to send traffic. This way traffic from that
source to those groups will always be flooded within the
provider network.
- A third option is to require that sources of CE multicast
routers must appear behind a router.
3.8. Data Forwarding Rules The following general rules MUST be followed when forwarding
multicast traffic in a VPLS:
First we define the rules that are common to PIM-SM, PIM-BIDIR and o Traffic arriving on a port MUST NOT be forwarded back onto the
PIM-DM PEs. Forwarding rules for each protocol type is specified in same port.
the sub-sections.
If there is no matching forwarding state, then the PE MAY either o Due to VPLS Split-Horizon rules, traffic ingressing on a PW MUST
discard the packet or send it towards all the snooped PIM CE routers NOT be forwarded to any other PW.
or to a configured set of ports. How this is determined is outside
the scope of this document.
The following rules MUST be followed when forwarding multicast 3.9.1. PIM-SM Data Forwarding Rules
traffic in a VPLS:
- Traffic arriving on a port MUST NOT be forwarded back onto Per the rules in [PIM-SM] and per the additional rules specified in
the same port. this document,
- Due to VPLS Split-Horizon rules, traffic ingressing on a PW
MUST NOT be forwarded to any other PW.
3.8.1. PIM-SM Data Forwarding Rules OutgoingPortList(*,G) = immediate_olist(*,G) (+)
UpstreamPorts(*,G) (+)
Rport(PimDR)
Per the rules in [PIM-SM] and per the additional rules specified in OutgoingPortList(S,G) = inherited_olist(S,G) (+)
this document, UpstreamPorts(S,G) (+)
(UpstreamPorts(*,G) (-)
UpstreamPorts(S,G,rpt)) (+)
Rport(PimDR)
OutgoingPortList(*,G) = inherited_olist(*,G) (+) UpstreamPorts(*,G) [PIM-SM]specifies how immediate_olist(*,G) and inherited_olist(S,G)
(+) Rport(PimDR) are built. PimDR is the IP address of the PIM DR in the VPLS.
OutgoingPortList(S,G) = inherited_olist(S,G) (+) UpstreamPorts(S,G) The PIM-SM Snooping forwarding rules are defined below in pseudocode:
(+) (UpstreamPorts(*,G) (-)
UpstreamPorts(S,G,rpt))
(+) Rport(PimDR)
[PIM-SM] specifies how inherited_olist(*,G) and inherited_olist(S,G) BEGIN
are built. PimDR is the IP address of the PIM DR in the VPLS. iif is the incoming port of the multicast packet.
S is the Source IP Address of the multicast packet.
G is the Destination IP Address of the multicast packet.
The PIM-SM Snooping forwarding rules are defined below in pseudocode: If there is (S,G) state on the PE
Then
OutgoingPortList = OutgoingPortList(S,G)
Else if there is (*,G) state on the PE
Then
OutgoingPortList = OutgoingPortList(*,G)
Else
OutgoingPortList = UserDefinedPortList
Endif
BEGIN If iif is an AC
iif is the incoming port of the multicast packet. Then
S is the Source IP Address of the multicast packet. OutgoingPortList = OutgoingPortList (-) iif
G is the Destination IP Address of the multicast packet. Else
## iif is a PW
OutgoingPortList = OutgoingPortList (-) PWPorts
Endif
If there is (S,G) state on the PE Forward the packet to OutgoingPortList.
Then END
OutgoingPortList = OutgoingPortList(S,G)
Else if there is (*,G) state on the PE
Then
OutgoingPortList = OutgoingPortList(*,G)
Else
OutgoingPortList = UserDefinedPortList
Endif
If iif is an AC First if there is (S,G) state on the PE, then the set of outgoing
Then ports is OutgoingPortList(S,G).
OutgoingPortList = OutgoingPortList (-) iif
Else
## iif is a PW
OutgoingPortList = OutgoingPortList (-) PWPorts
Endif
Forward the packet to OutgoingPortList. Otherwise if there is (*,G) state on the PE, the set of outgoing
END ports is OutgoingPortList(*,G).
First if there is (S,G) state on the PE, then the set of outgoing The packet is forwarded to the selected set of outgoing ports while
ports is OutgoingPortList(S,G). observing the general rules above in section Section 3.9
Otherwise if there is (*,G) state on the PE, the set of outgoing 3.9.2. PIM-BIDIR Data Forwarding Rules
ports is OutgoingPortList(*,G).
The packet is forwarded to the selected set of outgoing ports while The PIM-BIDIR Snooping forwarding rules are defined below in
observing the rules above in section 3.8 pseudocode:
3.8.2. PIM-BIDIR Data Forwarding Rules BEGIN
iif is the incoming port of the multicast packet.
G is the Destination IP Address of the multicast packet.
The PIM-BIDIR Snooping forwarding rules are defined below in If there is forwarding state for G
pseudocode: Then
OutgoingPortList = olist(G)
Else
OutgoingPortList = UserDefinedPortList
Endif
BEGIN If iif is an AC
iif is the incoming port of the multicast packet. Then
G is the Destination IP Address of the multicast packet. OutgoingPortList = OutgoingPortList (-) iif
Else
## iif is a PW
OutgoingPortList = OutgoingPortList (-) PWPorts
Endif
If there is forwarding state for G Forward the packet to OutgoingPortList.
Then END
OutgoingPortList = olist(G)
Else
OutgoingPortList = UserDefinedPortList
Endif
If iif is an AC
Then
OutgoingPortList = OutgoingPortList (-) iif
Else
## iif is a PW
OutgoingPortList = OutgoingPortList (-) PWPorts
Endif
Forward the packet to OutgoingPortList. If there is forwarding state for G, then forward the packet to
END olist(G) while observing the general rules above in section
Section 3.9
If there is forwarding state for G, then forward the packet to [PIM-BIDIR] specifies how olist(G) is contructed.
olist(G) while observing the rules above in section 3.8
[PIM-BIDIR] specifies how olist(G) is contructed. 3.9.3. PIM-DM Data Forwarding Rules
3.8.3. PIM-DM Data Forwarding Rules The PIM-DM Snooping data forwarding rules are defined below in
pseudocode:
The PIM-DM Snooping data forwarding rules are defined below in BEGIN
pseudocode: iif is the incoming port of the multicast packet.
S is the Source IP Address of the multicast packet.
G is the Destination IP Address of the multicast packet.
BEGIN If there is (S,G) state on the PE
iif is the incoming port of the multicast packet. Then
S is the Source IP Address of the multicast packet. OutgoingPortList = olist(S,G)
G is the Destination IP Address of the multicast packet. Else
OutgoingPortList = UserDefinedPortList
Endif
If there is (S,G) state on the PE If iif is an AC
Then Then
OutgoingPortList = olist(S,G) OutgoingPortList = OutgoingPortList (-) iif
Else Else
OutgoingPortList = UserDefinedPortList ## iif is a PW
Endif OutgoingPortList = OutgoingPortList (-) PWPorts
Endif
If iif is an AC Forward the packet to OutgoingPortList.
Then END
OutgoingPortList = OutgoingPortList (-) iif
Else
## iif is a PW
OutgoingPortList = OutgoingPortList (-) PWPorts
Endif
Forward the packet to OutgoingPortList. If there is forwarding state for (S,G), then forward the packet to
END olist(S,G) while observing the general rules above in section
Section 3.9
If there is forwarding state for (S,G), then forward the packet to [PIM-DM] specifies how olist(S,G) is contructed.
olist(S,G) while observing the rules above in section 3.8
[PIM-DM] specifies how olist(S,G) is contructed. 4. IANA Considerations
4. IANA Considerations This document makes no request of IANA.
This document does not require any IANA assignments or action. Note to RFC Editor: this section may be removed on publication as an
RFC.
5. Security Considerations 5. Security Considerations
Security considerations provided in VPLS solution documents (i.e., Security considerations provided in VPLS solution documents (i.e.,
[VPLS-LDP] and [VPLS-BGP) apply to this document as well. [VPLS-LDP] and [VPLS-BGP]) apply to this document as well.
6. Acknowledgements 6. Contributers
Many members of the L2VPN and PIM working groups have contributed to Karl (Xiangrong) Cai and Princy Elizabeth made significant
and provided valuable comments and feedback to this draft, including contributions to bring the specification to its current state,
Vach Kompella, Shane Amante, Sunil Khandekar, Rob Nath, Marc Lassere, especially in the area of Join forwarding rules.
Yuji Kamite, Yiqun Cai, Ali Sajassi, Jayant Kotalwar, Jozef Raets,
Himanshu Shah (Ciena), Himanshu Shah (Alcatel-Lucent).
7. References Yetik Serbest, Ray Qiu, Suresh Boddapati co-authored earlier
versions.
7.1. Normative References 7. Acknowledgements
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Many members of the L2VPN and PIM working groups have contributed to
Requirement Levels", BCP 14, RFC 2119, March 1997. and provided valuable comments and feedback to this draft, including
[PIM-DM] Deering, S., et al. "Protocol Independent Multicast Vach Kompella, Shane Amante, Sunil Khandekar, Rob Nath, Marc Lassere,
Version 2 - Dense Mode Specification", RFC 3973, Yuji Kamite, Yiqun Cai, Ali Sajassi, Jozef Raets, Himanshu Shah
January 2005. (Ciena), Himanshu Shah (Alcatel-Lucent).
[PIM-SM] Fenner, W, et al. "Protocol Independent Multicast-
Sparse Mode (PIM-SM): Protocol Specification
(Revised)", RFC 4601, August 2006.
[PIM-SSM] Holbrook, H., et al. "Source-Specific Multicast for
IP", RFC 4607, August 2006
[PIM-BIDIR] Handley, M., et al. "Bi-directional Protocol
Independent Multicast (BIDIR-PIM)", work in
progress
[RPF-VECTOR] IJ Wijnands, et al, "The RPF Vector TLV",
draft-ietf-pim-rpf-vector-03, Work in progress
7.2. Informative References 8. References
[VPLS-LDP] Lasserre, M, et al. "Virtual Private LAN Services 8.1. Normative References
using LDP Signaling", RFC 4762, January 2007
[VPLS-BGP] Kompella, K, et al. "Virtual Private LAN Service
using BGP for Auto-Discovery and Signaling", RFC
4761, January 2007
[IGMP-SNOOP] Christensen, M., et al. "Considerations for IGMP
and MLD Snooping Switches", RFC 4541, May 2006
[VPLS-MCAST-REQ] Kamite, Y, et al, "Requirements for Multicast
Support in Virtual Private LAN Services",
draft-ietf-l2vpn-vpls-mcast-reqts-03,
Work in Progress
[VPLS-MCAST-LDP] Qui, R, Serbest, Y, et al, "Using LDP for VPLS
Multicast", draft-qiu-serbest-vpls-mcast-ldp-00.txt,
Work in progress
[VPLS-MCAST-BGP] Aggarwal, R, et al, "Propagation of VPLS IP [PIM-BIDIR]
Multicast Group Membership Information", draft- Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
raggarwa-l2vpn-vpls-mcast-ctrl-00.txt, Work in "Bidirectional Protocol Independent Multicast (BIDIR-
progress PIM)", RFC 5015, 2007.
[VPLS-MCAST-TREES] Aggarwal, R, et al. "Multicast in VPLS",
draft-raggarwa-l2vpn-vpls-mcast-01.txt,
Work in progress.
Appendix A. Example Network Scenario [PIM-DM] Adams, A., Nicholas, J., and W. Siadak, "Protocol
Independent Multicast Version 2 - Dense Mode
Specification", RFC 3973, 2005.
Let us consider the scenario in Figure 3. [PIM-SM] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast- Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, 2006.
Figure 3: An Example Scenario for Triggering Assert [PIM-SSM] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, 2006.
+------+ AC3 +------+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
| PE2 |-----| CE3 | Requirement Levels", BCP 14, RFC 2119, 1997.
/| | | |
/ +------+ +------+
/ | |
/ | |
/PW12 | |
/ | +-----+
/ |PW23 | S |
/ | +-----+
/ | |
/ | |
/ | |
+------+ +------+ / +------+ +------+
| CE1 | | PE1 |/ PW13 | PE3 | | CE4 |
| |-----| |-------------| |-----| |
+------+ AC1 +------+ +------+ AC4 +------+
|
|AC2
+------+
| CE2 |
| |
+------+
In the scenario depicted in Figure 3, S is the source of a multicast [RPF-VECTOR]
stream (S,G). CE1 and CE2 both have two ECMP routes to reach the Wijnands, I., Boers, A., and E. Rosen, "The Reverse Path
source. Forwarding (RPF) Vector TLV", RFC 5496, 2009.
In the examples below, JT(Port,S,G,N) is the downstream Join Expiry 8.2. Informative References
Timer on the specified Port for the (S,G) with upstream neighbor N.
Appendix A.1 PIM-Snooping Example [IGMP-SNOOP]
Christensen, M., Kimball, K., and F. Solensky,
"Considerations for IGMP and MLD Snooping Switches",
RFC 4541, 2006.
[VPLS-BGP]
Kompella, K. and Y. Rekhter, "Virtual Private LAN Service
using BGP for Auto-Discovery and Signaling", RFC 4761,
2007.
[VPLS-LDP]
Lasserre, M. and V. Kompella, "Virtual Private LAN
Services using LDP Signaling", RFC 4762, 2007.
[VPLS-MCAST-REQ]
Kamite, Y., Wada, Y., Serbest, Y., Morin, T., and L. Fang,
"Requirements for Multicast Support in Virtual Private LAN
Services", RFC 5501, 2009.
[VPLS-MCAST-TREES]
Aggarwal, R., Kamite, Y., Fang, L., and Y. Rekhter,
"Multicast in VPLS", draft-ietf-l2vpn-vpls-mcast-10, Work
in Progress.
Appendix A. PIM-BIDIR Thoughts
This section describes some guidelines that may be used to preserve
PIM-BIDIR functionality in combination with Pim Snooping.
In order to preserve PIM-BIDIR Pim snooping routers need to set up
forwarding states so that :
o on the RPL all traffic is forwarded to all Rport(N)
o on any other interface traffic is always forwarded to the DF
The information needed to setup these states may be obtained by :
o determining the mapping between group(range) and RP
o snooping and storing DF election information
o determining where the RPL is, this could be achieved by static
configuration, or by combining the information mentioned in
previous bullets.
Appendix B. Example Network Scenario
Let us consider the scenario in Figure 3.
An Example Network for Triggering Assert
/----\ +------+ AC5 +------+ +------+ AC3 +------+ /----\
| S2 |---| CE5 |-----| PE4 |-------------| PE2 |-----| CE3 |---| S3 |
\----/ +------+ | |\ PW24 /| | +------+ \----/
+------+ \ / +------+ |
| \ / | |
| \ / | |
| PW34\ /PW12 | |
| \ / | /---\
PW14 | / |PW23 | S |
| / \ | \---/
| / \ | |
| / \ | |
| / \ | |
+------+ / \ +------+ |
+------+ | PE1 |/ PW13 \| PE3 | +------+
| CE1 |-----| |-------------| |-----| CE4 |
+------+ AC1 +------+ +------+ AC4 +------+
|
|AC2
+------+
| CE2 |
+------+
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.
B.1. Pim Snooping Example
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
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) while flooding it in the VPLS. PE2 2. PE1 snoops on the Join(S,G) while flooding it in the VPLS. PE2
and PE3 also snoop on the Join(S,G) while flooding it in the and PE3 also snoop on the Join(S,G) while flooding it in the
VPLS. 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 }
At PE3: PE3 ignores the Join(S,G) for the following At PE3:
reasons: PE3 doesn't create a forwarding state for (S,G) because
. It does not already have (S,G) state. the Join(S,G) was received on a PW and the Upstream RPort
. The Join(S,G) was received on a PW and the Upstream is a PW too. <<<<<
RPort is also a PW.
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). 5. All PEs snoop on the Join(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 }
skipping to change at page 32, line 39 skipping to change at page 35, line 27
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 }
At PE2: Note: Since PE2 already has (S,G) state, it does not At PE2: Note: Since PE2 already has (S,G) state, it does not
ignore the Join(S,G) even though it received the ignore the Join(S,G) even though it received the
Join(S,G) on a PW and the Upstream Rport is a PW. Join(S,G) on a PW and the Upstream Rport is a PW. <<<<<<
JT(PW12,S,G,CE4) = JP_HoldTime JT(PW12,S,G,CE4) = JP_HoldTime
JT(PW12,S,G,CE3) = active JT(PW12,S,G,CE3) = active
UpstreamNeighbors(S,G) = { CE3, CE4 } UpstreamNeighbors(S,G) = { CE3, CE4 }
UpstreamPorts(S,G) = { AC3, PW23 } UpstreamPorts(S,G) = { AC3, PW23 }
OutgoingPortList(S,G) = { PW12, AC3, PW23 } OutgoingPortList(S,G) = { PW12, AC3, PW23 }
At PE3: At PE3:
JT(PW13,S,G,CE4) = JP_HoldTime JT(PW13,S,G,CE4) = JP_HoldTime
UpstreamNeighbors(S,G) = { CE4 } UpstreamNeighbors(S,G) = { CE4 }
UpstreamPorts(S,G) = { AC4 } UpstreamPorts(S,G) = { AC4 }
skipping to change at page 33, line 4 skipping to change at page 35, line 45
JT(PW13,S,G,CE4) = JP_HoldTime JT(PW13,S,G,CE4) = JP_HoldTime
UpstreamNeighbors(S,G) = { CE4 } UpstreamNeighbors(S,G) = { CE4 }
UpstreamPorts(S,G) = { AC4 } UpstreamPorts(S,G) = { AC4 }
OutgoingPortList(S,G) = { PW13, AC4 } OutgoingPortList(S,G) = { PW13, AC4 }
6. The multicast stream (S,G) flows into the VPLS from the two CEs 6. The multicast stream (S,G) flows into the VPLS from the two CEs
CE3 and CE4. PE2 forwards the stream received from CE3 to PW23 CE3 and CE4. PE2 forwards the stream received from CE3 to PW23
and PE3 forwards the stream to AC4. This facilitates the CE and PE3 forwards the stream to AC4. This facilitates the CE
routers to trigger assert election. Let us say CE3 becomes the routers to trigger assert election. Let us say CE3 becomes the
assert winner. assert winner.
7. CE3 sends an Assert message to the VPLS. The PEs flood the 7. CE3 sends an Assert message to the VPLS. The PEs flood the
Assert message without examining it. Assert message without examining it.
8. CE4 stops sending the multicast stream to the VPLS. 8. CE4 stops sending the multicast stream to the VPLS.
9. CE2 notices an RPF change due to Assert and sends a Prune(S,G) 9. CE2 notices an RPF change due to Assert and sends a Prune(S,G)
with Upstream Neighbor = CE4. CE2 also sends a Join(S,G) with with Upstream Neighbor = CE4. CE2 also sends a Join(S,G) with
Upstream Neighbor = CE3. Upstream Neighbor = CE3.
10. All the PEs start a prune-pend timer on the ports on which 10. All the PEs start a prune-pend timer on the ports on which
they received the Prune(S,G). When the prune-pend timer expires, they received the Prune(S,G). When the prune-pend timer expires,
all PEs will remove the downstream (S,G,CE4) states. all PEs will remove the downstream (S,G,CE4) states.
Resulting states at the PEs: Resulting states at the PEs:
At PE1: At PE1:
JT(AC1,S,G,CE3) = active JT(AC1,S,G,CE3) = active
UpstreamNeighbors(S,G) = { CE3 } UpstreamNeighbors(S,G) = { CE3 }
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: no (S,G) state. At PE3: 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.
Appendix A.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.
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 consumes the Join(S,G). PE1 looks up the neighbor database 2. PE1 consumes the Join(S,G). PE1 looks up the neighbor database
and determines CE3 was learnt on PW12. PE1 sends a Proxy and determines CE3 was learnt on PW12. PE1 sends a Proxy
Join(S,G) to the resulting UpstreamPorts(G). i.e. it sends the Join(S,G) to the resulting UpstreamPorts(G). i.e. it sends the
proxy Join(S,G) on PW12. proxy Join(S,G) on PW12.
3. Likewise, PE2 consumes the Join(S,G) and sends a proxy Join(S,G) 3. Likewise, PE2 consumes the Join(S,G) and sends a proxy Join(S,G)
on AC3 with Upstream Neighbor = CE3. on AC3 with Upstream Neighbor = CE3.
The resulting states at the PEs is as follows: The resulting states at the PEs is as follows:
skipping to change at page 34, line 16 skipping to change at page 37, line 11
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: PE3 did not receive any PIM Join(S,G). So it has At PE3: PE3 did not receive any PIM Join(S,G). So it has
no (S,G) state. no (S,G) state.
4. The multicast stream (S,G) flows along CE3 -> PE2 -> PE1 -> CE1. 4. The multicast stream (S,G) flows along CE3 -> PE2 -> PE1 -> CE1.
5. Now let us say CE1 sends a Join(*,G) towards CE4. 5. Now let us say CE1 sends a Join(*,G) towards CE4.
6. PE1 consumes the Join(*,G). PE1 sends a Proxy Join(*,G) to the 6. PE1 consumes the Join(*,G). PE1 sends a Proxy Join(*,G) to the
resulting UpstreamPorts(G). Since UpstreamPorts(G) now has both resulting UpstreamPorts(G). Since UpstreamPorts(G) now has both
PW12 and PW13, the Join(*,G) gets sent on both PW12 and PW13. PW12 and PW13, the Join(*,G) gets sent on both PW12 and PW13.
Note that the UpstreamPorts(S,G) and OutgoingPortList(S,G) Note that the UpstreamPorts(S,G) and OutgoingPortList(S,G)
inherit the corresponding (*,G) sets, but not vice versa. inherit the corresponding (*,G) sets, but not vice versa.
remove "but not vice versa"
COMMENT : > Original "but not vice versa" applies to OutgoingPortList(S,G) only,
I assume, because of the earlier definition:
UpstreamPorts(G): This set is the union of all the
UpstreamPorts(S,G) and UpstreamPorts(*,G) for a given G
7. PE2 and PE3 perform a similar function. PE2 received the 7. PE2 and PE3 perform a similar function. PE2 received the
Join(*,G) on a PW and the Upstream Neighbor is also on a PW. Join(*,G) on a PW and the Upstream Neighbor is also on a PW.
Hence PE2 only adds UpstreamPorts(*,G) to OutgoingPortList(*,G) Hence PE2 only adds UpstreamPorts(*,G) to OutgoingPortList(*,G)
and not the downstream port PW12. and not the downstream port PW12.
At PE1: At PE1:
JT(AC1,S,G,CE3) = active JT(AC1,S,G,CE3) = active
UpstreamNeighbors(S,G) = { CE3 } UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { PW12, PW13 } UpstreamPorts(S,G) = { PW12, PW13 }
OutgoingPortList(S,G) = { AC1, PW12, PW13 } OutgoingPortList(S,G) = { AC1, PW12, PW13 }
skipping to change at page 35, line 14 skipping to change at page 38, line 20
OutgoingPortList(*,G) = { PW13, AC4 } OutgoingPortList(*,G) = { PW13, AC4 }
8. The above state results in both (S,G) and (*,G) streams to be 8. The above state results in both (S,G) and (*,G) streams to be
forwarded to AC1. The above state also results in the (S,G) forwarded to AC1. The above state also results in the (S,G)
stream to be forwarded from CE3 to CE4 resulting in an (S,G) stream to be forwarded from CE3 to CE4 resulting in an (S,G)
assert election. Following the assert election, CE3 becomes the assert election. Following the assert election, CE3 becomes the
(S,G) assert winner. CE4 stops sending (S,G) stream down the (S,G) assert winner. CE4 stops sending (S,G) stream down the
RPT. RPT.
9. CE1 notices an RPF change due to assert. It sends a 9. CE1 notices an RPF change due to assert. It sends a
Prune(S,G,rpt) with Upstream Neighbor = CE4. Prune(S,G,rpt) with Upstream Neighbor = CE4.
10. PE1 consumes the Prune(S,G,rpt) and forwards the 10. PE1 consumes the Prune(S,G,rpt) and forwards the
Prune(S,G,rpt) to both PW12 and PW13. PE2 consumes the Prune(S,G,rpt) to both PW12 and PW13. PE2 consumes the
Prune(S,G,rpt) and updates its states. PE3 updates its states Prune(S,G,rpt) and updates its states. PE3 updates its states
and forwards the Prune(S,G,rpt) on AC4. and forwards the Prune(S,G,rpt) on AC4.
At PE1: At PE1:
JT(AC1,S,G,CE3) = active JT(AC1,S,G,CE3) = active
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 }
skipping to change at page 35, line 47 skipping to change at page 39, line 5
UpstreamNeighbors(*,G) = { CE4 } UpstreamNeighbors(*,G) = { CE4 }
UpstreamPorts(*,G) = { PW23 } UpstreamPorts(*,G) = { PW23 }
OutgoingPortList(*,G) = { PW23 } OutgoingPortList(*,G) = { PW23 }
At PE3: At PE3:
JT(PW13,*,G,CE4) = JP_HoldTime JT(PW13,*,G,CE4) = JP_HoldTime
UpstreamNeighbors(*,G) = { CE4 } UpstreamNeighbors(*,G) = { CE4 }
UpstreamPorts(G) = { AC4 } UpstreamPorts(G) = { AC4 }
OutgoingPortList(*,G) = { PW13, AC4 } OutgoingPortList(*,G) = { PW13, AC4 }
Even in this example, at the end of the (S,G) / (*,G) assert Even in this example, at the end of the (S,G) / (*,G) assert
election, there should be no duplicate traffic forwarded downstream election, there should be no duplicate traffic forwarded downstream
and traffic should flow only to the desired CEs. and traffic should flow only to the desired CEs.
Other more complex scenarios exist. This draft should addressin PIM- Other more complex scenarios exist. This draft should addressin PIM-
SM and the rules specified in this draft should ensure that assert is SM and the rules specified in this draft should ensure that assert is
triggered among the CEs in all scenarios. triggered among the CEs in all scenarios.
Authors' Addresses Authors' Addresses
Venu Hemige Olivier Dornon
Alcatel-Lucent Alcatel-Lucent
701 East Middlefield Rd. 50 Copernicuslaan
Mountain View, CA 94043 Antwerp, B2018
Venu.hemige@alcatel-lucent.com
Yetik Serbest
AT&T Labs
9505 Arboretum Blvd.
Austin, TX 78759
Yetik_serbest@labs.att.com
Ray Qiu
Alcatel-Lucent
701 East Middlefield Rd.
Mountain View, CA 94043
Ray.Qiu@alcatel-lucent.com
Suresh Boddapati
Alcatel-Lucent
701 East Middlefield Rd.
Mountain View, CA 94043
Suresh.boddapati@alcatel-lucent.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any Email: olivier.dornon@alcatel-lucent.com
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Jayant Kotalwar
assurances of licenses to be made available, or the result of an Alcatel-Lucent
attempt made to obtain a general license or permission for the use of 701 East Middlefield Rd.
such proprietary rights by implementers or users of this Mountain View, CA 94043
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any Email: jayant.kotalwar@alcatel-lucent.com
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Full copyright statement Jeffrey Zhang
Juniper Networks, Inc.
10 Technology Park Drive
Westford, MA 01886
Copyright (C) The IETF Trust (2007). Email: zzhang@juniper.net
This document is subject to the rights, licenses and restrictions Venu Hemige
contained in BCP 78, and except as set forth therein, the authors Alcatel-Lucent
retain all their rights. 701 East Middlefield Rd.
Mountain View, CA 94043
This document and the information contained herein are provided on an Email: Venu.hemige@alcatel-lucent.com
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.
 End of changes. 296 change blocks. 
1225 lines changed or deleted 1227 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/