RFC 8220
Protocol Independent Multicast (PIM) over Virtual Private LAN Service (VPLS)
Pages: 43
Informational
Informational
Part 1 of 2 – Pages 1 to 24
Internet Engineering Task Force (IETF) O. Dornon Request for Comments: 8220 J. Kotalwar Category: Informational V. Hemige ISSN: 2070-1721 Nokia R. Qiu mistnet.io Z. Zhang Juniper Networks, Inc. September 2017 Protocol Independent Multicast (PIM) over Virtual Private LAN Service (VPLS)Abstract
This document describes the procedures and recommendations for Virtual Private LAN Service (VPLS) Provider Edges (PEs) to facilitate replication of multicast traffic to only certain ports (behind which there are interested Protocol Independent Multicast (PIM) routers and/or Internet Group Management Protocol (IGMP) hosts) via PIM snooping and proxying. With PIM snooping, PEs passively listen to certain PIM control messages to build control and forwarding states while transparently flooding those messages. With PIM proxying, PEs do not flood PIM Join/Prune messages but only generate their own and send them out of certain ports, based on the control states built from downstream Join/Prune messages. PIM proxying is required when PIM Join suppression is enabled on the Customer Edge (CE) devices and is useful for reducing PIM control traffic in a VPLS domain. This document also describes PIM relay, which can be viewed as lightweight proxying, where all downstream Join/Prune messages are simply forwarded out of certain ports and are not flooded, thereby avoiding the triggering of PIM Join suppression on CE devices.
Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8220. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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
1. Introduction ....................................................4 1.1. Multicast Snooping in VPLS .................................5 1.2. Assumptions ................................................6 1.3. Definitions ................................................6 1.4. Requirements Language ......................................7 2. PIM Snooping for VPLS ...........................................7 2.1. PIM Protocol Background ....................................7 2.2. General Rules for PIM Snooping in VPLS .....................8 2.2.1. Preserving Assert Triggers ..........................8 2.3. Some Considerations for PIM Snooping .......................9 2.3.1. Scaling .............................................9 2.3.2. IPv4 and IPv6 ......................................10 2.3.3. PIM-SM (*,*,RP) ....................................10
2.4. PIM Snooping vs. PIM Proxying .............................10
2.4.1. Differences between PIM Snooping, Relay,
and Proxying .......................................10
2.4.2. PIM Control Message Latency ........................11
2.4.3. When to Snoop and When to Proxy ....................12
2.5. Discovering PIM Routers ...................................13
2.6. PIM-SM and PIM-SSM ........................................14
2.6.1. Building PIM-SM States .............................15
2.6.2. Explanation for Per-(S,G,N) States .................17
2.6.3. Receiving (*,G) PIM-SM Join/Prune Messages .........18
2.6.4. Receiving (S,G) PIM-SM Join/Prune Messages .........20
2.6.5. Receiving (S,G,rpt) Join/Prune Messages ............22
2.6.6. Sending Join/Prune Messages Upstream ...............23
2.7. Bidirectional PIM (BIDIR-PIM) .............................24
2.8. Interaction with IGMP Snooping ............................24
2.9. PIM-DM ....................................................25
2.9.1. Building PIM-DM States .............................25
2.9.2. PIM-DM Downstream Per-Port PIM(S,G,N) State
Machine ............................................25
2.9.3. Triggering Assert Election in PIM-DM ...............26
2.10. PIM Proxy ................................................26
2.10.1. Upstream PIM Proxy Behavior .......................26
2.11. Directly Connected Multicast Source ......................26
2.12. Data-Forwarding Rules ....................................27
2.12.1. PIM-SM Data-Forwarding Rules ......................28
2.12.2. PIM-DM Data-Forwarding Rules ......................29
3. IANA Considerations ............................................29
4. Security Considerations ........................................30
5. References .....................................................30
5.1. Normative References ......................................30
5.2. Informative References ....................................31
Appendix A. BIDIR-PIM Considerations ..............................32
A.1. BIDIR-PIM Data-Forwarding Rules ............................32
Appendix B. Example Network Scenario ..............................33
B.1. PIM Snooping Example .......................................33
B.2. PIM Proxy Example with (S,G) / (*,G) Interaction ...........36
Acknowledgements ..................................................42
Contributors ......................................................42
Authors' Addresses ................................................43
1. Introduction
In the Virtual Private LAN Service (VPLS), the Provider Edge (PE) devices provide a logical interconnect such that Customer Edge (CE) devices belonging to a specific VPLS instance appear to be connected by a single LAN. The Forwarding Information Base (FIB) for a VPLS instance is populated dynamically by Media Access Control (MAC) address learning. Once a unicast MAC address is learned and associated with a particular Attachment Circuit (AC) or pseudowire (PW), a frame destined to that MAC address only needs to be sent on that AC or PW. For a frame not addressed to a known unicast MAC address, flooding has to be used. This happens with the following so-called "BUM" (Broadcast, Unknown Unicast, and Multicast) traffic: o B: The destination MAC address is a broadcast address. o U: The destination MAC address is unknown (has not been learned). o M: The destination MAC address is a multicast address. Multicast frames are flooded because a PE cannot know where corresponding multicast group members reside. VPLS solutions (RFC 4762 [VPLS-LDP] and RFC 4761 [VPLS-BGP]) perform replication for multicast traffic at the ingress PE devices. As stated in the VPLS Multicast Requirements document (RFC 5501 [VPLS-MCAST-REQ]), there are two issues with VPLS multicast today: 1. Multicast traffic is replicated to non-member sites. 2. Multicast traffic may be replicated when several PWs share a physical path. Issue 1 can be solved by multicast snooping -- PEs learn sites with multicast group members by snooping multicast protocol control messages on ACs and forward IP multicast traffic only to member sites. This document describes the procedures to achieve this when CE devices are PIM adjacencies of each other. Issue 2 is outside the scope of this document and is discussed in RFC 7117 [VPLS-MCAST]. While descriptions in this document are in the context of the VPLS, the procedures also apply to regular Layer 2 switches interconnected by physical connections, except that the PW-related concepts and procedures do not apply in that case.
1.1. Multicast Snooping in VPLS
IGMP snooping procedures described in RFC 4541 [IGMP-SNOOP] make sure that IP multicast traffic is only sent on the following: o ACs connecting to hosts that report related group membership o ACs connecting to routers that join related multicast groups o PWs connecting to remote PEs that have the above-described ACs Note that traffic is always sent on ports that have point-to-point connections to routers that are attached to a LAN on which there is at least one other router. Because IGMP snooping alone cannot determine if there are interested receivers beyond those routers, we always need to send traffic to these ports, even if there are no snooped group memberships. To further restrict traffic sent to those routers, PIM snooping can be used. This document describes the procedures for PIM snooping, including rules for when both IGMP and PIM snooping are enabled in a VPLS instance; see Sections 2.8 and 2.11 for details. Note that for both IGMP and PIM, the term "snooping" is used loosely, referring to the fact that a Layer 2 device peeks into Layer 3 routing protocol messages to build relevant control and forwarding states. Depending on whether the control messages are transparently flooded, selectively forwarded, or aggregated, the processing may be called "snooping" or "proxying" in different contexts. We will use the term "PIM snooping" in this document; however, unless explicitly noted otherwise, the procedures apply equally to PIM snooping and PIM proxying. The procedures specific to PIM proxying are described in Section 2.6.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.4. This document also describes PIM relay, which can be viewed as lightweight PIM proxying. Unless explicitly noted otherwise, in the rest of this document proxying implicitly includes relay as well. Please refer to Section 2.4.1 for an overview of the differences between snooping, proxying, and relay.
1.2. Assumptions
This document assumes that the reader has a good understanding of the PIM protocols. To help correlate the concepts and make the text easier to follow, this document is written in the same style as the following PIM RFCs: o RFC 3973 [PIM-DM] o RFC 4607 [PIM-SSM] o RFC 5015 [BIDIR-PIM] o RFC 5384 [JOIN-ATTR] o RFC 7761 [PIM-SM] In order to avoid replicating text related to PIM protocol handling from the PIM RFCs, this document cross-references corresponding definitions and procedures in those RFCs. Deviations in protocol handling specific to PIM snooping are specified in this document.1.3. Definitions
There are several definitions referenced in this document that are well described in the following PIM RFCs: RFC 3973 [PIM-DM], RFC 5015 [BIDIR-PIM], and RFC 7761 [PIM-SM]. The following definitions and abbreviations are used throughout this document: o A port is defined as either an AC or a PW. o When we say that a PIM message is received on a PE port, it means that the PE is processing the message for snooping/proxying or relaying. Abbreviations used in this document: o S: IP address of the multicast source. o G: IP address of the multicast group. o N: Upstream Neighbor field in a Join/Prune/Graft message. o Port(N): Port on which neighbor N is learned, i.e., the port on which N's Hellos are received. o rpt: Rendezvous Point Tree.
o PIM-DM: Protocol Independent Multicast - Dense Mode.
o PIM-SM: Protocol Independent Multicast - Sparse Mode.
o PIM-SSM: Protocol Independent Multicast - Source-Specific
Multicast.
1.4. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. PIM Snooping for VPLS
2.1. PIM Protocol Background
PIM is a multicast routing protocol running between routers, which
are CE devices in a VPLS. It uses the unicast routing table to
provide reverse-path information for building multicast trees. There
are a few variants of PIM. As described in RFC 3973 [PIM-DM],
multicast datagrams are pushed towards downstream neighbors, similar
to a broadcast mechanism, but in areas of the network where there are
no group members, routers prune back branches of the multicast tree
towards the source. Unlike PIM-DM, other PIM flavors (RFC 7761
[PIM-SM], RFC 4607 [PIM-SSM], and RFC 5015 [BIDIR-PIM]) employ a pull
methodology via explicit Joins instead of the push-and-prune
technique.
PIM routers periodically exchange Hello messages to discover and
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 their corresponding upstream router. The Join/Prune message can
be group specific (*,G) or group and source specific (S,G).
2.2. General Rules for PIM Snooping in VPLS
The following rules for the correct operation of PIM snooping MUST be followed. o PIM snooping MUST NOT affect the operation of customer Layer 2 protocols or Layer 3 protocols. o PIM messages and multicast data traffic forwarded by PEs MUST follow the split-horizon rule for mesh PWs, as defined in RFC 4762 [VPLS-LDP]. o PIM states in a PE MUST be per VPLS instance. o PIM Assert triggers MUST be preserved to the extent necessary to avoid sending duplicate traffic to the same PE (see Section 2.2.1).2.2.1. Preserving Assert Triggers
In PIM-SM / PIM-DM, there are scenarios where multiple routers could be forwarding the same multicast traffic on a LAN. When this happens, these routers start the PIM Assert election process by sending PIM Assert messages, to ensure that only the Assert winner forwards multicast 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 a VPLS with PIM snooping, two routers may forward the same multicast datagrams at the same time, but each copy may reach a different set of PEs; this 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. To achieve that, PEs enabled with PIM-SSM / PIM-SM snooping MUST forward multicast traffic for an (S,G) / (*,G) not only on the ports on which they snooped Join(S,G) / Join(*,G) but also towards the upstream neighbor(s). In other words, the ports on which the upstream neighbors are learned must be added to the outgoing port list, along with the ports on which Joins are snooped. Please refer to Section 2.6.1 for the rules that determine the set of upstream neighbors for a particular (x,G). Similarly, PIM-DM snooping SHOULD make sure that Asserts can be triggered (Section 2.9.3).
The above logic needs to be facilitated without breaking VPLS split-horizon forwarding rules. That is, 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).2.3. Some Considerations for PIM Snooping
The PIM snooping solution described here requires a PE to examine and operate on only PIM Hello and PIM Join/Prune packets. The PE does not need to examine any other PIM packets. Most of the PIM snooping procedures for handling Hello/Join/Prune messages are very similar to those executed in a PIM router. However, the PE does not need to have any routing tables like those required in PIM routing. It knows how to forward Join/Prune messages only by looking at the Upstream Neighbor field in the Join/Prune packets, as described in Section 2.12. The PE does not need to know about Rendezvous Points (RPs) and does not have to maintain any RP Set. All of that is transparent to a PIM snooping PE. In the following subsections, we list some considerations and observations for the implementation of PIM snooping in the VPLS.2.3.1. Scaling
PIM snooping needs to be employed on ACs at the downstream PEs (PEs receiving multicast traffic across the VPLS core) to prevent traffic from being sent out of ACs unnecessarily. PIM snooping techniques can also be employed on PWs at the upstream PEs (PEs receiving traffic from local ACs in a hierarchical VPLS) to prevent traffic from being sent to PEs unnecessarily. This may work well for small-scale or medium-scale deployments. However, if there are a large number of VPLS instances with a large number of PEs per instance, then the amount of snooping required at the upstream PEs can overwhelm the upstream PEs. There are two methods to reduce the burden on the upstream PEs. One is to use PIM proxying, as described in Section 2.6.6, to reduce the control messages forwarded by a PE. The other is not to snoop on the PWs at all but to have PEs signal the snooped states to other PEs out of band via BGP, as described in RFC 7117 [VPLS-MCAST]. In this document, it is assumed that snooping is performed on PWs.
2.3.2. IPv4 and IPv6
In the VPLS, PEs forward Ethernet frames received from CEs and as such are agnostic of the Layer 3 protocol used by the CEs. However, as a PIM snooping PE, the PE would have to look deeper into the IP and 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 document can be applied to both IPv4 and IPv6 payloads.2.3.3. PIM-SM (*,*,RP)
This document does not address (*,*,RP) states in the VPLS network, as they have been removed from the PIM protocol as described in RFC 7761 [PIM-SM].2.4. PIM Snooping vs. PIM Proxying
This document has previously alluded to PIM snooping/relay/proxying. Details on the PIM relay/proxying solution are discussed in Section 2.6.6. In this section, a brief description and comparison are given.2.4.1. Differences between PIM Snooping, Relay, and Proxying
Differences between PIM snooping and relay/proxying can be summarized as follows: +--------------------+---------------------+-----------------------+ | PIM snooping | PIM relay | PIM proxying | +====================|=====================|=======================+ | Join/Prune messages| Join/Prune messages | Join/Prune messages | | snooped and flooded| snooped; forwarded | consumed. Regenerated| | according to VPLS | as is out of certain| ones sent out of | | flooding procedures| upstream ports | certain upstream ports| +--------------------+---------------------+-----------------------+ | Hello messages | Hello messages | Hello messages | | snooped and flooded| snooped and flooded | snooped and flooded | | according to VPLS | according to VPLS | according to VPLS | | flooding procedures| flooding procedures | flooding procedures | +--------------------+---------------------+-----------------------+ | No PIM packets | No PIM packets | New Join/Prune | | generated | generated | messages generated | +--------------------+---------------------+-----------------------+ | CE Join suppression| CE Join suppression | CE Join suppression | | not allowed | allowed | allowed | +--------------------+---------------------+-----------------------+
Other than the above differences, most of the procedures are common to PIM snooping and PIM relay/proxying, unless specifically stated otherwise. Pure PIM snooping PEs simply snoop on PIM packets as they are being forwarded in the VPLS. As such, they truly provide transparent LAN services, since no customer packets are modified or consumed nor are new packets introduced in the VPLS. It is also simpler to implement than PIM proxying. However, for PIM snooping to work correctly, it is a requirement that CE routers MUST disable Join suppression in the VPLS. Otherwise, most of the CE routers with interest in a given multicast data stream will fail to send Join/Prune messages for that stream, and the PEs will not be able to tell which ACs and/or PWs have listeners for that stream. Given that a large number of existing CE deployments do not support the disabling of Join suppression and given the operational complexity for a provider to manage the disabling of Join suppression in the VPLS, it becomes a difficult solution to deploy. Another disadvantage of PIM snooping is that it does not scale as well as PIM proxying. If there are a large number of CEs in a VPLS, then every CE will see every other CE's Join/Prune messages. PIM relay/proxying has the advantage that it does not require Join suppression to be disabled in the VPLS. Multicast as part of a VPLS can be very easily provided without requiring any changes on the CE routers. PIM relay/proxying helps scale VPLS multicast, since Join/Prune messages are only sent to certain upstream ports instead of flooded, and in cases of full proxying (vs. relay), the PEs intelligently generate only one Join/Prune message for a given multicast stream. PIM proxying, however, loses the transparency argument, since Join/Prune packets 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, for both the provider and the customer. Data traffic will still be completely transparent.2.4.2. PIM Control Message Latency
A PIM snooping/relay/proxying PE snoops on PIM Hello packets while transparently flooding them in the VPLS. As such, there is no latency introduced by the VPLS in the delivery of PIM Hello packets to remote CEs in the VPLS.
A PIM snooping PE snoops on PIM Join/Prune packets while transparently flooding them in the VPLS. There is no latency introduced by the VPLS in the delivery of PIM Join/Prune packets when PIM snooping is employed. A PIM relay/proxying PE does not simply flood PIM Join/Prune packets. This can result in additional latency for a downstream CE to receive multicast traffic 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. Performing only proxying of Join/Prune and not Hello messages keeps the PE's behavior very similar to that of a PIM router, without introducing too much additional complexity. It keeps the PIM proxying solution fairly simple. Since Join/Prune messages 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/Prune packets). 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.2.4.3. When to Snoop and When to Proxy
From the above descriptions, factors that affect the choice of snooping/relay/proxying include: o Whether CEs do Join suppression or not o Whether Join/Prune latency is critical or not o Whether the scale of PIM protocol messages/states in a VPLS requires the scaling benefit of proxying Of the above factors, Join suppression is the hard one -- pure snooping can only be used when Join suppression is disabled on all CEs. The latency associated with relay/proxying is implementation dependent and may not be a concern at all with a particular implementation. The scaling benefit may not be important either, in that on a real LAN with Explicit Tracking (ET) a PIM router will need to receive and process all PIM Join/Prune messages as well.
A PIM router indicates that Join suppression is disabled if the T-bit
is set in the LAN Prune Delay option of its Hello message. If all
PIM routers on a LAN set the T-bit, ET is possible, allowing an
upstream router to track all the downstream neighbors that have Join
states for any (S,G) or (*,G). This has two benefits:
o No need for the Prune-Pending process -- the upstream router may
immediately stop forwarding data when it receives a Prune from the
last downstream neighbor and immediately prune to its upstream
neighbor.
o For management purposes, the upstream router knows exactly which
downstream routers exist for a particular Join state.
While full proxying can be used with or without Join suppression on
CEs and does not interfere with an upstream CE's bypass of the
Prune-Pending process, it does proxy all its downstream CEs as a
single one to the upstream neighbors, removing the second benefit
mentioned above.
Therefore, the general rule is that if Join suppression is enabled on
one or more CEs, then proxying or relay MUST be used, but if Join
suppression is known to be disabled on all CEs, then snooping, relay,
or proxying MAY be used, while snooping or relay SHOULD be used.
An implementation MAY choose to dynamically determine which mode to
use, through the tracking of the above-mentioned T-bit in all snooped
PIM Hello messages, or MAY simply require static provisioning.
2.5. Discovering PIM Routers
A PIM snooping PE MUST snoop on PIM Hellos received on ACs and PWs.
That is, the PE transparently floods the PIM Hello while snooping on
it. PIM Hellos are used by the snooping PE to discover PIM routers
and their characteristics.
For each neighbor discovered by a PE, it includes an entry in the PIM
Neighbor Database with the following fields:
o Layer 2 encapsulation for the router sending the PIM Hello.
o IP address and address family of the router sending the PIM Hello.
o Port (AC/PW) on which the PIM Hello was received.
o Hello Option fields.
The PE should be able to interpret and act on Hello Option fields as currently defined in RFC 7761 [PIM-SM]. The Option fields of particular interest in this document are: o Hello-Hold-Time o Tracking Support o Designated Router (DR) Priority Please refer to RFC 7761 [PIM-SM] for a list of the Hello Option fields. When a PIM Hello is received, the PE MUST reset the neighbor-expiry-timer to Hello-Hold-Time. If a PE does not receive a Hello message 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 the 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 procedures defined in RFC 7761 [PIM-SM] to identify the PIM DR in the VPLS instance. It should also be able to determine if tracking support is active in the VPLS instance.2.6. PIM-SM and PIM-SSM
The key characteristic of PIM-SM and PIM-SSM is explicit Join behavior. In this model, multicast traffic is only forwarded to locations that specifically request it. 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.
2.6.1. Building PIM-SM States
PIM-SM and PIM-SSM states are built by snooping on the PIM-SM Join/Prune messages received on ACs/PWs. The downstream state machine of a PIM-SM snooping PE very closely resembles the downstream state machine of PIM-SM routers. The downstream state consists of: Per downstream (Port,*,G): o DownstreamJPState: One of {"NoInfo" (NI), "Join" (J), "Prune-Pending" (PP)} Per downstream (Port,*,G,N): o Prune-Pending Timer (PPT(N)) o Join Expiry Timer (ET(N)) Per downstream (Port,S,G): o DownstreamJPState: One of {"NoInfo" (NI), "Join" (J), "Prune-Pending" (PP)} Per downstream (Port,S,G,N): o Prune-Pending Timer (PPT(N)) o Join Expiry Timer (ET(N)) Per downstream (Port,S,G,rpt): o DownstreamJPRptState: One of {"NoInfo" (NI), "Pruned" (P), "Prune-Pending" (PP)} Per downstream (Port,S,G,rpt,N): o Prune-Pending Timer (PPT(N)) o Join Expiry Timer (ET(N)) where S is the address of the multicast source, G is the group address, and N is the Upstream Neighbor field in the Join/Prune message.
Note that unlike the case of PIM-SM routers, where the PPT and ET are per (Interface,S,G), PIM snooping PEs have to maintain the PPT and ET per (Port,S,G,N). The reasons for this are explained in Section 2.6.2. Apart from the above states, we define the following state summarization macros: UpstreamNeighbors(*,G): If there are one or more Join(*,G)s received on 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 are one or more Join(S,G)s received on 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 Port(N) ports where N is in the set UpstreamNeighbors(*,G). Multicast streams forwarded using a (*,G) match MUST be forwarded to these ports. So, UpstreamPorts(*,G) MUST be added to OutgoingPortList(*,G). UpstreamPorts(S,G): This is the set of all Port(N) ports where N is in the set UpstreamNeighbors(S,G). UpstreamPorts(S,G) MUST be added to OutgoingPortList(S,G). InheritedUpstreamPorts(S,G): This is the union of UpstreamPorts(S,G) and UpstreamPorts(*,G). UpstreamPorts(S,G,rpt): If PruneDesired(S,G,rpt) becomes TRUE, then 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). UpstreamPorts(G): This set is the union of all the UpstreamPorts(S,G) and UpstreamPorts(*,G) for a given G. Proxy (S,G) Join/Prune and (*,G) Join/Prune messages MUST be sent to a subset of UpstreamPorts(G) as specified in Section 2.6.6.1. 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 2.12 ("Data-Forwarding Rules") for the specification on
how OutgoingPortList is calculated.
NumETsActive(Port,*,G): This is the number of (Port,*,G,N) entries
that have the 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): This is the number of (Port,S,G,N) entries
that have the Expiry Timer running. This macro keeps track of the
number of Join(S,G)s that are received on this Port with different
upstream neighbors.
JoinAttributeTlvs(*,G): Join Attributes (RFC 5384 [JOIN-ATTR]) are
TLVs that may be present in received Join(*,G) messages. An
example would be Reverse Path Forwarding (RPF) Vectors (RFC 5496
[RPF-VECTOR]). If present, they must be copied to
JoinAttributeTlvs(*,G).
JoinAttributeTlvs(S,G): Join Attributes (RFC 5384 [JOIN-ATTR]) are
TLVs that may be present in received Join(S,G) messages. If
present, they must be copied to JoinAttributeTlvs(S,G).
Since there are a few differences between the downstream state
machines of PIM-SM routers and PIM-SM snooping PEs, we specify the
details of the downstream state machine of PIM-SM snooping PEs, at
the risk of repeating most of the text documented in RFC 7761
[PIM-SM].
2.6.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 PE
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 allow the CE routers to decide which upstream
neighbor gets elected as the RPF-Neighbor. And for this purpose, the PE will have to track downstream and upstream Joins and Prunes per (S,G,N).2.6.3. Receiving (*,G) PIM-SM Join/Prune Messages
A Join(*,G) or Prune(*,G) is considered "received" if one of the following conditions is met: o The port on which it arrived is not Port(N) where N is the upstream neighbor N of the Join/Prune(*,G). o If both Port(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 Port(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 Port(N) PW can be added to the related forwarding entries' OutgoingPortList to trigger an Assert, but that is only needed for those states with AC UpstreamPorts. Note that in the PW-only case, it is OK for the arrival port and Port(N) to be the same. See 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 are exactly as specified in RFC 7761 [PIM-SM].
We define the following per-port (*,G,N) macro to help with the state machine below. +---------------++-------------------------------------------------+ | || Previous State | | ++-------------+--------------+--------------------+ | Event || NoInfo (NI) | Join (J) | Prune-Pending (PP) | +---------------++-------------+--------------+--------------------+ | 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 | - | |and || | Action | | |NumETsActive>1 || | ETExpiry(N) | | +---------------++-------------+--------------+--------------------+ Figure 1: Downstream Per-Port (*,G) State Machine in Tabular Form 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 Join Attribute TLVs in the received (*,G) message and if they are different from the recorded JoinAttributeTlvs(*,G), then copy them into JoinAttributeTlvs(*,G). In the case of conflicting attributes, the PE will need to perform conflict resolution per (N) as described in RFC 5384 [JOIN-ATTR].
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 (RFC 7761
[PIM-SM]) to NoInfo. If there are no other (Port,*,G,N) states
(different ports but for the same N), remove N from
UpstreamPorts(*,G) -- this will also trigger the Upstream Finite
State Machine (FSM) with "JoinDesired(*,G,N) to FALSE".
2.6.4. Receiving (S,G) PIM-SM Join/Prune Messages
A Join(S,G) or Prune(S,G) is considered "received" if one of the
following conditions is met:
o The port on which it arrived is not Port(N) where N is the
upstream neighbor N of the Join/Prune(S,G).
o If both Port(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 Port(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 Port(N) PW can be added to
the related forwarding entries' OutgoingPortList to trigger an
Assert, but that is only needed for those states with AC
UpstreamPorts. Note that in the PW-only case, it is OK for the
arrival port and Port(N) to be the same. See 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 are exactly as specified in RFC 7761 [PIM-SM]. +---------------++-------------------------------------------------+ | || Previous State | | ++-------------+--------------+--------------------+ | Event || NoInfo (NI) | Join (J) | Prune-Pending (PP) | +---------------++-------------+--------------+--------------------+ | Receive || -> J state | -> J state | -> J state | | Join(S,G) || Action | Action | Action | | || RxJoin(N) | RxJoin(N) | RxJoin(N) | +---------------++-------------+--------------+--------------------+ |Receive || - | -> 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 | - | |and || | Action | | |NumETsActive>1 || | ETExpiry(N) | | +---------------++-------------+--------------+--------------------+ Figure 2: Downstream Per-Port (S,G) State Machine in Tabular Form
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(S,G), then add N to
UpstreamNeighbors(S,G) and trigger a Join(S,G) with upstream
neighbor N to be forwarded upstream. If there are Join Attribute
TLVs in the received (S,G) message and if they are different from
the recorded JoinAttributeTlvs(S,G), then copy them into
JoinAttributeTlvs(S,G). In cases of conflicting attributes, the
PE will need to perform conflict resolution per (N) as described
in RFC 5384 [JOIN-ATTR].
Action PPTExpiry(N):
Same as Action ETExpiry(N) below, plus send a Prune-Echo(S,G) with
upstream neighbor N on the downstream port.
Action ETExpiry(N):
Disable timers ET(N) and PPT(N). Delete Neighbor state
(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) states (different
ports but for the same N), remove N from UpstreamPorts(S,G) --
this will also trigger the Upstream FSM with "JoinDesired(S,G,N)
to FALSE".
2.6.5. Receiving (S,G,rpt) Join/Prune Messages
A Join(S,G,rpt) or Prune(S,G,rpt) is "received" when the port on
which it was received is not also the port on which the
upstream neighbor N of the Join/Prune(S,G,rpt) was learned.
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.3 of RFC 7761 [PIM-SM].
2.6.6. Sending Join/Prune Messages Upstream
This section applies only to a PIM relay/proxying PE and not to a PIM snooping PE. A full PIM proxying (not relay) PE MUST implement the Upstream FSM along the lines of the procedure described in Section 4.5.4 of RFC 7761 [PIM-SM]. For the purposes of the Upstream FSM, a Join or Prune message with upstream neighbor N is "seen" on a PIM relay/proxying PE if the port on which the message was received is also Port(N) and the port is an AC. The AC requirement is needed because a Join received on the Port(N) PW must not suppress this PE's Join on that PW. A PIM relay PE does not implement the Upstream FSM. It simply forwards received Join/Prune messages out of the same set of upstream ports as in the PIM proxying case. In order to correctly facilitate Asserts among the CE routers, such Join/Prune messages need to send not only towards the upstream neighbor but also on certain PWs, as described below. If JoinAttributeTlvs(*,G) is not empty, then it must be encoded in a Join(*,G) message sent upstream. If JoinAttributeTlvs(S,G) is not empty, then it must be encoded in a Join(S,G) message sent upstream.2.6.6.1. Where to Send Join/Prune Messages
The following rules apply to both (1) forwarded (in the case of PIM relay) and (2) refreshed and triggered (in the case of PIM proxying) (S,G) / (*,G) Join/Prune messages. o The Upstream Neighbor field in the Join/Prune to be sent is set to the N in the corresponding Upstream FSM. o If Port(N) is an AC, send the message to Port(N). o Additionally, if OutgoingPortList(x,G,N) contains at least one AC, then the message MUST be sent to at least all the PWs in UpstreamPorts(G) (for (*,G)) or InheritedUpstreamPorts(S,G) (for (S,G)). Alternatively, the message MAY be sent to all PWs.
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 an Assert. Sending to all PWs guarantees that if two upstream routers both send traffic for the same flow (even if it is to different sets of downstream PEs), then the two routers will receive from each other, triggering an Assert.
(page 24 continued on part 2)