From owner-pim@catarina.usc.edu Mon Oct 4 06:45:57 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA26782 for ; Mon, 4 Oct 1999 06:45:56 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id DAA21172 for pim-list; Mon, 4 Oct 1999 03:24:54 -0700 Received: from ficon-tech.com ([12.10.198.190]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id DAA21168 for ; Mon, 4 Oct 1999 03:24:43 -0700 Received: from ficon-tech.com (renu.india.ficon-tech.com [172.25.1.111] (may be forged)) by ficon-tech.com (8.8.7/8.8.7) with ESMTP id PAA19112 for ; Mon, 4 Oct 1999 15:51:01 +0530 (IST) (envelope-from ragarwal@ficon-tech.com) Message-ID: <37F87E84.FC223C89@ficon-tech.com> Date: Mon, 04 Oct 1999 15:46:36 +0530 From: Renu Agarwal Organization: Ficon Technology India Pvt Ltd., X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: pim@catarina.usc.edu Subject: Postscript version of PIM_SM rfc 2362 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Can anybody tell me about the postscript version of RFC2362 containing PIM-SM protocol specifications? All I could find was the draft-ietf-idmr-PIM-SM-spec-10.ps which I believe does not match with the latest RFC. Thanks in advacne for the help, Renu ___________________________________________________________ Renu Agarwal E-mail: mailto:ragarwal@ficon-tech.com Ficon Technology Web : http://www.ficon-tech.com ___________________________________________________________ From owner-pim@catarina.usc.edu Mon Oct 4 06:58:46 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA26928 for ; Mon, 4 Oct 1999 06:58:45 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id DAA21278 for pim-list; Mon, 4 Oct 1999 03:53:46 -0700 Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by catarina.usc.edu (8.6.10/8.6.9) with SMTP id DAA21268; Mon, 4 Oct 1999 03:53:37 -0700 Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 4 Oct 1999 11:53:16 +0100 To: David Oran cc: maddogs , idmr , idr , msdp , pim , mboned , malloc , rmt Subject: Re: Maestro BoF Results In-reply-to: Your message of "Mon, 02 Aug 1999 11:17:41 EDT." Date: Mon, 04 Oct 1999 11:53:15 +0100 Message-ID: <11012.939034395@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-pim@catarina.usc.edu Precedence: bulk ... ..."One of the conclusions from the BoF was to continue discussions on these subjects to ascertain if there is a critical mass of support to charter one or more Working Groups to pursue IETF standards (or other outputs) in these areas. We are therefore resurrecting a moribund Routing Area mailing list for this purpose: routing-discussion@ietf.org" so whats the conclusion vis-a-vis multicast discussion (considering imminance of next/DC) ietf? cheers jon (apols for multi-list hit, but some folks might have had a peripheral but strong enough interest to want to know the outcome without seeing the process) From owner-pim@catarina.usc.edu Mon Oct 4 15:07:29 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07255 for ; Mon, 4 Oct 1999 15:06:04 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id LAA23197 for pim-list; Mon, 4 Oct 1999 11:30:40 -0700 Received: (from pavlin@localhost) by catarina.usc.edu (8.6.10/8.6.9) id LAA23182 for pim@catarina.usc.edu; Mon, 4 Oct 1999 11:30:27 -0700 Received: from siara.com (gate.siara.com [209.31.24.134]) by catarina.usc.edu (8.6.10/8.6.9) with SMTP id LAA23156 for ; Mon, 4 Oct 1999 11:28:24 -0700 Received: from siara.com by siara.com with esmtp id m11YCpo-001FGmC; Mon, 4 Oct 1999 11:27:40 -0700 (PDT) Message-ID: <37F8F19C.F8393E6C@siara.com> Date: Mon, 04 Oct 1999 11:27:40 -0700 From: Liming Wei X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: pim@catarina.usc.edu Subject: PIM SM draft submitted. Content-Type: multipart/mixed; boundary="------------9CB92B9E03FFFB1066D7ED60" Sender: owner-pim@catarina.usc.edu Precedence: bulk This is a multi-part message in MIME format. --------------9CB92B9E03FFFB1066D7ED60 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Folks, The attached draft is already submitted into the ID repository. Sorry for the delay, but please review and comment on it. We should do a WG last call very soon on the outstanding drafts. Thanks. -Liming --------------9CB92B9E03FFFB1066D7ED60 Content-Type: text/plain; charset=us-ascii; name="pimv2.txt" Content-Disposition: inline; filename="pimv2.txt" Content-Transfer-Encoding: 7bit Network Working Group L Wei, Editor Internet Draft Siara D. Estrin USC D. Farinacci Cisco A. Helmy USC D. Thaler Microsoft S. Deering Cisco M. Handley UCL V. Jacobson Cisco C. Liu USC P. Sharma USC October 1999 draft-ietf-pim-v2-sm-01.txt Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Estrin, et. al. Experimental [Page 1] Internet Draft PIM-SM Oct 1999 1 Introduction This document describes a protocol for efficiently routing to multicast groups that may span wide-area (and inter-domain) internets. We refer to the approach as Protocol Independent Multicast--Sparse Mode (PIM-SM) because it is not dependent on any particular unicast routing protocol, and because it is designed to support sparse groups as defined in [1][2]. This document describes the protocol details. For the motivation behind the design and a description of the architecture, see [1][2]. Section 2 summarizes PIM-SM operation. It describes the protocol from a network perspective, in particular, how the participating routers interact to create and maintain the multicast distribution tree. Section 3 describes PIM-SM operations from the perspective of a single router implementing the protocol; this section constitutes the main body of the protocol specification. It is organized according to PIM-SM message type; for each message type we describe its contents, its generation, and its processing. Sections 3.8 and 3.9 summarize the timers and flags referred to throughout this document. Section 4 provides packet format details. 2 PIM-SM Protocol Overview In this section we provide an overview of the architectural components of PIM-SM. A router receives explicit Join/Prune messages from those neighboring routers that have downstream group members. The router then forwards data packets addressed to a multicast group, G, only onto those interfaces on which explicit joins have been received. Note that all routers mentioned in this document are assumed to be PIM-SM capable, unless otherwise specified. A Designated Router (DR) sends periodic Join/Prune messages toward a group-specific Rendezvous Point (RP) for each group for which it has active members. Each router along the path toward the RP builds a wildcard (any-source) state for the group and sends Join/Prune messages on toward the RP. We use the term route entry to refer to the state maintained in a router to represent the distribution tree. A route entry may include such fields as the source address, the group address, the incoming interface from which packets are accepted, the list of outgoing interfaces to which packets are sent, Estrin, et. al. Experimental [Page 2] Internet Draft PIM-SM Oct 1999 timers, flag bits, etc. The wildcard route entry's incoming interface points toward the RP; the outgoing interfaces point to the neighboring downstream routers that have sent Join/Prune messages toward the RP. This state creates a shared, RP-centered, distribution tree that reaches all group members. When a data source first sends to a group, its DR unicasts Register messages to the RP with the source's data packets encapsulated within. If the data rate is high, the RP can send source-specific Join/Prune messages back towards the source and the source's data packets will follow the resulting forwarding state and travel unencapsulated to the RP. Whether they arrive encapsulated or natively, the RP forwards the source's decapsulated data packets down the RP-centered distribution tree toward group members. If the data rate warrants it, routers with local receivers can join a source-specific, shortest path, distribution tree, and prune this source's packets off of the shared RP-centered tree. For low data rate sources, neither the RP, nor last-hop routers need join a source-specific shortest path tree and data packets can be delivered via the shared, RP-tree. The following subsections describe SM operation in more detail, in particular, the control messages, and the actions they trigger. 2.1 Local hosts joining a group In order to join a multicast group, G, a host conveys its membership information through the Internet Group Management Protocol (IGMP), as specified in [4][5], (see figure 1). From this point on we refer to such a host as a receiver, R, (or member) of the group G. Note that all figures used in this section are for illustration and are not intended to be complete. For complete and detailed protocol action see Section 3. | ----- ----- ------- Host -+- | A |----------------| B |-----------------| C | RP | ----- ----- ------- -----> -----------> -----------> IGMP report (*,G) join (*,G) join Fig. 1 Example: how a receiver joins, and sets up shared tree When a DR (e.g., router A in figure 1) gets a membership indication from IGMP for a new group, G, the DR looks up the associated RP. The DR creates a wildcard multicast route entry for the group, referred to here as a (*,G) entry; if there is no more specific match for a particular source, the packet will be forwarded according to this entry. The RP address is included in a special field in the route entry and is included in periodic upstream Join/Prune messages. The outgoing interface is set to that included in the IGMP membership indication for the new member. The incoming interface is set to the interface used to send unicast packets to the RP. Estrin, et. al. Experimental [Page 3] Internet Draft PIM-SM Oct 1999 When there are no longer directly connected members for the group, IGMP notifies the DR. If the DR has neither local members nor downstream receivers, the (*,G) state is deleted. 2.2 Establishing the RP-rooted shared tree Triggered by the (*,G) state, the DR creates a Join/Prune message with the RP address in its join list and the the wildcard bit (WC- bit) and RP-tree bit (RPT-bit) set to 1. The WC-bit indicates that any source may match and be forwarded according to this entry if there is no longer match; the RPT-bit indicates that this join is being sent up the shared, RP-tree. The prune list is left empty. When the RPT-bit is set to 1 it indicates that the join is associated with the shared RP-tree and therefore the Join/Prune message is propagated along the RP-tree. When the WC-bit is set to 1 it indicates that the address is an RP and the downstream receivers expect to receive packets from all sources via this (shared tree) path. The term RPT- bit is used to refer to both the RPT-bit flags associated with route entries, and the RPT-bit included in each encoded address in a Join/Prune message. Each upstream router creates or updates its multicast route entry for (*,G) when it receives a Join/Prune with the RPT-bit and WC-bit set. The interface on which the Join/Prune message arrived is added to the list of outgoing interfaces (oifs) for (*,G). Based on this entry each upstream router between the receiver and the RP sends a Join/Prune message in which the join list includes the RP. The packet payload contains Multicast-Address=G, Join=RP,WC-bit,RPT-bit, Prune=NULL. 2.3 Hosts sending to a group When a host starts sending multicast data packets to a group, initially its DR must deliver each packet to the RP for distribution down the RP-tree (see figure 2). The sender's DR initially encapsulates each data packet in a Register message and unicasts it to the RP for that group. The RP decapsulates each Register message and forwards the enclosed data packet natively to downstream members on the shared RP-tree. -------- | |Source| | ----- ----- ---- ------ | ---------- |Host |--+---| A |---| B |--|RP|----| C |-----+---| Receiver| -------- | ----- ----- ---- ------ | | Host | -------> ----------> ------------> ----------- Data packet Register forward decapsulated data packet Fig. 2 Example: a host sending to a group If the data rate of the source warrants the use of a source-specific shortest path tree (SPT), the RP may construct a new multicast route entry that is specific to the source, hereafter referred to as (S,G) state, and send periodic Join/Prune messages toward the source. Note that over time, the rules for when to switch can be modified without Estrin, et. al. Experimental [Page 4] Internet Draft PIM-SM Oct 1999 global coordination. When and if the RP does switch to the SPT, the routers between the source and the RP build and maintain (S,G) state in response to these messages and send (S,G) messages upstream toward the source. The source's DR must stop encapsulating data packets in Registers when (and so long as) it receives Register-Stop messages from the RP. The RP triggers Register-Stop messages in response to Registers, if the RP has no downstream receivers for the group (or for that particular source), or if the RP has already joined the (S,G) tree and is receiving the data packets natively. Each source's DR maintains, per (S,G), a Register-Suppression-timer. The Register- Suppression-timer is started by the Register-Stop message; upon expiration, the source's DR resumes sending data packets to the RP, encapsulated in Register messages. 2.4 Switching from shared tree (RP-tree) to shortest path tree (SP-tree)} A router with directly-connected members first joins the shared RP- tree. The router can switch to a source's shortest path tree (SP- tree) after receiving packets from that source over the shared RP- tree. The recommended policy is to initiate the switch to the SP-tree after receiving a significant number of data packets during a specified time interval from a particular source. To realize this policy the router can monitor data packets from sources for which it has no source-specific multicast route entry and initiate such an entry when the data rate exceeds the configured threshold. As shown in figure 3, router `A' initiates a (S,G) state. First Hop Router for Source ----- ------- | D |-------| Host| / ----- ------- Source tree / / \ <-------------------/ / \ / \ ------ | ----- ----- - ----- |Host|--+-| A |----------------| B |---------------| C | RP ------ | ----- ----- ----- Receiver| <--------------------------------------- Shared tree Fig. 3 Example: Switching from shared tree to shortest path tree When a (S,G) entry is activated (and periodically so long as the state exists), a Join/Prune message is sent upstream towards the source, S, with S in the join list. The payload contains Multicast- Address=G, Join=S, Prune=NULL. When the (S,G) entry is created, the outgoing interface list is copied from (*,G), i.e., all local shared tree branches are replicated in the new shortest path tree. In this way when a data packet from S arrives and matches on this entry, all receivers will continue to receive the source's packets along this path. (In more complicated scenarios, other entries in the router have to be considered, as described in Section 3). Note that (S,G) state must be maintained in each last-hop router that is responsible for initiating and maintaining an SP-tree. Even when (*,G) and (S,G) overlap, both states are needed to trigger the source-specific Join/Prune messages. (S,G) state is kept alive by data packets arriving from that source. A timer, Entry-timer, is set for the (S,G) Estrin, et. al. Experimental [Page 5] Internet Draft PIM-SM Oct 1999 entry and this timer is restarted whenever data packets for (S,G) are forwarded out at least one oif, or Registers are sent. When the Entry-timer expires, the state is deleted. The last-hop router is the router that delivers the packets to their ultimate end-system destination. This is the router that monitors if there is group membership and joins or prunes the appropriate distribution trees in response. In general the last-hop router is the Designated Router (DR) for the LAN. However, under various conditions described later, a parallel router connected to the same LAN may take over as the last-hop router in place of the DR. Only the RP and routers with local members can initiate switching to the SP-tree; intermediate routers do not. Consequently, last-hop routers create (S,G) state in response to data packets from the source, S; whereas intermediate routers only create (S,G) state in response to Join/Prune messages from downstream that have S in the Join list. The (S,G) entry is initialized with the SPT-bit cleared, indicating that the shortest path tree branch from S has not yet been setup completely, and the router can still accept packets from S that arrive on the (*,G) entry's indicated incoming interface (iif). Each PIM multicast entry has an associated incoming interface on which packets are expected to arrive. When a router with a (S,G) entry and a cleared SPT-bit starts to receive packets from the new source S on the iif for the (S,G) entry, and that iif differs from the (*,G) entry's iif, the router sets the SPT-bit, and sends a Join/Prune message towards the RP, indicating that the router no longer wants to receive packets from S via the shared RP-tree. The Join/Prune message sent towards the RP includes S in the prune list, with the RPT-bit set indicating that S's packets must not be forwarded down this branch of the shared tree. If the router receiving the Join/Prune message has (S,G) state (with or without the route entry's RPT-bit flag set), it deletes the arriving interface from the (S,G) oif list. If the router has only (*,G) state, it creates an entry with the RPT-bit flag set to 1. For brevity we refer to an (S,G) entry that has the RPT-bit flag set to 1 as an (S,G)RPT-bit entry. This notational distinction is useful to point out the different actions taken for (S,G) entries depending on the setting of the RPT-bit flag. Note that a router can have no more than one active (S,G) entry for any particular S and G, at any particular time; whether the RPT-bit flag is set or not. In other words, a router never has both an (S,G) and an (S,G)RPT-bit entry for the same S and G at the same time. The Join/Prune message payload contains Multicast-Address=G, Join=NULL, Prune=S,RPT-bit. Estrin, et. al. Experimental [Page 6] Internet Draft PIM-SM Oct 1999 A new receiver may join an existing RP-tree on which source-specific prune state has been established (e.g., because downstream receivers have switched to SP-trees). In this case the prune state must be eradicated upstream of the new receiver to bring all sources' data packets down to the new receiver. Therefore, when a (*,G) Join arrives at a router that has any (Si,G)RPT-bit entries (i.e., entries that cause the router to send source-specific prunes toward the RP), these entries must be updated upstream of the router so as to bring all sources' packets down to the new member. To accomplish this, each router that receives a (*,G) Join/Prune message updates all existing (S,G)RPT-bit entries. The router may also trigger a (*,G) Join/Prune message upstream to cause the same updating of RPT-bit settings upstream and pull down all active sources' packets. If the arriving (*,G) join has some sources included in its prune list, then the corresponding (S,G)RPT-bit entries are left unchanged (i.e., the RPT-bit remains set and no oif is added). 2.5 Steady state maintenance of distribution tree (i.e., router state)} In the steady state each router sends periodic Join/Prune messages for each active PIM route entry; the Join/Prune messages are sent to the neighbor indicated in the corresponding entry. These messages are sent periodically to capture state, topology, and membership changes. A Join/Prune message is also sent on an event-triggered basis each time a new route entry is established for some new source (note that some damping function may be applied, e.g., a short delay to allow for merging of new Join information). Join/Prune messages do not elicit any form of explicit acknowledgment; routers recover from lost packets using the periodic refresh mechanism. 2.6 Obtaining RP information To obtain the RP information, all routers within a PIM domain collect Bootstrap messages. Bootstrap messages are sent hop-by-hop within the domain; the domain's bootstrap router (BSR) is responsible for originating the Bootstrap messages. Bootstrap messages are used to carry out a dynamic BSR election when needed and to distribute RP information in steady state. A domain in this context is a contiguous set of routers that all implement PIM and are configured to operate within a common boundary defined by PIM Multicast Border Routers (PMBRs). PMBRs connect each PIM domain to the rest of the internet. Routers use a set of available RPs (called the RP-Set) distributed in Bootstrap messages to get the proper Group to RP mapping. The following paragraphs summarize the mechanism; details of the mechanism may be found in Sections 3.6 and Appendix 6.2. A (small) Estrin, et. al. Experimental [Page 7] Internet Draft PIM-SM Oct 1999 set of routers, within a domain, are configured as candidate BSRs and, through a simple election mechanism, a single BSR is selected for that domain. A set of routers within a domain are also configured as candidate RPs (C-RPs); typically these will be the same routers that are configured as C-BSRs. Candidate RPs periodically unicast Candidate-RP-Advertisement messages (C-RP-Advs) to the BSR of that domain. C-RP-Advs include the address of the advertising C-RP, as well as an optional group address and a mask length field, indicating the group prefix(es) for which the candidacy is advertised. The BSR then includes a set of these Candidate-RPs (the RP-Set), along with the corresponding group prefixes, in Bootstrap messages it periodically originates. Bootstrap messages are distributed hop-by- hop throughout the domain. Routers receive and store Bootstrap messages originated by the BSR. When a DR gets a membership indication from IGMP for (or a data packet from) a directly connected host, for a group for which it has no entry, the DR uses a hash function to map the group address to one of the C-RPs whose Group-prefix includes the group (see Section 3.7). The DR then sends a Join/Prune message towards (or unicasts Registers to) that RP. The Bootstrap message indicates liveness of the RPs included therein. If an RP is included in the message, then it is tagged as `up' at the routers; while RPs not included in the message are removed from the list of RPs over which the hash algorithm acts. Each router continues to use the contents of the most recently received Bootstrap message until it receives a new Bootstrap message. If a PIM domain partitions, each area separated from the old BSR will elect its own BSR, which will distribute an RP-Set containing RPs that are reachable within that partition. When the partition heals, another election will occur automatically and only one of the BSRs will continue to send out Bootstrap messages. As is expected at the time of a partition or healing, some disruption in packet delivery may occur. This time will be on the order of the region's round-trip time and the bootstrap router timeout value. 2.7 Interoperation with dense mode protocols such as DVMRP In order to interoperate with networks that run dense-mode, broadcast and prune, protocols, such as DVMRP, all packets generated within a PIM-SM region must be pulled out to that region's PIM Multicast Border Routers (PMBRs) and injected (i.e., broadcast) into the DVMRP network. A PMBR is a router that sits at the boundary of a PIM-SM domain and interoperates with other types of multicast routers such as those that run DVMRP. Generally a PMBR would speak both protocols and implement interoperability functions not required by regular PIM Estrin, et. al. Experimental [Page 8] Internet Draft PIM-SM Oct 1999 routers. To support interoperability, a special entry type, referred to as (*,*,RP), must be supported by all PIM routers. For this reason we include details about (*,*,RP) entry handling in this general PIM specification. A data packet will match on a (*,*,RP) entry if there is no more specific entry (such as (S,G) or (*,G)) and the destination group address in the packet maps to the RP listed in the (*,*,RP) entry. In this sense, a (*,*,RP) entry represents an aggregation of all the groups that hash to that RP. PMBRs initialize (*,*,RP) state for each RP in the domain's RPset. The (*,*,RP) state causes the PMBRs to send (*,*,RP) Join/Prune messages toward each of the active RPs in the domain. As a result distribution trees are built that carry all data packets originated within the PIM domain (and sent to the RPs) down to the PMBRs. PMBRs are also responsible for delivering externally-generated packets to routers within the PIM domain. To do so, PMBRs initially encapsulate externally-originated packets (i.e., received on DVMRP interfaces) in Register messages and unicast them to the corresponding RP within the PIM domain. The Register message has a bit indicating that it was originated by a border router and the RP caches the originating PMBR's address in the route entry so that duplicate Registers from other PMBRs can be declined with a Register-Stop message. All PIM routers must be capable of supporting (*,*,RP) state and interpreting associated Join/Prune messages. We describe the handling of (*,*,RP) entries and messages throughout this document; however, detailed PIM Multicast Border Router (PMBR) functions will be specified in a separate interoperability document (see directory, http://catarina.usc.edu/pim/interop/). 2.8 Multicast data packet processing Data packets are processed in a manner similar to other multicast schemes. A router first performs a longest match on the source and group address in the data packet. A (S,G) entry is matched first if one exists; a (*,G) entry is matched otherwise. If neither state exists, then a (*,*,RP) entry match is attempted as follows: the router hashes on G to identify the RP for group G, and looks for a (*,*,RP) entry that has this RP address associated with it. If none of the above exists, then the packet is dropped. If a state is matched, the router compares the interface on which the packet arrived to the incoming interface field in the matched route entry. If the iif check fails the packet is dropped, otherwise the packet is forwarded to all interfaces listed in the outgoing interface list. Estrin, et. al. Experimental [Page 9] Internet Draft PIM-SM Oct 1999 Some special actions are needed to deliver packets continuously while switching from the shared to shortest-path tree. In particular, when a (S,G) entry is matched, incoming packets are forwarded as follows: 1 If the SPT-bit is set, then: 1 if the incoming interface is the same as a matching (S,G) iif, the packet is forwarded to the oif-list of (S,G). 2 if the incoming interface is different than a matching (S,G) iif , the packet is discarded. 2 If the SPT-bit is cleared, then: 1 if the incoming interface is the same as a matching (S,G) iif, the packet is forwarded to the oif-list of (S,G). In addition, the SPT bit is set for that entry if the incoming interface differs from the incoming interface of the (*,G) or (*,*,RP) entry. 2 if the incoming interface is different than a matching (S,G) iif, the incoming interface is tested against a matching (*,G) or (*,*,RP) entry. If the iif is the same as one of those, the packet is forwarded to the oif-list of the matching entry. 3 Otherwise the iif does not match any entry for G and the packet is discarded. Data packets never trigger prunes. However, data packets may trigger actions that in turn trigger prunes. For example, when router B in figure 3 decides to switch to SP-tree at step 3, it creates a (S,G) entry with SPT-bit set to 0. When data packets from S arrive at interface 2 of B, B sets the SPT-bit to 1 since the iif for (*,G) is different than that for (S,G). This triggers the sending of prunes towards the RP. Estrin, et. al. Experimental [Page 10] Internet Draft PIM-SM Oct 1999 2.9 Operation over Multi-access Networks This section describes a few additional protocol mechanisms needed to operate PIM over multi-access networks: Designated Router election, Assert messages to resolve parallel paths, and the Join/Prune- Suppression-Timer to suppress redundant Joins on multi-access networks. Designated router election: When there are multiple routers connected to a multi-access network, one of them must be chosen to operate as the designated router (DR) at any point in time. The DR is responsible for sending triggered Join/Prune and Register messages toward the RP. A simple designated router (DR) election mechanism is used for both SM and traditional IP multicast routing. Neighboring routers send Hello messages to each other. The sender with the largest network layer address assumes the role of DR. Each router connected to the multi-access LAN sends the Hellos periodically in order to adapt to changes in router status. Parallel paths to a source or the RP--Assert process: If a router receives a multicast datagram on a multi-access LAN from a source whose corresponding (S,G) outgoing interface list includes the interface to that LAN, the packet must be a duplicate. In this case a single forwarder must be elected. Using Assert messages addressed to `224.0.0.13' (ALL-PIM-ROUTERS group) on the LAN, upstream routers can resolve which one will act as the forwarder. Downstream routers listen to the Asserts so they know which one was elected, and therefore where to send subsequent Joins. Typically this is the same as the downstream router's RPF (Reverse Path Forwarding) neighbor; but there are circumstances where this might not be the case, e.g., when using multiple unicast routing protocols on that LAN. The RPF neighbor for a particular source (or RP) is the next-hop router to which packets are forwarded en route to that source (or RP); and therefore is considered a good path via which to accept packets from that source. The upstream router elected is the one that has the shortest distance to the source. Therefore, when a packet is received on an outgoing interface a router sends an Assert message on the multi-access LAN indicating what metric it uses to reach the source of the data packet. The router with the smallest numerical metric (with ties broken by highest address) will become the forwarder. All other Estrin, et. al. Experimental [Page 11] Internet Draft PIM-SM Oct 1999 upstream routers will delete the interface from their outgoing interface list. The downstream routers also do the comparison in case the forwarder is different than the RPF neighbor. Associated with the metric is a metric preference value. This is provided to deal with the case where the upstream routers may run different unicast routing protocols. The numerically smaller metric preference is always preferred. The metric preference is treated as the high-order part of an assert metric comparison. Therefore, a metric value can be compared with another metric value provided both metric preferences are the same. A metric preference can be assigned per unicast routing protocol and needs to be consistent for all routers on the multi-access network. Asserts are also needed for (*,G) entries since an RP-Tree and an SP-Tree for the same group may both cross the same multi-access network. When an assert is sent for a (*,G) entry, the first bit in the metric preference (RPT-bit) is always set to 1 to indicate that this path corresponds to the RP tree, and that the match must be done on (*,G) if it exists. Furthermore, the RPT-bit is always cleared for metric preferences that refer to SP-tree entries; this causes an SP- tree path to always look better than an RP-tree path. When the SP- tree and RPtree cross the same LAN, this mechanism eliminates the duplicates that would otherwise be carried over the LAN. In case the packet, or the Assert message, matches on oif for (*,*,RP) entry, a (*,G) entry is created, and asserts take place as if the matching state were (*,G). The DR may lose the (*,G) Assert process to another router on the LAN if there are multiple paths to the RP through the LAN. From then on, the DR is no longer the last-hop router for local receivers and removes the LAN from its (*,G) oif list. The winning router becomes the last-hop router and is responsible for sending (*,G) join messages to the RP. Join/Prune suppression: Join/Prune suppression may be used on multi-access LANs to reduce duplicate control message overhead; it is not required for correct performance of the protocol. If a Join/Prune message arrives and matches on the incoming interface for an existing (S,G), (*,G), or (*,*,RP) route entry, and the Holdtime included in the Join/Prune message is greater than the recipient's own [Join/Prune-Holdtime] (with ties resolved in favor of the higher network layer address), a timer (the Join/Prune-Suppression-timer) in the recipient's route entry may be started to suppress further Join/Prune messages. After this timer expires, the recipient triggers a Join/Prune message, and Estrin, et. al. Experimental [Page 12] Internet Draft PIM-SM Oct 1999 resumes sending periodic Join/Prunes, for this entry. The Join/Prune-Suppression-timer should be restarted each time a Join/Prune message is received with a higher Holdtime. 2.10 Unicast Routing Changes When unicast routing changes, an RPF check is done on all active (S,G), (*,G) and (*,*,RP) entries, and all affected expected incoming interfaces are updated. In particular, if the new incoming interface appears in the outgoing interface list, it is deleted from the outgoing interface list. The previous incoming interface may be added to the outgoing interface list by a subsequent Join/Prune from downstream. Join/Prune messages received on the current incoming interface are ignored. Join/Prune messages received on new interfaces or existing outgoing interfaces are not ignored. Other outgoing interfaces are left as is until they are explicitly pruned by downstream routers or are timed out due to lack of appropriate Join/Prune messages. If the router has a (S,G) entry with the SPT-bit set, and the updated iif(S,G) does not differ from iif(*,G) or iif(*,*,RP), then the router resets the SPT-bit. The router must send a Join/Prune message with S in the Join list out any new incoming interfaces to inform upstream routers that it expects multicast datagrams over the interface. It may also send a Join/Prune message with S in the Prune list out the old incoming interface, if the link is operational, to inform upstream routers that this part of the distribution tree is going away. 2.11 PIM-SM for Inter-Domain Multicast Future documents will address the use of PIM-SM as a backbone inter- domain multicast routing protocol. Design choices center primarily around the distribution and usage of RP information for wide area, inter-domain groups. 2.12 Security All PIM control messages may use IPsec [6] to address security concerns. Security mechanisms are likely to be enhanced in the near future. 3 Detailed Protocol Description This section describes the protocol operations from the perspective of an individual router implementation. In particular, for each message type we describe how it is generated and processed. Estrin, et. al. Experimental [Page 13] Internet Draft PIM-SM Oct 1999 3.1 Hello Hello messages are sent so neighboring routers can discover each other. 3.1.1 Sending Hellos Hello messages are sent periodically between PIM neighbors, every [Hello-Period] seconds. This informs routers what interfaces have PIM neighbors. Hello messages are multicast using address 224.0.0.13 (ALL-PIM-ROUTERS group). The packet includes a Holdtime, set to [Hello-Holdtime], for neighbors to keep the information valid. Hellos are sent on all types of communication links. The DR Election Priority Option SHOULD be included in all Hello messages, to allow DR election to be independent of the relative IP addresses. The DR election priority is a 32-bit unsigned number. The numerically larger priority is always preferred. The priority based DR election is used only when all routers on the LAN include this option in their Hellos. An implementation capable of doing this option SHOULD always include it in the Hellos even if no DR election priority is explicitly configured. The default priority is 1. The Generation Identifier (GenID) Option SHOULD also be included in all Hello messages. This option contains a randomly generated 32-bit value that is different each time a router restarts. Once a new GenID is found from a neighbor, that neighbor SHOULD be treated as a new neighbor by the local system. 3.1.2 Receiving Hellos When a router receives a Hello message, it stores the network layer address for that neighbor, sets its Neighbor-timer for the Hello sender to the Holdtime included in the Hello, and determines the Designated Router (DR) for that interface. The highest addressed system is elected DR. Each Hello received causes reevaluation of the DR's address. If no DR election priority option is specified in a Hello message, the Hello sender is deemed not capable of handling the DR election priority option. When such a hello message is received, the neighbor with the highest IP address is elected the DR. This way new systems can interoperate with systems implementing older versions of this specification. The DR election priority received in a Hello is kept until the next Hello from the same system arrives. The newly received priority replaces the cached priority for the same neighbor. When a router that is the active DR receives a Hello from a new neighbor (i.e., from an address that is not yet in the DRs neighbor table, or a neighbor with a new GenID), the DR unicasts its most recent RP-set information to the new neighbor. 3.1.3 Timing out neighbor entries A periodic process is run to time out PIM neighbors that have not sent Hellos. If the DR has gone down, a new DR is chosen by scanning all neighbors on the interface and selecting the new DR to be the one with the highest network layer address. If an interface has gone down, the router may optionally time out all PIM neighbors associated with the interface. 3.2 Join/Prune Join/Prune messages are sent to join or prune a branch off of the multicast distribution tree. A single message contains both a join and prune list, either one of which may be null. Each list contains a set of source addresses, indicating the source-specific trees or shared tree that the router wants to join or prune. In this specification, the term (S,G) entry covers all (S,G) entries, irrespective of any flag settings unless explicitly stated otherwise. Estrin, et. al. Experimental [Page 14] Internet Draft PIM-SM Oct 1999 3.2.1 Sending Join/Prune Messages Join/Prune messages are merged such that a message sent to a particular upstream neighbor, N, includes all of the current joined and pruned sources that are reached via N; according to unicast routing Join/Prune messages are multicast to all routers on multi- access networks with the target address set to the next hop router towards S or RP. Join/Prune messages are sent every [Join/Prune- Period] seconds. In the future we will introduce mechanisms to rate- limit this control traffic on a hop by hop basis, in order to avoid excessive overhead on small links. In addition, certain events cause triggered Join/Prune messages to be sent. Periodic Join/Prune Messages: A router sends a periodic Join/Prune message to each distinct RPF neighbor associated with each (S,G), (*,G) and (*,*,RP) entry. Join/Prune messages are only sent if the RPF neighbor is a PIM neighbor. A periodic Join/Prune message sent to a particular RPF neighbor is constructed as follows: 1 Each router determines the RP for a (*,G) entry by using the hash function described. The RP address (with RPT and WC bits set) is included in the join list of a periodic Join/Prune message under the following conditions: 1 The Join/Prune message is being sent to the RPF neighbor toward the RP for an active (*,G) or (*,*,RP) entry, and 2 The outgoing interface list in the (*,G) or (*,*,RP) entry is non-NULL, or the router is the DR on the same interface as the RPF neighbor. 2 A particular source address, S, is included in the join list with the RPT and WC bits cleared under the following conditions: 1 The Join/Prune message is being sent to the RPF neighbor toward S, and 2 There exists an active (S,G) entry with the RPT-bit flag cleared, and 3 The oif list in the (S,G) entry is not null. Estrin, et. al. Experimental [Page 15] Internet Draft PIM-SM Oct 1999 3 A particular source address, S, is included in the prune list with the RPT and WC bits cleared under the following conditions: 1 The Join/Prune message is being sent to the RPF neighbor toward S, and 2 There exists an active (S,G) entry with the RPT-bit flag cleared, and 3 The oif list in the (S,G) entry is null. 4 A particular source address, S, is included in the prune list with the RPT-bit set and the WC bit cleared under the following conditions: 1 The Join/Prune message is being sent to the RPF neighbor toward the RP and there exists a (S,G) entry with the RPT-bit flag set and null oif list, or 2 The Join/Prune message is being sent to the RPF neighbor toward the RP, there exists a (S,G) entry with the RPT-bit flag cleared and SPT-bit set, and the incoming interface toward S is different than the incoming interface toward the RP, or 3 The Join/Prune message is being sent to the RPF neighbor toward the RP, and there exists a (*,G) entry and (S,G) entry for a directly connected source. 5 The RP address (with RPT and WC bits set) is included in the prune list if: 1 The Join/Prune message is being sent to the RPF neighbor toward the RP and there exists a (*,G) entry with a null oif list (see Section 3.5.2). Triggered Join/Prune Messages: In addition to periodic messages, the following events will trigger Join/Prune messages if as a result, a) a new entry is created, or b) the oif list changes from null to non-null or non- null to null. The contents of triggered messages are the same as the periodic, described above. 1 Receipt of an indication from IGMP that the state of directly-connected-membership has changed (i.e., new members have just joined `membership indication' or all members have Estrin, et. al. Experimental [Page 16] Internet Draft PIM-SM Oct 1999 left), for a group G, may cause the last-hop router to build or modify corresponding (*,G) state. When IGMP indicates that there are no longer directly connected members, the oif is removed from the oif list if the oif-timer is not running. A Join/Prune message is triggered if and only if a) a new entry is created, or b) the oif list changes from null to non-null or non-null to null, as follows: 1 If the receiving router does not have a route entry for G the router creates a (*,G) entry, copies the oif list from the corresponding (*,*,RP) entry (if it exists), and includes the interface included in the IGMP membership indication in the oif list; as always, the router never includes the entry's iif in the oif list. The router sends a Join/Prune message towards the RP with the RP address and RPT-bit and WC-bits set in the join list. Or, 2 If a (S,G)RPT-bit or (*,G) entry already exists, the interface included in the IGMP membership indication is added to the oif list (if it was not included already). 2 Receipt of a Join/Prune message for (S,G), (*,G) or (*,*,RP) will cause building or modifying corresponding state, and subsequent triggering of upstream Join/Prune messages, in the following cases: 1 When there is no current route entry, the RP address included in the Join/Prune message is checked against the local RP-Set information. If it matches, an entry will be created and the new entry will in turn trigger an upstream Join/Prune message. If the router has no RP-Set information it may discard the message, or optionally use the RP address included in the message. 2 When the outgoing interface list of an (S,G)RPT-bit entry becomes null, the triggered Join/Prune message will contain S in the prune list. 3 When there exists a (S,G)RPT-bit with null oif list, and an (*,G) Join/Prune message is received, the arriving interface is added to the oif list and a (*,G) Join/Prune message is triggered upstream. This triggered (*,G) Join/Prune message SHOULD include (S,G)RPT-bit prunes for all (S,G)RPT-bit entries with null oif list. 4 When there exists a (*,G) with null oif list, and a (*,*,RP) Join/Prune message is received, the receiving interface is added to the oif list and a (*,*,RP) Join/Prune message is triggered upstream. Estrin, et. al. Experimental [Page 17] Internet Draft PIM-SM Oct 1999 3 Receipt of a packet that matches on a (S,G) entry whose SPT-bit is cleared triggers the following if the packet arrived on the correct incoming interface and there is a (*,G) or (*,*,RP) entry with a different incoming interface: a) the router sets the SPT-bit on the (S,G) entry, and b) the router sends a Join/Prune message towards the RP with S in the prune list and the RPT-bit set. 4 Receipt of a packet at the DR from a directly connected source S, on the subnet containing the address S, triggers a Join/Prune message towards the RP with S in the prune list and the RPT-bit set under the following conditions: a) there is no matching (S,G) state, and b) there exists a (*,G) or (*,*,RP) for which the DR is not the RP. 5 When a Join/Prune message is received for a group G, the prune list is checked. If the prune list contains a source or RP for which the receiving router has a corresponding active (S,G), (*,G) or (*,*,RP) entry, and whose iif is that on which the Join/Prune was received, then a join for (S,G), (*,G) or (*,*,RP) is triggered to override the prune, respectively. (This is necessary in the case of parallel downstream routers connected to a multi-access network.) 6 When the RP fails, the RP will not be included in the Bootstrap messages sent to all routers in that domain. This triggers the DRs to send (*,G) Join/Prune messages towards the new RP for the group, as determined by the RP-Set and the hash function. As described earlier, PMBRs trigger (*,*,RP) joins towards each RP in the RP-Set. 7 When an entry's Join/Prune-Suppression timer expires, a Join/Prune message is triggered upstream corresponding to that entry, even if the outgoing interface has not transitioned between null and non-null states. 8 When the RPF neighbor changes (whether due to an Assert or changes in unicast routing), the router sets a random delay timer (the Random-Delay-Join-Timer) whose expiration triggers sending of a Join/Prune message for the asserted route entry to the Assert winner (if the Join/Prune Suppression timer has expired.) We do not trigger prunes onto interfaces based on data packets. Data packets that arrive on the wrong incoming interface are silently dropped. However, on point-to-point interfaces triggered prunes may be sent as an optimization. Estrin, et. al. Experimental [Page 18] Internet Draft PIM-SM Oct 1999 aragraphFragmentation It is possible that a Join/Prune message constructed according to the preceding rules could exceed the MTU of a network. In this case, the message can undergo semantic fragmentation whereby information corresponding to different groups can be sent in different messages. However, if a Join/Prune message must be fragmented the complete prune list corresponding to a group G must be included in the same Join/Prune message as the associated RP-tree Join for G. If such semantic fragmentation is not possible, IP fragmentation should be used between the two neighboring hops. 3.2.2 Receiving Join/Prune Messages When a router receives Join/Prune message, it processes it as follows. The receiver of the Join/Prune notes the interface on which the PIM message arrived, call it I. The receiver then checks to see if the Join/Prune message was addressed to the receiving router itself (i.e., the router's address appears in the Unicast Upstream Neighbor Router field of the Join/Prune message). (If the router is connected to a multiaccess LAN, the message could be intended for a different router.) If the Join/Prune is for this router the following actions are taken. For each group address G, in the Join/Prune message, the associated join list is processed as follows. We refer to each address in the join list as Sj; Sj refers to the RP if the RPT-bit and WC-bit are both set. For each Sj in the join list of the Join/Prune message: 1 If an address, Sj, in the join list of the Join/Prune message has the RPT-bit and WC-bit set, then Sj is the RP address used by the downstream router(s) and the following actions are taken: 1 If Sj is not the same as the receiving router's RP mapping for G, the receiving router may ignore the Join/Prune message with respect to that group entry. If the router does not have any RP-Set information, it may use the address Sj included in the Join/Prune message as the RP for the group. 2 If Sj is the same as the receiving router's RP mapping for G, the receiving router adds I to the outgoing interface list of the (*,G) route entry (if there is no (*,G) entry, the router creates one first) and sets the Oif-timer for that interface to the Holdtime specified in the Join/Prune message. In addition, the Oif-Deletion-Delay for that interface is set to 1/3rd the Holdtime specified Estrin, et. al. Experimental [Page 19] Internet Draft PIM-SM Oct 1999 in the Join/Prune message. If a (*,*,RP) entry exists, for the RP associated with G, then the oif list of the newly created (*,G) entry is copied from that (*,*,RP) entry. 3 For each (Si,G) entry associated with group G: i) if Si is not included in the prune list, ii) if I is not on the same subnet as the address Si, and iii) if I is not the iif, then interface I is added to the oif list and the Oif-timer for that interface in each affected entry is increased (never decreased) to the Holdtime included in the Join/Prune message. In addition, if the Oif-timer for that interface is increased, the Oif-Deletion-Delay for that interface is set to 1/3rd the Holdtime specified in the Join/Prune message. If the group address in the Join/Prune message is `*' then every (*,G) and (S,G) entry, whose group address hashes to the RP indicated in the (*,*,RP) Join/Prune message, is updated accordingly. A `*' in the group field of the Join/Prune is represented by a group address 224.0.0.0 and a group mask length of 4, indicating a (*,*,RP) Join. 4 If the (Si,G) entry has its RPT-bit flag set to 1, and its oif list is the same as the (*,G) oif list, then the (Si,G)RPT-bit entry is deleted, 5 The incoming interface is set to the interface used to send unicast packets to the RP in the (*,G) route entry, i.e., RPF interface toward the RP. 2 For each address, Sj, in the join list whose RPT-bit and WC-bit are not set, and for which there is no existing (Sj,G) route entry, the router initiates one. The router creates a (S,G) entry and copies all outgoing interfaces from the (S,G)RPT-bit entry, if it exists. If there is no (S,G) entry, the oif list is copied from the (*,G) entry; and if there is no (*,G) entry, the oif list is copied from the (*,*,RP) entry, if it exists. In all cases, the iif of the (S,G) entry is always excluded from the oif list. 1 If the interface used to reach Sj, is the same as I, this represents an error (or a unicast routing change) and the Join/Prune must not be processed. 2 Interface I is added to the outgoing interface list for (Sj,G). The incoming interface for (Sj,G) is set to the interface used to send unicast packets to Sj (i.e., the RPF neighbor). Estrin, et. al. Experimental [Page 20] Internet Draft PIM-SM Oct 1999 3 For each address, Sj, in the join list of the Join/Prune message, for which there is an existing (Sj,G) route entry, 1 If the RPT-bit is not set for Sj listed in the Join/Prune message, but the RPT-bit flag is set on the existing (Sj,G) entry, the router clears the RPT-bit flag on the (Sj,G) entry, sets the incoming interface to point towards Sj for that (Sj,G) entry, and sends a Join/Prune message corresponding to that entry through the new incoming interface; and 2 If I is not the same as the existing incoming interface, the router adds I to the list of outgoing interfaces. 3 The Oif-timer for I is increased (never decreased) to the Holdtime included in the Join/Prune message. In addition, if the Oif-timer for that interface is increased, the Oif-Deletion-Delay for that interface is set to 1/3rd the Holdtime specified in the Join/Prune message. For each group address G, in the Join/Prune message, the associated prune list is processed as follows. We refer to each address in the prune list as Sp; Sp refers to the RP if the RPT- bit and WC-bit are both set. For each Sp in the prune list of the Join/Prune message: 1 For each address, Sp, in the prune list whose RPT-bit and WC-bit are cleared: 1 If there is an existing (Sp,G) route entry, the router lowers the entry's Oif-timer for I to its Oif-Deletion- Delay, allowing for other downstream routers on a multi- access LAN to override the prune. However, on point-to- point links, the oif-timer is expired immediately. 2 If the router has a current (*,G), or (*,*,RP), route entry, and if the existing (Sp,G) entry has its RPT-bit flag set to 1, then this (Sp,G)RPT-bit entry is maintained (not deleted) even if its outgoing interface list is null. 2 For each address, Sp, in the prune list whose RPT-bit is set and whose WC-bit cleared: Estrin, et. al. Experimental [Page 21] Internet Draft PIM-SM Oct 1999 1 If there is an existing (Sp,G) route entry, the router lowers the entry's Oif-timer for I to its Oif-Deletion- Delay, allowing for other downstream routers on a multi- access LAN to override the prune. However, on point-to- point links, the oif-timer is expired immediately. 2 If the router has a current (*,G), or (*,*,RP), route entry, and if the existing (Sp,G) entry has its RPT-bit flag set to 1, then this (Sp,G)RPT-bit entry is not deleted, and the Entry-timer is restarted, even if its outgoing interface list is null. 3 If (*,G), or corresponding (*,*,RP), state exists, but there is no (Sp,G) entry, an (Sp,G)RPT-bit entry is created . The outgoing interface list is copied from the (*,G), or (*,*,RP), entry, with the interface, I, on which the prune was received, is deleted. Packets from the pruned source, Sp, match on this state and are not forwarded toward the pruned receivers. 4 If there exists a (Sp,G) entry, with or without the RPT-bit set, the oif-timer for I is expired, and the Entry-timer is restarted. 3 For each address, Sp, in the prune list whose RPT-bit and WC-bit are both set: 1 If there is an existing (*,G) entry, with Sp as the RP for G, the router lowers the entry's Oif-timer for I to its Oif-Deletion-Delay, allowing for other downstream routers on a multi-access LAN to override the prune. However, on point-to-point links, the oif-timer is expired immediately. 2 If the corresponding (*,*,RP) state exists, but there is no (*,G) entry, a (*,G) entry is created. The outgoing interface list is copied from (*,*,RP) entry, with the interface, I, on which the prune was received, deleted. For any new (S,G), (*,G) or (*,*,RP) entry created by an incoming Join/Prune message, the SPT-bit is cleared (and if a Join/Prune-Suppression timer is used, it is left off.) If the entry has a Join/Prune-Suppression timer associated with it, and if the received Join/Prune does not indicate the router as its target, then the receiving router examines the join and prune lists to see if any addresses in the list `completely-match' existing (S,G), (*,G), or (*,*,RP) state for which the receiving router currently schedules Join/Prune messages. An element on the join or Estrin, et. al. Experimental [Page 22] Internet Draft PIM-SM Oct 1999 prune list `completely-matches' a route entry only if both the addresses and RPT-bit flag are the same. If the incoming Join/Prune message completely matches an existing (S,G), (*,G), or (*,*,RP) entry and the Join/Prune arrived on the iif for that entry, then the router compares the Holdtime included in the Join/Prune message, to its own [Join/Prune-Holdtime]. If its own [Join/Prune-Holdtime] is lower, the Join/Prune-Suppression-timer is started at the [Join/Prune-Suppression-Timeout]. When the Join/Prune Suppression timer expires, the router triggers a Join/Prune message for the corresponding entry(ies). 3.3 Register and Register-Stop When a source first starts sending to a group its packets are encapsulated in Register messages and sent to the RP. If the data rate warrants source-specific paths, the RP sets up source specific state and starts sending (S,G) Join/Prune messages toward the source, with S in the join list. 3.3.1 Sending Registers and Receiving Register-Stops Register messages are sent as follows: 1 When a DR receives a packet from a directly connected source, S, on the subnet containing the address S, 1 If there is no corresponding (S,G) entry, and the router has RP-Set information, and the DR is not the RP for G, the DR creates an (S,G) entry with the Register- Suppression-timer turned off and the RP address set according to the hash function mapping for the corresponding group. The oif list is copied from existing (*,G) or (*,*,RP) entries, if they exist. The iif of the (S,G) entry is always excluded from the oif list. If there exists a (*,G) or (*,*,RP) entry, the DR sends a Join/Prune message towards the RP with S in the prune list and the RPT-bit set. 2 If there is a (S,G) entry in existence, the DR simply restarts the corresponding Entry-timer. When a PMBR (e.g., a router that connects the PIM-SM region to a dense mode region running DVMRP or PIM-DM) receives a packet from a source in the dense mode region, the router Estrin, et. al. Experimental [Page 23] Internet Draft PIM-SM Oct 1999 treats the packet as if it were from a directly connected source. A separate document will describe the details of interoperability. 2 If the new or previously-existing (S,G) entry's Register- Suppression-timer is not running, the data packet is encapsulated in a Register message and unicast to the RP for that group. The data packet is also forwarded according to (S,G) state in the DR if the oif list is not null; since a receiver may join the SP-tree while the DR is still registering to the RP. 3 If the (S,G) entry's Register-Suppression-timer is running, the data packet is not sent in a Register message, it is just forwarded according to the (S,G) oif list. When the DR receives a Register-Stop message, it restarts the Register-Suppression-timer in the corresponding (S,G) entry(ies) at [Register-Suppression-Timeout] seconds. If there is data to be registered, the DR may send a null Register (a Register message with a zero-length data portion in the inner packet) to the RP, [Probe- Time] seconds before the Register-Suppression-timer expires, to avoid sending occasional bursts of traffic to an RP unnecessarily. 3.3.2 Receiving Register Messages and Sending Register-Stops When a router (i.e., the RP) receives a Register message, the router does the following: 1 Decapsulates the data packet, and checks for a corresponding (S,G) entry. 1 If a (S,G) entry with cleared (0) SPT bit exists, and the received Register does not have the Null-Register-Bit set to 1, the packet is forwarded; and the SPT bit is left cleared (0). If the SPT bit is 1, the packet is dropped, and Register-Stop messages are triggered. Register-Stops should be rate-limited (in an implementation-specific manner) so that no more than a few are sent per round trip time. This prevents a high datarate stream of packets from triggering a large number of Register-Stop messages between the time that the first packet is received and the time when the source receives the first Register-Stop. 2 If there is no (S,G) entry, but there is a (*,G) entry, and the received Register does not have the Null- Register-Bit set to 1, the packet is forwarded according to the (*,G) entry. Estrin, et. al. Experimental [Page 24] Internet Draft PIM-SM Oct 1999 3 If there is a (*,*,RP) entry but no (*,G) entry, and the Register received does not have the Null-Register-Bit set to 1, a (*,G) or (S,G) entry is created and the oif list is copied from the (*,*,RP) entry to the new entry. The packet is forwarded according to the created entry. 4 If there is no G or (*,*,RP) entry corresponding to G, the packet is dropped, and a Register-Stop is triggered. 5 A "Border bit" bit is added to the Register message, to facilitate interoperability mechanisms. PMBRs set this bit when registering for external sources (see Section 2.7). If the "Border bit" is set in the Register, the RP does the following: 1 If there is no matching (S,G) state, but there exists (*,G) or (*,*,RP) entry, the RP creates a (S,G) entry, with a `PMBR' field. This field holds the source of the Register (i.e. the outer network layer address of the register packet). The RP triggers a (S,G) join towards the source of the data packet, and clears the SPT bit for the (S,G) entry. If the received Register is not a `null Register' the packet is forwarded according to the created state. Else, 2 If the `PMBR' field for the corresponding (S,G) entry matches the source of the Register packet, and the received Register is not a `null Register', the decapsulated packet is forwarded to the oif list of that entry. Else, 3 The packet is dropped, and a Register-stop is triggered towards the source of the Register. The (S,G) Entry-timer is restarted by Registers arriving from that source to that group. 2 If the matching (S,G) or (*,G) state contains a null oif list, the RP unicasts a Register-Stop message to the source of the Register message; in the latter case, the source-address field, within the Register-Stop message, is set to the wildcard Estrin, et. al. Experimental [Page 25] Internet Draft PIM-SM Oct 1999 value (all 0's). This message is not processed by intermediate routers, hence no (S,G) state is constructed between the RP and the source. 3 If the Register message arrival rate warrants it and there is no existing (S,G) entry, the RP sets up a (S,G) route entry with the outgoing interface list, excluding iif(S,G), copied from the (*,G) outgoing interface list, its SPT-bit is initialized to 0. If a (*,G) entry does not exist, but there exists a (*,*,RP) entry with the RP corresponding to G , the oif list for (S,G) is copied - excluding the iif - from that (*,*,RP) entry. A timer (Entry-timer) is set for the (S,G) entry and this timer is restarted by receipt of data packets for (S,G). The (S,G) entry causes the RP to send a Join/Prune message for the indicated group towards the source of the register message. If the (S,G) oif list becomes null, Join/Prune messages will not be sent towards the source, S. 3.4 Multicast Data Packet Forwarding Processing a multicast data packet involves the following steps: 1 Lookup route state based on a longest match of the source address, and an exact match of the destination address in the data packet. If neither S, nor G, find a longest match entry, and the RP for the packet's destination group address has a corresponding (*,*,RP) entry, then the longest match does not require an exact match on the destination group address. In summary, the longest match is performed in the following order: (1) (S,G), (2) (*,G). If neither is matched, then a lookup is performed on (*,*,RP) entries. 2 If the packet arrived on the interface found in the matching-entry's iif field, and the oif list is not null: 1 Forward the packet to the oif list for that entry, excluding the subnet containing S, and restart the Entry- timer if the matching entry is (S,G). Optionally, the (S,G) Entry-timer may be restarted by periodic checking of the matching packet count. Estrin, et. al. Experimental [Page 26] Internet Draft PIM-SM Oct 1999 2 If the entry is a (S,G) entry with a cleared SPT-bit, and a (*,G) or associated (*,*,RP) also exists whose incoming interface is different than that for (S,G), set the SPT-bit for the (S,G) entry and trigger an (S,G) RPT- bit prune towards the RP. 3 If the source of the packet is a directly-connected host and the router is the DR on the receiving interface, check the Register-Suppression-timer associated with the (S,G) entry. If it is not running, then the router encapsulates the data packet in a register message and sends it to the RP. This covers the common case of a packet arriving on the RPF interface to the source or RP and being forwarded to all joined branches. It also detects when packets arrive on the SP-tree, and triggers their pruning from the RP-tree. If it is the DR for the source, it sends data packets encapsulated in Registers to the RPs. 3 If the packet matches to an entry but did not arrive on the interface found in the entry's iif field, check the SPT-bit of the entry. If the SPT-bit is set, drop the packet. If the SPT-bit is cleared, then lookup the (*,G), or (*,*,RP), entry for G. If the packet arrived on the iif found in (*,G), or the corresponding (*,*,RP), forward the packet to the oif list of the matching entry. This covers the case when a data packet matches on a (S,G) entry for which the SP-tree has not yet been completely established upstream. 4 If the packet does not match any entry, but the source of the data packet is a local, directly-connected host, and the router is the DR on a multi-access LAN and has RP-Set information, the DR uses the hash function to determine the RP associated with the destination group, G. The DR creates a (S,G) entry, with the Register-Suppression-timer not running, encapsulates the data packet in a Register message and unicasts it to the RP. 5 If the packet does not match to any entry, and it is not a local host or the router is not the DR, drop the packet. 3.4.1 Data triggered switch to shortest path tree (SP-tree) Different criteria can be applied to trigger switching over from the RP-based shared tree to source-specific, shortest path trees. Estrin, et. al. Experimental [Page 27] Internet Draft PIM-SM Oct 1999 One proposed example is to do so based on data rate. For example, when a (*,G), or corresponding (*,*,RP), entry is created, a data rate counter may be initiated at the last-hop routers. The counter is incremented with every data packet received for directly connected members of an SM group, if the longest match is (*,G) or (*,*,RP). If and when the data rate for the group exceeds a certain configured threshold (t1), the router initiates `source-specific' data rate counters for the following data packets. Then, each counter for a source, is incremented when packets matching on (*,G), or (*,*,RP), are received from that source. If the data rate from the particular source exceeds a configured threshold (t2), a (S,G) entry is created and a Join/Prune message is sent towards the source. If the RPF interface for (S,G) is not the same as that for (*,G) -or (*,*,RP), then the SPT-bit is cleared in the (S,G) entry. Other configured rules may be enforced to cause or prevent establishment of (S,G) state. 3.5 Assert Asserts are used to resolve which of the parallel routers connected to a multi-access LAN is responsible for forwarding packets onto the LAN. 3.5.1 Sending Asserts The following Assert rules are provided when a multicast packet is received on an outgoing multi-access interface "I" of an existing active (S,G), (*,G) or (*,*,RP) entry: 1 Do unicast routing table lookup on source address from data packet, and send assert on interface "I" for source address in data packet; include metric preference of routing protocol and metric from routing table lookup. 2 If route is not found, use metric preference of 0x7fffffff and metric 0xffffffff. When an assert is sent for a (*,G) entry, the first bit in the metric preference (the RPT-bit) is set to 1, indicating the data packet is routed down the RP-tree. Asserts should be rate-limited in an implementation-specific manner. Estrin, et. al. Experimental [Page 28] Internet Draft PIM-SM Oct 1999 3.5.2 Receiving Asserts When an Assert is received the router performs a longest match on the source and group address in the Assert message, only active entries -- that have packet forwarding state -- are matched. The router checks the first bit of the metric preference (RPT-bit). 1 If the RPT-bit is set, the router first does a match on (*,G), or (*,*,RP), entries; if no matching entry is found, it ignores the Assert. 2 If the RPT-bit is not set in the Assert, the router first does a match on (S,G) entries; if no matching entry is found, the router matches (*,G) or (*,*,RP) entries. Receiving Asserts on an entry's outgoing interface: If the interface that received the Assert message is in the oif list of the matched entry, then this Assert is processed by this router as follows: 1 If the Assert's RPT-bit is set and the matching entry is (*,*,RP), the router creates a (*,G) entry. If the Assert's RPT-bit is cleared and the matching entry is (*,G), or (*,*,RP), the router creates a (S,G)RPT-bit entry. Otherwise, no new entry is created in response to the Assert. 2 The router then compares the metric values received in the Assert with the metric values associated with the matched entry. The RPT-bit and metric preference (in that order) are treated as the high-order part of an Assert metric comparison. If the value in the Assert is less than the router's value (with ties broken by the IP address, where higher network layer address wins), delete the interface from the entry. When the deletion occurs for a (*,G) or (*,*,RP) entry , the interface is also deleted from any associated (S,G)RPT-bit or (*,G) entries, respectively. The Entry-timer for the affected entries is restarted. 3 If the router has won the election the router keeps the interface in its outgoing interface list. It acts as the forwarder for the LAN. The winning router sends an Assert message containing its own metric to that outgoing interface. This will cause other routers on the LAN to prune that interface from their route entries. The winning router sets the RPT-bit in the Assert message if a (*,G) or (S,G)RPT-bit entry was matched. Estrin, et. al. Experimental [Page 29] Internet Draft PIM-SM Oct 1999 Receiving Asserts on an entry's incoming interface If the Assert arrived on the incoming interface of an existing (S,G), (*,G), or (*,*,RP) entry, the Assert is processed as follows. If the Assert message does not match the entry, exactly, it is ignored; i.e, longest-match is not used in this case. If the Assert message does match exactly, then: 1 Downstream routers will select the upstream router with the smallest metric preference and metric as their RPF neighbor. If two metrics are the same, the highest network layer address is chosen to break the tie. This is important so that downstream routers send subsequent Joins/Prunes (in SM) to the correct neighbor. An Assert-timer is initiated when changing the RPF neighbor to the Assert winner. When the timer expires, the router resets its RPF neighbor according to its unicast routing tables to capture network dynamics and router failures. 2 If the downstream routers have downstream members, and if the Assert caused the RPF neighbor to change, the downstream routers must trigger a Join/Prune message to inform the upstream router that packets are to be forwarded on the multi-access network. 3.6 Candidate-RP-Advertisements and Bootstrap messages Candidate-RP-Advertisements (C-RP-Advs) are periodic PIM messages unicast to the BSR by those routers that are configured as Candidate-RPs (C-RPs). Bootstrap messages are periodic PIM messages originated by the Bootstrap router (BSR) within a domain, and forwarded hop-by-hop to distribute the current RP-set to all routers in that domain. The Bootstrap messages also support a simple mechanism by which the Candidate BSR (C-BSR) with the highest BSR-priority and address (referred to as the preferred BSR) is elected as the BSR for the domain. We recommend that each router configured as a C-RP also be configured as a C-BSR. Sections 3.6.2 and 3.6.3 describe the combined function of Bootstrap messages as the vehicle for BSR election and RP-Set distribution. A Finite State Machine description of the BSR election and RP-Set distribution mechanisms is included in Appendix II. Estrin, et. al. Experimental [Page 30] Internet Draft PIM-SM Oct 1999 3.6.1 Sending Candidate-RP-Advertisements C-RPs periodically unicast C-RP-Advs to the BSR for that domain. The interval for sending these messages is subject to local configuration at the C-RP. Candidate-RP-Advertisements carry group address and group mask fields. This enables the advertising router to limit the advertisement to certain prefixes or scopes of groups. The advertising router may enforce this scope acceptance when receiving Registers or Join/Prune messages. C-RPs should send C-RP-Adv messages with the `Priority' field set to `0'. 3.6.2 Receiving C-RP-Advs and Originating Bootstrap Upon receiving a C-RP-Adv, a router does the following: 1 If the router is not the elected BSR, it ignores the message, else 2 The BSR adds the RP address to its local pool of candidate RPs, according to the associated group prefix(es) in the C-RP- Adv message. The Holdtime in the C-RP-Adv message is also stored with the corresponding RP, to be included later in the Bootstrap message. The BSR may apply a local policy to limit the number of Candidate RPs included in the Bootstrap message. The BSR may override the prefix indicated in a C-RP-Adv unless the `Priority' field is not zero. The BSR keeps an RP-timer per RP in its local RP-set. The RP-timer is initialized to the Holdtime in the RP's C-RP-Adv. When the timer expires, the corresponding RP is removed from the RP-set. The RP- timer is restarted by the C-RP-Advs from the corresponding RP. The BSR also uses its Bootstrap-timer to periodically send Bootstrap messages. In particular, when the Bootstrap-timer expires, the BSR originates a Bootstrap message on each of its PIM interfaces. To reduce the bootstrap message overhead during partition healing, the BSR should set a random time (as a function of the priority and address) after which the Bootstrap message is originated only if no other preferred Bootstrap message is received. For details see appendix 6.2. The message is sent with a TTL of 1 to the `ALL-PIM- ROUTERS' group. In steady state, the BSR originates Bootstrap messages periodically. At startup, the Bootstrap-timer is initialized to [Bootstrap-Timeout], causing the first Bootstrap message to be originated only when and if the timer expires. For Estrin, et. al. Experimental [Page 31] Internet Draft PIM-SM Oct 1999 timer details, see Section 3.6.3. A DR unicasts a Bootstrap message to each new PIM neighbor, i.e., after the DR receives the neighbor's Hello message (it does so even if the new neighbor becomes the DR). The Bootstrap message is subdivided into sets of group-prefix,RP- Count,RP-addresses. For each RP-address, the corresponding Holdtime is included in the "RP-Holdtime" field. The format of the Bootstrap message allows `semantic fragmentation', if the length of the original Bootstrap message exceeds the packet maximum boundaries (see Section 4). However, we recommend against configuring a large number of routers as C-RPs, to reduce the semantic fragmentation required. 3.6.3 Receiving and Forwarding Bootstrap Each router keeps a Bootstrap-timer, initialized to [Bootstrap- Timeout] at startup. When a router receives Bootstrap message sent to `ALL-PIM-ROUTERS' group, it performs the following: 1 If the message was not sent by the RPF neighbor towards the BSR address included, the message is dropped. Else 2 If the included BSR is not preferred over, and not equal to, the currently active BSR: 1 If the Bootstrap-timer has not yet expired, or if the receiving router is a C-BSR, then the Bootstrap message is dropped. Else 2 If the Bootstrap-timer has expired and the receiving router is not a C-BSR, the receiving router stores the RP- Set and BSR address and priority found in the message, and restarts the timer by setting it to [Bootstrap-Timeout]. The Bootstrap message is then forwarded out all PIM interfaces, excluding the one over which the message arrived, to `ALL-PIM-ROUTERS' group, with a TTL of 1. 3 If the Bootstrap message includes a BSR address that is preferred over, or equal to, the currently active BSR, the router restarts its Bootstrap-timer at [Bootstrap-Timeout] seconds. and stores the BSR address and RP-Set information. The Bootstrap message is then forwarded out all PIM interfaces, excluding the one over which the message arrived, to `ALL-PIM- ROUTERS' group, with a TTL of 1. Estrin, et. al. Experimental [Page 32] Internet Draft PIM-SM Oct 1999 4 If the receiving router has no current RP set information and the Bootstrap was unicast to it from a directly connected neighbor, the router stores the information as its new RP-set. This covers the startup condition when a newly booted router obtains the RP-Set and BSR address from its DR. When a router receives a new RP-Set, it checks if each of the RPs referred to by existing state (i.e., by (*,G), (*,*,RP), or (S,G)RPT-bit entries) is in the new RP-Set. If an RP is not in the new RP-set, that RP is considered unreachable and the hash algorithm (see below) is re-performed for each group with locally active state that previously hashed to that RP. This will cause those groups to be distributed among the remaining RPs. When the new RP-Set contains a new RP, the value of the new RP is calculated for each group covered by that C-RP's Group-prefix. Any group for which the new RP's value is greater than the previously active RP's value is switched over to the new RP. 3.7 Hash Function The hash function is used by all routers within a domain, to map a group to one of the C-RPs from the RP-Set. For a particular group, G, the hash function uses only those C-RPs whose Group-prefix covers G. The algorithm takes as input the group address, and the addresses of the Candidate RPs, and gives as output one RP address to be used. The protocol requires that all routers hash to the same RP within a domain (except for transients). The following hash function must be used in each router: 1 For RP addresses in the RP-Set, whose Group-prefix is the longest that covers G, select the RPs with the highest priority (i.e. lowest `Priority' value), and compute a value: Value(G,M,C(i))= (1103515245 * ((1103515245 * (G&M)+12345) XOR C(i)) + 12345) mod 2^31 where C_i is the RP address and M is a hash-mask included in Bootstrap messages. The hash-mask allows a small number of consecutive groups (e.g., 4) to always hash to the same RP. For instance, hierarchically-encoded data can be sent on consecutive group addresses to get the same delay and fate-sharing characteristics. For address families other than IPv4, a 32-bit digest to be used as C_i must first be derived from the actual RP address. Such a digest method must be used consistently throughout the PIM Estrin, et. al. Experimental [Page 33] Internet Draft PIM-SM Oct 1999 domain. For IPv6 addresses, we recommend using the equivalent IPv4 address for an IPv4-compatible address, and the CRC-32 checksum [7] of all other IPv6 addresses. 2 From the RPs with the highest priority (i.e. lowest `Priority' value), the candidate with the highest resulting value is then chosen as the RP for that group, and its identity and hash value are stored with the entry created. Ties between RPs having the same hash value and priority, are broken in advantage of the highest address. The hash function algorithm is invoked by a DR, upon reception of a packet, or IGMP membership indication, for a group, for which the DR has no entry. It is invoked by any router that has (*,*,RP) state when a packet is received for which there is no corresponding (S,G) or (*,G) entry. Furthermore, the hash function is invoked by all routers upon receiving a (*,G) or (*,*,RP) Join/Prune message. 3.8 Processing Timer Events In this subsection, we enumerate all timers that have been discussed or implied. Since some critical timer events are not associated with the receipt or sending of messages, they are not fully covered by earlier subsections. Timers are implemented in an implementation-specific manner. For example, a timer may count up or down, or may simply expire at a specific time. Setting a timer to a value T means that it will expire after T seconds. 3.8.1 Timers related to tree maintenance Each (S,G), (*,G), and (*,*,RP) route entry has multiple timers associated with it: one for each interface in the outgoing interface list, one for the multicast routing entry itself, and one optional Join/Prune-Suppression-Timer. Each (S,G) and (*,G) entry also has an Assert-timer and a Random-Delay-Join-Timer for use with Asserts. In addition, DR's have a Register-Suppression-timer for each (S,G) entry and every router has a single Join/Prune-timer. (A router may optionally keep separate Join/Prune-timers for different interfaces or route entries if different Join/Prune periods are desired.) * [Join/Prune-Timer] This timer is used for periodically sending aggregate Join/Prune messages. To avoid synchronization among routers booting simultaneously, it is initially set to a random value between 1 and [Join/Prune- Period]. When it expires, the timer is immediately restarted Estrin, et. al. Experimental [Page 34] Internet Draft PIM-SM Oct 1999 to [Join/Prune-Period]. A Join/Prune message is then sent out each interface. This timer should not be restarted by other events. * [Join/Prune-Suppression-Timer (kept per route entry)] A route entry's (optional) Join/Prune-Suppression-Timer may be used to suppress duplicate joins from multiple downstream routers on the same LAN. When a Join message is received from a neighbor on the entry's incoming interface in which the included Holdtime is higher than the router's own [Join/Prune-Holdtime] (with ties broken by higher network layer address), the timer is set to [Join/Prune-Suppression- Timeout], with some random jitter introduced to avoid synchronization of triggered Join/Prune messages on expiration. (The random timeout value must be < 1.5 * [Join/Prune-Period] to prevent losing data after 2 dropped Join/Prunes.) The timer is restarted every time a subsequent Join/Prune message (with higher Holdtime/IP address) for the entry is received on its incoming interface. While the timer is running, Join/Prune messages for the entry are not sent. This timer is idle (not running) for point-to-point links. * [Oif-Timer (kept per oif for each route entry)] A timer for each oif of a route entry is used to time out that oif. Because some of the outgoing interfaces in an (S,G) entry are copied from the (*,G) outgoing interface list, they may not have explicit (S,G) join messages from some of the downstream routers (i.e., where members are joining to the (*,G) tree only). Thus, when an Oif-timer is restarted in a (*,G) entry, the Oif-timer is restarted for that interface in each existing (S,G) entry whose oif list contains that interface. The same rule applies to (*,G) and (S,G) entries when restarting an Oif-timer on a (*,*,RP) entry. The following table shows its usage when first adding the oif to the entry's oiflist, when it should be restarted (unless it is already higher), and when it should be decreased (unless it is already lower). Set to | When | Applies to included Holdtime | adding oif off Join/Prune | (S,G) (*,G) | | (*,*,RP) Increased (only) to | When | Applies to included Holdtime | received Join/Prune | (S,G) (*,G) | | (*,*,RP) (*,*,RP) oif-timer value | (*,*,RP) oif-timer restarted | (S,G) (*,G) (*,G) oif-timer value | (*,G) oif-timer restarted | (S,G) Estrin, et. al. Experimental [Page 35] Internet Draft PIM-SM Oct 1999 When the timer expires, the oif is removed from the oiflist if there are no directly-connected members. When deleted, the oif is also removed in any associated (S,G) or (*,G) entries. * [Entry-Timer (kept per route entry)] A timer for each route entry is used to time out that entry. The following table summarizes its usage when first adding the oif to the entry's oiflist, and when it should be restarted (unless it is already higher). Set to | When | Applies to [Data-Timeout] | created off data packet | (S,G) included Holdtime | created off Join/Prune | (S,G) (*,G) (*,*,RP) Increased (only) to | When | Applies to [Data-Timeout] | receiving data packets | (S,G)no RPT-bit oif-timer value | any oif-timer restarted | (S,G)RPT-bit (*,G) | | (*,*,RP) [Assert-Timeout] | assert received | (S,G)RPT-bit (*,G) | | w/null oif When the timer expires, the route entry is deleted; if the entry is a (*,G) or (*,*,RP) entry, all associated (S,G)RPT- bit entries are also deleted. * [Register-Suppression-Timer (kept per (S,G) route entry)] An (S,G) route entry's Register-Suppression-Timer is used to suppress registers when the RP is receiving data packets natively. When a Register-Stop message for the entry is received from the RP, the timer is set to a random value in the range 0.5 * [Register-Suppression-Timeout] to 1.5 * [Register-Suppression-Timeout]. While the timer is running, Registers for that entry will be suppressed. If null registers are used, a null register is sent [Probe-Time] seconds before the timer expires. * [Assert-Timer (per (S,G) or (*,G) route entry)] The Assert-Timer for an (S,G) or (*,G) route entry is used for timing out Asserts received. When an Assert is received and the RPF neighbor is changed to the Assert winner, the Assert- Timer is set to [Assert-Timeout], and is restarted to this value every time a subsequent Assert for the entry is received on its incoming interface. When the timer expires, the router resets its RPF neighbor according to its unicast routing table. Estrin, et. al. Experimental [Page 36] Internet Draft PIM-SM Oct 1999 * [Random-Delay-Join-Timer (per (S,G) or (*,G) route entry)] The Random-Delay-Join-Timer for an (S,G) or (*,G) route entry is used to prevent synchronization among downstream routers on a LAN when their RPF neighbor changes. When the RPF neighbor changes, this timer is set to a random value between 0 and [Random-Delay-Join-Timeout] seconds. When the timer expires, a triggered Join/Prune message is sent for the entry unless its Join/Prune-Suppression-Timer is running. 3.8.2 Timers relating to neighbor discovery * [Hello-Timer] This timer is used to periodically send Hello messages. To avoid synchronization among routers booting simultaneously, it is initially set to a random value between 1 and [Hello-Period]. When it expires, the timer is immediately restarted to [Hello-Period]. A Hello message is then sent out each interface. This timer should not be restarted by other events. * [Neighbor-Timer (kept per neighbor)] A Neighbor-Timer for each neighbor is used to time out the neighbor state. When a Hello message is received from a new neighbor, the timer is initially set to the Holdtime included in the Hello message (which is equal to the neighbor's value of [Hello-Holdtime]). Every time a subsequent Hello is received from that neighbor, the timer is restarted to the Holdtime in the Hello. When the timer expires, the neighbor state is removed. 3.8.3 Timers relating to RP information * [C-RP-Adv-Timer (C-RP's only)] Routers configured as candidate RP's use this timer to periodically send C-RP-Adv messages. To avoid synchronization among routers booting simultaneously, the timer is initially set to a random value between 1 and [C-RP-Adv-Period]. When it expires, the timer is immediately restarted to [C-RP-Adv-Period]. A C-RP-Adv message is then sent to the elected BSR. This timer should not be restarted by other events. * [RP-Timer (BSR only, kept per RP in RP-Set)] The BSR uses a timer per RP in the RP-Set to monitor liveness. When a C-RP is added to the RP-Set, its timer is set to the Holdtime included in the C-RP-Adv message from that C-RP (which is equal to the C-RP's value of [RP-Holdtime]). Every time a subsequent C-RP- Adv is received from that RP, its timer is restarted to the Holdtime in the C-RP-Adv. When the timer expires, the RP is removed from the RP-Set included in Bootstrap messages. Estrin, et. al. Experimental [Page 37] Internet Draft PIM-SM Oct 1999 * [Bootstrap-Timer] This timer is used by the BSR to periodically originate Bootstrap messages, and by other routers to time out the BSR (see 3.6.3). This timer is initially set to [Bootstrap-Timeout]. A C-BSR restarts this timer to [Bootstrap-Timeout] upon receiving a Bootstrap message from a preferred router, and originates a Bootstrap message and restarts the timer to [Bootstrap-Period] when it expires. Routers not configured as C-BSR's restart this timer to [Bootstrap-Timeout] upon receiving a Bootstrap message from the elected or a more preferred BSR, and ignore Bootstrap messages from non-preferred C-BSRs while it is running. 3.8.4 Default timer values Most of the default timeout values for state information are 3.5 times the refresh period. For example, Hellos refresh Neighbor state and the default Hello-timer period is 30 seconds, so a default Neighbor-timer duration of 105 seconds is included in the Holdtime field of the Hellos. In order to improve convergence, however, the default timeout value for information related to RP liveness and Bootstrap messages is 2.5 times the refresh period. In this version of the spec, we suggest particular numerical timer settings. A future version of the specification will specify a mechanism for timer values to be scaled based upon observed network parameters. * [Join/Prune-Period] This is the interval between sending Join/Prune messages. Default: 60 seconds. This value may be set to take into account such things as the configured bandwidth and expected average number of multicast route entries for the attached network or link (e.g., the period would be longer for lower-speed links, or for routers in the center of the network that expect to have a larger number of entries). In addition, a router could modify this value (and corresponding Join/Prune-Holdtime value) if the number of route entries changes significantly (e.g., by an order of magnitude). For example, given a default minimum Join/Prune- Period value, if the number of route entries with a particular iif increases from N to N*100, the router could increase its Join/Prune-Period (and Join/Prune-Holdtime), for that interface, by a factor of 10; and if/when the number of entries decreases back to N, the Join/Prune-Period (and Join/Prune-Holdtime) could be decreased to its previous value. If the Join/Prune-Period is modified, these changes should be made relatively infrequently and the router should continue to refresh at its previous Join/Prune-Period for at least Join/Prune-Holdtime, in order to allow the upstream router to Estrin, et. al. Experimental [Page 38] Internet Draft PIM-SM Oct 1999 adapt. * [Join-Prune Holdtime] This is the Holdtime specified in Join/Prune messages, and is used to time out oifs. This should be set to 3.5 * [Join/Prune-Period]. Default: 210 seconds. * [Join/Prune-Suppression-Timeout] This is the mean interval between receiving a Join/Prune with a higher Holdtime (with ties broken by higher network layer address) and allowing duplicate Join/Prunes to be sent again. This should be set to approximately 1.25 * [Join/Prune-Period]. Default: 75 seconds. * [Data-Timeout] This is the time after which (S,G) state for a silent source will be deleted. Default: 210 seconds. * [Register-Suppression-Timeout] This is the mean interval between receiving a Register-Stop and allowing Registers to be sent again. A lower value means more frequent register bursts at RP, while a higher value means longer join latency for new receivers. Default: 60 seconds. (Note that if null Registers are sent [Probe-Time] seconds before the timeout, register bursts are prevents, and [Register- Suppression-Timeout] may be lowered to decrease join latency.) * [Probe-Time] When null Registers are used, this is the time between sending a null Register and the Register- Suppression-Timer expiring unless it is restarted by receiving a Register-Stop. Thus, a null Register would be sent when the Register-Suppression-Timer reaches this value. Default: 5 seconds. * [Assert-Timeout] This is the interval between the last time an Assert is received, and the time at which the assert is timed out. Default: 180 seconds. * [Random-Delay-Join-Timeout] This is the maximum interval between the time when the RPF neighbor changes, and the time at which a triggered Join/Prune message is sent. Default: 4.5 seconds. * [Hello-Period] This is the interval between sending Hello messages. Default: 30 seconds. * [Hello-Holdtime] This is the Holdtime specified in Hello messages, after which neighbors will time out their neighbor entries for the router. This should be set to 3.5 * [Hello-Period]. Default: 105 seconds. Estrin, et. al. Experimental [Page 39] Internet Draft PIM-SM Oct 1999 * [C-RP-Adv-Period] For C-RPs, this is the interval between sending C-RP-Adv messages. Default: 60 seconds. * [RP-Holdtime] For C-RPs, this is the Holdtime specified in C-RP-Adv messages, and is used by the BSR to time out RPs. This should be set to 2.5 * [C-RP-Adv-Period]. Default: 150 seconds. * [Bootstrap-Period] At the elected BSR, this is the interval between originating Bootstrap messages, and should be equal to 60 seconds. * [Bootstrap-Timeout] This is the time after which the elected BSR will be assumed unreachable when Bootstrap messages are not received from it. This should be set to `2 * [Bootstrap-Period] + 10'. Default: 130 seconds. 3.9 Summary of flags used Following is a summary of all the flags used in our scheme. Bit | Used in | Definition Border | Register | Register for external sources is coming from PIM multicast border router Null | Register | Register sent as Probe of RP, the encapsulated IP data packet should not be forwarded RPT | Route entry | Entry represents state on the RP-tree RPT | Join/Prune | Join is associated with the shared tree and therefore the Join/Prune message is propagated along the RP-tree (source encoded is an RP address) RPT | Assert | The data packet was routed down the shared tree; thus, the path indicated corresponds to the RP tree SPT | (S,G) entry | Packets have arrived on the iif towards S, and the iif is different from the (*,G) iif WC |Join | The receiver expects to receive packets from all sources via this (shared tree) path. Thus, the Join/Prune applies to a (*,G) entry WC | Route entry | Wildcard entry; if there is no more specific match for a particular source, packets will be forwarded according to this entry Estrin, et. al. Experimental [Page 40] Internet Draft PIM-SM Oct 1999 4 Packet Formats This section describes the details of the packet formats for PIM control messages. All PIM control messages have protocol number 103. Basically, PIM messages are either unicast (e.g. Registers and Register-Stop), or multicast hop-by-hop to `ALL-PIM-ROUTERS' group `224.0.0.13' (e.g. Join/Prune, Asserts, etc.). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type | Reserved | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PIM Ver PIM Version number is 2. Type Types for specific PIM messages. PIM Types are: 0 = Hello 1 = Register 2 = Register-Stop 3 = Join/Prune 4 = Bootstrap 5 = Assert 6 = Graft (used in PIM-DM only) 7 = Graft-Ack (used in PIM-DM only) 8 = Candidate-RP-Advertisement Reserved set to zero. Ignored upon receipt. Checksum The checksum is the 16-bit one's complement of the one's complement sum of the entire PIM message, (excluding the data portion in the Register message). For computing the checksum, the checksum field is zeroed. Estrin, et. al. Experimental [Page 41] Internet Draft PIM-SM Oct 1999 4.1 Encoded Source and Group Address formats 1 Encoded-Unicast-address: Takes the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Family | Encoding Type | Unicast Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++++++ Addr Family The address family of the `Unicast Address' field of this address. Here is the address family numbers assigned by IANA: Number Description -------- --------------------------------------------------------- 0 Reserved 1 IP (IP version 4) 2 IP6 (IP version 6) 3 NSAP 4 HDLC (8-bit multidrop) 5 BBN 1822 6 802 (includes all 802 media plus Ethernet "canonical format") 7 E.163 8 E.164 (SMDS, Frame Relay, ATM) 9 F.69 (Telex) 10 X.121 (X.25, Frame Relay) 11 IPX 12 Appletalk 13 Decnet IV 14 Banyan Vines 15 E.164 with NSAP format subaddress Encoding Type The type of encoding used within a specific Address Family. The value `0' is reserved for this field, and represents the native encoding of the Address Family. Unicast Address The unicast address as represented by the given Address Family and Encoding Type. Estrin, et. al. Experimental [Page 42] Internet Draft PIM-SM Oct 1999 2 Encoded-Group-Address: Takes the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Family | Encoding Type | Reserved | Mask Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group multicast Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Addr Family described above. Encoding Type described above. Reserved Transmitted as zero. Ignored upon receipt. Mask Len The Mask length is 8 bits. The value is the number of contiguous bits left justified used as a mask which describes the address. It is less than or equal to the address length in bits for the given Address Family and Encoding Type. If the message is sent for a single group then the Mask length must equal the address length in bits for the given Address Family and Encoding Type. (e.g. 32 for IPv4 native encoding and 128 for IPv6 native encoding). Group multicast Address contains the group address. 3 Encoded-Source-Address: Takes the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Family | Encoding Type | Rsrvd |S|W|R| Mask Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Addr Family described above. Encoding Type described above. Estrin, et. al. Experimental [Page 43] Internet Draft PIM-SM Oct 1999 Reserved Transmitted as zero, ignored on receipt. S,W,R See Section 4.5 for details. Mask Length Mask length is 8 bits. The value is the number of contiguous bits left justified used as a mask which describes the address. The mask length must be less than or equal to the address length in bits for the given Address Family and Encoding Type. If the message is sent for a single group then the Mask length must equal the address length in bits for the given Address Family and Encoding Type. In version 2 of PIM, it is strongly recommended that this field be set to 32 for IPv4 native encoding. Source Address The source address. 4.2 Hello Message It is sent periodically by routers on all interfaces. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type | Reserved | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OptionType | OptionLength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OptionValue | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++ | . | | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OptionType | OptionLength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OptionValue | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++ PIM Version, Type, Reserved, Checksum Described above. Estrin, et. al. Experimental [Page 44] Internet Draft PIM-SM Oct 1999 OptionType The type of the option given in the following OptionValue field. OptionLength The length of the OptionValue field in bytes. OptionValue A variable length field, carrying the value of the option. The Option fields may contain the following values: * OptionType = 1; OptionLength = 2; OptionValue = Holdtime; where Holdtime is the amount of time a receiver must keep the neighbor reachable, in seconds. If the Holdtime is set to `0xffff', the receiver of this message never times out the neighbor. This may be used with ISDN lines, to avoid keeping the link up with periodic Hello messages. Furthermore, if the Holdtime is set to `0', the information is timed out immediately. * OptionType 2 to 16: reserved * OptionType = 18; OptionLength = 4; OptionValue = DR Priority; where DR Priority is a 32-bit unsigned number and SHOULD be treated as the higher order bits of the address during DR election. * OptionType = 19; OptionLength = 0; Bidirectional PIM capable * OptionType = 20; OptionLength = 4; OptionValue = Generation ID; where Generation ID is a random 32-bit value generated upon router startup. * OptionType = 21; OptionLength = 4; OptionValue = 1; This is the State Refresh capable option for dense mode. * The rest of the OptionTypes are defined in another document. In general, options may be ignored; but a router must not ignore the 'Holdtime' OptionType. 4.3 Register Message A Register message is sent by the DR or a PMBR to the RP when a multicast packet needs to be transmitted on the RP-tree. Source address is set to the address of the DR, destination address is to the RP's address. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type | Reserved | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |B|N| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Multicast data packet | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Estrin, et. al. Experimental [Page 45] Internet Draft PIM-SM Oct 1999 PIM Version, Type, Reserved, Checksum Described above. Note that the checksum for Registers is done only on first 8 bytes of packet, including the PIM header and the next 4 bytes, excluding the data packet portion. For interoperability reasons, a message carrying checksum done over the entire PIM register message SHOULD be accepted. B The Border bit. If the router is a DR for a source that it is directly connected to, it sets the B bit to 0. If the router is a PMBR for a source in a directly connected cloud, it sets the B bit to 1. N The Null-Register bit. Set to 1 by a DR that is probing the RP before expiring its local Register-Suppression timer. Set to 0 otherwise. Multicast data packet The original packet sent by the source. For (S,G) null Registers, the Multicast data packet portion contains only a dummy header with S as the source address, G as the destination address, and a data length of zero. 4.4 Register-Stop Message A Register-Stop is unicast from the RP to the sender of the Register message. Source address is the address to which the register was addressed. Destination address is the source address of the register message. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type | Reserved | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Group Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Unicast-Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PIM Version, Type, Reserved, Checksum Described above. Encoded-Group Address Format described above. Note that for Register-Stops the Mask Len field contains full address length * 8 (e.g. 32 for IPv4 native encoding), if the message is sent for a single group. Estrin, et. al. Experimental [Page 46] Internet Draft PIM-SM Oct 1999 Encoded-Unicast-Source Address host address of source from multicast data packet in register. The format for this address is given in the Encoded-Unicast-Address in 4.1. A special wild card value (0's), can be used to indicate any source. 4.5 Join/Prune Message A Join/Prune message is sent by routers towards upstream sources and RPs. Joins are sent to build shared trees (RP trees) or source trees (SPT). Prunes are sent to prune source trees when members leave groups as well as sources that do not use the shared tree. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type | Reserved | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Unicast-Upstream Neighbor Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Num groups | Holdtime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Multicast Group Address-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Joined Sources | Number of Pruned Sources | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Joined Source Address-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Joined Source Address-n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Pruned Source Address-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Pruned Source Address-n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Multicast Group Address-n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Joined Sources | Number of Pruned Sources | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Estrin, et. al. Experimental [Page 47] Internet Draft PIM-SM Oct 1999 | Encoded-Joined Source Address-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Joined Source Address-n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Pruned Source Address-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Pruned Source Address-n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PIM Version, Type, Reserved, Checksum Described above. Encoded-Unicast Upstream Neighbor Address The address of the RPF or upstream neighbor. The format for this address is given in the Encoded-Unicast-Address in 4.1. .IP "Reserved" Transmitted as zero, ignored on receipt. Holdtime The amount of time a receiver must keep the Join/Prune state alive, in seconds. If the Holdtime is set to `0xffff', the receiver of this message never times out the oif. This may be used with ISDN lines, to avoid keeping the link up with periodical Join/Prune messages. Furthermore, if the Holdtime is set to `0', the information is timed out immediately. Number of Groups The number of multicast group sets contained in the message. Encoded-Multicast group address For format description see Section 4.1. A wild card group in the (*,*,RP) join is represented by a 224.0.0.0 in the group address field and `4' in the mask length field. A (*,*,RP) join also has the WC-bit and the RPT-bit set. Number of Joined Sources Number of join source addresses listed for a given group. Estrin, et. al. Experimental [Page 48] Internet Draft PIM-SM Oct 1999 Join Source Address-1 .. n This list contains the sources that the sending router will forward multicast datagrams for if received on the interface this message is sent on. See format section 4.1. The fields explanation for the Encoded-Source-Address format follows: Reserved Described above. S The Sparse bit is a 1 bit value, set to 1 for PIM-SM. It is used for PIM v.1 compatibility. W The WC bit is a 1 bit value. If 1, the join or prune applies to the (*,G) or (*,*,RP) entry. If 0, the join or prune applies to the (S,G) entry where S is Source Address. Joins and prunes sent towards the RP must have this bit set. R The RPT-bit is a 1 bit value. If 1, the information about (S,G) is sent towards the RP. If 0, the information must be sent toward S, where S is the Source Address. Mask Length, Source Address Described above. Represented in the form of < WC-bit >< RPT-bit >< Source address>: A source address could be a host IPv4 native encoding address : < 0 >< 0 >< 32 >< 192.1.1.17 > A source address could be the RP's IP address : < 1 >< 1 >< 32 >< 131.108.13.111 > A source address could be a subnet address to prune from the RP-tree : < 0 >< 1 >< 28 >< 192.1.1.16 > A source address could be a general aggregate : < 0 >< 0 >< 16 >< 192.1.0.0 > Estrin, et. al. Experimental [Page 49] Internet Draft PIM-SM Oct 1999 Number of Pruned Sources Number of prune source addresses listed for a group. Prune Source Address-1 .. n This list contains the sources that the sending router does not want to forward multicast datagrams for when received on the interface this message is sent on. If the Join/Prune message boundary exceeds the maximum packet size, then the join and prune lists for the same group must be included in the same packet. 4.6 Bootstrap Message The Bootstrap messages are multicast to `ALL-PIM-ROUTERS' group, out all interfaces having PIM neighbors (excluding the one over which the message was received). Bootstrap messages are sent with TTL value of 1. Bootstrap messages originate at the BSR, and are forwarded by intermediate routers. Bootstrap message is divided up into `semantic fragments', if the original message exceeds the maximum packet size boundaries. The semantics of a single `fragment' is given below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type | Reserved | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fragment Tag | Hash Mask len | BSR-priority | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Unicast-BSR-Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Group Address-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP-Count-1 | Frag RP-Cnt-1 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Unicast-RP-Address-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP1-Holdtime | RP1-Priority | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Unicast-RP-Address-2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP2-Holdtime | RP2-Priority | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Estrin, et. al. Experimental [Page 50] Internet Draft PIM-SM Oct 1999 | Encoded-Unicast-RP-Address-m | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RPm-Holdtime | RPm-Priority | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Group Address-2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Group Address-n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP-Count-n | Frag RP-Cnt-n | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Unicast-RP-Address-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP1-Holdtime | RP1-Priority | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Unicast-RP-Address-2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP2-Holdtime | RP2-Priority | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Unicast-RP-Address-m | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RPm-Holdtime | RPm-Priority | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PIM Version, Type, Reserved, Checksum Described above. Fragment Tag A randomly generated number, acts to distinguish the fragments belonging to different Bootstrap messages; fragments belonging to same Bootstrap message carry the same `Fragment Tag'. Hash Mask len The length (in bits) of the mask to use in the hash function. For IPv4 we recommend a value of 30. For IPv6 we recommend a value of 126. BSR-priority Contains the BSR priority value of the included BSR. This field is considered as a high order byte when comparing BSR addresses. Estrin, et. al. Experimental [Page 51] Internet Draft PIM-SM Oct 1999 Encoded-Unicast-BSR-Address The address of the bootstrap router for the domain. The format for this address is given in the Encoded-Unicast- Address in 4.1. .IP "Encoded-Group Address-1..n" The group prefix (address and mask) with which the Candidate RPs are associated. Format previously described. RP-Count-1..n The number of Candidate RP addresses included in the whole Bootstrap message for the corresponding group prefix. A router does not replace its old RP-Set for a given group prefix until/unless it receives `RP-Count' addresses for that prefix; the addresses could be carried over several fragments. If only part of the RP-Set for a given group prefix was received, the router discards it, without updating that specific group prefix's RP-Set. Frag RP-Cnt-1..m The number of Candidate RP addresses included in this fragment of the Bootstrap message, for the corresponding group prefix. The `Frag RP-Cnt' field facilitates parsing of the RP-Set for a given group prefix, when carried over more than one fragment. Encoded-Unicast-RP-address-1..m The address of the Candidate RPs, for the corresponding group prefix. The format for this address is given in the Encoded-Unicast-Address in 4.1. .IP "RP1..m-Holdtime" The Holdtime for the corresponding RP. This field is copied from the `Holdtime' field of the associated RP stored at the BSR. RP1..m-Priority The `Priority' of the corresponding RP and Encoded-Group Address. This field is copied from the `Priority' field stored at the BSR when receiving a Candidate-RP- Advertisement. The highest priority is `0' (i.e. the lower the value of the `Priority' field, the higher). Note that the priority is per RP per Encoded-Group Address. 4.7 Assert Message The Assert message is sent when a multicast data packet is received on an outgoing interface corresponding to the (S,G) or (*,G) associated with the source. Estrin, et. al. Experimental [Page 52] Internet Draft PIM-SM Oct 1999 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type | Reserved | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Group Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Unicast-Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| Metric Preference | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PIM Version, Type, Reserved, Checksum Described above. Encoded-Group Address The group address to which the data packet was addressed, and which triggered the Assert. Format previously described. Encoded-Unicast-Source Address Source address from multicast datagram that triggered the Assert packet to be sent. The format for this address is given in the Encoded-Unicast-Address in 4.1. .IP "R" RPT-bit is a 1 bit value. If the multicast datagram that triggered the Assert packet is routed down the RP tree, then the RPT-bit is 1; if the multicast datagram is routed down the SPT, it is 0. Metric Preference Preference value assigned to the unicast routing protocol that provided the route to Host address. Metric The unicast routing table metric. The metric is in units applicable to the unicast routing protocol used. 4.8 Graft Message Used in dense-mode. Refer to PIM dense mode specification. 4.9 Graft-Ack Message Used in dense-mode. Refer to PIM dense mode specification. Estrin, et. al. Experimental [Page 53] Internet Draft PIM-SM Oct 1999 4.10 Candidate-RP-Advertisement Candidate-RP-Advertisements are periodically unicast from the C-RPs to the BSR. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type | Reserved | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix-Cnt | Priority | Holdtime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Unicast-RP-Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Group Address-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Group Address-n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PIM Version, Type, Reserved, Checksum Described above. Prefix-Cnt The number of encoded group addresses included in the message; indicating the group prefixes for which the C-RP is advertising. A Prefix-Cnt of `0' implies a prefix of 224.0.0.0 with mask length of 4; i.e. all multicast groups. If the C-RP is not configured with Group-prefix information, the C-RP puts a default value of `0' in this field. Priority The `Priority' of the included RP, for the corresponding Encoded-Group Address (if any). highest priority is `0' (i.e. the lower the value of the `Priority' field, the higher the priority). This field is stored at the BSR upon receipt along with the RP address and corresponding Encoded-Group Address. Holdtime The amount of time the advertisement is valid. This field allows advertisements to be aged out. Estrin, et. al. Experimental [Page 54] Internet Draft PIM-SM Oct 1999 Encoded-Unicast-RP-Address The address of the interface to advertise as a Candidate RP. The format for this address is given in the Encoded- Unicast-Address in 4.1. .IP "Encoded-Group Address-1..n" The group prefixes for which the C-RP is advertising. Format previously described. 5 Security Considerations All PIM control messages MAY use IPsec \cite{IPsec} to address security concerns. The authentication methods are addressed in a companion document[9]. 6 Acknowledgments Tony Ballardie, Scott Brim, Jon Crowcroft, Bill Fenner, Paul Francis, Joel Halpern, Horst Hodel, Polly Huang, Stephen Ostrowski, Lixia Zhang, Girish Chandranmenon, Rob Coltun and many members of the PIM WG provided detailed comments on previous drafts. The authors of CBT [8] and membership of the IDMR WG provided many of the motivating ideas for this work and useful feedback on design details. This work was supported by the National Science Foundation, ARPA, cisco Systems and Sun Microsystems. Estrin, et. al. Experimental [Page 55] Internet Draft PIM-SM Oct 1999 7 Appendices 7.1 Appendix I: Major Changes and Updates to the Spec This appendix populates the major changes in the specification document as compared to RFC2362. 7.1.1 Major Changes 1 DR priority election option for Hello message; 2 Security Considerations section 3 Hello Geneneration Identifier (GenID) option 4 Section 3.2.1.2.3 (in Triggered Join/Prune messages:). Clarification on triggered (*,G) join need to be accompanied by (S,G)RPT-bit prunes. 7.1.2 Packet Format Changes Packet format now includes Hello DR priority election option and Generation Identifier (GenID) option. Estrin, et. al. Experimental [Page 56] Internet Draft PIM-SM Oct 1999 7.2 Appendix II: BSR Election and RP-Set Distribution For simplicity, the bootstrap message is used in both the BSR election and the RP-Set distribution mechanisms. These mechanisms are described by the following state machine, illustrated in figure 4. The protocol transitions for a Candidate-BSR are given in state diagram (a). For routers not configured as Candidate-BSRs, the protocol transitions are given in state diagram (b). PrefBSMRxd;FwdBSM, [1][2][3] TExp;OrigBSM,[4] / \ / \ | | _______________________ | | | \|/ / \ | \|/ ---------- / \ --------------- |CandBSR |--- -->| Elected BSR | | |<--\ ___| | ---------- \__________________________/ --------------- Initial state: CandBSR; LclBSR = Local address, LclRP-Set = empty (a) State transition diagram for a candidate BSR PrefBSMRxd; FwdBSM,[1][2][3] / \ TExp | | /-----------------------\ | \|/ ----------- / \ ----------- | AxptAny |--- --->| AxpPref | | |<---\ _____| | ----------- \______________________/ ----------- BSMRxd;FwdBSM,[1][2][3] Initial state: AxptAny; LclBSR = 0, LclRP-Set = empty (b) State transition diagram for a router not configured as C-BSR State Variables LclBSR = Local concatenated BSR priority and BSR IP address LclRP-Set = Local RP-Set RxdBSR = Received concatenated BSR priority and BSR IP address RxdRP-Set = Received RP-Set Bootstrap-Period = 60 seconds Bootstrap-Timeout = 2.5 x Bootstrap-Period = 150 seconds Predicates Name Meaning -------------------------------------------- P RxdBSR >= LclBSR Incoming Events Name Interface Meaning ------------------------------------------------------------- PrefBSMRxd RPF nbr toward Bootstrap msg rcvd satisfying P included BSR BSMRxd RPF nbr toward Bootstrap message received included BSR TExp Timer provider Bootstrap timer expired machinery States Name Meaning ---------------------------------------------------------------------- AxptPref Accept only Bootstrap messages from preferred or equal BSR AxptAny Accept any RP-Set messages coming thru the right interface CandBSR Candidate bootstrap router ElectedBSR Elected bootstrap router Outgoing events Name Interface Meaning ------------------------------------------------------------- FwdBSM All interfaces except Forward Bootstrap message receiving interface OrigBSM All interfaces Originate Bootstrap message Specific actions [1] = Restart Bootstrap timer at Bootstrap-Timeout [2] = (LclBSR = RxdBSR) [3] = (LclRP-Set = RxdRP-Set) [4] = Restart Bootstrap timer at Bootstrap-Period Fig. 4 State Diagram for the BSR election and RP-Set distribution Each PIM router keeps a bootstrap-timer, initialized to [Bootstrap- Timeout], in addition to a local BSR field `LclBSR' (initialized to a local address if Candidate-BSR, or to 0 otherwise), and a local RP- Set `LclRP-Set' (initially empty). The main stimuli to the state machine are timer events and arrival of bootstrap messages: Initial States and Timer Events 1 If the router is a Candidate-BSR: 1 2 The router operates initially in the `CandBSR' state, where it does not originate any bootstrap messages. 3 If the bootstrap-timer expires, and the current state is `CandBSR', the router originates a bootstrap message carrying the local RP-Set and its own BSR priority and address, restarts the bootstrap-timer at [Bootstrap-Period] seconds, and transits into the `ElectedBSR' state. Note that the actual sending of the bootstrap message may be delayed by a random value to reduce transient control overhead. To obtain best results, the random value is set such that the preferred BSR is the first to originate a bootstrap message. We propose the following as an efficient implementation of the random value delay (in seconds): Delay = 5 + 2 * log_2(1 + bestPriority - myPriority) + AddrDelay where myPriority is the Candidate-BSR's configured priority, and bestPriority equals: bestPriority = Max(storedPriority, myPriority) ] Estrin, et. al. Experimental [Page 57] Internet Draft PIM-SM Oct 1999 and AddrDelay is given by the following: 1 if ( bestPriority equals myPriority) then [AddrDelay = log_2(bestAddr - myAddr) / 16, ] 2 else [AddrDelay = 2 - (myAddr / 2^31) ] where myAddr is the Candidate-BSR's address, and bestAddr is the stored BSR's address. 4 If the bootstrap-timer expires, and the current state is `ElectedBSR', the router originates a bootstrap message, and restarts the RP-Set timer at [Bootstrap- Period]. No state transition is incurred. This way, the elected BSR originates periodic bootstrap messages every [Bootstrap-Period]. 2 If a router is not a Candidate-BSR: 1 2 The router operates initially in the `AxptAny' state. In such state, a router accepts the first bootstrap message from the The Reverse Path Forwarding (RPF) neighbor toward the included BSR. The RPF neighbor in this case is the next hop router en route to the included BSR. 3 If the bootstrap-timer expires, and the current state is `AxptPref'-- where the router accepts only preferred bootstrap messages (those that carry BSR- priority and address higher than, or equal to, `LclBSR') from the RPF neighbor toward the included BSR-- the router transits into the `AxptAny' state. In this case, if an elected BSR becomes unreachable, the routers start accepting bootstrap messages from another Candidate-BSR after the bootstrap-timer expires. All PIM routers within a domain converge on the preferred reachable Candidate-BSR. Estrin, et. al. Experimental [Page 58] Internet Draft PIM-SM Oct 1999 Receiving Bootstrap Message: To avoid loops, an RPF check is performed on the included BSR address. Upon receiving a bootstrap message from the RPF neighbor toward the included BSR, the following actions are taken: 1 If the router is not a Candidate-BSR: 1 If the current state is `AxptAny', the router accepts the bootstrap message, and transits into the `AxptPref' state. 2 If the current state is `AxptPref', and the bootstrap message is preferred, the message is accepted. No state transition is incurred. 2 If the router is a Candidate-BSR, and the bootstrap message is preferred, the message is accepted. Further, if this happens when the current state is `Elected BSR', the router transits into the `CandBSR' state. When a bootstrap message is accepted, the router restarts the bootstrap-timer at [Bootstrap-Timeout], stores the received BSR priority and address in `LclBSR', and the received RP-Set in `LclRP-Set', and forwards the bootstrap message out all interfaces except the receiving interface. If a bootstrap message is rejected, no state transitions are triggered. Estrin, et. al. Experimental [Page 59] Internet Draft PIM-SM Oct 1999 7.3 Appendix III: Glossary of Terms Following is an alphabetized list of terms and definitions used throughout this specification. * { Bootstrap router (BSR)}. A BSR is a dynamically elected router within a PIM domain. It is responsible for constructing the RP-Set and originating Bootstrap messages. * { Candidate-BSR (C-BSR)}. A C-BSR is a router configured to participate in the BSR election and act as BSRs if elected. * { Candidate RP (C-RP)}. A C-RP is a router configured to send periodic Candidate-RP-Advertisement messages to the BSR, and act as an RP when it receives Join/Prune or Register messages for the advertised group prefix. * { Designated Router (DR)}. The DR sets up multicast route entries and sends corresponding Join/Prune and Register messages on behalf of directly-connected receivers and sources, respectively. The DR may or may not be the same router as the IGMP Querier. The DR may or may not be the long-term, last-hop router for the group; a router on the LAN that has a lower metric route to the data source, or to the group's RP, may take over the role of sending Join/Prune messages. * { Incoming interface (iif)}. The iif of a multicast route entry indicates the interface from which multicast data packets are accepted for forwarding. The iif is initialized when the entry is created. * Join list. The Join list is one of two lists of addresses that is included in a Join/Prune message; each address refers to a source or RP. It indicates those sources or RPs to which downstream receiver(s) wish to join. * { Last-hop router}. The last-hop router is the last router to receive multicast data packets before they are delivered to directly-connected member hosts. In general the last-hop router is the DR for the LAN. However, under various conditions described in this document a parallel router connected to the same LAN may take over as the last-hop router in place of the DR. * { Outgoing interface (oif) list}. Each multicast route entry has an oif list containing the outgoing interfaces to which multicast packets should be forwarded. Estrin, et. al. Experimental [Page 60] Internet Draft PIM-SM Oct 1999 * Prune List. The Prune list is the second list of addresses that is included in a Join/Prune message. It indicates those sources or RPs from which downstream receiver(s) wish to prune. * { PIM Multicast Border Router (PMBR)}. A PMBR connects a PIM domain to other multicast routing domain(s). * { Rendezvous Point (RP)}. Each multicast group has a shared-tree via which receivers hear of new sources and new receivers hear of all sources. The RP is the root of this per-group shared tree, called the RP-Tree. * { RP-Set}. The RP-Set is a set of RP addresses constructed by the BSR based on Candidate-RP advertisements received. The RP-Set information is distributed to all PIM routers in the BSR's PIM domain. * { Reverse Path Forwarding (RPF)}. RPF is used to select the appropriate incoming interface for a multicast route entry . The RPF neighbor for an address X is the the next-hop router used to forward packets toward X. The RPF interface is the interface to that RPF neighbor. In the common case this is the next hop used by the unicast routing protocol for sending unicast packets toward X. For example, in cases where unicast and multicast routes are not congruent, it can be different. * { Route entry.} A multicast route entry is state maintained in a router along the distribution tree and is created, and updated based on incoming control messages. The route entry may be different from the forwarding entry; the latter is used to forward data packets in real time. Typically a forwarding entry is not created until data packets arrive, the forwarding entry's iif and oif list are copied from the route entry, and the forwarding entry may be flushed and recreated at will. * { Shortest path tree (SPT)}. The SPT is the multicast distribution tree created by the merger of all of the shortest paths that connect receivers to the source (as determined by unicast routing). * { Sparse Mode (SM)}. SM is one mode of operation of a multicast protocol. PIM SM uses explicit Join/Prune messages and Rendezvous points in place of Dense Mode PIM's and DVMRP's broadcast and prune mechanism. Estrin, et. al. Experimental [Page 61] Internet Draft PIM-SM Oct 1999 * { Wildcard (WC) multicast route entry}. Wildcard multicast route entries are those entries that may be used to forward packets for any source sending to the specified group. Wildcard bots in the join list of a Join/Prune message represent either a (*,G) or (*,*,RP) join; in the prune list they represent a (*,G) prune. * { (S,G) route entry}. (S,G) is a source-specific route entry. It may be created in response to data packets, Join/Prune messages, or Asserts. The (S,G) state in routers creates a source-rooted, shortest path (or reverse shortest path) distribution tree. (S,G)RPT bit entries are source- specific entries on the shared RP-Tree; these entries are used to prune particular sources off of the shared tree. * { (*,G) route entry}. Group members join the shared RP-Tree for a particular group. This tree is represented by (*,G) multicast route entries along the shortest path branches between the RP and the group members. * { (*,*,RP) route entry}. (*,*,RP) refers to any source and any multicast group that maps to the RP included in the entry. The routers along the shortest path branches between a domain's RP(s) and its PMBRs keep (*,*,RP) state and use it to determine how to deliver packets toward the PMBRs if data packets arrive for which there is not a longer match. The wildcard group in the (*,*,RP) route entry is represented by a group address of 224.0.0.0 and a mask length of 4 bits. References 1. Deering, S., Estrin, D., Farinacci, D., Jacobson, V., Liu, C., Wei, L., Sharma, P., and A. Helmy, "Protocol Independent Multicast (pim): Motivation and Architecture", Work in Progress. 2. S. Deering, D. Estrin, D. Farinacci, V. Jacobson, C. Liu, and L. Wei. The pim architecture for wide-area multicast routing. ACM Transactions on Networks, April 1996. 3. Estrin, D., Farinacci, D., Jacobson, V., Liu, C., Wei, L., Sharma, P., and A. Helmy, "Protocol Independent Multicast-dense Mode (pim- dm): Protocol Specification", Work in Progress. 4. Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989. 5. Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997. Estrin, et. al. Experimental [Page 62] Internet Draft PIM-SM Oct 1999 6. Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, August 1995. 7. Mark R. Nelson. File verification using CRC. Dr. Dobb's Journal, May 1992. 8. A.J. Ballardie, P.F. Francis, and J.Crowcroft. Core based trees. In Proceedings of the ACM SIGCOMM, San Francisco, 1993. 9. Wei, L., "Authenticating PIM Version 2 Messages", draft-ietf-pim-v2-auth-01.txt, work in progress. Authors' Addresses NOTE: The author list has been reordered to reflect the involvement in detailed editorial work on this specification document. The first four authors are the primary editors and are listed alphabetically. The rest of the authors, also listed alphabetically, participated in all aspects of the architectural and detailed design but managed to get away without hacking the latex! Deborah Estrin Computer Science Dept/ISI University of Southern Calif. Los Angeles, CA 90089 EMail: estrin@usc.edu Dino Farinacci Cisco Systems Inc. 170 West Tasman Drive, San Jose, CA 95134 EMail: dino@cisco.com Ahmed Helmy Computer Science Dept. University of Southern Calif. Los Angeles, CA 90089 EMail: ahelmy@catarina.usc.edu David Thaler EECS Department University of Michigan Ann Arbor, MI 48109 EMail: thalerd@eecs.umich.edu Estrin, et. al. Experimental [Page 63] Internet Draft PIM-SM Oct 1999 Stephen Deering 170 W Tasman Drive San Jose, 95134 EMail: deering@cisco.com Mark Handley Department of Computer Science University College London Gower Street London, WC1E 6BT UK EMail: m.handley@cs.ucl.ac.uk Van Jacobson 170 W Tasman Drive San Jose, CA 95134 EMail: van@cisco.com Ching-gung Liu Computer Science Dept. University of Southern Calif. Los Angeles, CA 90089 EMail: charley@catarina.usc.edu Puneet Sharma Computer Science Dept. University of Southern Calif. Los Angeles, CA 90089 EMail: puneet@catarina.usc.edu Liming Wei Siara Systems, Inc. 300 Ferguson Drive Mountain View, CA 94043 EMail: lwei@siara.com Estrin, et. al. Experimental [Page 64] Internet Draft PIM-SM Oct 1999 Full Copyright Statement Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Estrin, et. al. Experimental [Page 65] --------------9CB92B9E03FFFB1066D7ED60-- From owner-pim@catarina.usc.edu Mon Oct 4 18:20:17 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA09585 for ; Mon, 4 Oct 1999 18:20:16 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id PAA24633 for pim-list; Mon, 4 Oct 1999 15:11:29 -0700 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id PAA24629 for ; Mon, 4 Oct 1999 15:11:22 -0700 Received: from agni.iprg.nokia.com (agni.iprg.nokia.com [205.226.8.100]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id PAA04539; Mon, 4 Oct 1999 15:10:50 -0700 (PDT) Received: from agni.iprg.nokia.com (localhost [127.0.0.1]) by agni.iprg.nokia.com (8.8.8/8.6.12) with ESMTP id PAA08789; Mon, 4 Oct 1999 15:10:50 -0700 (PDT) Message-Id: <199910042210.PAA08789@agni.iprg.nokia.com> To: Liming Wei cc: pim@catarina.usc.edu Subject: Re: PIM SM draft submitted. In-reply-to: Your message of "Mon, 04 Oct 1999 11:27:40 PDT." <37F8F19C.F8393E6C@siara.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <8786.939075050.1@agni.iprg.nokia.com> Date: Mon, 04 Oct 1999 15:10:50 -0700 From: Ravi Kiran Puvvala Sender: owner-pim@catarina.usc.edu Precedence: bulk 7.1 Appendix I: Major Changes and Updates to the Spec This section does not include the changes that are related to the definition change for the register checksum. In section 4.3 a register checksum is calculated according to the following statement. This is done only on first 8 bytes of packet, including the PIM header and the next 4 bytes, excluding the data packet portion. For interoperability reasons, a message carrying checksum done over the entire PIM register message SHOULD be accepted. If a PIM router accepts both types of register messages, how does a router pick which checksum type to use when sending register messages to a RP. The RP could be a vendor who only accepts register checksums which includes the multicast data packet. If the purpose of adding the interoperability statement is to comply with these implementations, it does not solve the problem of sending registers to him. I think, we should add the checksum type in the register header, or else it's a hit on the performance to check for both types of checksum for each register packet. Ravi From owner-pim@catarina.usc.edu Mon Oct 4 18:42:31 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA09773 for ; Mon, 4 Oct 1999 18:42:30 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id PAA24795 for pim-list; Mon, 4 Oct 1999 15:34:19 -0700 Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id PAA24791 for ; Mon, 4 Oct 1999 15:34:14 -0700 Received: by ftp.extremenetworks.com with Internet Mail Service (5.5.2448.0) id <36G7QRVR>; Mon, 4 Oct 1999 15:33:43 -0700 Message-ID: From: Desikan Saravanan To: pim@catarina.usc.edu Subject: RE: Processing prunes clarification. Date: Mon, 4 Oct 1999 15:33:35 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pim@catarina.usc.edu Precedence: bulk Ravi: I guess thats my question. How long should the upstream wait to get the join-override before sending its prune up? 1 sec/2sec or something else. Usual way of doing this is to decrease the join timer to Oif-deletion-delay timer and spec specifically specifies that at all other places. Since in this case oif does not exist, should one be created and its deletion-delay be set to 1/3rd the holdtime in the J/P message itself? Des: I guess we should create an oif and start its deletion-delay timer, otherwise it unncessarily creates prune and join traffic upstream. Ravi: The point talks about "clearing" the bit (not setting it). Once its cleared by first join, we need not clear it for second join. But thats not a big deal. More importantly it should not be cleared each time a join is recvd after SPT-bit is set once. Doing that would result in SPTBitClear-To-SPTBitSet switch every join interval (although spec clarifies it not to be like that at other places). But again, its nothing major. Just rewording "until data comes down FOR THE FIRST TIME down the shortest path tree" would also do. Des: I agree with you Ravi. Regards Des From owner-pim@catarina.usc.edu Tue Oct 5 08:18:53 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA27884 for ; Tue, 5 Oct 1999 08:18:52 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id FAA29741 for pim-list; Tue, 5 Oct 1999 05:08:47 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id FAA29737 for ; Tue, 5 Oct 1999 05:08:41 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26181; Tue, 5 Oct 1999 06:53:37 -0400 (EDT) Message-Id: <199910051053.GAA26181@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: pim@catarina.usc.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pim-v2-sm-00.txt Date: Tue, 05 Oct 1999 06:53:36 -0400 Sender: owner-pim@catarina.usc.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Protocol Independent Multicast Working Group of the IETF. Title : Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification Author(s) : L. Wei, D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma Filename : draft-ietf-pim-v2-sm-00.txt Pages : 65 Date : 04-Oct-99 This document describes a protocol for efficiently routing to multicast groups that may span wide-area (and inter-domain) internets. We refer to the approach as Protocol Independent Multicast--Sparse Mode (PIM-SM) because it is not dependent on any particular unicast routing protocol, and because it is designed to support sparse groups as defined in [1][2]. This document describes the protocol details. For the motivation behind the design and a description of the architecture, see [1][2]. Section 2 summarizes PIM-SM operation. It describes the protocol from a network perspective, in particular, how the participating routers interact to create and maintain the multicast distribution tree. Section 3 describes PIM-SM operations from the perspective of a single router implementing the protocol; this section constitutes the main body of the protocol specification. It is organized according to PIM-SM message type; for each message type we describe its contents, its generation, and its processing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pim-v2-sm-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pim-v2-sm-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pim-v2-sm-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991004140751.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pim-v2-sm-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pim-v2-sm-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991004140751.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-pim@catarina.usc.edu Wed Oct 6 00:29:19 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA18395 for ; Wed, 6 Oct 1999 00:29:19 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id VAA05732 for pim-list; Tue, 5 Oct 1999 21:23:37 -0700 Received: from ficon-tech.com ([12.10.198.190]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id VAA05728 for ; Tue, 5 Oct 1999 21:23:24 -0700 Received: from ficon-tech.com (renu.india.ficon-tech.com [172.25.1.111] (may be forged)) by ficon-tech.com (8.8.7/8.8.7) with ESMTP id JAA12084 for ; Wed, 6 Oct 1999 09:49:24 +0530 (IST) (envelope-from ragarwal@ficon-tech.com) Message-ID: <37FACCBE.4D7A71D1@ficon-tech.com> Date: Wed, 06 Oct 1999 09:44:54 +0530 From: Renu Agarwal Organization: Ficon Technology India Pvt Ltd., X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: pim@catarina.usc.edu Subject: New PIM-SM Draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit I am new to this group and therefore are not aware of many things going on this mailing list. Please pardon me if I am sounding too naive. We are planning to implement rfc2362 for PIM-SM mode. Can someone please let me know how this draft is different from the rfc2362? What are the major changes? In case you know of any location which has the changed notes, please let me know. Thanks in advance for your co-operation, Regards Renu ___________________________________________________________ Renu Agarwal E-mail: mailto:ragarwal@ficon-tech.com Ficon Technology Web : http://www.ficon-tech.com ___________________________________________________________ From owner-pim@catarina.usc.edu Wed Oct 6 00:45:38 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA18508 for ; Wed, 6 Oct 1999 00:45:37 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id VAA05815 for pim-list; Tue, 5 Oct 1999 21:40:34 -0700 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id VAA05811 for ; Tue, 5 Oct 1999 21:40:30 -0700 Received: from agni.iprg.nokia.com (agni.iprg.nokia.com [205.226.8.100]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id VAA24537; Tue, 5 Oct 1999 21:39:59 -0700 (PDT) Received: from agni.iprg.nokia.com (localhost [127.0.0.1]) by agni.iprg.nokia.com (8.8.8/8.6.12) with ESMTP id VAA12752; Tue, 5 Oct 1999 21:39:59 -0700 (PDT) Message-Id: <199910060439.VAA12752@agni.iprg.nokia.com> To: Renu Agarwal cc: pim@catarina.usc.edu Subject: Re: New PIM-SM Draft In-reply-to: Your message of "Wed, 06 Oct 1999 09:44:54 +0530." <37FACCBE.4D7A71D1@ficon-tech.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <12749.939184798.1@agni.iprg.nokia.com> Date: Tue, 05 Oct 1999 21:39:58 -0700 From: Ravi Kiran Puvvala Sender: owner-pim@catarina.usc.edu Precedence: bulk Take a look at section 7.1 (page 55) in the draft. Ravi Renu Agarwal writes: | | I am new to this group and therefore are not aware of many things going | on this mailing list. Please pardon me if I am sounding too naive. | | We are planning to implement rfc2362 for PIM-SM mode. Can someone please | let me know how this draft is different from the rfc2362? What are the | major changes? In case you know of any location which has the changed | notes, please let me know. | | | Thanks in advance for your co-operation, | | | Regards | Renu | | | ___________________________________________________________ | Renu Agarwal E-mail: mailto:ragarwal@ficon-tech.com | Ficon Technology Web : http://www.ficon-tech.com | ___________________________________________________________ From owner-pim@catarina.usc.edu Wed Oct 6 18:48:49 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21629 for ; Wed, 6 Oct 1999 18:48:48 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id PAA10528 for pim-list; Wed, 6 Oct 1999 15:33:57 -0700 Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id PAA10524 for ; Wed, 6 Oct 1999 15:33:51 -0700 Received: by dfssl with Internet Mail Service (5.5.2650.21) id <426V280A>; Wed, 6 Oct 1999 15:33:01 -0700 Message-ID: <19398D273324D3118A2B0008C7E9A56904A67A2B@SIT.platinum.corp.microsoft.com> From: "Mohit Talwar (Exchange)" To: pim@catarina.usc.edu Subject: Sending Join/Prune Messages (Periodic) Date: Wed, 6 Oct 1999 15:32:46 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pim@catarina.usc.edu Precedence: bulk Hi All, A short question... To give context, I quote from section 3.2.1... --- Periodic Join/Prune Messages: A router sends a periodic Join/Prune message to each distinct RPF neighbor associated with each (S,G), (*,G) and (*,*,RP) entry. Join/Prune messages are only sent if the RPF neighbor is a PIM neighbor. A periodic Join/Prune message sent to a particular RPF neighbor is constructed as follows: 1 Each router determines the RP for a (*,G) entry by using the hash function described. The RP address (with RPT and WC bits set) is included in the join list of a periodic Join/Prune message under the following conditions: 1 The Join/Prune message is being sent to the RPF neighbor toward the RP for an active (*,G) or (*,*,RP) entry, and 2 The outgoing interface list in the (*,G) or (*,*,RP) entry is non-NULL, or the router is the DR on the same interface as the RPF neighbor. --- "...router is the DR on the same interface as the RPF neighbor." Is this rule there to take care of the case when a DR finds that there are local receivers for a group on the RPF interface? So the DR keeps the entry *active* till IGMP informs it that all local receivers have left the group. Please let me know if I have misunderstood something. Thanx, Mohit. From owner-pim@catarina.usc.edu Wed Oct 6 19:11:52 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA22063 for ; Wed, 6 Oct 1999 19:11:50 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id PAA10718 for pim-list; Wed, 6 Oct 1999 15:55:01 -0700 Received: from kit.isi.edu (kit.isi.edu [128.9.160.207]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id PAA10714 for ; Wed, 6 Oct 1999 15:54:56 -0700 Received: (from eddy@localhost) by kit.isi.edu (8.9.2/8.8.7) id PAA07422; Wed, 6 Oct 1999 15:45:19 -0700 (PDT) (envelope-from eddy) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 6 Oct 1999 15:45:19 -0700 (PDT) From: eddy@isi.edu To: "Mohit Talwar (Exchange)" Cc: pim@catarina.usc.edu Subject: Re: Sending Join/Prune Messages (Periodic) In-Reply-To: <19398D273324D3118A2B0008C7E9A56904A67A2B@SIT.platinum.corp.microsoft.com> References: <19398D273324D3118A2B0008C7E9A56904A67A2B@SIT.platinum.corp.microsoft.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14331.53455.104175.877540@kit.isi.edu> Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mohit Talwar (Exchange) states: > > "...router is the DR on the same interface as the RPF neighbor." > > Is this rule there to take care of the case when a DR finds that > there are local receivers for a group on the RPF interface? So > the DR keeps the entry *active* till IGMP informs it that all local > receivers have left the group. > > Please let me know if I have misunderstood something. > > Thanx, > Mohit. yes, this is correct. - rusty From owner-pim@catarina.usc.edu Mon Oct 11 09:51:50 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03571 for ; Mon, 11 Oct 1999 09:51:49 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id GAA03687 for pim-list; Mon, 11 Oct 1999 06:36:47 -0700 Received: from peridot.cisco.com (peridot.cisco.com [171.69.198.64]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id GAA03683 for ; Mon, 11 Oct 1999 06:36:42 -0700 Received: (from pbhavesh@localhost) by peridot.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA18525 for pim@catarina.usc.edu; Mon, 11 Oct 1999 06:36:11 -0700 (PDT) From: Bhavesh Pathak Message-Id: <199910111336.GAA18525@peridot.cisco.com> Subject: doubt in sec. 2.8 and 2.9 of draft-ietf-pim-v2-sm-00.txt To: pim@catarina.usc.edu Date: Mon, 11 Oct 1999 06:36:11 -0700 (PDT) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Dear everybody, I am trying to understand draft-ietf-pim-v2-sm-00.txt. I am not able to understand following. A. The section "2.8 Multicast data packet processing" says that, If the SPT-bit is cleared, then: 1 if the incoming interface is the same as a matching (S,G) iif, the packet is forwarded to the oif-list of (S,G). In addition, the SPT bit is set for that entry if ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the incoming interface differs from the incoming interface ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ of the (*,G) or (*,*,RP) entry. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Question: Why it is required that entry's incoming interfaces needs to be from (*,G) or (*,*,RP) to set SPT bit? B. In the section "Parallel paths to a source or the RP--Assert process:" it says that: " In case the packet, or the Assert message, matches on oif for (*,*,RP) entry, a (*,G) entry is created, and asserts take place as if the matching state were (*,G)." Question: I am unable to understand why it is required to create (*,G) entry? How does it help? -bhavesh From owner-pim@catarina.usc.edu Mon Oct 11 11:54:03 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07179 for ; Mon, 11 Oct 1999 11:54:02 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id IAA04207 for pim-list; Mon, 11 Oct 1999 08:33:44 -0700 Received: from ntserver1.redstonecom.com (ntserver1.redstonecom.com [199.105.223.130]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id IAA04203 for ; Mon, 11 Oct 1999 08:33:37 -0700 Received: by NTSERVER1 with Internet Mail Service (5.0.1460.8) id <431ZJJ0W>; Mon, 11 Oct 1999 11:33:09 -0400 Message-ID: <90ABC30C744ED311B16E00500464BEFC167E91@NTSERVER1> From: "Shekhar, Ravi" To: pim@catarina.usc.edu Subject: source address in assert packet. Date: Mon, 11 Oct 1999 11:33:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-pim@catarina.usc.edu Precedence: bulk > 3.5.1 Sending Asserts > > The following Assert rules are provided when a multicast packet is > received on an outgoing multi-access interface "I" of an existing > active (S,G), (*,G) or (*,*,RP) entry: > > 1 Do unicast routing table lookup on source address from data > packet, and send assert on interface "I" for source address in > data packet; include metric preference of routing protocol and > metric from routing table lookup. ... > 4.7 Assert Message ... > Encoded-Unicast-Source Address > Source address from multicast datagram that triggered the > Assert packet to be sent. The format for this address is > given in the Encoded-Unicast-Address in 4.1. Text in the draft requires source addresss in the assert packet to be that of source address in the data packet which triggered the assert. But to identify the RP in case of <*, *, RP> assert, isnt it required to have the source address in the assert packet be address of RP? Although not necessarily required for identification of <*, G> asserts (due to R bit), is it also desirable to have RP address as the source address in case of <*, G> asserts? [ If I remember right, there was some discussion regarding this on the mailing list already. Archive is currently unavailable. Could someone recap? ] Thanks. - Ravi Shekhar. From owner-pim@catarina.usc.edu Mon Oct 11 15:03:24 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12249 for ; Mon, 11 Oct 1999 15:03:22 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id LAA05062 for pim-list; Mon, 11 Oct 1999 11:45:32 -0700 Received: from lobster.baynetworks.com (ns3.BayNetworks.COM [192.32.253.3]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id LAA05054 for ; Mon, 11 Oct 1999 11:45:13 -0700 Received: from mailhost.BayNetworks.COM (h8754.s84f5.BayNetworks.COM [132.245.135.84]) by lobster.baynetworks.com (8.9.1/8.9.1) with ESMTP id OAA09721; Mon, 11 Oct 1999 14:47:23 -0400 (EDT) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id OAA04072; Mon, 11 Oct 1999 14:40:03 -0400 (EDT) Received: from diamante.engeast (diamante [192.32.174.50]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id OAA25869; Mon, 11 Oct 1999 14:44:03 -0400 for Received: by diamante.engeast (SMI-8.6/SMI-SVR4) id OAA28945; Mon, 11 Oct 1999 14:44:02 -0400 Date: Mon, 11 Oct 1999 14:44:02 -0400 From: bng@BayNetworks.COM (Billy Ng) Message-Id: <199910111844.OAA28945@diamante.engeast> To: pim@catarina.usc.edu, rshekhar@unisphere.cc Subject: Re: source address in assert packet. X-Sun-Charset: US-ASCII Sender: owner-pim@catarina.usc.edu Precedence: bulk > From rshekhar@unisphere.cc Mon Oct 11 11:45:27 1999 > > > 3.5.1 Sending Asserts > > > > The following Assert rules are provided when a multicast packet is > > received on an outgoing multi-access interface "I" of an existing > > active (S,G), (*,G) or (*,*,RP) entry: > > > > 1 Do unicast routing table lookup on source address from data > > packet, and send assert on interface "I" for source address in > > data packet; include metric preference of routing protocol and > > metric from routing table lookup. > ... > > > 4.7 Assert Message > ... > > Encoded-Unicast-Source Address > > Source address from multicast datagram that triggered the > > Assert packet to be sent. The format for this address is > > given in the Encoded-Unicast-Address in 4.1. > > > Text in the draft requires source addresss in the assert packet to be that > > of source address in the data packet which triggered the assert. > > But to identify the RP in case of <*, *, RP> assert, isnt it required to > have the source address in the assert packet be address of RP? > > Although not necessarily required for identification of <*, G> asserts > (due > to R bit), is it also desirable to have RP address as the source address > in > case of <*, G> asserts? [ If I remember right, there was some discussion > regarding this on the mailing list already. Archive is currently > unavailable. > Could someone recap? ] > > Thanks. > - Ravi Shekhar. > Ravi, Yes, this was brought up by Hal and me :) See the original mail below and response from rusty: From eddy@isi.edu Fri Sep 4 15:10:32 1998 Date: Fri, 4 Sep 1998 12:10:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: eddy@isi.edu To: Hal_Sandick@BayNetworks.COM (Hal Sandick) Cc: pim@catarina.usc.edu, Billy_Ng@BayNetworks.COM Subject: Re: Assert RPF X-Mailer: VM 6.31 under 20.2 XEmacs Lucid Content-Length: 2242 X-Lines: 49 Status: RO Hal Sandick states: > Billy Ng and I found a slight ambiguity in RFC2362 (PIM-SM) regarding how > upstream routers do the RPF check during the Assert process. Section 2.9 > describes an upstream router doing a RPF check to the source for a (S,G) > entry or to the RP for a shared tree entry: > > > "If a router receives a multicast data gram on a multi-access LAN from > a source whose corresponding (S,G) outgoing interface list includes > the interface to that LAN, the packet must be a duplicate. In this > case a single forwarder must be elected. Using Assert messages > addressed to `224.0.0.13' (ALL-PIM-ROUTERS group) on the LAN, > upstream routers can resolve which one will act as the forwarder. > Downstream routers listen to the Asserts so they know which one was > elected, and therefore where to send subsequent Joins. Typically this > is the same as the downstream router's RPF (Reverse Path Forwarding) > neighbor; but there are circumstances where this might not be the > case, e.g., when using multiple unicast routing protocols on that > LAN. The RPF neighbor for a particular source (or RP) is the next-hop > router to which packets are forwarded en route to that source (or > RP); and therefore is considered a good path via which to accept > packets from that source." > > In section 3.5.1 on sending asserts, only the "source" of the data gram is > referred to: > > "The following Assert rules are provided when a multicast packet is > received on an outgoing multi-access interface "I" of an existing > active (S,G), (*,G) or (*,*,RP) entry: > > 1 Do unicast routing table lookup on source address from data > packet, and send assert on interface "I" for source address in > data packet; include metric preference of routing protocol and > metric from routing table lookup." > > We assume that section 2.9 is correct and that section 3.5.1 should be > changed to indicate a RPF lookup for the source for a (S,G) entry and a RPF > lookup for the RP for a shared tree entry. > > Regards, > > Hal Hal, it looks like you are correct, i've made a note of this in http://www.isi.edu/~eddy/pim/pim-specv2-notes.html - rusty From owner-pim@catarina.usc.edu Mon Oct 11 15:23:50 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12612 for ; Mon, 11 Oct 1999 15:23:49 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id MAA05225 for pim-list; Mon, 11 Oct 1999 12:06:40 -0700 Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id MAA05221; Mon, 11 Oct 1999 12:06:36 -0700 Received: from rumi (localhost [127.0.0.1]) by rumi.usc.edu (8.9.3/8.6.9) with ESMTP id MAA55133; Mon, 11 Oct 1999 12:05:59 -0700 (PDT) Message-Id: <199910111905.MAA55133@rumi.usc.edu> To: Bhavesh Pathak cc: pim@catarina.usc.edu Subject: Re: doubt in sec. 2.8 and 2.9 of draft-ietf-pim-v2-sm-00.txt In-reply-to: Your message of "Mon, 11 Oct 1999 06:36:11 PDT." <199910111336.GAA18525@peridot.cisco.com> Date: Mon, 11 Oct 1999 12:05:59 -0700 From: Pavlin Ivanov Radoslavov Sender: owner-pim@catarina.usc.edu Precedence: bulk > The section "2.8 Multicast data packet processing" says that, > > If the SPT-bit is cleared, then: > > 1 if the incoming interface is the same as a matching > (S,G) iif, the packet is forwarded to the oif-list of > (S,G). In addition, the SPT bit is set for that entry if > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > the incoming interface differs from the incoming interface > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > of the (*,G) or (*,*,RP) entry. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Question: Why it is required that entry's incoming interfaces needs > to be from (*,G) or (*,*,RP) to set SPT bit? ~~~~ "...to be different from..."(?) The SPT indicates a tree/entry rooted in the Source instead of the RP. > B. > In the section "Parallel paths to a source or the RP--Assert process:" > it says that: > > " In case the packet, or the Assert message, matches on oif for > (*,*,RP) entry, a (*,G) entry is created, and asserts take place as > if the matching state were (*,G)." > > Question: I am unable to understand why it is required to create > (*,G) entry? How does it help? The Asserts are with regard to a (S,G) or (*,G) entries only, so for example, the loser of the (*,G) assert needs to have (*,G) entry to prune the oif for that group only. Pavlin From owner-pim@catarina.usc.edu Mon Oct 11 15:35:21 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12855 for ; Mon, 11 Oct 1999 15:35:19 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id MAA05335 for pim-list; Mon, 11 Oct 1999 12:20:09 -0700 Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id MAA05331 for ; Mon, 11 Oct 1999 12:20:03 -0700 Received: from rumi (localhost [127.0.0.1]) by rumi.usc.edu (8.9.3/8.6.9) with ESMTP id MAA55178 for ; Mon, 11 Oct 1999 12:19:27 -0700 (PDT) Message-Id: <199910111919.MAA55178@rumi.usc.edu> To: pim@catarina.usc.edu Subject: PIM-SM draft ambiguities Date: Mon, 11 Oct 1999 12:19:27 -0700 From: Pavlin Ivanov Radoslavov Sender: owner-pim@catarina.usc.edu Precedence: bulk 2.10 Unicast Routing Changes When unicast routing changes, an RPF check is done on all active (S,G), (*,G) and (*,*,RP) entries, and all affected expected incoming interfaces are updated. In particular, if the new incoming interface appears in the outgoing interface list, it is deleted from the outgoing interface list. The previous incoming interface may be added to the outgoing interface list by a subsequent Join/Prune from downstream. Join/Prune messages received on the current incoming ~~~~~~~~~~~~~~~~~~~~ Shoudn't this be "the new incoming interface"? If the iif has just changed, the "current iif" has some ambiguity. interface are ignored. Join/Prune messages received on new interfaces or existing outgoing interfaces are not ignored. Other outgoing interfaces are left as is until they are explicitly pruned by downstream routers or are timed out due to lack of appropriate Join/Prune messages. If the router has a (S,G) entry with the SPT-bit set, and the updated iif(S,G) does not differ from iif(*,G) or iif(*,*,RP), then the router resets the SPT-bit. The router must send a Join/Prune message with S in the Join list out Join message should be sent also for the (*,G) and the (*,*,RP) entries that have just changed their iif toward the RP. "J/P message with S" may create the impression that J/P is sent only toward a source S (when appropriate), but not toward the RP. any new incoming interfaces to inform upstream routers that it expects multicast datagrams over the interface. It may also send a Join/Prune message with S in the Prune list out the old incoming ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Same comment as above. Pavlin interface, if the link is operational, to inform upstream routers that this part of the distribution tree is going away. From owner-pim@catarina.usc.edu Mon Oct 11 15:42:41 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13062 for ; Mon, 11 Oct 1999 15:42:39 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id MAA05389 for pim-list; Mon, 11 Oct 1999 12:24:01 -0700 Received: from siara.com (gate.siara.com [209.31.24.134]) by catarina.usc.edu (8.6.10/8.6.9) with SMTP id MAA05384 for ; Mon, 11 Oct 1999 12:23:48 -0700 Received: from truchard.siara.com by siara.com with smtp id m11al2E-001FOSC; Mon, 11 Oct 1999 12:23:02 -0700 (PDT) Received: by truchard.siara.com id m11al2E-001Bf8C; Mon, 11 Oct 1999 12:23:02 -0700 (PDT) Message-ID: Date: Mon, 11 Oct 1999 12:23:02 -0700 (PDT) From: Liming Wei To: pbhavesh@cisco.com CC: pim@catarina.usc.edu In-reply-to: <199910111336.GAA18525@peridot.cisco.com> (message from Bhavesh Pathak on Mon, 11 Oct 1999 06:36:11 -0700 (PDT)) Subject: Re: doubt in sec. 2.8 and 2.9 of draft-ietf-pim-v2-sm-00.txt Reply-to: lwei@siara.com Sender: owner-pim@catarina.usc.edu Precedence: bulk Bhavesh, > From: Bhavesh Pathak > > Dear everybody, > I am trying to understand draft-ietf-pim-v2-sm-00.txt. I am not > able to understand following. > > A. > The section "2.8 Multicast data packet processing" says that, > > If the SPT-bit is cleared, then: > > 1 if the incoming interface is the same as a matching > (S,G) iif, the packet is forwarded to the oif-list of > (S,G). In addition, the SPT bit is set for that entry if > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > the incoming interface differs from the incoming interface > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > of the (*,G) or (*,*,RP) entry. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Question: Why it is required that entry's incoming interfaces needs > to be from (*,G) or (*,*,RP) to set SPT bit? The SPT bit is only relevant when the (S,G)'s iif is different from that for the (*,G) or (*,*,RP). After a diverging router decides to switch to Source tree (SPT) from a shared tree (RPT), it needs to continue to forward packets down the RPT, even if the (S,G) alreaedy exists and RPF fails on the (S,G) entry. > > B. > In the section "Parallel paths to a source or the RP--Assert process:" > it says that: > > " In case the packet, or the Assert message, matches on oif for > (*,*,RP) entry, a (*,G) entry is created, and asserts take place as > if the matching state were (*,G)." > > Question: I am unable to understand why it is required to create > (*,G) entry? How does it help? The assert relates to a particular group G, and may not apply for other groups. -Liming From owner-pim@catarina.usc.edu Mon Oct 11 15:46:29 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13208 for ; Mon, 11 Oct 1999 15:46:26 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id MAA05435 for pim-list; Mon, 11 Oct 1999 12:28:48 -0700 Received: from siara.com (gate.siara.com [209.31.24.134]) by catarina.usc.edu (8.6.10/8.6.9) with SMTP id MAA05431 for ; Mon, 11 Oct 1999 12:28:37 -0700 Received: from truchard.siara.com by siara.com with smtp id m11al6z-001FOSC; Mon, 11 Oct 1999 12:27:57 -0700 (PDT) Received: by truchard.siara.com id m11al6y-001Bf8C; Mon, 11 Oct 1999 12:27:56 -0700 (PDT) Message-ID: Date: Mon, 11 Oct 1999 12:27:56 -0700 (PDT) From: Liming Wei To: rshekhar@unisphere.cc CC: pim@catarina.usc.edu In-reply-to: <90ABC30C744ED311B16E00500464BEFC167E91@NTSERVER1> (rshekhar@unisphere.cc) Subject: Re: source address in assert packet. Reply-to: lwei@siara.com Sender: owner-pim@catarina.usc.edu Precedence: bulk > From: "Shekhar, Ravi" > > Text in the draft requires source addresss in the assert packet to be that > > of source address in the data packet which triggered the assert. > > But to identify the RP in case of <*, *, RP> assert, isnt it required to > have the source address in the assert packet be address of RP? > > Although not necessarily required for identification of <*, G> asserts > (due > to R bit), is it also desirable to have RP address as the source address > in > case of <*, G> asserts? [ If I remember right, there was some discussion > regarding this on the mailing list already. Archive is currently > unavailable. > Could someone recap? ] I don't have the archive either. It should be the source address, because that is the "raw" information about the packets causing such asserts. Also in case of error, the local box may have a different idea of who the RP should be. Instead of changing the protocol actions, we would be better off keeping the source address in the asserts. -Liming From owner-pim@catarina.usc.edu Mon Oct 11 16:00:11 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13503 for ; Mon, 11 Oct 1999 16:00:11 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id MAA05683 for pim-list; Mon, 11 Oct 1999 12:46:35 -0700 Received: from ntserver1.redstonecom.com (ntserver1.redstonecom.com [199.105.223.130]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id MAA05675 for ; Mon, 11 Oct 1999 12:46:22 -0700 Received: by NTSERVER1 with Internet Mail Service (5.0.1460.8) id <431ZJKVZ>; Mon, 11 Oct 1999 15:45:50 -0400 Message-ID: <90ABC30C744ED311B16E00500464BEFC16B5E6@NTSERVER1> From: "Shekhar, Ravi" To: lwei@siara.com, rshekhar@unisphere.cc Cc: pim@catarina.usc.edu Subject: RE: source address in assert packet. Date: Mon, 11 Oct 1999 15:45:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-pim@catarina.usc.edu Precedence: bulk > I don't have the archive either. It should be the source address, > because that is the "raw" information about the packets causing such > asserts. Also in case of error, the local box may have a different > idea of who the RP should be. Instead of changing the protocol > actions, we would be better off keeping the source address in the > asserts. > > -Liming > Thanks Liming. I take it to mean that <*, *, RP> asserts are not allowed in this version. Is that right? If thats the case, then section 3.5 might need slight correction in the following paragraph: > Receiving Asserts on an entry's incoming interface > > If the Assert arrived on the incoming interface of an existing (S,G), > (*,G), or (*,*,RP) entry, the Assert is processed as follows. If the > Assert message does not match the entry, exactly, it is ignored; i.e, > longest-match is not used in this case. It talks about "exactly" matching <*, *, RP>, which should never happen. Also prehaps it would be appropriate to create <*, G> entry (or may be wait till data triggers it to be created) like the preceding paragraph on "receiving assert on outgoing interface" specifically states. Regards. - Ravi Shekhar. From owner-pim@catarina.usc.edu Mon Oct 11 16:00:41 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13515 for ; Mon, 11 Oct 1999 16:00:40 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id MAA05733 for pim-list; Mon, 11 Oct 1999 12:49:22 -0700 Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id MAA05729; Mon, 11 Oct 1999 12:49:17 -0700 Received: from rumi (localhost [127.0.0.1]) by rumi.usc.edu (8.9.3/8.6.9) with ESMTP id MAA55284; Mon, 11 Oct 1999 12:48:41 -0700 (PDT) Message-Id: <199910111948.MAA55284@rumi.usc.edu> To: lwei@siara.com cc: pim@catarina.usc.edu Subject: PIM archive (was Re: source address in assert packet). In-reply-to: Your message of "Mon, 11 Oct 1999 12:27:56 PDT." Date: Mon, 11 Oct 1999 12:48:41 -0700 From: Pavlin Ivanov Radoslavov Sender: owner-pim@catarina.usc.edu Precedence: bulk > > regarding this on the mailing list already. Archive is currently > > unavailable. > > Could someone recap? ] > > I don't have the archive either. It should be the source address, The official archive (from the IETF) site is: http://www.juniper.net/~pusateri/pim.html and I guess this one is down. There is also archive from USC: http://netweb.usc.edu/pim/mail-archive/ ftp://catarina.usc.edu/pub/pim/mail-archive/ Pavlin From owner-pim@catarina.usc.edu Mon Oct 11 16:29:17 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14463 for ; Mon, 11 Oct 1999 16:29:15 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id NAA06041 for pim-list; Mon, 11 Oct 1999 13:18:08 -0700 Received: from siara.com (gate.siara.com [209.31.24.134]) by catarina.usc.edu (8.6.10/8.6.9) with SMTP id NAA06037; Mon, 11 Oct 1999 13:18:02 -0700 Received: from truchard.siara.com by siara.com with smtp id m11also-001FOSC; Mon, 11 Oct 1999 13:17:22 -0700 (PDT) Received: by truchard.siara.com id m11alsn-001Bf8C; Mon, 11 Oct 1999 13:17:21 -0700 (PDT) Message-ID: Date: Mon, 11 Oct 1999 13:17:21 -0700 (PDT) From: Liming Wei To: pavlin@catarina.usc.edu CC: pim@catarina.usc.edu In-reply-to: <199910111919.MAA55178@rumi.usc.edu> (message from Pavlin Ivanov Radoslavov on Mon, 11 Oct 1999 12:19:27 -0700) Subject: Re: PIM-SM draft ambiguities Reply-to: lwei@siara.com Sender: owner-pim@catarina.usc.edu Precedence: bulk > From: Pavlin Ivanov Radoslavov > > 2.10 Unicast Routing Changes > > When unicast routing changes, an RPF check is done on all active > (S,G), (*,G) and (*,*,RP) entries, and all affected expected incoming > interfaces are updated. In particular, if the new incoming interface > appears in the outgoing interface list, it is deleted from the > outgoing interface list. The previous incoming interface may be added > to the outgoing interface list by a subsequent Join/Prune from > downstream. Join/Prune messages received on the current incoming > ~~~~~~~~~~~~~~~~~~~~ > Shoudn't this be "the new incoming interface"? If the iif has just > changed, the "current iif" has some ambiguity. Better. Changed. > > interface are ignored. Join/Prune messages received on new > interfaces or existing outgoing interfaces are not ignored. Other > outgoing interfaces are left as is until they are explicitly pruned > by downstream routers or are timed out due to lack of appropriate > Join/Prune messages. If the router has a (S,G) entry with the SPT-bit > set, and the updated iif(S,G) does not differ from iif(*,G) or > iif(*,*,RP), then the router resets the SPT-bit. > > The router must send a Join/Prune message with S in the Join list out > > Join message should be sent also for the (*,G) and the (*,*,RP) > entries that have just changed their iif toward the RP. "J/P message > with S" may create the impression that J/P is sent only toward a > source S (when appropriate), but not toward the RP. > > any new incoming interfaces to inform upstream routers that it > expects multicast datagrams over the interface. It may also send a > Join/Prune message with S in the Prune list out the old incoming > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Same comment as above. > > Pavlin Changed to say "with S or RP in the join list...", "with S or RP in the prune list...". The context will be clear about what this paragraph means. -Liming From owner-pim@catarina.usc.edu Mon Oct 11 16:42:16 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14968 for ; Mon, 11 Oct 1999 16:42:15 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id NAA06178 for pim-list; Mon, 11 Oct 1999 13:29:30 -0700 Received: from siara.com (gate.siara.com [209.31.24.134]) by catarina.usc.edu (8.6.10/8.6.9) with SMTP id NAA06166 for ; Mon, 11 Oct 1999 13:29:19 -0700 Received: from truchard.siara.com by siara.com with smtp id m11am3d-001FOaC; Mon, 11 Oct 1999 13:28:33 -0700 (PDT) Received: by truchard.siara.com id m11am3d-001Bf8C; Mon, 11 Oct 1999 13:28:33 -0700 (PDT) Message-ID: Date: Mon, 11 Oct 1999 13:28:33 -0700 (PDT) From: Liming Wei To: rshekhar@unisphere.cc CC: rshekhar@unisphere.cc, pim@catarina.usc.edu In-reply-to: <90ABC30C744ED311B16E00500464BEFC16B5E6@NTSERVER1> (rshekhar@unisphere.cc) Subject: Re: source address in assert packet. Reply-to: lwei@siara.com Sender: owner-pim@catarina.usc.edu Precedence: bulk > From: "Shekhar, Ravi" > > > I don't have the archive either. It should be the source address, > > because that is the "raw" information about the packets causing such > > asserts. Also in case of error, the local box may have a different > > idea of who the RP should be. Instead of changing the protocol > > actions, we would be better off keeping the source address in the > > asserts. > > > > -Liming > > > > Thanks Liming. > > I take it to mean that <*, *, RP> asserts are not allowed in this version. > Is that right? I would say "a packet can arrive on an out going interface of a (*,*,RP) entry, and an assert needs to happen as a result". > > If thats the case, then section 3.5 might need slight correction in the > following paragraph: > > > Receiving Asserts on an entry's incoming interface > > > > If the Assert arrived on the incoming interface of an existing (S,G), > > (*,G), or (*,*,RP) entry, the Assert is processed as follows. If the > > Assert message does not match the entry, exactly, it is ignored; i.e, > > longest-match is not used in this case. > > It talks about "exactly" matching <*, *, RP>, which should never happen. > > Also prehaps it would be appropriate to create <*, G> entry (or may be > wait > till data triggers it to be created) like the preceding paragraph on > "receiving assert on outgoing interface" specifically states. Yes makes sense. The language here should be "if a longest match lookup does not find anything, the Assert is ignored". "if a longest match lookup finds an entry, do the following:...". Fixed. -Liming From owner-pim@catarina.usc.edu Mon Oct 11 16:46:29 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15059 for ; Mon, 11 Oct 1999 16:46:28 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id NAA06202 for pim-list; Mon, 11 Oct 1999 13:32:56 -0700 Received: from siara.com (gate.siara.com [209.31.24.134]) by catarina.usc.edu (8.6.10/8.6.9) with SMTP id NAA06198; Mon, 11 Oct 1999 13:32:43 -0700 Received: from truchard.siara.com by siara.com with smtp id m11am6w-001FObC; Mon, 11 Oct 1999 13:31:58 -0700 (PDT) Received: by truchard.siara.com id m11am6w-001Bf8C; Mon, 11 Oct 1999 13:31:58 -0700 (PDT) Message-ID: Date: Mon, 11 Oct 1999 13:31:58 -0700 (PDT) From: Liming Wei To: pavlin@catarina.usc.edu CC: pim@catarina.usc.edu In-reply-to: <199910111948.MAA55284@rumi.usc.edu> (message from Pavlin Ivanov Radoslavov on Mon, 11 Oct 1999 12:48:41 -0700) Subject: Re: PIM archive (was Re: source address in assert packet). Reply-to: lwei@siara.com Sender: owner-pim@catarina.usc.edu Precedence: bulk > From: Pavlin Ivanov Radoslavov > > > I don't have the archive either. It should be the source address, > > The official archive (from the IETF) site is: > http://www.juniper.net/~pusateri/pim.html > and I guess this one is down. > > There is also archive from USC: > http://netweb.usc.edu/pim/mail-archive/ > ftp://catarina.usc.edu/pub/pim/mail-archive/ Thanks Pavlin. -Liming From owner-pim@catarina.usc.edu Mon Oct 11 17:29:21 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16040 for ; Mon, 11 Oct 1999 17:29:20 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id OAA06481 for pim-list; Mon, 11 Oct 1999 14:16:51 -0700 Received: from seattle.3com.com (seattle.3com.com [129.213.128.97]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id OAA06477 for ; Mon, 11 Oct 1999 14:16:45 -0700 Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id OAA05597 for ; Mon, 11 Oct 1999 14:16:43 -0700 (PDT) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id OAA28395 for ; Mon, 11 Oct 1999 14:16:42 -0700 (PDT) Received: from dutch.nsd.3com.com (dutch.nsd.3com.com [129.213.48.27]) by chicago.nsd.3com.com (8.8.8/8.8.8) with ESMTP id OAA14825 for ; Mon, 11 Oct 1999 14:16:42 -0700 (PDT) Received: from localhost (venu@localhost) by dutch.nsd.3com.com (8.8.8/8.8.8) with SMTP id OAA12265 for ; Mon, 11 Oct 1999 14:15:54 -0700 (PDT) X-Authentication-Warning: dutch.nsd.3com.com: venu owned process doing -bs Date: Mon, 11 Oct 1999 14:15:54 -0700 (PDT) From: Nair Venugopal X-Sender: venu@dutch.nsd.3com.com To: pim@catarina.usc.edu Subject: GenIDs in draft-ietf-pim-v2-sm-00.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pim@catarina.usc.edu Precedence: bulk Hi, Would like a clarification about the triggered events that should occur if a GenID capable DR reboots (section 3.1.2). Should the router with the "next highest" DR priority (with IP addresses as tie-breakers) unicast the most recent RP-Set information to the ("rebooted") DR when it detects the DR with a new-GenID? The PIM GenID I-draft (draft-ietf-pim-hello-genid-01.txt, Section 1) suggested the following. "By including this GenID as an option in the Hello packet, a neighbor reboot can easily be detected if its GenID is different from before. When such an event happens, the DR on the LAN unicasts its most recent RP-Set information to the rebooted neighbor. If the rebooted neighbor was the DR, the next highest ip address (or the next highest DR priority if this option is enabled) neighbor will unicast the information." Was this (last line in the quoted text above) excluded in the new PIM-SMv2 ID because it would cause other problems? Thanks. --Venu -------------------------------------------------------------------- Nair Venugopal --- venu@3com.com --- 3Com WAP Engineering From owner-pim@catarina.usc.edu Mon Oct 11 18:34:46 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17032 for ; Mon, 11 Oct 1999 18:34:45 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id PAA06770 for pim-list; Mon, 11 Oct 1999 15:23:39 -0700 Received: from ntserver1.redstonecom.com (ntserver1.redstonecom.com [199.105.223.130]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id PAA06766 for ; Mon, 11 Oct 1999 15:23:29 -0700 Received: by NTSERVER1 with Internet Mail Service (5.0.1460.8) id <431ZJLAH>; Mon, 11 Oct 1999 18:22:58 -0400 Message-ID: <90ABC30C744ED311B16E00500464BEFC16B69C@NTSERVER1> From: "Shekhar, Ravi" To: Nair Venugopal , pim@catarina.usc.edu Subject: RE: GenIDs in draft-ietf-pim-v2-sm-00.txt Date: Mon, 11 Oct 1999 18:22:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-pim@catarina.usc.edu Precedence: bulk > Hi, > > Would like a clarification about the triggered events that > should occur if > a GenID capable DR reboots (section 3.1.2). Should the router with the > "next highest" DR priority (with IP addresses as > tie-breakers) unicast the > most recent RP-Set information to the ("rebooted") DR when it > detects the > DR with a new-GenID? > > The PIM GenID I-draft (draft-ietf-pim-hello-genid-01.txt, Section 1) > suggested the following. > > "By including this GenID as an option in the > Hello packet, a neighbor reboot can easily be detected if > its GenID > is different from before. When such an event happens, the > DR on the > LAN unicasts its most recent RP-Set information to the rebooted > neighbor. If the rebooted neighbor was the DR, the next > highest ip > address (or the next highest DR priority if this option is > enabled) > neighbor will unicast the information." > > Was this (last line in the quoted text above) excluded in the > new PIM-SMv2 > ID because it would cause other problems? My guess is that this will automatically follow the way gen-id detected reboot will be processed. A new gen-id from a nbr should be treated as nbr going down and then coming back up as a new nbr. In the first part of processing as "nbr going down", next highest ip address (or next highest DR priority) router will become the DR. And then in the second part of processing "as new nbr coming up", this new DR will advertise its RP-set information to the new nbr. Regards. - Ravi Shekhar. From owner-pim@catarina.usc.edu Mon Oct 11 20:31:06 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA18361 for ; Mon, 11 Oct 1999 20:31:04 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id RAA07412 for pim-list; Mon, 11 Oct 1999 17:13:56 -0700 Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id RAA07408; Mon, 11 Oct 1999 17:13:50 -0700 Received: from juniper.net (red.juniper.net [208.197.169.254]) by red.juniper.net (8.8.8/8.8.5) with ESMTP id RAA03797; Mon, 11 Oct 1999 17:13:22 -0700 (PDT) Message-Id: <199910120013.RAA03797@red.juniper.net> To: lwei@siara.com cc: pavlin@catarina.usc.edu, pim@catarina.usc.edu, pusateri@juniper.net Subject: Re: PIM archive (was Re: source address in assert packet). In-Reply-To: Message from Liming Wei of "Mon, 11 Oct 1999 13:31:58 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3794.939687201.1@juniper.net> Date: Mon, 11 Oct 1999 17:13:21 -0700 From: Tom Pusateri Sender: owner-pim@catarina.usc.edu Precedence: bulk In message you write: >> From: Pavlin Ivanov Radoslavov >> >> > I don't have the archive either. It should be the source address, >> >> The official archive (from the IETF) site is: >> http://www.juniper.net/~pusateri/pim.html >> and I guess this one is down. >> >> There is also archive from USC: >> http://netweb.usc.edu/pim/mail-archive/ >> ftp://catarina.usc.edu/pub/pim/mail-archive/ > >Thanks Pavlin. > >-Liming Sorry guys. I moved offices recently and my mail gets delivered on a different machine. I'll see if I can get the html archive going again. But if not, we may have to rely on the ascii archive. Tom From owner-pim@catarina.usc.edu Tue Oct 12 03:06:46 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA06165 for ; Tue, 12 Oct 1999 03:06:44 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id AAA09127 for pim-list; Tue, 12 Oct 1999 00:03:16 -0700 Received: from hotmail.com (law-f37.hotmail.com [209.185.131.100]) by catarina.usc.edu (8.6.10/8.6.9) with SMTP id AAA09114 for ; Tue, 12 Oct 1999 00:03:05 -0700 Received: (qmail 90350 invoked by uid 0); 12 Oct 1999 07:02:34 -0000 Message-ID: <19991012070234.90349.qmail@hotmail.com> Received: from 192.135.245.219 by www.hotmail.com with HTTP; Tue, 12 Oct 1999 00:02:34 PDT X-Originating-IP: [192.135.245.219] From: "bhavesh pathak" To: pim@catarina.usc.edu Subject: (PIM-SM)when source and receiver are on same LAN Date: Tue, 12 Oct 1999 00:02:34 PDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-pim@catarina.usc.edu Precedence: bulk Dear everybody, I am trying to understand draft-ietf-pim-v2-sm-00.txt. I am not able to understand how following situation will be handled. -------- | |Source| | 1-----2 1-----2 1----2 1------2 | ---------- |Host |--+---| A |---| B |---|RP|----| C |-----+---| Receiver| -------- | ----- ----- ---- ------ | | Host2 | -------> | ----------> <------------> ----------- Data packet| Register forward | decapsulated | data packet ---------- | |Receiver| | | Host1 |--+ ---------- | NOTE: 1, 2 represents the interface number for router. 1. Say initially, Receiver-Host1 has not up. IN this case, A will have (S,G) entry with iif = A1, oif = A2 A will have (*,G) entry with iif = A2, oif = NULL 2. IF the receiver-Host1 comes up and wants to receive multicast data, will the entries in A be modified as follows? A will have (S,G) entry with iif = A1, oif = A2,A1 A will have (*,G) entry with iif = A2, oif = A1 How this situation will be handled? bhavesh ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-pim@catarina.usc.edu Tue Oct 12 13:38:36 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22660 for ; Tue, 12 Oct 1999 13:38:35 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id KAA11774 for pim-list; Tue, 12 Oct 1999 10:28:37 -0700 Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id KAA11770 for ; Tue, 12 Oct 1999 10:28:33 -0700 Received: from ceng.usc.edu (helmy@ceng.usc.edu [128.125.253.190]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id KAA14412; Tue, 12 Oct 1999 10:28:30 -0700 (PDT) Received: from localhost (helmy@localhost) by ceng.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id KAA28897; Tue, 12 Oct 1999 10:28:31 -0700 (PDT) Date: Tue, 12 Oct 1999 10:28:30 -0700 (PDT) From: helmy To: bhavesh pathak cc: pim@catarina.usc.edu Subject: Re: (PIM-SM)when source and receiver are on same LAN In-Reply-To: <19991012070234.90349.qmail@hotmail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pim@catarina.usc.edu Precedence: bulk > Dear everybody, > I am trying to understand draft-ietf-pim-v2-sm-00.txt. I am not > able to understand how following situation will be handled. > > -------- | > |Source| | 1-----2 1-----2 1----2 1------2 | ---------- > |Host |--+---| A |---| B |---|RP|----| C |-----+---| Receiver| > -------- | ----- ----- ---- ------ | | Host2 | > -------> | ----------> <------------> ----------- > Data packet| Register forward > | decapsulated > | data packet > ---------- | > |Receiver| | > | Host1 |--+ > ---------- | > > NOTE: 1, 2 represents the interface number for router. > 1. Say initially, Receiver-Host1 has not up. IN this case, > > A will have (S,G) entry with iif = A1, oif = A2 > A will have (*,G) entry with iif = A2, oif = NULL If the receiver is not up yet (i.e. has not joined the group), then A will only have a S,G with the register bit set, iif A1 and oif is the register vif (virtual interface), which is whatever the unicast says is the way to RP (remember that registers are unicast). If there are no receivers downstream of A then A will not have *,G > > 2. IF the receiver-Host1 comes up and wants to receive multicast data, > will the entries in A be modified as follows? > > A will have (S,G) entry with iif = A1, oif = A2,A1 > A will have (*,G) entry with iif = A2, oif = A1 when the receiver joins the group, A will create *,G with iif pointing towards RP (i.e. A2) and oif pointing towards the LAN (i.e. A1). However since it has S,G and *,G with different iifs, it sends a prune for S,G towards the RP. So in the end the receiver gets the packets from the LAN directly and the decapsulated registers don't flow back towards the LAN. Regs, -A > > How this situation will be handled? > > bhavesh > > ______________________________________________________ > Get Your Private, Free Email at http://www.hotmail.com > From owner-pim@catarina.usc.edu Tue Oct 12 14:05:48 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23266 for ; Tue, 12 Oct 1999 14:05:46 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id KAA11969 for pim-list; Tue, 12 Oct 1999 10:50:55 -0700 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id KAA11965 for ; Tue, 12 Oct 1999 10:50:50 -0700 Received: from agni.iprg.nokia.com (agni.iprg.nokia.com [205.226.8.100]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id KAA22803; Tue, 12 Oct 1999 10:50:14 -0700 (PDT) Received: from agni.iprg.nokia.com (localhost [127.0.0.1]) by agni.iprg.nokia.com (8.8.8/8.6.12) with ESMTP id KAA13701; Tue, 12 Oct 1999 10:50:13 -0700 (PDT) Message-Id: <199910121750.KAA13701@agni.iprg.nokia.com> To: helmy Cc: pim@catarina.usc.edu Subject: Re: (PIM-SM)when source and receiver are on same LAN In-reply-to: Your message of "Tue, 12 Oct 1999 10:28:30 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13698.939750613.1@agni.iprg.nokia.com> Date: Tue, 12 Oct 1999 10:50:13 -0700 From: Ravi Kiran Puvvala Sender: owner-pim@catarina.usc.edu Precedence: bulk helmy writes: | when the receiver joins the group, A will create *,G with iif pointing | towards RP (i.e. A2) and oif pointing towards the LAN (i.e. A1). However | since it has S,G and *,G with different iifs, it sends a prune for S,G | towards the RP. When does A detect that it has both <*,G> and with different IIF's. I think ... - Receiver1 joins G - A creates <*,G> - A propogates the <*,G> join towards the RP - Source sends traffic to A - A encapsulates data in a register and sends it to RP - RP decapsulates the packet and sends it to A - A detects that it is receiving packets on the OIF, then it sends a prune towards the RP. Ravi From owner-pim@catarina.usc.edu Tue Oct 12 14:56:24 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24093 for ; Tue, 12 Oct 1999 14:56:24 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id LAA12179 for pim-list; Tue, 12 Oct 1999 11:03:49 -0700 Received: from siara.com (gate.siara.com [209.31.24.134]) by catarina.usc.edu (8.6.10/8.6.9) with SMTP id LAA12175 for ; Tue, 12 Oct 1999 11:03:44 -0700 Received: from truchard.siara.com by siara.com with smtp id m11b6GO-001FHOC; Tue, 12 Oct 1999 11:03:04 -0700 (PDT) Received: by truchard.siara.com id m11b6GO-001Bf8C; Tue, 12 Oct 1999 11:03:04 -0700 (PDT) Message-ID: Date: Tue, 12 Oct 1999 11:03:04 -0700 (PDT) From: Liming Wei To: pim@catarina.usc.edu Subject: PIM WG meeting at DC Reply-to: lwei@siara.com Sender: owner-pim@catarina.usc.edu Precedence: bulk Folks, Please send agenda items for the DC working group meeting to this list, or to Tom or myself. Thanks, -Liming From owner-pim@catarina.usc.edu Tue Oct 12 15:04:22 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24377 for ; Tue, 12 Oct 1999 15:04:21 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id LAA12592 for pim-list; Tue, 12 Oct 1999 11:52:21 -0700 Received: from ntserver1.redstonecom.com (ntserver1.redstonecom.com [199.105.223.130]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id LAA12588 for ; Tue, 12 Oct 1999 11:52:15 -0700 Received: by NTSERVER1 with Internet Mail Service (5.0.1460.8) id <4Y7N4AZT>; Tue, 12 Oct 1999 14:51:53 -0400 Message-ID: <90ABC30C744ED311B16E00500464BEFC17130C@NTSERVER1> From: "Shekhar, Ravi" To: Ravi Kiran Puvvala , helmy Cc: pim@catarina.usc.edu Subject: RE: (PIM-SM)when source and receiver are on same LAN Date: Tue, 12 Oct 1999 14:51:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-pim@catarina.usc.edu Precedence: bulk In this case, since A will already have an exisiting SPT entry (with local intf as iif) due to source being active, when <*, G> join is triggered by A towards RP, prune will be included along with it. And it will continue to be like this in all the subsequent regular updates as long as source is active. - Ravi Shekhar. > helmy writes: > > | when the receiver joins the group, A will create *,G with > iif pointing > | towards RP (i.e. A2) and oif pointing towards the LAN (i.e. > A1). However > | since it has S,G and *,G with different iifs, it sends a > prune for S,G > | towards the RP. > > When does A detect that it has both <*,G> and with > different IIF's. > > I think ... > > - Receiver1 joins G > - A creates <*,G> > - A propogates the <*,G> join towards the RP > - Source sends traffic to A > - A encapsulates data in a register and sends it to RP > - RP decapsulates the packet and sends it to A > - A detects that it is receiving packets on the OIF, > then it sends a prune towards the RP. > > Ravi > From owner-pim@catarina.usc.edu Tue Oct 12 18:26:06 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28084 for ; Tue, 12 Oct 1999 18:26:05 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id PAA13825 for pim-list; Tue, 12 Oct 1999 15:16:11 -0700 Received: from mail2.packetengines.com (mail2.packetengines.com [208.227.187.173]) by catarina.usc.edu (8.6.10/8.6.9) with SMTP id PAA13818 for ; Tue, 12 Oct 1999 15:16:06 -0700 Received: from STEAM.corp.packetengines.com by mail2.packetengines.com via smtpd (for catarina.usc.edu [128.125.52.1]) with SMTP; 12 Oct 1999 22:16:06 UT Received: by STEAM.corp.packetengines.com with Internet Mail Service (5.5.2448.0) id ; Tue, 12 Oct 1999 15:13:31 -0700 Message-ID: From: Sudhir Cheruathur To: pim@catarina.usc.edu Subject: FW: PIM-SM source aggregation Date: Tue, 12 Oct 1999 15:13:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pim@catarina.usc.edu Precedence: bulk -----Original Message----- From: Liming Wei [mailto:lwei@siara.com] Sent: Tuesday, October 12, 1999 11:42 AM To: sudhir@packetengines.com Subject: Re: PIM-SM source aggregation Sudhir, If it is ok with you, please forward this message to the WG mailing list. The issue of source address aggregation is still a work-in-progress subject. Although the packet format allows source masks, no mechanism is put in place to utilize it yet. And there is not a known design to do source aggregation well, without side effects or showstoppers. That does not mean a truely simple yet effective way does not exist for source aggregation. It does require non-trivial design work. You are welcome to propose such a mechanism to the PIM working group, with the understanding that the discussions on it may generate more issues. If you like, I can put down 10 minutes for you to talk about this in the DC working group meeting. -Liming > From: Sudhir Cheruathur > > Hi Liming Wei, > > > I posted this question on the mailing list but I did not get any reply. > I hope it is ok to ask you directly. If it is inconvenient, my apologies. > > > My question is related to source aggregation in PIM-SM. > > > Consider the following network. > > R1----------------------R2------s1,s2 > | | > | | > R4----------------------R3 > | > G > > (in case the above figure is unreadable) > R1 is connected to R2 and R4. > R2 is connected to R3 and R1 > R3 is connected to R2 and R4 > R4 is connected to R1 and R3 > > > > Let R1 be the RP. > > Let sources 1.1.1.1(s1) and 1.1.1.2(s2) be connected > to R2 on another interface. > > A host on R4 wants to recv packets to group G. > > When source S1 starts to send packets to G, At > R2 (S,G) created is (1.1.1.0,G). > (I am assuming that it is ok to aggregate S in this way.) > > When source S2 starts to send packets to G. The above > (1.1.1.0,G) is used to send packets to the RP. > > Traffic starts to flow via RPT between R2 and R4 via the RP (R1). > > Now R4 initiates SPT towards S1. However the (S,G) > created here is (1.1.1.1,G), > > R4 sends a (1.1.1.1, G) join towards R2 via R3 > R3 creates (1.1.1.1,G) sends a join to R2. > > Now does R2 create (1.1.1.1,G) or use the already existing > (1.1.1.0,G) to join the SPT ? > > If it does i.e. use the existing aggregated entry, won't the > following happen ? > > At R4 (1.1.1.1,G) upstream R3. > At R3 (1.1.1.1,G) upstream R2. > At R2 (1.1.1.0,G) upstream local interface. > > Because of these states traffic from S2 (1.1.1.2) starts flowing > down the SPT tree (towards R3). But will get dropped at R3. > > > > Is it required that all routers use fully qualified source > addresses for (S,G) ? > > When looking up an existing (S,G)state while processing (S,G) joins/prunes, > should S's match exactly or should one use the longest match ? > > The J/P packets contain the netmask so intermediate routers > can have same (S,G) as the one who initiates the joins. > But what happens at the sender's/receiver's end, is it a policy decision ? > > Thanks a bunch. > > Regds > Sudhir C > From owner-pim@catarina.usc.edu Tue Oct 12 19:06:15 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28454 for ; Tue, 12 Oct 1999 19:06:12 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id QAA14113 for pim-list; Tue, 12 Oct 1999 16:00:38 -0700 Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id QAA14109; Tue, 12 Oct 1999 16:00:34 -0700 Received: from rumi (localhost [127.0.0.1]) by rumi.usc.edu (8.9.3/8.6.9) with ESMTP id PAA58131; Tue, 12 Oct 1999 15:59:57 -0700 (PDT) Message-Id: <199910122259.PAA58131@rumi.usc.edu> To: Sudhir Cheruathur cc: pim@catarina.usc.edu Subject: Re: FW: PIM-SM source aggregation In-reply-to: Your message of "Tue, 12 Oct 1999 15:13:31 PDT." Date: Tue, 12 Oct 1999 15:59:57 -0700 From: Pavlin Ivanov Radoslavov Sender: owner-pim@catarina.usc.edu Precedence: bulk > > My question is related to source aggregation in PIM-SM. > > > > > > Consider the following network. > > > > R1----------------------R2------s1,s2 > > | | > > | | > > R4----------------------R3 > > | > > G > > > > (in case the above figure is unreadable) > > R1 is connected to R2 and R4. > > R2 is connected to R3 and R1 > > R3 is connected to R2 and R4 > > R4 is connected to R1 and R3 > > > > > > > > Let R1 be the RP. > > > > Let sources 1.1.1.1(s1) and 1.1.1.2(s2) be connected > > to R2 on another interface. > > > > A host on R4 wants to recv packets to group G. > > > > When source S1 starts to send packets to G, At > > R2 (S,G) created is (1.1.1.0,G). > > (I am assuming that it is ok to aggregate S in this way.) > > > > When source S2 starts to send packets to G. The above > > (1.1.1.0,G) is used to send packets to the RP. > > > > Traffic starts to flow via RPT between R2 and R4 via the RP (R1). > > > > Now R4 initiates SPT towards S1. However the (S,G) > > created here is (1.1.1.1,G), > > > > R4 sends a (1.1.1.1, G) join towards R2 via R3 > > R3 creates (1.1.1.1,G) sends a join to R2. > > > > Now does R2 create (1.1.1.1,G) or use the already existing > > (1.1.1.0,G) to join the SPT ? If we assume that the router lookup supports longest prefix match, then R2 should create (1.1.1.1/32,G) with oif=(1.1.1.0/24,G)oifs+oif toward R3, and at the same time it should keep the existing (1.1.1.0/24,G). On the other side, if the s2 bw is low and if the overhead of sending it over R2-R3 is tolerable, then no need to add (1.1.1.1/32,G); instead, you should just add the R2-R3 oif to (1.1.1.0/24,G). However, this technique should be used more carefully than the first one. If the router doesn't support longest prefix match, then it either should split the aggregate (1.1.1.0/24,G) after the first (S,G) join is received (actually, it can delete the (1.1.1.0/24,G) and later will create "on demand" the (S,G)s for all active sources), or should use the second technique above (again, only if the total bw overhead is tolerable). There is nothing PIM-SM specific here, and it is router implementation issue. Could you tell me why are you concerned about the states in R2? It is quite likely that R2 will be an edge router, with relatively limited number of active senders, so it will have relatively small number of states. R1 (the RP) should be ot major concern, because it will have much larger number of states. Pavlin > > > > If it does i.e. use the existing aggregated entry, won't the > > following happen ? > > > > At R4 (1.1.1.1,G) upstream R3. > > At R3 (1.1.1.1,G) upstream R2. > > At R2 (1.1.1.0,G) upstream local interface. > > > > Because of these states traffic from S2 (1.1.1.2) starts flowing > > down the SPT tree (towards R3). But will get dropped at R3. > > > > > > > > Is it required that all routers use fully qualified source > > addresses for (S,G) ? > > > > When looking up an existing (S,G)state while processing (S,G) > joins/prunes, > > should S's match exactly or should one use the longest match ? > > > > The J/P packets contain the netmask so intermediate routers > > can have same (S,G) as the one who initiates the joins. > > But what happens at the sender's/receiver's end, is it a policy decision ? > > > > Thanks a bunch. > > > > Regds > > Sudhir C > > From owner-pim@catarina.usc.edu Wed Oct 13 00:37:27 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA04445 for ; Wed, 13 Oct 1999 00:37:26 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id VAA15418 for pim-list; Tue, 12 Oct 1999 21:32:46 -0700 Received: from hotmail.com (law-f257.hotmail.com [209.185.130.173]) by catarina.usc.edu (8.6.10/8.6.9) with SMTP id VAA15414 for ; Tue, 12 Oct 1999 21:32:42 -0700 Received: (qmail 69342 invoked by uid 0); 13 Oct 1999 04:30:08 -0000 Message-ID: <19991013043008.69341.qmail@hotmail.com> Received: from 192.135.245.219 by www.hotmail.com with HTTP; Tue, 12 Oct 1999 21:30:07 PDT X-Originating-IP: [192.135.245.219] From: "bhavesh pathak" To: pim@catarina.usc.edu Subject: sending of register stop message Date: Tue, 12 Oct 1999 21:30:07 PDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-pim@catarina.usc.edu Precedence: bulk Dear everybody, In following configaration I am not able to understand when RP will be able to send Register stop message to A? > > -------- | > |Source| | 1-----2 1-----2 1----2 1------2 | ---------- > |Host |--+---| A |---| B |---|RP|----| C |-----+---| Receiver| > -------- | ----- ----- ---- ------ | | Host2 | > -------> | ----------> -------------> ----------- >Data packet| Register forward > | decapsulated > | data packet > > In the above situation A sends register message to RP for (S,G)entry with RP bit set. At this time A will have : (S,G) entry with iif = A1, oif = NULL(??) Registering bit set Say RP has already existing (*,G) entry. When RP receives Register, - it will update iif to RP1 interface. - it will send Join/Prune message towards A with (S,G) having RPT and WC bit clear. - it will create (S,G) entry, copy oif from (*,G) entry with SPT bit clear. When A receives Join/Prune : - it will update oif to A2, - will start sending data unencapsulated to RP and also encapsulted in RP message. When RP receives unencapsulated data: - it will find that (S,G) register message and unencapsulated data are coming on the same interface. So, it will not set SPT bit. This situation will persist for ever. So, it will not (NEVER) send register-stop message? with regards, bhavesh ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-pim@catarina.usc.edu Wed Oct 13 01:14:49 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA05597 for ; Wed, 13 Oct 1999 01:14:48 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id WAA15601 for pim-list; Tue, 12 Oct 1999 22:09:23 -0700 Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id WAA15597; Tue, 12 Oct 1999 22:09:19 -0700 Received: from rumi (localhost [127.0.0.1]) by rumi.usc.edu (8.9.3/8.6.9) with ESMTP id WAA58996; Tue, 12 Oct 1999 22:08:42 -0700 (PDT) Message-Id: <199910130508.WAA58996@rumi.usc.edu> To: "bhavesh pathak" cc: pim@catarina.usc.edu Subject: Re: sending of register stop message In-reply-to: Your message of "Tue, 12 Oct 1999 21:30:07 PDT." <19991013043008.69341.qmail@hotmail.com> Date: Tue, 12 Oct 1999 22:08:41 -0700 From: Pavlin Ivanov Radoslavov Sender: owner-pim@catarina.usc.edu Precedence: bulk > Dear everybody, > > In following configaration I am not able to understand when > RP will be able to send Register stop message to A? > > > > > -------- | > > |Source| | 1-----2 1-----2 1----2 1------2 | ---------- > > |Host |--+---| A |---| B |---|RP|----| C |-----+---| Receiver| > > -------- | ----- ----- ---- ------ | | Host2 | > > -------> | ----------> -------------> ----------- > >Data packet| Register forward > > | decapsulated > > | data packet > > > > > In the above situation A sends register message to RP for > (S,G)entry with RP bit set. > At this time A will have : > (S,G) entry with iif = A1, oif = NULL(??) Registering bit set > > Say RP has already existing (*,G) entry. > When RP receives Register, > - it will update iif to RP1 interface. The (*,G) entry iif is never updated. The (*,G) entry in the RP will always have iif=register_vif. Only the (S,G) entry iif can change. Pavlin > - it will send Join/Prune message towards A with (S,G) having RPT > and WC bit clear. > - it will create (S,G) entry, copy oif from (*,G) entry with SPT bit > clear. > > When A receives Join/Prune : > - it will update oif to A2, > - will start sending data unencapsulated to RP and also encapsulted > in RP message. > > When RP receives unencapsulated data: > - it will find that (S,G) register message and unencapsulated data > are coming on the same interface. So, it will not set SPT bit. > This situation will persist for ever. > > So, it will not (NEVER) send register-stop message? > > with regards, > bhavesh > > > ______________________________________________________ > Get Your Private, Free Email at http://www.hotmail.com From owner-pim@catarina.usc.edu Wed Oct 13 01:16:26 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA05843 for ; Wed, 13 Oct 1999 01:16:25 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id WAA15659 for pim-list; Tue, 12 Oct 1999 22:13:16 -0700 Received: from kit.isi.edu (kit.isi.edu [128.9.160.207]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id WAA15653 for ; Tue, 12 Oct 1999 22:13:11 -0700 Received: (from eddy@localhost) by kit.isi.edu (8.9.2/8.8.7) id WAA26548; Tue, 12 Oct 1999 22:02:28 -0700 (PDT) (envelope-from eddy) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 12 Oct 1999 22:02:28 -0700 (PDT) From: eddy@isi.edu To: "bhavesh pathak" Cc: pim@catarina.usc.edu Subject: Re: sending of register stop message In-Reply-To: <19991013043008.69341.qmail@hotmail.com> References: <19991013043008.69341.qmail@hotmail.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14340.4465.510241.429429@kit.isi.edu> Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit bhavesh pathak states: > > When RP receives unencapsulated data: > - it will find that (S,G) register message and unencapsulated data > are coming on the same interface. So, it will not set SPT bit. > This situation will persist for ever. > while the register may arrive on the same interface as the native packet, the unicast register shouldn't be thought of as arriving on the physical interface because it may not. off-the-top-o-my-head i don't think there is a problem setting the spt on the RP since it's RPF(src) and RPF(RP) are indeed different :). and hence the subsequent arrival of a register will invoke a regstop. - rusty From owner-pim@catarina.usc.edu Wed Oct 13 02:43:04 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA15612 for ; Wed, 13 Oct 1999 02:43:04 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id XAA16030 for pim-list; Tue, 12 Oct 1999 23:39:26 -0700 Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id XAA16026 for ; Tue, 12 Oct 1999 23:39:21 -0700 Received: from ceng.usc.edu (helmy@ceng.usc.edu [128.125.253.190]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id XAA15894; Tue, 12 Oct 1999 23:39:20 -0700 (PDT) Received: from localhost (helmy@localhost) by ceng.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id XAA04457; Tue, 12 Oct 1999 23:39:21 -0700 (PDT) Date: Tue, 12 Oct 1999 23:39:21 -0700 (PDT) From: helmy To: bhavesh pathak cc: pim@catarina.usc.edu Subject: Re: sending of register stop message In-Reply-To: <19991013043008.69341.qmail@hotmail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pim@catarina.usc.edu Precedence: bulk > Dear everybody, > > In following configaration I am not able to understand when > RP will be able to send Register stop message to A? > > > > > -------- | > > |Source| | 1-----2 1-----2 1----2 1------2 | ---------- > > |Host |--+---| A |---| B |---|RP|----| C |-----+---| Receiver| > > -------- | ----- ----- ---- ------ | | Host2 | > > -------> | ----------> -------------> ----------- > >Data packet| Register forward > > | decapsulated > > | data packet > > > > > In the above situation A sends register message to RP for > (S,G)entry with RP bit set. > At this time A will have : > (S,G) entry with iif = A1, oif = NULL(??) Registering bit set > > Say RP has already existing (*,G) entry. > When RP receives Register, > - it will update iif to RP1 interface. > - it will send Join/Prune message towards A with (S,G) having RPT > and WC bit clear. > - it will create (S,G) entry, copy oif from (*,G) entry with SPT bit > clear. > > When A receives Join/Prune : > - it will update oif to A2, > - will start sending data unencapsulated to RP and also encapsulted > in RP message. > > When RP receives unencapsulated data: > - it will find that (S,G) register message and unencapsulated data > are coming on the same interface. So, it will not set SPT bit. > This situation will persist for ever. No, the register decapsulation S,G entry will have an incoming interface of the virtual interface (register vif), which indicates that the packet was encapsulated in registers. When the native data arrives at the RP it will match on the iif towards the Source, and not match on the register vif. In short, there are ways to distinguish between decapsulated registers and native data. For more info about the implementation details you should probably look at the implementation document in catarina.usc.edu/pim Regards, -A > > So, it will not (NEVER) send register-stop message? > > with regards, > bhavesh > > > ______________________________________________________ > Get Your Private, Free Email at http://www.hotmail.com > From owner-pim@catarina.usc.edu Wed Oct 13 08:03:53 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA19537 for ; Wed, 13 Oct 1999 08:03:53 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id EAA17730 for pim-list; Wed, 13 Oct 1999 04:59:06 -0700 Received: from hotmail.com (law-f128.hotmail.com [209.185.131.191]) by catarina.usc.edu (8.6.10/8.6.9) with SMTP id EAA17726 for ; Wed, 13 Oct 1999 04:59:00 -0700 Received: (qmail 9154 invoked by uid 0); 13 Oct 1999 11:58:30 -0000 Message-ID: <19991013115830.9153.qmail@hotmail.com> Received: from 192.135.245.219 by www.hotmail.com with HTTP; Wed, 13 Oct 1999 04:58:29 PDT X-Originating-IP: [192.135.245.219] From: "bhavesh pathak" To: pim@catarina.usc.edu Subject: W bit Date: Wed, 13 Oct 1999 04:58:29 PDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-pim@catarina.usc.edu Precedence: bulk Dear everyone, draft say tat (on page-49) " W The WC bit is a 1 bit value. If 1, the join or prune applies to the (*,G) or (*,*,RP) entry. If 0, the join or prune applies to the (S,G) entry where S is Source Address. Joins and prunes sent towards the RP must have this bit set." From above it looks as if Join/Prune for (S,G) cannot be sent towards RP. Is it correct? with regards, bhavesh ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-pim@catarina.usc.edu Wed Oct 13 13:54:12 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01232 for ; Wed, 13 Oct 1999 13:54:11 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id KAA18917 for pim-list; Wed, 13 Oct 1999 10:45:59 -0700 Received: from kit.isi.edu (kit.isi.edu [128.9.160.207]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id KAA18913 for ; Wed, 13 Oct 1999 10:45:47 -0700 Received: (from eddy@localhost) by kit.isi.edu (8.9.2/8.8.7) id KAA27657; Wed, 13 Oct 1999 10:34:58 -0700 (PDT) (envelope-from eddy) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 13 Oct 1999 10:34:58 -0700 (PDT) From: eddy@isi.edu To: "bhavesh pathak" Cc: pim@catarina.usc.edu Subject: Re: W bit In-Reply-To: <19991013115830.9153.qmail@hotmail.com> References: <19991013115830.9153.qmail@hotmail.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14340.49544.391265.895444@kit.isi.edu> Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit bhavesh pathak states: > Dear everyone, > draft say tat (on page-49) > " > W The WC bit is a 1 bit value. If 1, the join or prune > applies to the (*,G) or (*,*,RP) entry. If 0, the join > or prune applies to the (S,G) entry where S is Source > Address. Joins and prunes sent towards the RP must > have this bit set." > > >From above it looks as if Join/Prune for (S,G) cannot be sent > towards RP. Is it correct? > s,g prunes need to be sent to RP when your on the SPT for that paritcular source, you'd send it with the RPT bit set. AFAIK rfc2362 didn't explicitly talk about s,g joins to the RP, but I seem to remember an email where Dino confirmed that s,g.rpt joins toward the RP should be supported. - rusty From owner-pim@catarina.usc.edu Wed Oct 13 15:36:14 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA02793 for ; Wed, 13 Oct 1999 15:36:13 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id MAA19546 for pim-list; Wed, 13 Oct 1999 12:21:27 -0700 Received: from ntserver1.redstonecom.com (ntserver1.redstonecom.com [199.105.223.130]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id MAA19542 for ; Wed, 13 Oct 1999 12:21:21 -0700 Received: by NTSERVER1 with Internet Mail Service (5.0.1460.8) id <45HQPF4T>; Wed, 13 Oct 1999 15:20:51 -0400 Message-ID: <90ABC30C744ED311B16E00500464BEFC17AFB5@NTSERVER1> From: "Shekhar, Ravi" To: eddy@isi.edu, bhavesh pathak Cc: pim@catarina.usc.edu Subject: RE: W bit Date: Wed, 13 Oct 1999 15:20:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-pim@catarina.usc.edu Precedence: bulk > AFAIK rfc2362 didn't explicitly talk about s,g joins to the RP, but I > seem to remember an email where Dino confirmed that s,g.rpt joins > toward the RP should be supported. > RPT joins are at least useful in overriding RPT prunes. Sending <*, G>join to override has unwanted effect of getting all other pruned data too. - Ravi Shekhar. From owner-pim@catarina.usc.edu Wed Oct 13 15:58:32 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03113 for ; Wed, 13 Oct 1999 15:58:31 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id MAA19706 for pim-list; Wed, 13 Oct 1999 12:50:27 -0700 Received: from shrimp.baynetworks.com (ns4.BayNetworks.COM [192.32.253.7]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id MAA19702 for ; Wed, 13 Oct 1999 12:50:20 -0700 Received: from mailhost.BayNetworks.COM (h8754.s84f5.BayNetworks.COM [132.245.135.84]) by shrimp.baynetworks.com (8.9.1/8.9.1) with ESMTP id PAA23325; Wed, 13 Oct 1999 15:45:47 -0400 (EDT) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id PAA09122; Wed, 13 Oct 1999 15:45:14 -0400 (EDT) Received: from diamante.engeast (diamante [192.32.174.50]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id PAA11509; Wed, 13 Oct 1999 15:49:15 -0400 for Received: by diamante.engeast (SMI-8.6/SMI-SVR4) id PAA00743; Wed, 13 Oct 1999 15:49:15 -0400 Date: Wed, 13 Oct 1999 15:49:15 -0400 From: bng@BayNetworks.COM (Billy Ng) Message-Id: <199910131949.PAA00743@diamante.engeast> To: eddy@isi.edu, bhaveshpathak@hotmail.com, rshekhar@unisphere.cc Subject: RE: W bit Cc: pim@catarina.usc.edu X-Sun-Charset: US-ASCII Sender: owner-pim@catarina.usc.edu Precedence: bulk > From rshekhar@unisphere.cc Wed Oct 13 15:28:28 1999 > > > AFAIK rfc2362 didn't explicitly talk about s,g joins to the RP, but I > > seem to remember an email where Dino confirmed that s,g.rpt joins > > toward the RP should be supported. > > > > RPT joins are at least useful in overriding RPT prunes. > Sending <*, G>join to override has unwanted effect of getting all > other pruned data too. > > - Ravi Shekhar. > This is not true. Other (S,G)RPTs are still in the same packet with the (*,G), so no unwanted traffic for other flows. I do not see other reasons for having a (S,G)RPT join. --Billy From owner-pim@catarina.usc.edu Wed Oct 13 16:12:27 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA03373 for ; Wed, 13 Oct 1999 16:12:27 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id NAA19781 for pim-list; Wed, 13 Oct 1999 13:01:51 -0700 Received: from ntserver1.redstonecom.com (ntserver1.redstonecom.com [199.105.223.130]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id NAA19777 for ; Wed, 13 Oct 1999 13:01:46 -0700 Received: by NTSERVER1 with Internet Mail Service (5.0.1460.8) id <45HQPFZ2>; Wed, 13 Oct 1999 16:01:18 -0400 Message-ID: <90ABC30C744ED311B16E00500464BEFC17AFEB@NTSERVER1> From: "Shekhar, Ravi" To: bng@BayNetworks.COM, eddy@isi.edu, bhaveshpathak@hotmail.com, "Shekhar, Ravi" Cc: pim@catarina.usc.edu Subject: RE: W bit Date: Wed, 13 Oct 1999 16:01:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-pim@catarina.usc.edu Precedence: bulk > > > > RPT joins are at least useful in overriding G>RPT prunes. > > Sending <*, G>join to override has unwanted effect of getting all > > other pruned data too. > > > > - Ravi Shekhar. > > > > This is not true. Other (S,G)RPTs are still in the same packet with > the (*,G), so no unwanted traffic for other flows. I do not see other > reasons for having a (S,G)RPT join. My understanding is that this could potentially result in a vicious circle of prune overriding messages. Consider two routers: R1 with <*, G>joinprune and R2 with <*, G>joinprune state. Lets say R1 sends <*, G>joinprune to override some prune. Now in order to override R1's prune, R2 will send <*, G>joinprune. And then to override R2's prune, R1 will again send <*, G>joinprune ..... and so on.... One can do tricks with set-intersection of S's but if you increase the number of routers on the LAN, even that will end up generating quite a few number of messages in the worst case. - Ravi Shekhar. From owner-pim@catarina.usc.edu Wed Oct 13 16:31:10 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA03694 for ; Wed, 13 Oct 1999 16:31:09 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id NAA19952 for pim-list; Wed, 13 Oct 1999 13:25:23 -0700 Received: from scallop.baynetworks.com (ns5.baynetworks.com [194.133.90.101]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id NAA19948 for ; Wed, 13 Oct 1999 13:25:12 -0700 Received: from mailhost.BayNetworks.COM (h8754.s84f5.BayNetworks.COM [132.245.135.84]) by scallop.baynetworks.com (8.9.1/8.9.1) with ESMTP id WAA17386; Wed, 13 Oct 1999 22:27:08 +0200 (MET DST) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id QAA11581; Wed, 13 Oct 1999 16:20:33 -0400 (EDT) Received: from diamante.engeast (diamante [192.32.174.50]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id QAA20376; Wed, 13 Oct 1999 16:24:33 -0400 for Received: by diamante.engeast (SMI-8.6/SMI-SVR4) id QAA00832; Wed, 13 Oct 1999 16:24:34 -0400 Date: Wed, 13 Oct 1999 16:24:34 -0400 From: bng@BayNetworks.COM (Billy Ng) Message-Id: <199910132024.QAA00832@diamante.engeast> To: bng@BayNetworks.COM, eddy@isi.edu, bhaveshpathak@hotmail.com, rshekhar@unisphere.cc Subject: RE: W bit Cc: pim@catarina.usc.edu X-Sun-Charset: US-ASCII Sender: owner-pim@catarina.usc.edu Precedence: bulk > From rshekhar@unisphere.cc Wed Oct 13 16:06:05 1999 > > > > > > > RPT joins are at least useful in overriding > G>RPT prunes. > > > Sending <*, G>join to override has unwanted effect of getting all > > > other pruned data too. > > > > > > - Ravi Shekhar. > > > > > > > This is not true. Other (S,G)RPTs are still in the same packet with > > the (*,G), so no unwanted traffic for other flows. I do not see other > > reasons for having a (S,G)RPT join. > > My understanding is that this could potentially result in a vicious circle > > of prune overriding messages. > Agree for a shared LAN, but even a (S1,G)RPT join is not going to help since it has the same effect as a (*,G) join that does not include the (S1,G)RPT prune. The upstream router will see a prune then a join to override the prune in either case. --Billy > Consider two routers: R1 with <*, G>joinprune and R2 with > <*, G>joinprune state. > > Lets say R1 sends <*, G>joinprune to override some prune. > Now in order to override R1's prune, R2 will send <*, G>join G>prune. > And then to override R2's prune, R1 will again send <*, G>join G>prune > ..... and so on.... > > One can do tricks with set-intersection of S's but if you increase the > number of routers on the LAN, even that will end up generating quite a few > number of messages in the worst case. > > - Ravi Shekhar. > From owner-pim@catarina.usc.edu Wed Oct 13 16:49:19 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA04057 for ; Wed, 13 Oct 1999 16:49:18 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id NAA20319 for pim-list; Wed, 13 Oct 1999 13:39:55 -0700 Received: from ntserver1.redstonecom.com (ntserver1.redstonecom.com [199.105.223.130]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id NAA20315 for ; Wed, 13 Oct 1999 13:39:50 -0700 Received: by NTSERVER1 with Internet Mail Service (5.0.1460.8) id <45HQPF9P>; Wed, 13 Oct 1999 16:39:22 -0400 Message-ID: <90ABC30C744ED311B16E00500464BEFC17B036@NTSERVER1> From: "Shekhar, Ravi" To: bng@BayNetworks.COM, eddy@isi.edu, bhaveshpathak@hotmail.com, "Shekhar, Ravi" Cc: pim@catarina.usc.edu Subject: RE: W bit Date: Wed, 13 Oct 1999 16:39:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-pim@catarina.usc.edu Precedence: bulk > > My understanding is that this could potentially result in > a vicious circle > > > > of prune overriding messages. > > > > Agree for a shared LAN, but even a (S1,G)RPT join is not going to help > since it has the same effect as a (*,G) join that does not include > the (S1,G)RPT prune. The upstream router will see a prune then a join > to override the prune in either case. Well, RPTjoin will only join S1. Any S3, which has been pruned by all downstream routers, will not get joined by it. Whereas a <*, G> join will result in joining not just but also . - Ravi Shekhar. > > Consider two routers: R1 with <*, G>joinprune and R2 with > > <*, G>joinprune state. > > > > Lets say R1 sends <*, G>joinprune to override some prune. > > Now in order to override R1's prune, R2 will send > <*, G>join > G>prune. > > And then to override R2's prune, R1 will again > send <*, G>join > G>prune > > ..... and so on.... > > > > One can do tricks with set-intersection of S's but if you > increase the > > number of routers on the LAN, even that will end up > generating quite a few > > number of messages in the worst case. > > > > - Ravi Shekhar. > > > From owner-pim@catarina.usc.edu Wed Oct 13 18:05:55 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA05231 for ; Wed, 13 Oct 1999 18:05:54 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id OAA20807 for pim-list; Wed, 13 Oct 1999 14:59:39 -0700 Received: from kit.isi.edu (kit.isi.edu [128.9.160.207]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id OAA20803 for ; Wed, 13 Oct 1999 14:59:33 -0700 Received: (from eddy@localhost) by kit.isi.edu (8.9.2/8.8.7) id OAA28350; Wed, 13 Oct 1999 14:47:32 -0700 (PDT) (envelope-from eddy) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 13 Oct 1999 14:47:32 -0700 (PDT) From: eddy@isi.edu To: bng@BayNetworks.COM (Billy Ng) Cc: eddy@isi.edu, bhaveshpathak@hotmail.com, rshekhar@unisphere.cc, pim@catarina.usc.edu Subject: RE: W bit In-Reply-To: <199910131949.PAA00743@diamante.engeast> References: <199910131949.PAA00743@diamante.engeast> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14340.64761.465346.492649@kit.isi.edu> Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Billy Ng states: > > > This is not true. Other (S,G)RPTs are still in the same packet with > the (*,G), so no unwanted traffic for other flows. I do not see other > reasons for having a (S,G)RPT join. > > --Billy is there a good reason not to, otherwise why restrict it? someone may have a reason to pull a specific source from the RP (igmpv3, perhaps), source aggregation, etc. - rusty From owner-pim@catarina.usc.edu Wed Oct 13 18:20:23 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA05320 for ; Wed, 13 Oct 1999 18:20:22 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id PAA20973 for pim-list; Wed, 13 Oct 1999 15:13:54 -0700 Received: from kit.isi.edu (kit.isi.edu [128.9.160.207]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id PAA20967 for ; Wed, 13 Oct 1999 15:13:46 -0700 Received: (from eddy@localhost) by kit.isi.edu (8.9.2/8.8.7) id PAA28400; Wed, 13 Oct 1999 15:03:01 -0700 (PDT) (envelope-from eddy) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 13 Oct 1999 15:03:01 -0700 (PDT) From: eddy@isi.edu To: eddy@isi.edu Cc: bng@BayNetworks.COM (Billy Ng), bhaveshpathak@hotmail.com, rshekhar@unisphere.cc, pim@catarina.usc.edu Subject: RE: W bit In-Reply-To: <14340.64761.465346.492649@kit.isi.edu> References: <199910131949.PAA00743@diamante.engeast> <14340.64761.465346.492649@kit.isi.edu> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14341.369.342658.107275@kit.isi.edu> Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit eddy@ISI.EDU states: > > > is there a good reason not to, otherwise why restrict it? also Ravi's arguments are convincing. - rusty From owner-pim@catarina.usc.edu Thu Oct 14 00:40:10 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA11282 for ; Thu, 14 Oct 1999 00:40:09 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id VAA22653 for pim-list; Wed, 13 Oct 1999 21:32:50 -0700 Received: from lobster.baynetworks.com ([192.32.253.3]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id UAA22057 for ; Wed, 13 Oct 1999 20:10:37 -0700 Received: from mailhost.BayNetworks.COM (h8754.s84f5.BayNetworks.COM [132.245.135.84]) by lobster.baynetworks.com (8.9.1/8.9.1) with ESMTP id XAA14426; Wed, 13 Oct 1999 23:12:54 -0400 (EDT) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id XAA27671; Wed, 13 Oct 1999 23:05:33 -0400 (EDT) Received: from diamante.engeast (diamante [192.32.174.50]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id XAA22077; Wed, 13 Oct 1999 23:09:34 -0400 for Received: by diamante.engeast (SMI-8.6/SMI-SVR4) id XAA01054; Wed, 13 Oct 1999 23:09:35 -0400 Date: Wed, 13 Oct 1999 23:09:35 -0400 From: bng@BayNetworks.COM (Billy Ng) Message-Id: <199910140309.XAA01054@diamante.engeast> To: bng@BayNetworks.COM, eddy@isi.edu, bhaveshpathak@hotmail.com, rshekhar@unisphere.cc Subject: RE: W bit Cc: pim@catarina.usc.edu X-Sun-Charset: US-ASCII Sender: owner-pim@catarina.usc.edu Precedence: bulk > From rshekhar@unisphere.cc Wed Oct 13 16:40:36 1999 > > > > My understanding is that this could potentially result in > > a vicious circle > > > > > > of prune overriding messages. > > > > > > > Agree for a shared LAN, but even a (S1,G)RPT join is not going to help > > since it has the same effect as a (*,G) join that does not include > > the (S1,G)RPT prune. The upstream router will see a prune then a join > > to override the prune in either case. > > Well, RPTjoin will only join S1. Any S3, which has been pruned by > all downstream routers, will not get joined by it. Whereas a <*, G> join > will result in joining not just but also . > > - Ravi Shekhar. > As rusty pointed out, igmpv3 could use (S,G)RPT join for example. I was merely pointing out that with the current usage of PIM-SM, there is always a (*,G) on all RP tree, but yes, if only (S,G)RPT join exist without (*,G), then you have made your point. Thanks, --Billy > > > > Consider two routers: R1 with <*, G>joinprune and R2 with > > > <*, G>joinprune state. > > > > > > Lets say R1 sends <*, G>joinprune to override some prune. > > > Now in order to override R1's prune, R2 will send > > <*, G>join > > G>prune. > > > And then to override R2's prune, R1 will again > > send <*, G>join > > G>prune > > > ..... and so on.... > > > > > > One can do tricks with set-intersection of S's but if you > > increase the > > > number of routers on the LAN, even that will end up > > generating quite a few > > > number of messages in the worst case. > > > > > > - Ravi Shekhar. > > > > > > From owner-pim@catarina.usc.edu Thu Oct 14 00:45:00 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA11297 for ; Thu, 14 Oct 1999 00:44:59 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id VAA22928 for pim-list; Wed, 13 Oct 1999 21:40:47 -0700 Received: from usc.edu (root@[128.125.253.136]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id QAA21375 for ; Wed, 13 Oct 1999 16:56:36 -0700 Received: from ceng.usc.edu (helmy@ceng.usc.edu [128.125.253.190]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id QAA05746; Wed, 13 Oct 1999 16:56:35 -0700 (PDT) Received: from localhost (helmy@localhost) by ceng.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id QAA11711; Wed, 13 Oct 1999 16:56:35 -0700 (PDT) Date: Wed, 13 Oct 1999 16:55:01 -0700 (PDT) From: helmy To: Ravi Kiran Puvvala cc: pim@catarina.usc.edu Subject: Re: (PIM-SM)when source and receiver are on same LAN In-Reply-To: <199910121750.KAA13701@agni.iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pim@catarina.usc.edu Precedence: bulk > helmy writes: > > | when the receiver joins the group, A will create *,G with iif pointing > | towards RP (i.e. A2) and oif pointing towards the LAN (i.e. A1). However > | since it has S,G and *,G with different iifs, it sends a prune for S,G > | towards the RP. > > When does A detect that it has both <*,G> and with different IIF's. > > I think ... > > - Receiver1 joins G > - A creates <*,G> > - A propogates the <*,G> join towards the RP > - Source sends traffic to A > - A encapsulates data in a register and sends it to RP > - RP decapsulates the packet and sends it to A > - A detects that it is receiving packets on the OIF, > then it sends a prune towards the RP. actually, the fact that A has 2 entries (S,G) for registers and (*,G), is what triggers the prunes. Another scenario is when the receiver joins first then the sender starts sending, same rules apply, Regards, -Ahmed > > Ravi > From owner-pim@catarina.usc.edu Thu Oct 14 00:54:49 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA11333 for ; Thu, 14 Oct 1999 00:54:49 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id VAA22777 for pim-list; Wed, 13 Oct 1999 21:38:02 -0700 Received: from mail-green.research.att.com ([135.207.30.103]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id SAA21733 for ; Wed, 13 Oct 1999 18:40:57 -0700 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id C614D1E01B for ; Wed, 13 Oct 1999 21:40:55 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id VAA01275 for ; Wed, 13 Oct 1999 21:40:55 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id SAA26170; Wed, 13 Oct 1999 18:40:54 -0700 (PDT) Message-Id: <199910140140.SAA26170@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: pim@catarina.usc.edu Subject: Hello message option numbers Date: Wed, 13 Oct 1999 18:40:53 -0700 Versions: dmail (solaris) 2.2e/makemail 2.8u Sender: owner-pim@catarina.usc.edu Precedence: bulk Hi, draft-ietf-idmr-pimv2-dr-priority-00.txt said that the DR Priority option was #19. draft-ietf-pim-v2-sm-00.txt says that it's #18 and that #19 is bidir-capable. Is this a problem? Bill From owner-pim@catarina.usc.edu Thu Oct 14 02:09:30 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA21077 for ; Thu, 14 Oct 1999 02:09:29 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id VAA22379 for pim-list; Wed, 13 Oct 1999 21:11:19 -0700 Received: from usc.edu (root@[128.125.253.136]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id QAA21375 for ; Wed, 13 Oct 1999 16:56:36 -0700 Received: from ceng.usc.edu (helmy@ceng.usc.edu [128.125.253.190]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id QAA05746; Wed, 13 Oct 1999 16:56:35 -0700 (PDT) Received: from localhost (helmy@localhost) by ceng.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id QAA11711; Wed, 13 Oct 1999 16:56:35 -0700 (PDT) Date: Wed, 13 Oct 1999 16:55:01 -0700 (PDT) From: helmy To: Ravi Kiran Puvvala cc: pim@catarina.usc.edu Subject: Re: (PIM-SM)when source and receiver are on same LAN In-Reply-To: <199910121750.KAA13701@agni.iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pim@catarina.usc.edu Precedence: bulk > helmy writes: > > | when the receiver joins the group, A will create *,G with iif pointing > | towards RP (i.e. A2) and oif pointing towards the LAN (i.e. A1). However > | since it has S,G and *,G with different iifs, it sends a prune for S,G > | towards the RP. > > When does A detect that it has both <*,G> and with different IIF's. > > I think ... > > - Receiver1 joins G > - A creates <*,G> > - A propogates the <*,G> join towards the RP > - Source sends traffic to A > - A encapsulates data in a register and sends it to RP > - RP decapsulates the packet and sends it to A > - A detects that it is receiving packets on the OIF, > then it sends a prune towards the RP. actually, the fact that A has 2 entries (S,G) for registers and (*,G), is what triggers the prunes. Another scenario is when the receiver joins first then the sender starts sending, same rules apply, Regards, -Ahmed > > Ravi > From owner-pim@catarina.usc.edu Thu Oct 14 02:16:04 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA22354 for ; Thu, 14 Oct 1999 02:16:04 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id VAA22342 for pim-list; Wed, 13 Oct 1999 21:10:53 -0700 Received: from mail-green.research.att.com ([135.207.30.103]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id SAA21733 for ; Wed, 13 Oct 1999 18:40:57 -0700 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id C614D1E01B for ; Wed, 13 Oct 1999 21:40:55 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id VAA01275 for ; Wed, 13 Oct 1999 21:40:55 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id SAA26170; Wed, 13 Oct 1999 18:40:54 -0700 (PDT) Message-Id: <199910140140.SAA26170@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: pim@catarina.usc.edu Subject: Hello message option numbers Date: Wed, 13 Oct 1999 18:40:53 -0700 Versions: dmail (solaris) 2.2e/makemail 2.8u Sender: owner-pim@catarina.usc.edu Precedence: bulk Hi, draft-ietf-idmr-pimv2-dr-priority-00.txt said that the DR Priority option was #19. draft-ietf-pim-v2-sm-00.txt says that it's #18 and that #19 is bidir-capable. Is this a problem? Bill From owner-pim@catarina.usc.edu Thu Oct 14 02:40:14 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA22626 for ; Thu, 14 Oct 1999 02:40:13 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id VAA22317 for pim-list; Wed, 13 Oct 1999 21:10:33 -0700 Received: from lobster.baynetworks.com ([192.32.253.3]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id UAA22057 for ; Wed, 13 Oct 1999 20:10:37 -0700 Received: from mailhost.BayNetworks.COM (h8754.s84f5.BayNetworks.COM [132.245.135.84]) by lobster.baynetworks.com (8.9.1/8.9.1) with ESMTP id XAA14426; Wed, 13 Oct 1999 23:12:54 -0400 (EDT) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id XAA27671; Wed, 13 Oct 1999 23:05:33 -0400 (EDT) Received: from diamante.engeast (diamante [192.32.174.50]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id XAA22077; Wed, 13 Oct 1999 23:09:34 -0400 for Received: by diamante.engeast (SMI-8.6/SMI-SVR4) id XAA01054; Wed, 13 Oct 1999 23:09:35 -0400 Date: Wed, 13 Oct 1999 23:09:35 -0400 From: bng@BayNetworks.COM (Billy Ng) Message-Id: <199910140309.XAA01054@diamante.engeast> To: bng@BayNetworks.COM, eddy@isi.edu, bhaveshpathak@hotmail.com, rshekhar@unisphere.cc Subject: RE: W bit Cc: pim@catarina.usc.edu X-Sun-Charset: US-ASCII Sender: owner-pim@catarina.usc.edu Precedence: bulk > From rshekhar@unisphere.cc Wed Oct 13 16:40:36 1999 > > > > My understanding is that this could potentially result in > > a vicious circle > > > > > > of prune overriding messages. > > > > > > > Agree for a shared LAN, but even a (S1,G)RPT join is not going to help > > since it has the same effect as a (*,G) join that does not include > > the (S1,G)RPT prune. The upstream router will see a prune then a join > > to override the prune in either case. > > Well, RPTjoin will only join S1. Any S3, which has been pruned by > all downstream routers, will not get joined by it. Whereas a <*, G> join > will result in joining not just but also . > > - Ravi Shekhar. > As rusty pointed out, igmpv3 could use (S,G)RPT join for example. I was merely pointing out that with the current usage of PIM-SM, there is always a (*,G) on all RP tree, but yes, if only (S,G)RPT join exist without (*,G), then you have made your point. Thanks, --Billy > > > > Consider two routers: R1 with <*, G>joinprune and R2 with > > > <*, G>joinprune state. > > > > > > Lets say R1 sends <*, G>joinprune to override some prune. > > > Now in order to override R1's prune, R2 will send > > <*, G>join > > G>prune. > > > And then to override R2's prune, R1 will again > > send <*, G>join > > G>prune > > > ..... and so on.... > > > > > > One can do tricks with set-intersection of S's but if you > > increase the > > > number of routers on the LAN, even that will end up > > generating quite a few > > > number of messages in the worst case. > > > > > > - Ravi Shekhar. > > > > > > From owner-pim@catarina.usc.edu Thu Oct 14 02:44:16 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA22641 for ; Thu, 14 Oct 1999 02:44:15 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id UAA22105 for pim-list; Wed, 13 Oct 1999 20:11:04 -0700 Received: from usc.edu (root@[128.125.253.136]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id QAA21375 for ; Wed, 13 Oct 1999 16:56:36 -0700 Received: from ceng.usc.edu (helmy@ceng.usc.edu [128.125.253.190]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id QAA05746; Wed, 13 Oct 1999 16:56:35 -0700 (PDT) Received: from localhost (helmy@localhost) by ceng.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id QAA11711; Wed, 13 Oct 1999 16:56:35 -0700 (PDT) Date: Wed, 13 Oct 1999 16:55:01 -0700 (PDT) From: helmy To: Ravi Kiran Puvvala cc: pim@catarina.usc.edu Subject: Re: (PIM-SM)when source and receiver are on same LAN In-Reply-To: <199910121750.KAA13701@agni.iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pim@catarina.usc.edu Precedence: bulk > helmy writes: > > | when the receiver joins the group, A will create *,G with iif pointing > | towards RP (i.e. A2) and oif pointing towards the LAN (i.e. A1). However > | since it has S,G and *,G with different iifs, it sends a prune for S,G > | towards the RP. > > When does A detect that it has both <*,G> and with different IIF's. > > I think ... > > - Receiver1 joins G > - A creates <*,G> > - A propogates the <*,G> join towards the RP > - Source sends traffic to A > - A encapsulates data in a register and sends it to RP > - RP decapsulates the packet and sends it to A > - A detects that it is receiving packets on the OIF, > then it sends a prune towards the RP. actually, the fact that A has 2 entries (S,G) for registers and (*,G), is what triggers the prunes. Another scenario is when the receiver joins first then the sender starts sending, same rules apply, Regards, -Ahmed > > Ravi > From owner-pim@catarina.usc.edu Thu Oct 14 02:44:33 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA22658 for ; Thu, 14 Oct 1999 02:44:32 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id UAA22052 for pim-list; Wed, 13 Oct 1999 20:10:34 -0700 Received: from mail-green.research.att.com ([135.207.30.103]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id SAA21733 for ; Wed, 13 Oct 1999 18:40:57 -0700 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id C614D1E01B for ; Wed, 13 Oct 1999 21:40:55 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id VAA01275 for ; Wed, 13 Oct 1999 21:40:55 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id SAA26170; Wed, 13 Oct 1999 18:40:54 -0700 (PDT) Message-Id: <199910140140.SAA26170@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: pim@catarina.usc.edu Subject: Hello message option numbers Date: Wed, 13 Oct 1999 18:40:53 -0700 Versions: dmail (solaris) 2.2e/makemail 2.8u Sender: owner-pim@catarina.usc.edu Precedence: bulk Hi, draft-ietf-idmr-pimv2-dr-priority-00.txt said that the DR Priority option was #19. draft-ietf-pim-v2-sm-00.txt says that it's #18 and that #19 is bidir-capable. Is this a problem? Bill From owner-pim@catarina.usc.edu Thu Oct 14 02:49:17 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA22683 for ; Thu, 14 Oct 1999 02:49:16 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id UAA22086 for pim-list; Wed, 13 Oct 1999 20:10:53 -0700 Received: from lobster.baynetworks.com ([192.32.253.3]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id UAA22057 for ; Wed, 13 Oct 1999 20:10:37 -0700 Received: from mailhost.BayNetworks.COM (h8754.s84f5.BayNetworks.COM [132.245.135.84]) by lobster.baynetworks.com (8.9.1/8.9.1) with ESMTP id XAA14426; Wed, 13 Oct 1999 23:12:54 -0400 (EDT) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id XAA27671; Wed, 13 Oct 1999 23:05:33 -0400 (EDT) Received: from diamante.engeast (diamante [192.32.174.50]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id XAA22077; Wed, 13 Oct 1999 23:09:34 -0400 for Received: by diamante.engeast (SMI-8.6/SMI-SVR4) id XAA01054; Wed, 13 Oct 1999 23:09:35 -0400 Date: Wed, 13 Oct 1999 23:09:35 -0400 From: bng@BayNetworks.COM (Billy Ng) Message-Id: <199910140309.XAA01054@diamante.engeast> To: bng@BayNetworks.COM, eddy@isi.edu, bhaveshpathak@hotmail.com, rshekhar@unisphere.cc Subject: RE: W bit Cc: pim@catarina.usc.edu X-Sun-Charset: US-ASCII Sender: owner-pim@catarina.usc.edu Precedence: bulk > From rshekhar@unisphere.cc Wed Oct 13 16:40:36 1999 > > > > My understanding is that this could potentially result in > > a vicious circle > > > > > > of prune overriding messages. > > > > > > > Agree for a shared LAN, but even a (S1,G)RPT join is not going to help > > since it has the same effect as a (*,G) join that does not include > > the (S1,G)RPT prune. The upstream router will see a prune then a join > > to override the prune in either case. > > Well, RPTjoin will only join S1. Any S3, which has been pruned by > all downstream routers, will not get joined by it. Whereas a <*, G> join > will result in joining not just but also . > > - Ravi Shekhar. > As rusty pointed out, igmpv3 could use (S,G)RPT join for example. I was merely pointing out that with the current usage of PIM-SM, there is always a (*,G) on all RP tree, but yes, if only (S,G)RPT join exist without (*,G), then you have made your point. Thanks, --Billy > > > > Consider two routers: R1 with <*, G>joinprune and R2 with > > > <*, G>joinprune state. > > > > > > Lets say R1 sends <*, G>joinprune to override some prune. > > > Now in order to override R1's prune, R2 will send > > <*, G>join > > G>prune. > > > And then to override R2's prune, R1 will again > > send <*, G>join > > G>prune > > > ..... and so on.... > > > > > > One can do tricks with set-intersection of S's but if you > > increase the > > > number of routers on the LAN, even that will end up > > generating quite a few > > > number of messages in the worst case. > > > > > > - Ravi Shekhar. > > > > > > From owner-pim@catarina.usc.edu Thu Oct 14 02:55:10 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA22703 for ; Thu, 14 Oct 1999 02:55:09 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id TAA21838 for pim-list; Wed, 13 Oct 1999 19:10:28 -0700 Received: from mail-green.research.att.com ([135.207.30.103]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id SAA21733 for ; Wed, 13 Oct 1999 18:40:57 -0700 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id C614D1E01B for ; Wed, 13 Oct 1999 21:40:55 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id VAA01275 for ; Wed, 13 Oct 1999 21:40:55 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id SAA26170; Wed, 13 Oct 1999 18:40:54 -0700 (PDT) Message-Id: <199910140140.SAA26170@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: pim@catarina.usc.edu Subject: Hello message option numbers Date: Wed, 13 Oct 1999 18:40:53 -0700 Versions: dmail (solaris) 2.2e/makemail 2.8u Sender: owner-pim@catarina.usc.edu Precedence: bulk Hi, draft-ietf-idmr-pimv2-dr-priority-00.txt said that the DR Priority option was #19. draft-ietf-pim-v2-sm-00.txt says that it's #18 and that #19 is bidir-capable. Is this a problem? Bill From owner-pim@catarina.usc.edu Thu Oct 14 03:06:54 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA22842 for ; Thu, 14 Oct 1999 03:06:53 -0400 (EDT) From: owner-pim@catarina.usc.edu Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id AAA24432 for pim-list; Thu, 14 Oct 1999 00:01:17 -0700 Date: Thu, 14 Oct 1999 00:01:17 -0700 Message-Id: <199910140701.AAA24432@catarina.usc.edu> Apparently-To: pim-list@catarina.usc.edu From owner-pim@catarina.usc.edu Thu Oct 14 03:07:53 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA22863 for ; Thu, 14 Oct 1999 03:07:52 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id SAA21737 for pim-list; Wed, 13 Oct 1999 18:41:01 -0700 Received: from mail-green.research.att.com ([135.207.30.103]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id SAA21733 for ; Wed, 13 Oct 1999 18:40:57 -0700 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id C614D1E01B for ; Wed, 13 Oct 1999 21:40:55 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id VAA01275 for ; Wed, 13 Oct 1999 21:40:55 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id SAA26170; Wed, 13 Oct 1999 18:40:54 -0700 (PDT) Message-Id: <199910140140.SAA26170@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: pim@catarina.usc.edu Subject: Hello message option numbers Date: Wed, 13 Oct 1999 18:40:53 -0700 Versions: dmail (solaris) 2.2e/makemail 2.8u Sender: owner-pim@catarina.usc.edu Precedence: bulk Hi, draft-ietf-idmr-pimv2-dr-priority-00.txt said that the DR Priority option was #19. draft-ietf-pim-v2-sm-00.txt says that it's #18 and that #19 is bidir-capable. Is this a problem? Bill From owner-pim@catarina.usc.edu Thu Oct 14 03:17:04 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA22934 for ; Thu, 14 Oct 1999 03:17:03 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id TAA21883 for pim-list; Wed, 13 Oct 1999 19:10:53 -0700 Received: from usc.edu (root@[128.125.253.136]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id QAA21375 for ; Wed, 13 Oct 1999 16:56:36 -0700 Received: from ceng.usc.edu (helmy@ceng.usc.edu [128.125.253.190]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id QAA05746; Wed, 13 Oct 1999 16:56:35 -0700 (PDT) Received: from localhost (helmy@localhost) by ceng.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id QAA11711; Wed, 13 Oct 1999 16:56:35 -0700 (PDT) Date: Wed, 13 Oct 1999 16:55:01 -0700 (PDT) From: helmy To: Ravi Kiran Puvvala cc: pim@catarina.usc.edu Subject: Re: (PIM-SM)when source and receiver are on same LAN In-Reply-To: <199910121750.KAA13701@agni.iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pim@catarina.usc.edu Precedence: bulk > helmy writes: > > | when the receiver joins the group, A will create *,G with iif pointing > | towards RP (i.e. A2) and oif pointing towards the LAN (i.e. A1). However > | since it has S,G and *,G with different iifs, it sends a prune for S,G > | towards the RP. > > When does A detect that it has both <*,G> and with different IIF's. > > I think ... > > - Receiver1 joins G > - A creates <*,G> > - A propogates the <*,G> join towards the RP > - Source sends traffic to A > - A encapsulates data in a register and sends it to RP > - RP decapsulates the packet and sends it to A > - A detects that it is receiving packets on the OIF, > then it sends a prune towards the RP. actually, the fact that A has 2 entries (S,G) for registers and (*,G), is what triggers the prunes. Another scenario is when the receiver joins first then the sender starts sending, same rules apply, Regards, -Ahmed > > Ravi > From owner-pim@catarina.usc.edu Thu Oct 14 03:19:54 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA22945 for ; Thu, 14 Oct 1999 03:19:53 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id SAA21626 for pim-list; Wed, 13 Oct 1999 18:10:45 -0700 Received: from usc.edu (root@[128.125.253.136]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id QAA21375 for ; Wed, 13 Oct 1999 16:56:36 -0700 Received: from ceng.usc.edu (helmy@ceng.usc.edu [128.125.253.190]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id QAA05746; Wed, 13 Oct 1999 16:56:35 -0700 (PDT) Received: from localhost (helmy@localhost) by ceng.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id QAA11711; Wed, 13 Oct 1999 16:56:35 -0700 (PDT) Date: Wed, 13 Oct 1999 16:55:01 -0700 (PDT) From: helmy To: Ravi Kiran Puvvala cc: pim@catarina.usc.edu Subject: Re: (PIM-SM)when source and receiver are on same LAN In-Reply-To: <199910121750.KAA13701@agni.iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pim@catarina.usc.edu Precedence: bulk > helmy writes: > > | when the receiver joins the group, A will create *,G with iif pointing > | towards RP (i.e. A2) and oif pointing towards the LAN (i.e. A1). However > | since it has S,G and *,G with different iifs, it sends a prune for S,G > | towards the RP. > > When does A detect that it has both <*,G> and with different IIF's. > > I think ... > > - Receiver1 joins G > - A creates <*,G> > - A propogates the <*,G> join towards the RP > - Source sends traffic to A > - A encapsulates data in a register and sends it to RP > - RP decapsulates the packet and sends it to A > - A detects that it is receiving packets on the OIF, > then it sends a prune towards the RP. actually, the fact that A has 2 entries (S,G) for registers and (*,G), is what triggers the prunes. Another scenario is when the receiver joins first then the sender starts sending, same rules apply, Regards, -Ahmed > > Ravi > From owner-pim@catarina.usc.edu Thu Oct 14 03:24:13 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA22961 for ; Thu, 14 Oct 1999 03:24:12 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id RAA21428 for pim-list; Wed, 13 Oct 1999 17:10:26 -0700 Received: from usc.edu (root@[128.125.253.136]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id QAA21375 for ; Wed, 13 Oct 1999 16:56:36 -0700 Received: from ceng.usc.edu (helmy@ceng.usc.edu [128.125.253.190]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id QAA05746; Wed, 13 Oct 1999 16:56:35 -0700 (PDT) Received: from localhost (helmy@localhost) by ceng.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id QAA11711; Wed, 13 Oct 1999 16:56:35 -0700 (PDT) Date: Wed, 13 Oct 1999 16:55:01 -0700 (PDT) From: helmy To: Ravi Kiran Puvvala cc: pim@catarina.usc.edu Subject: Re: (PIM-SM)when source and receiver are on same LAN In-Reply-To: <199910121750.KAA13701@agni.iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pim@catarina.usc.edu Precedence: bulk > helmy writes: > > | when the receiver joins the group, A will create *,G with iif pointing > | towards RP (i.e. A2) and oif pointing towards the LAN (i.e. A1). However > | since it has S,G and *,G with different iifs, it sends a prune for S,G > | towards the RP. > > When does A detect that it has both <*,G> and with different IIF's. > > I think ... > > - Receiver1 joins G > - A creates <*,G> > - A propogates the <*,G> join towards the RP > - Source sends traffic to A > - A encapsulates data in a register and sends it to RP > - RP decapsulates the packet and sends it to A > - A detects that it is receiving packets on the OIF, > then it sends a prune towards the RP. actually, the fact that A has 2 entries (S,G) for registers and (*,G), is what triggers the prunes. Another scenario is when the receiver joins first then the sender starts sending, same rules apply, Regards, -Ahmed > > Ravi > From owner-pim@catarina.usc.edu Thu Oct 14 03:27:28 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA22994 for ; Thu, 14 Oct 1999 03:27:27 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id QAA21379 for pim-list; Wed, 13 Oct 1999 16:56:40 -0700 Received: from usc.edu (root@[128.125.253.136]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id QAA21375 for ; Wed, 13 Oct 1999 16:56:36 -0700 Received: from ceng.usc.edu (helmy@ceng.usc.edu [128.125.253.190]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id QAA05746; Wed, 13 Oct 1999 16:56:35 -0700 (PDT) Received: from localhost (helmy@localhost) by ceng.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id QAA11711; Wed, 13 Oct 1999 16:56:35 -0700 (PDT) Date: Wed, 13 Oct 1999 16:55:01 -0700 (PDT) From: helmy To: Ravi Kiran Puvvala cc: pim@catarina.usc.edu Subject: Re: (PIM-SM)when source and receiver are on same LAN In-Reply-To: <199910121750.KAA13701@agni.iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pim@catarina.usc.edu Precedence: bulk > helmy writes: > > | when the receiver joins the group, A will create *,G with iif pointing > | towards RP (i.e. A2) and oif pointing towards the LAN (i.e. A1). However > | since it has S,G and *,G with different iifs, it sends a prune for S,G > | towards the RP. > > When does A detect that it has both <*,G> and with different IIF's. > > I think ... > > - Receiver1 joins G > - A creates <*,G> > - A propogates the <*,G> join towards the RP > - Source sends traffic to A > - A encapsulates data in a register and sends it to RP > - RP decapsulates the packet and sends it to A > - A detects that it is receiving packets on the OIF, > then it sends a prune towards the RP. actually, the fact that A has 2 entries (S,G) for registers and (*,G), is what triggers the prunes. Another scenario is when the receiver joins first then the sender starts sending, same rules apply, Regards, -Ahmed > > Ravi > From owner-pim@catarina.usc.edu Sun Oct 17 07:28:47 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA06698 for ; Sun, 17 Oct 1999 07:28:47 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id EAA02015 for pim-list; Sun, 17 Oct 1999 04:23:39 -0700 Received: from hotmail.com (law-f230.hotmail.com [209.185.130.168]) by catarina.usc.edu (8.6.10/8.6.9) with SMTP id EAA02011 for ; Sun, 17 Oct 1999 04:23:34 -0700 Received: (qmail 74760 invoked by uid 0); 17 Oct 1999 11:23:04 -0000 Message-ID: <19991017112304.74759.qmail@hotmail.com> Received: from 192.135.245.219 by www.hotmail.com with HTTP; Sun, 17 Oct 1999 04:23:04 PDT X-Originating-IP: [192.135.245.219] From: "bhavesh pathak" To: pim@catarina.usc.edu Subject: (PIM-SM) subsection-3 of 3.2.2 Date: Sun, 17 Oct 1999 04:23:04 PDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-pim@catarina.usc.edu Precedence: bulk Dear everyone, I am not able to understand following part from the section 3.2.2. 3. For each (Si,G) entry associated with group G: i) if Si is not included in the prune list, ii) if I is not on the same subnet as the address Si, and iii) if I is not the iif, then interface I is added to the oif list and the Oif-timer for that interface in each affected entry is increased (never decreased) to the Holdtime included in the Join/Prune message. In addition, if the Oif-timer for that interface is increased, the Oif-Deletion-Delay for that interface is set to 1/3rd the Holdtime specified in the Join/Prune message. If the group address in the Join/Prune message is `*' then every (*,G) and (S,G) entry, whose group address hashes to the RP indicated in the (*,*,RP) Join/Prune message, is updated accordingly. A `*' in the group field of the Join/Prune is represented by a group address 224.0.0.0 and a group mask length of 4, indicating a (*,*,RP) Join. can someone help me to understand above part with some example or something like that.. with regards, bhavesh ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-pim@catarina.usc.edu Sun Oct 17 08:00:59 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07040 for ; Sun, 17 Oct 1999 08:00:57 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id EAA02125 for pim-list; Sun, 17 Oct 1999 04:58:20 -0700 Received: from hotmail.com (law-f129.hotmail.com [209.185.131.192]) by catarina.usc.edu (8.6.10/8.6.9) with SMTP id EAA02121 for ; Sun, 17 Oct 1999 04:58:17 -0700 Received: (qmail 22132 invoked by uid 0); 17 Oct 1999 11:40:47 -0000 Message-ID: <19991017114047.22131.qmail@hotmail.com> Received: from 192.135.245.219 by www.hotmail.com with HTTP; Sun, 17 Oct 1999 04:40:47 PDT X-Originating-IP: [192.135.245.219] From: "bhavesh pathak" To: pim@catarina.usc.edu Subject: (PIM-SM) prune list processing Date: Sun, 17 Oct 1999 04:40:47 PDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-pim@catarina.usc.edu Precedence: bulk Dear everyone, In the prune-list processing part of PIM-SM draft says that, (sec 3.2.2) 1. For each address, Sp, in the prune list whose RPT-bit and WC-bit are cleared: 1. ... (able to understand) 2. If the router has a current (*,G), or (*,*,RP), route entry, and if the existing (Sp,G) entry has its RPT-bit flag set to 1, then this (Sp,G)RPT-bit entry is maintained (not deleted) even if its outgoing interface list is null. I am not able to understand the details given the second subsection. can someone help to understand? with regards, bhavesh ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-pim@catarina.usc.edu Sun Oct 17 08:10:26 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07204 for ; Sun, 17 Oct 1999 08:10:25 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id FAA02218 for pim-list; Sun, 17 Oct 1999 05:07:56 -0700 Received: from hotmail.com (law-f58.hotmail.com [209.185.131.121]) by catarina.usc.edu (8.6.10/8.6.9) with SMTP id FAA02214 for ; Sun, 17 Oct 1999 05:07:52 -0700 Received: (qmail 42467 invoked by uid 0); 17 Oct 1999 12:07:21 -0000 Message-ID: <19991017120721.42466.qmail@hotmail.com> Received: from 192.135.245.219 by www.hotmail.com with HTTP; Sun, 17 Oct 1999 05:07:21 PDT X-Originating-IP: [192.135.245.219] From: "bhavesh pathak" To: pim@catarina.usc.edu Subject: (PIM-SM) source address in register stop message Date: Sun, 17 Oct 1999 05:07:21 PDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-pim@catarina.usc.edu Precedence: bulk Dear everybody, In section 3.3.2 PIM-SM draft says that, 2. If the matching (S,G) or (*,G) state contains a null oif list, the RP unicasts a Register-Stop message to the source of the Register message; in the latter case, the source-address field, within the Register-Stop message, is set to the wildcard value (all 0's). This message is not processed by intermediate routers, hence no (S,G) state is constructed between the RP and the source. Register-stop message is unicasted to sender of Register-Request. So, In all the cases (whether source address is all 0's or not) register-stop message will be processed by only source of Register-Request and never by intermediate routers. So, significance of setting source address to all 0's when matching entry is (*,G)? with regards, bhavesh ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-pim@catarina.usc.edu Sun Oct 17 08:39:21 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07514 for ; Sun, 17 Oct 1999 08:39:20 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id FAA02314 for pim-list; Sun, 17 Oct 1999 05:35:15 -0700 Received: from hotmail.com (law-f99.hotmail.com [209.185.131.162]) by catarina.usc.edu (8.6.10/8.6.9) with SMTP id FAA02310 for ; Sun, 17 Oct 1999 05:35:11 -0700 Received: (qmail 11144 invoked by uid 0); 17 Oct 1999 12:34:40 -0000 Message-ID: <19991017123440.11143.qmail@hotmail.com> Received: from 192.135.245.219 by www.hotmail.com with HTTP; Sun, 17 Oct 1999 05:34:40 PDT X-Originating-IP: [192.135.245.219] From: "bhavesh pathak" To: pim@catarina.usc.edu Subject: (PIM-SM) processing of received assert message Date: Sun, 17 Oct 1999 05:34:40 PDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-pim@catarina.usc.edu Precedence: bulk Dear everyone, a. When assert message is received on the outgoing interface, longest match is used to match with the entry, but if the ^^^^^^^ assert message is received on the incoming interface exact ^^^^^ match is enforced. Why such a difference? b. "Receiving Asserts on an entry's incoming interface" section says that, 2 If the downstream routers have downstream members, and if the Assert caused the RPF neighbor to change, the downstream routers must trigger a Join/Prune message to inform the upstream router that packets are to be forwarded on the multi-access network. upR1 upR2 (upstream router) | | ----------------------- LAN | | (incoming interface) downR1 downR2 (downstream routers) | | --------- | downdownR1 Here, when downR2 receives assert message in the incoming interface. It means that, - there is a contention between upR1 and upR2 regarding who should forward the multicast data to LAN. - after assert related processing gets compeleted one of upR1 or upR2 will be responsible to forward the traffic on LAN. If above is correct, then downR2 will be able to recieve multicast data even without sending join/prune message towards upstream neighbor. So, I am not able to understand why does downR2 MUST send send Join/Prune towards upstream neighbour? with regards, bhavesh ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-pim@catarina.usc.edu Tue Oct 19 03:11:00 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA07130 for ; Tue, 19 Oct 1999 03:10:59 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id AAA12215 for pim-list; Tue, 19 Oct 1999 00:03:38 -0700 Received: from hotmail.com (law-f154.hotmail.com [209.185.131.217]) by catarina.usc.edu (8.6.10/8.6.9) with SMTP id AAA12211 for ; Tue, 19 Oct 1999 00:03:30 -0700 Received: (qmail 67800 invoked by uid 0); 19 Oct 1999 07:02:59 -0000 Message-ID: <19991019070259.67799.qmail@hotmail.com> Received: from 192.135.245.219 by www.hotmail.com with HTTP; Tue, 19 Oct 1999 00:02:58 PDT X-Originating-IP: [192.135.245.219] From: "bhavesh pathak" To: pim@catarina.usc.edu Subject: some doubts in PIM-DM draft Date: Tue, 19 Oct 1999 00:02:58 PDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-pim@catarina.usc.edu Precedence: bulk Dear everyone, I have following doubts in PIM-SM draft. 1. In section-5 it says that, " If a router creates a (S,G) entry with an empty outgoing interface list after receiving a multicast datagram,..." I am not able to understand when router will need to create a empty (S,G) entry. 2. In the section-5 it says that, "The Hello message has a Holdtime field that tells the neighbor to delete neighbor information if it is not refreshed ^^^^^^^^^^^^^^^^^^^^ before expiration." Can some one explain me what all is the stored as a part of neighbor information? thanks, bhavesh ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-pim@catarina.usc.edu Tue Oct 19 15:39:18 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00657 for ; Tue, 19 Oct 1999 15:39:17 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id MAA15337 for pim-list; Tue, 19 Oct 1999 12:25:17 -0700 Received: from seattle.3com.com (seattle.3com.com [129.213.128.97]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id MAA15330 for ; Tue, 19 Oct 1999 12:25:07 -0700 Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id MAA09896 for ; Tue, 19 Oct 1999 12:24:56 -0700 (PDT) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id MAA19994 for ; Tue, 19 Oct 1999 12:24:56 -0700 (PDT) Received: from dutch.nsd.3com.com (dutch.nsd.3com.com [129.213.48.27]) by chicago.nsd.3com.com (8.8.8/8.8.8) with ESMTP id MAA14698 for ; Tue, 19 Oct 1999 12:24:56 -0700 (PDT) Received: from localhost (venu@localhost) by dutch.nsd.3com.com (8.8.8/8.8.8) with SMTP id MAA12833 for ; Tue, 19 Oct 1999 12:22:25 -0700 (PDT) X-Authentication-Warning: dutch.nsd.3com.com: venu owned process doing -bs Date: Tue, 19 Oct 1999 12:22:25 -0700 (PDT) From: Nair Venugopal X-Sender: venu@dutch.nsd.3com.com To: pim@catarina.usc.edu Subject: PIM-SMv2 interoperability issue w.r.t Bootstrap packets Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pim@catarina.usc.edu Precedence: bulk I would like to do a survey of how various PIM-SMv2 implementations forward Bootstrap packets on downstream links. First, a bit of context. While testing PIM-SM interoperability with another implementation { Cisco-11.3(3)T }, we observed that our implementation was dropping Bootstrap packets forwarded by a Cisco router (R2 in the Figure1 below). Figure1: ------- | | R1(RP/BSR)----|-----R2------|------R3--- | | ### all interfaces have a configured IP address ### R1,R3: 3Com routers ### R2 : Cisco router On investigating, it turned out that router R2 was forwarding Bootstrap packets to R3, using the IP address of its interface on the R2-R1 link as the in the IP header of the Bootstrap packet. Our implementation ignored the Bootstrap packet because it failed the "was the Bootstrap packet sent by the RPF neighbor towards the BSR" check (rfc 2362: section 3.6.3.1). Our "RPF neighbor" check to handle this scenario is as follows. a) Do we have an RPF route to the BSR's IP address ? b) Did we receive the Bootstrap packet on the correct incoming i/f ? c) Is the the previous-hop gateway IP address of this RPF route equal to the srcIP address in the bootstrap packet? OR If the link on which the we received the BSR packet is an UnNumbered link, does the in the IP header of the bootstrap packet exist in the PIM neighbor list for this link. We dropped the packet from R2 because check (c) failed. i.e., because the srcIP address in the Bootstrap packet forwarded by R2 did not match the IP address of any of the PIM neighbors on the R2-R3 link. ---------------------------------------------------------------------- So my questions are.... Figure2: ------- R8(BSR) / \ / \ R6 R7 \_______/ | R5 ---|--- | R4 1) Are the checks listed above, specifically (c) TOO conservative? Or should one "lighten-up" and accept/process all Bootstrap packets received on the correct RPF interface? 2) In the topology (figure 2), should R4 get multiple BSR packets every Bootstrap period ? 3) In the topology (figure 2), should R5 process the RP-Sets in the BSR packets forwarded by both R6 and R7 ? 4) If one ignores the check (c) above, there is no protocol failure; only additional processing on each downstream router. Is this correct? 5) For PIM packets sent out on UnNumbered links, are there any de-facto conventions for picking up the in the in the IP header. E.g.: All "link-local" PIM packets (Hellos/JoinPrunes/BootStraps/Asserts) sourced on an UnNumbered link SHOULD use the same IP address as the source IP address in the IP header? Thanks. --Venu -------------------------------------------------------------------- Nair Venugopal --- venu@3com.com --- 3Com WAP Engineering From owner-pim@catarina.usc.edu Tue Oct 19 19:05:35 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA03957 for ; Tue, 19 Oct 1999 19:05:34 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id PAA16329 for pim-list; Tue, 19 Oct 1999 15:58:10 -0700 Received: from siara.com (gate.siara.com [209.31.24.134]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id PAA16325 for ; Tue, 19 Oct 1999 15:58:04 -0700 Received: from malt.mtv.siara.com (malt.mtv.siara.com [192.168.40.9]) by siara.com (8.9.3-LCCHA/8.9.3/lccha Siara hub 1.4) with ESMTP id PAA25890; Tue, 19 Oct 1999 15:57:22 -0700 (PDT) Received: (from lwei@localhost) by malt.mtv.siara.com (8.9.3-LCCHA/8.9.3/lccha Siara client 1.5) id PAA16575; Tue, 19 Oct 1999 15:57:08 -0700 (PDT) Date: Tue, 19 Oct 1999 15:57:08 -0700 (PDT) Message-Id: <199910192257.PAA16575@malt.mtv.siara.com> From: Liming Wei To: pim@catarina.usc.edu, agenda@ietf.org Cc: oran@cisco.com, rculton@siara.com, pusateri@juniper.net, lwei@siara.com Subject: PIM WG at DC Reply-to: lwei@siara.com Sender: owner-pim@catarina.usc.edu Precedence: bulk This is just a status that I did send a request for a PIM WG meeting time slot before the deadline, but didn't receive any reply so far. Dave Oran helped to send an inquiry last Friday, and I ping'ed again yesterday. Still no reply. I'll try to figure out what is going on and let you know soon. -Liming From owner-pim@catarina.usc.edu Tue Oct 19 19:11:17 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04029 for ; Tue, 19 Oct 1999 19:11:15 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id QAA16379 for pim-list; Tue, 19 Oct 1999 16:00:10 -0700 Received: from smtprtp1.ntcom.nortel.net (smtprtp1.ntcom.nortel.net [137.118.22.14]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id QAA16374 for ; Tue, 19 Oct 1999 16:00:01 -0700 Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprtp1.ntcom.nortel.net; Tue, 19 Oct 1999 18:11:27 -0400 Received: from zsc4c004.corpwest.baynetworks.com ([134.177.2.151]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id VA7DF6XQ; Tue, 19 Oct 1999 18:06:49 -0400 Received: from vpandya-pc.corpwest.baynetworks.com ([134.177.80.124]) by zsc4c004.corpwest.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id VA654C1B; Tue, 19 Oct 1999 15:06:39 -0700 Message-Id: <3.0.1.32.19991019150440.0087e6b0@ZSC4C004.corpwest.baynetworks.com> X-Sender: vpandya@ZSC4C004.corpwest.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 19 Oct 1999 15:04:40 -0400 To: pim@catarina.usc.edu From: "Vaishali Pandya" Subject: PIMSM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-pim@catarina.usc.edu Precedence: bulk Hi, Can anybody tell me what will happen to the following case: When RP receives register message, it will create SG with *G oif - iif(SG). But, if *g and SG comes via the same interface, oif for SG will be null and join/prune towards S will not be send. So, How this kind of case will work??? Thanks in advance. -Vaishali From owner-pim@catarina.usc.edu Tue Oct 19 19:19:16 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04078 for ; Tue, 19 Oct 1999 19:19:15 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id QAA16571 for pim-list; Tue, 19 Oct 1999 16:06:14 -0700 Received: from siara.com (gate.siara.com [209.31.24.134]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id QAA16567 for ; Tue, 19 Oct 1999 16:06:08 -0700 Received: from malt.mtv.siara.com (malt.mtv.siara.com [192.168.40.9]) by siara.com (8.9.3-LCCHA/8.9.3/lccha Siara hub 1.4) with ESMTP id QAA26371; Tue, 19 Oct 1999 16:05:29 -0700 (PDT) Received: (from lwei@localhost) by malt.mtv.siara.com (8.9.3-LCCHA/8.9.3/lccha Siara client 1.5) id QAA16873; Tue, 19 Oct 1999 16:05:14 -0700 (PDT) Date: Tue, 19 Oct 1999 16:05:14 -0700 (PDT) Message-Id: <199910192305.QAA16873@malt.mtv.siara.com> From: Liming Wei To: mbeaulie@ietf.org CC: pim@catarina.usc.edu, oran@cisco.com, rculton@siara.com, pusateri@juniper.net In-reply-to: <199910192303.TAA03933@ietf.org> (message from Marcia Beaulieu on Tue, 19 Oct 1999 19:04:52 -0400) Subject: Re: PIM WG at DC Reply-to: lwei@siara.com Sender: owner-pim@catarina.usc.edu Precedence: bulk Thanks Marcia. I guess I should have waited before firing up another message to you :-). -Liming ------------- > From: Marcia Beaulieu > > PIM has been scheduled on Wednesday at 1300-1500, I am just trying > to work out some last minute adjustments before the final agenda goes > out. > > Marcia > > At 03:57 PM 10/19/99 -0700, Liming Wei wrote: > >This is just a status that I did send a request for a PIM WG meeting > >time slot before the deadline, but didn't receive any reply so far. > >Dave Oran helped to send an inquiry last Friday, and I ping'ed > >again yesterday. Still no reply. > > > >I'll try to figure out what is going on and let you know soon. > > > >-Liming > > > From owner-pim@catarina.usc.edu Tue Oct 19 19:20:30 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04099 for ; Tue, 19 Oct 1999 19:20:29 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id QAA16477 for pim-list; Tue, 19 Oct 1999 16:03:26 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id QAA16473 for ; Tue, 19 Oct 1999 16:03:20 -0700 Received: from marcia.cnri.reston.va.us ([10.27.5.109]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA03933; Tue, 19 Oct 1999 19:03:15 -0400 (EDT) Message-Id: <199910192303.TAA03933@ietf.org> X-Sender: mbeaulie@odin X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Tue, 19 Oct 1999 19:04:52 -0400 To: lwei@siara.com, pim@catarina.usc.edu From: Marcia Beaulieu Subject: Re: PIM WG at DC Cc: oran@cisco.com, rculton@siara.com, pusateri@juniper.net, lwei@siara.com In-Reply-To: <199910192257.PAA16575@malt.mtv.siara.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-pim@catarina.usc.edu Precedence: bulk PIM has been scheduled on Wednesday at 1300-1500, I am just trying to work out some last minute adjustments before the final agenda goes out. Marcia At 03:57 PM 10/19/99 -0700, Liming Wei wrote: >This is just a status that I did send a request for a PIM WG meeting >time slot before the deadline, but didn't receive any reply so far. >Dave Oran helped to send an inquiry last Friday, and I ping'ed >again yesterday. Still no reply. > >I'll try to figure out what is going on and let you know soon. > >-Liming > From owner-pim@catarina.usc.edu Tue Oct 19 20:17:36 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04506 for ; Tue, 19 Oct 1999 20:17:34 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id RAA17261 for pim-list; Tue, 19 Oct 1999 17:11:04 -0700 Received: from kit.isi.edu (kit.isi.edu [128.9.160.207]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id RAA17257 for ; Tue, 19 Oct 1999 17:11:00 -0700 Received: (from eddy@localhost) by kit.isi.edu (8.9.2/8.8.7) id RAA47379; Tue, 19 Oct 1999 17:00:03 -0700 (PDT) (envelope-from eddy) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 19 Oct 1999 17:00:03 -0700 (PDT) From: eddy@isi.edu To: Nair Venugopal Cc: pim@catarina.usc.edu Subject: Re: PIM-SMv2 interoperability issue w.r.t Bootstrap packets In-Reply-To: References: X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14348.60892.104443.694692@kit.isi.edu> Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Nair Venugopal states: > Figure2: > ------- > R8(BSR) > / \ > / \ > R6 R7 > \_______/ > | > R5 > ---|--- > | > R4 > > 1) Are the checks listed above, specifically (c) TOO conservative? > Or should one "lighten-up" and accept/process all Bootstrap > packets received on the correct RPF interface? > i don't think so. in the following topology -+---+---+- L1 | | | L3 - BSR R1 R2 | | | -+---+---+- L2 say BSR uses it's L3 addr as the BSR addr, R1 RPF's L1 to BSR and R2 RPF's L2 to BSR you'd get looping BSR's if you only checked the neighbors address. also requiring the forwarder to use it's oif when sending the BSR. > > 4) If one ignores the check (c) above, there is no protocol failure; > only additional processing on each downstream router. Is this correct? > i think you get a failure, or an extreme case of reliability :) - rusty From owner-pim@catarina.usc.edu Tue Oct 19 21:00:43 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA04843 for ; Tue, 19 Oct 1999 21:00:42 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id RAA17550 for pim-list; Tue, 19 Oct 1999 17:45:31 -0700 Received: from kit.isi.edu (kit.isi.edu [128.9.160.207]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id RAA17546 for ; Tue, 19 Oct 1999 17:45:26 -0700 Received: (from eddy@localhost) by kit.isi.edu (8.9.2/8.8.7) id RAA47447; Tue, 19 Oct 1999 17:34:29 -0700 (PDT) (envelope-from eddy) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 19 Oct 1999 17:34:28 -0700 (PDT) From: eddy@isi.edu To: eddy@isi.edu Cc: Nair Venugopal , pim@catarina.usc.edu Subject: Re: PIM-SMv2 interoperability issue w.r.t Bootstrap packets In-Reply-To: <14348.60892.104443.694692@kit.isi.edu> References: <14348.60892.104443.694692@kit.isi.edu> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14349.3556.795929.904011@kit.isi.edu> Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit eddy@ISI.EDU states: > > say BSR uses it's L3 addr as the BSR addr, R1 RPF's L1 to BSR and R2 > RPF's L2 to BSR you'd get looping BSR's if you only checked the > neighbors address. also requiring the forwarder to use it's oif when ^^^^^^^^^^^^^^^^^ oops, ment to say interface. - rusty From owner-pim@catarina.usc.edu Tue Oct 19 21:11:56 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA04959 for ; Tue, 19 Oct 1999 21:11:54 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id SAA17732 for pim-list; Tue, 19 Oct 1999 18:00:36 -0700 Received: (from pavlin@localhost) by catarina.usc.edu (8.6.10/8.6.9) id SAA17726 for pim@catarina.usc.edu; Tue, 19 Oct 1999 18:00:12 -0700 Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id RAA17407 for ; Tue, 19 Oct 1999 17:26:10 -0700 Received: from kouvelas-u10.cisco.com (kouvelas-u10.cisco.com [171.69.65.54]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id RAA07969; Tue, 19 Oct 1999 17:25:31 -0700 (PDT) Received: from localhost (kouvelas@localhost) by kouvelas-u10.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.WS.1.2) with ESMTP id RAA07230; Tue, 19 Oct 1999 17:25:05 -0700 (PDT) Message-Id: <199910200025.RAA07230@kouvelas-u10.cisco.com> X-Authentication-Warning: kouvelas-u10.cisco.com: kouvelas owned process doing -bs To: lwei@siara.com, pusateri@juniper.net cc: pim@catarina.usc.edu cc: estrin@usc.edu, mjh@aciri.org, kouvelas@cisco.com, lorenzo@cisco.com Subject: Alternative bidir PIM proposal Date: Tue, 19 Oct 1999 17:25:04 -0700 From: Isidor Kouvelas Sender: owner-pim@catarina.usc.edu Precedence: bulk Liming, Tom, We would like a slot in the Washington meeting for presenting the draft below. The draft has been submitted today to the ID directories. thanks Lorenzo Vicisano Isidor Kouvelas PIM Working Group Deborah Estrin Internet Draft ISI/USC Expiration Date: May, 2000 Mark Handley ACIRI Isidor Kouvelas cisco Systems Lorenzo Vicisano cisco Systems October 19, 1999 A New Proposal for Bi-directional PIM Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document discusses a new form of Bi-directional PIM, a variant of PIM Sparse Mode [1] that builds bi-directional shared trees con- necting multicast sources and receivers. The ideas presented in this document are similar to those described in [2]. The main difference between the two proposals is in the method used to forward packets traveling upstream from a source to the RP. In particular [2] uses an IP option (UMP option) on data packets to assist with upstream forwarding. The UMP option identifies the next hop router responsible for forwarding the packet upstream. Estrin, Handley, Kouvelas, Vicisano [Page 1] Internet Draft New bidir PIM October 1999 In contrast, this proposal does not alter data packets to embed con- trol information. Instead the identification of the next hop upstream forwarder is performed at RP discovery time using a fail-safe elec- tion mechanism. This significantly simplifies forwarding procedures and eliminates forwarding loops and packet duplication problems that exist in [2]. 1 Introduction This document discusses Bi-directional PIM, a variant of PIM Sparse Mode [1] that builds bi-directional shared trees connecting multicast sources and receivers. PIM Sparse-Mode (PIM-SM) version 1 and version 2 construct uni- directional shared trees that are used to forward data from senders to receivers of a multicast group. PIM-SM also allows the construc- tion of source specific trees, but this capability is not related to the proposal described in this document. The shared tree for each multicast group is rooted at a multicast router called the Rendezvous Point (RP). Different multicast group ranges can use separate RPs within a PIM domain. In unidirectional PIM-SM, there are two possible methods for distri- buting data packets on the shared tree, which differ in the way pack- ets are forwarded from a source to the RP: o Initially when a source starts transmitting, it's first hop router encapsulates data packets in special control messages (Registers) which are unicast to the RP. After reaching the RP the packets are decapsulated and distributed on the shared tree. o A transition from the above distribution mode can be made at a later stage. This is achieved by building source specific state on all routers along the path between the source and the RP. This state is then used to natively forward packets from that source. Both these mechanisms suffer from problems. Encapsulation results in significant processing, bandwidth and delay overheads. Source state has additional protocol and memory requirements. Bi-directional PIM dispenses with both encapsulation and source state by allowing packets to be natively forwarded from a source to the RP using shared tree state. For a complete discussion of the pros and cons of Bi-directional PIM consult [2]. The ideas presented in this document are similar to those described Estrin, Handley, Kouvelas, Vicisano [Page 2] Internet Draft New bidir PIM October 1999 in [2]. The main difference between the two proposals is in the method used to forward packets traveling upstream from a source to the RP. In particular [2] uses an IP option (UMP option) on data packets to assist with upstream forwarding. The UMP option identifies the next hop router responsible for forwarding the packet upstream. In contrast, this proposal does not alter data packets to embed con- trol information. Instead the identification of the next hop upstream forwarder is performed at RP discovery time using a fail-safe elec- tion mechanism. This significantly simplifies forwarding procedures and eliminates forwarding loops and packet duplication problems that exist in [2]. Section 8 presents a comparison between the proposal in this document and [2]. The rest of this document is structured as follows. Section 2 defines basic terms. Section 3 describes bidirectional tree formation and forwarding. The new forwarding rules rely heavily on an election mechanism described in section 4. 2 Definitions In the discussion below, the terms upstream, downstream and RPF interface are always referring to the shared tree rooted at the Ren- dezvous Point. Downstream indicates the direction on which packets travel from the RP to receivers along the shared tree. Upstream indi- cates the opposite direction used by packets traveling from sources to the RP. The RPF interface for a group is the interface unicast routing uses to reach the RP. We assume that the reader is familiar with the unidirectional PIM-SM protocol [1] as much of the functionality is common to the version of bidir PIM described below. In particular in the rest of this document we will use the concepts of (*,G), (S,G) and (*,*,RP) state and their component fields (olist, iif, ...). We will also reference Join and Prune messages whose semantics and packet formats are defined in [1]. In the context of this document Join and Prune messages always have the RP and WC bits set. Also, for consistency with [1], (*,G) entries always have the RP and WC bits set. Finally, default timer values are the ones given in [1]. The protocol presented in this document is largely based on the con- cept of a Designated Forwarder (DF). A single DF exists for each RP on every link within a PIM domain (this includes both multi-access and point-to-point links). The DF is the router on the link with the best unicast route to the RP. A DF for a given RP is in charge of forwarding downstream traffic onto the link, and forwarding upstream traffic from the link towards the RP. It does this for all the bi- directional groups served by the RP. The DF election procedures are Estrin, Handley, Kouvelas, Vicisano [Page 3] Internet Draft New bidir PIM October 1999 described in section 4. 3 Tree Building and Forwarding This section describes how bi-directional tree building procedures and forwarding rules vary from normal PIM-SM operation. A router learns which multicast addresses will be used for regular PIM and which will be for bidirectional groups along with the candi- date RP information through PIM-SM bootstrap messages. Thus uni- directional and bidirectional groups can coexist in the same domain. Throughout the section it is assumed that on each link, all the routers have a consistent view on which router has the best path to the RP. This router is called the DF for that RP on the link. This assumption rests on the DF election procedures described in section 4. In the procedures described in the rest of this section, if DF infor- mation is required but not available (election is incomplete), then no tree building or forwarding action is taken. 3.1 Tree Building 3.1.1 Joining the (Shared) Tree The procedures for joining the (*,G) shared tree, are almost identi- cal to those used in PIM-SM with the difference that the tasks of the DR are handled by the DF. When a router receives a membership indication from IGMP for a bidirectional group G with rendezvous point RP, and it is the DF for the group on the link on which the report was received, the following steps are taken: o If (*,G) state exists but the interface on which the report was received is not in the olist of the entry, then the interface is added to the olist. o If no (*,G) state exists for the group, then a (*,G) entry is created and populated with the RP DF information with the interface in the olist. o If (*,G) state existed or was created, we also follow standard PIM-SM procedures [1] for updating timers and originating a Join message for the group directed upstream. The Join is directed to the DF for the (*,G) incoming interface. Estrin, Handley, Kouvelas, Vicisano [Page 4] Internet Draft New bidir PIM October 1999 When a router receives a Join message addressed to it for a bidir group G with rendezvous point RP, it must determine if it is the DF on the link for this group. To do this it consults (*,G) state or the RP election information if no (*,G) state exists. If the router is not the DF, it must ignore the Join message. If it is the DF, then the following steps are taken: o If no (*,G) state exists, then it is created and populated with the RP DF information, and the olist contains only the interface on which the join was received. o If (*,G) state exists but the interface on which the join was received is not included in the (*,G) olist, then it is added. o Standard PIM-SM procedures for updating timers and originating a Join message for the group directed upstream are followed. The Join is directed to the DF for the (*,G) incoming interface. 3.1.2 Leaving the (shared) tree When the DF for a link receives notification that an interface is no longer required in the olist of a group (either through IGMP or by receiving a Prune), it follows standard PIM-SM procedures except any originated prunes are addressed to the DF on the (*,G) iif. 3.1.3 Designated Forwarder Change When the DF for a RP on a link changes to a different router, tree maintenance has to take place to ensure that traffic is still delivered for all affected groups. 3.1.3.1 Old DF Actions On losing its status, the old DF has to take the following actions for existing groups that are affected. o If there were downstream receivers (discovered through IGMP or downstream Joins), the router has to delete the interface to the link from its olist. o If the interface deletion results in a null olist for the (*,G) then the usual actions are taken to propagate a Prune upstream. 3.1.3.2 New DF Actions On assuming the role of the DF a router has to take the following actions for each existing group that is affected. If the router has IGMP information from local receivers for a group, the interface to Estrin, Handley, Kouvelas, Vicisano [Page 5] Internet Draft New bidir PIM October 1999 the link must be added to the olist for the (*,G). If the (*,G) entry did not exist then it must be created and populated with the RP DF information. If the (*,G) olist was previously null then the usual actions are taken to propagate a Join upstream. 3.1.3.3 Downstream Router Actions When learning about a switch to a new DF on the RPF interface, down- stream routers must take the following actions for all affected groups. o If the router has a (*,G) entry with a non-null olist, it must send a Join for the group towards the new DF. o The router may also send a Prune for the group towards the old DF. 3.2 Forwarding Data The following responsibilities are uniquely assigned to the DF of a link: o The DF is the only router that forwards packets traveling down- stream onto the link. o The DF is the only router that picks-up upstream traveling packets off the link to forward towards the RP. Non-DF routers on a link that use that link to reach the RP, may per- form the following forwarding actions for bidirectional groups: o Forward packets from the link towards downstream receivers. o Forward packets from downstream sources onto the link (provided they are the DF for the downstream link from which the packet was picked-up). When a router receives a multicast packet sent to a bidir group G, it first looks for a (*,G) matching entry. If this is not found, then the matching (*,*,RP) state may be used. Alternatively (*,G) state may be created with a null olist and populated with the RP DF infor- mation. The router must forward the packet if either: o it was received on the incoming interface (iif) of the entry (always forward downstream traveling packets) Estrin, Handley, Kouvelas, Vicisano [Page 6] Internet Draft New bidir PIM October 1999 o the router is the Designated Forwarder (DF) for G for the interface on which the packet was received (only the DF forwards upstream). If a decision to forward the packet is made, then it is forwarded on all the interfaces in the olist as well as the entry's incoming interface with the exception of the interface the packet was received on. Otherwise the packet is discarded. Note: A major advantage of using a Designated Forwarder in bi- directional PIM is that special treatment is no longer required for sources that are directly connected to a router. Data from such sources does not need to be differentiated from other multicast traffic and will automatically be picked up by the DF. This removes the need for performing a directly connected check for data to groups that do not have existing (*,G) state. 3.2.1 Source-only Branches Source-only branches of the distribution tree for a group are branches which do not lead to any receivers, but which are used to forward packets traveling upstream from sources towards the RP. Routers along source-only branches do not have an olist for the group and hence do not need to maintain (*,G) state. Upstream forwarding can be performed using (*,*,RP) state. An implementation may decide to maintain (*,G) state for accounting or performance reasons. 4 Designated Forwarder Many of the most complicated aspects in the operation of the PIM pro- tocol suite are in place to enable operation on multi-access links. The most notable example is the bi-directional PIM proposal [2] where an UMP option is required to nominate the upstream router responsible for forwarding packets towards the RP. A similar problem exists both in bidir [2] and Sparse-Mode PIM [1] where a Designated Router (DR) has to be elected to handle directly connected sources. In both of the above cases, the choice of the router on the link to perform the desired operation is critical. In bidir PIM [2], if the router elected as the DR is different from that chosen by downstream neighbors for joining the tree, loops in the topology can occur. The main shortcoming of the DR is that its election does not take into consideration the location of the RP. Similarly loops can occur if two different downstream routers on a multi-access link direct joins and UMP data packets to separate upstream neighbors (see section 8 for a detailed explanation of these problems). This section presents a fail-safe mechanism for electing a per-RP Estrin, Handley, Kouvelas, Vicisano [Page 7] Internet Draft New bidir PIM October 1999 designated router on each link in a PIM domain. We call this router the Designated Forwarder (DF). 4.1 DF Requirements The DF election chooses the best router on a link to assume the responsibility of forwarding traffic between the RP and the link for a given bi-directional group. Different multicast groups that share a common RP must use the same bi-directional tree for data forwarding. Hence, the election of an upstream forwarder on each link does not have to be a group specific decision but instead can be RP-specific. As the number of RPs is typically small, the number of elections that have to be performed is significantly reduced by this observation. To optimise tree creation, it is desirable that the winner of the election process should be the router on the link with the "best" unicast routing metric to the RP. When comparing metrics from dif- ferent unicast routing protocols, we use the same comparison rules used in the PIM assert process [1]. The election process needs to take place when information on a new RP initially becomes available, and can be re-used as new bidir groups for the same RP are encountered. There are however some conditions where an update to the election is required: o There is a change in unicast metric to reach the RP for any of the routers on the link. o The interface on which the RP is reachable changes to an interface for which the router was previously the DF. o A new PIM neighbor starts up on a link. o The elected DF dies. The election process has to be robust enough to ensure with very high probability that all routers on the link have a consistent view of the DF. This is because with the forwarding rules described in sec- tion 3.2, if multiple routers end-up thinking that they should be responsible for forwarding, loops may result. 4.2 DF Election Description To perform the election of the DF for a particular RP, routers on a link need to exchange their unicast routing metric information for reaching the RP. Estrin, Handley, Kouvelas, Vicisano [Page 8] Internet Draft New bidir PIM October 1999 In the election protocol described below, many message exchanges are repeated 3 times for reliability. In all those cases the message retransmissions are spaced in time by a small random interval. For the purposes of the election, interface specific counters and timers need to be maintained for each RP. When (*,G) entries are created, they inherit information on the elected DF from the corresponding RP database entry. Subsequent changes in the winner of the DF election for a RP are propagated to all dependent (*,G) entries. 4.2.1 Bootstrap Election Initially when no DF has been elected, routers finding out about a new RP start participating in the election by sending Offer messages. Offer messages include the router's metric to reach the RP. Offers are periodically retransmitted with a period randomly chosen in the interval [0.5 * Offer-Interval, Offer-Interval]. If a router hears a better offer from a neighbor, it stops partici- pating in the election for a period of [3 * Offer-Interval]. If dur- ing this period no winner is elected, then it restarts the election from the beginning. If a router receives an offer with worse metrics, then it restarts the election from the beginning. The result should be that all routers except the best candidate stop advertising. A router assumes the role of the DF after having advertised its metrics 3 times without receiving any offer from any other neighbor. At that point it transmits a Winner message which declares to every other router on the link the identity of the winner and the metrics it is using. Routers hearing a winner message stop participating in the election and record the identity and metrics of the winner. If the local metrics are better than those of the winner then the router records the identity of the winner but reinitiates the election. 4.2.2 Loser Metric Changes Whenever the unicast metric to a RP changes for a non-DF router to a value that is better than that previously advertised by the DF, the router with the new metric should take action to eventually assume forwarding responsibility. After the metric change is detected, the new candidate restarts participating in the election. If no response is received after 3 retransmissions, the router assumes the role of the DF following the usual Winner announcement procedure. Estrin, Handley, Kouvelas, Vicisano [Page 9] Internet Draft New bidir PIM October 1999 Upon receipt of an offer that is worse than its current metric, the DF will respond with a Winner message declaring its status and advertising its metric. Upon receiving this message, the originator of the Offer records the identity of the DF and aborts the election. Upon receipt of an offer that is better the its current metric, the DF records the identity and metrics of the offering router and responds with a Backoff message. This instructs the offering router to hold off for a short period of time while the unicast routing sta- bilises. The Backoff message includes the offering router's new metric and address. All routers on the link who have pending offers with metrics equal or worse than those in the backoff message (including the original offering router) will hold further offers for a period of time defined in the Backoff message. If during the backoff period, a third router sends a new better offer, the Backoff message is repeated for the new offer and the backoff period restarted. Before the backoff period expires, the acting DF nominates the router having made the best offer as the new DF using a Pass message. This message includes the IDs and metrics of both the old and new DFs. The old DF stops performing its tasks as soon as the transmission is made. The new DF assumes the role of the DF as soon as it receives the Pass message. All other routers on the link take note of the new DF and its metric. 4.2.3 Winner Metric Changes If the DF's routing metric to reach the RP changes to a worse value, it sends a set of 3 randomly spaced Offer messages on the link, advertising the new metric. Routers who receive this announcement but have a better metric may respond with an Offer message which results in the same handoff procedure described above. All routers assume the DF has not changed until they see a Pass or Winner message indi- cating the change. There is no pressure to make this handoff quickly if the acting DF still has a path to the RP. The old path may now be suboptimal but it will still work while the re-election is in progress. If the routing metric at the DF changes to a better value, a single Winner message is sent advertising the new metric. 4.2.4 Winner Loses Path If the DF's path to the RP switches to be through the link for which it is the DF, then it can no longer provide forwarding services. It Estrin, Handley, Kouvelas, Vicisano [Page 10] Internet Draft New bidir PIM October 1999 therefore immediately stops being the DF and restarts the election. As its path to the RP is through the link, an infinite metric is used in the Offer message it sends. [At this stage the old DF will have a new RPF neighbor on the link (indicated by unicast routing) which it could use in a Pass message but this adds unnecessary complication to the election process.] 4.2.5 Late Router Starting Up A late router starting up will have no knowledge of a previous elec- tion outcome. As a result it will start advertising its metric in Offer messages. As soon as this happens, the Winner will respond either with a Winner or with a Backoff message. 4.2.6 Winner Dies Whenever the DF dies, a new DF has to be elected. The speed at which this can be achieved depends on whether there are any downstream routers on the link. If there are downstream routers, then typically their RPF neighbor reported by the unicast routing protocol will be the DF. They will therefore notice a change in RPF neighbor away from the DF. They will then restart the election by transmitting Offer messages. If the RP is now reachable through the link via another upstream router, then they will use an infinite metric in the Offer. If no downstream routers are present then the only way for other upstream routers to detect a DF failure is by the timeout of the PIM neighbor information, which will take significantly longer. 4.3 Election Protocol Specification 4.3.1 Protocol State The operation of the election protocol makes use of the variables and timers described below. These are maintained per RP for each multi- cast enabled link on the router. Offer-Count (O-count) Used to maintain the number of times an Offer or Winner mes- sage has been transmitted. Best-Offer Used by the DF to record who has made the last offer for sending the Pass message. Estrin, Handley, Kouvelas, Vicisano [Page 11] Internet Draft New bidir PIM October 1999 Offer-Timer (O-timer) Used to schedule transmission of Offer and Winner messages. Pass-Timer (P-timer) Used on the DF to schedule transmission of a Pass message. 4.3.2 Message Summary The election uses the following control messages: Offer (OfferingID, Metric) Sent by routers that believe they have a better metric to the RP than the metric that has been on offer so far. Winner (DF-ID, DF-Metric) Sent by a router when assuming the role of the DF or when re-asserting in response to worse offers. Backoff (DF-ID, DF-Metric, OfferingID, OfferMetric, BackoffInterval) Used by the DF to acknowledge better offers. It instructs other routers with equal or worse offers to wait till the DF passes responsibility to the sender of the offer. Pass (Old-DF-ID, Old-DF-Metric, New-DF-ID, New-DF-Metric) Used by the old DF to pass forwarding responsibility to a router that has previously made an offer. The Old-DF-Metric is the current metric of the DF at the time the pass is sent. 4.3.3 Protocol Events During protocol operation, in addition to the expiration of the two timers and reception of the four messages, the following events can take place: o Discovery of new RP o Metric change o DF loses path o Detection of DF failure (unicast routing changed for downstream or Hello expired) 4.3.4 Protocol Operation Estrin, Handley, Kouvelas, Vicisano [Page 12] Internet Draft New bidir PIM October 1999 In the two tables below the following rules and notation apply: o Whenever the notation "?=" is used to assign a value to a timer, the value is assigned only if the timer is not running or the time left running is longer than the new value. o Whenever the DF is set, the associated metrics are also recorded. o Timers in square brackets are randomly chosen between 0.5 and 1 times the supplied value. o When a router has a path to the RP through the link on which the election is taking place, then an infinite metric is used in Offer messages. Estrin, Handley, Kouvelas, Vicisano [Page 13] Internet Draft New bidir PIM October 1999 Event Condition Non-DF action DF action ======================================================================= Offer |Local metric |O-count = 0 |Send Backoff rcvd |worse |O-timer = [Offer-Int] |Best-Offer = sender | | + 3 * Offer-Int |P-timer = Backoff-Int |-------------------------------------------------------------- |Local metric |O-count = 0 |Send Winner |better |O-timer ?= [Offer-Int] | ----------------------------------------------------------------------- Winner |Local metric |O-count = 0 rcvd |worse |Stop O-timer | |DF = sender |-------------------------------------------------------------- |Local metric |O-count = 0 |better |O-timer ?= [Offer-Int] | |DF = sender ----------------------------------------------------------------------- Backoff |Local metric |O-count = 0 rcvd |worse or to us |O-timer = Backoff-Int + [Offer-Int] | |DF = sender |-------------------------------------------------------------- |Local metric |O-count = 0 |better |O-timer ?= [Offer-Int] | |DF = sender ----------------------------------------------------------------------- Pass |Local metric |O-count = 0 rcvd |worse or to us |Stop O-timer | |DF = destination |-------------------------------------------------------------- |Local metric |O-count = 0 |better |0-timer ?= [Offer-Int] | |DF = destination ----------------------------------------------------------------------- Estrin, Handley, Kouvelas, Vicisano [Page 14] Internet Draft New bidir PIM October 1999 Event Condition Non-DF action DF action ======================================================================= New RP | |O-count = 0 |N/A | |O-timer ?= [Offer-Int] | ----------------------------------------------------------------------- Metric |DF metric |nop |O-count = 0 change |better (*) | |O-timer ?= [Offer-Int] |-------------------------------------------------------------- |DF metric |O-count = 0 |Send Winner |worse (*) |O-timer ?= [Offer-Int] | ----------------------------------------------------------------------- No path | |nop |Send Offer (**) to RP | | |O-count = 1 | | |O-timer ?= [Offer-Int] | | |DF = unknown ----------------------------------------------------------------------- DF | |O-count = 0 |N/A failure | |O-timer ?= [Offer-Int] | ----------------------------------------------------------------------- O-timer |O-count <= 3 |Send Offer expires | |O-count++ | |O-timer ?= [Offer-Int] |---------------|---------------------------------------------- |else |Send Winner | |O-count = 0 | |DF = us ----------------------------------------------------------------------- P-timer | |DF = Best-Offer expires | |Send Pass ----------------------------------------------------------------------- (*) These comparisons are made against the previously stored DF metrics. In the case of the DF, the old local metrics are used to compare against. So "DF metric better" means that the metric has actually become worse. (**) As the path to the RP is now through the link an infinite metric is used in the offer. 4.4 Election Message Formats All election messages are sent with a TTL of 1 and are multicast to the ALL-PIM-ROUTERS group. The structure of Encoded-Unicast addresses is described in [1]. 4.4.1 Common Header Estrin, Handley, Kouvelas, Vicisano [Page 15] Internet Draft New bidir PIM October 1999 The header below is common to all election messages. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type |Subtype| Rsvd | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Unicast-RP-Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Metric Preference | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD Subtype Used to distinguish between different election messages and is set according to the table below: Message Subtype ----------------------- Offer 1 Winner 2 Backoff 3 Pass 4 Checksum Calculated as specified in [1]. RP-Address The address of the bidir RP for which the election is taking place. Sender Metric Preference Preference value assigned to the unicast routing protocol that the message sender used to obtain the route to the RP- address. Sender Metric The unicast routing table metric used by the message sender to reach the RP. The metric is in units applicable to the unicast routing protocol used. The Backoff and Pass messages have the additional fields described below. Estrin, Handley, Kouvelas, Vicisano [Page 16] Internet Draft New bidir PIM October 1999 4.4.2 Backoff Message The Backoff message uses the following fields in addition to the com- mon ones described above. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Unicast-Offering-Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Offering Metric Preference | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Offering Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Offering Address The address of the router that made the last (best) Offer. Offering Metric Preference Preference value assigned to the unicast routing protocol that the offering router used to obtain the route to RP- address. Offering Metric The unicast routing table metric used by the offering router to reach the RP. The metric is in units applicable to the unicast routing protocol used. Interval The backoff interval in milliseconds to be used by routers with worse metrics than the offering router. 4.4.3 Pass Message The Pass message uses the following fields in addition to the common ones described above. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Unicast-New-Winner-Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | New Winner Metric Preference | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | New Winner Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ New Winner Address The address of the router that made the last (best) Offer. Estrin, Handley, Kouvelas, Vicisano [Page 17] Internet Draft New bidir PIM October 1999 New Winner Metric Preference Preference value assigned to the unicast routing protocol that the offering router used to obtain the route to RP- address. New Winner Metric The unicast routing table metric used by the offering router to reach the RP. The metric is in units applicable to the unicast routing protocol used. 4.5 Timer Values The Offer-Interval is 100 ms. The default Backoff-Interval used in Backoff messages is 1 sec. 5 Advertising Bi-directional Groups Routers discover that a group operates in bi-directional mode from the Encoded-Group Address fields in PIM Bootstrap and Candidate-RP Advertisement messages. The Encoded-Group Address field is modified to include the Bidir-bit (B bit) as specified below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Family | Encoding Type |B| Reserved | Mask Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group Multicast Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ When the Bidir-bit is set, all upgraded bi-directional PIM routers will follow the forwarding rules described in this specification. 6 Interoperability with legacy code The rules provided in [2] for interoperating between legacy PIM-SM routers and new bi-directional capable routers change only slightly to support this new proposal. The only difference is in the defini- tion of a boundary between a bi-directional capable area and a legacy area of the network. In [2], a bidir capable router forwarding upstream, register encapsulates the data packet to the RP if its RPF neighbor is not bidir capable. In our proposal all the routers on a link need to co-operate to elect the Designated Forwarder, if even one of the routers on the link is a legacy router, the election cannot take place. As a result register encapsulation is necessary if one or more routers on the RPF Estrin, Handley, Kouvelas, Vicisano [Page 18] Internet Draft New bidir PIM October 1999 interface are not bi-directional capable. As in [2], a Hello option must be used to differentiate between bi- directional capable and legacy routers, and (S,G) state must be created on the router doing the register encapsulation to prevent loops. 7 Comparison with PIM-SM This section needs work... o Bidir only uses a shared tree for data distribution. o No assert at all, but DF election (DF forwards upstream also). The only special requirement when new receiver branches are added, is that Join/Prune messages on links are always sent to the election winner (DF). o The DF election problem is easier than the assert problem because there is a small number of RPs and you can do the per RP DF elec- tion a priori. With the assert mechanism, in addition to each RP, a forwarder has to be elected for each possible source to a group. This can not be done before data is avaialble. o Sender-only branches do not need to keep per group state. o A router that has (*,G) and gets a packet on the iif, does not need to check if the packet comes from a directly connected source. This case does not need special handling. 8 Comparison with UMP based bidirectional PIM Using an UMP option for upstream forwarding has the following dissad- vantages: o Using the DF election, only routers willing to be forwarders can be elected. In contrast in [2], the downstream router designates the upstream neighbor responsible for forwarding (using Joins and UMP packets). o Using the UMP option, regular data packets are overloaded with con- trol information for the routing protocol. o Inserting the extra option in multicast packets transmitted from a source may result in a packet size exceeding the MTU which will result in fragmentation. o The use of an option complicates the router forwarding mechanism. Estrin, Handley, Kouvelas, Vicisano [Page 19] Internet Draft New bidir PIM October 1999 Additional code to process the new special packet type needs to be written. o The contents of the UMP option have to be rewritten and the packet checksum adjusted on each hop towards the RP at data forwarding time. This introduces additional per packet processing overhead. In bidir PIM [2], if the router elected as the DR is different from that chosen by downstream neighbors for joining the tree, loops can occur. The main shortcoming of the DR is that its election does not take into consideration the location of the RP. To resolve this prob- lem the DR priority draft [3] provides a method for manually confi- guring the DR election winner. Although this provides a solution it has two drawbacks: o It requires a case by case manual configuration. o It cannot solve the problem if there are different RPs in a domain serving separate multicast group ranges. In this scenario the requirements of each RP for the DR positioning on a particular link may differ. 9 Security Considerations All PIM control messages MAY use IPsec to address security concerns. 10 References [1] Estrin, et al., "Protocol Independent Multicast-Sparse Mode (PIM- SM): Protocol Specification", RFC 2362, June 1998. [2] D. Estrin, D. Farinacci, "Bi-directional Shared Trees in PIM-SM", Work In Progress, , May 1999. [3] Wei, L., Farinacci, D., "PIM Version 2 DR Election Priority Option", INTERNET-DRAFT, March 1998. 11 Appendix A: Election Reliability Enhancements For the correct operation of bi-directional PIM it is very important to avoid situations where two routers consider themselves to be Designated Forwarders for the same link. The two precautions below are not required for correct operation but can help diagnose anomalies and correct them. 11.1 Missing Pass Estrin, Handley, Kouvelas, Vicisano [Page 20] Internet Draft New bidir PIM October 1999 After a DF has been elected, a router whose metrics change to become better than the forwarder will attempt to take over. If during the re-election the acting DF has a condition that causes it to lose all of the election messages (like a CPU overload), the new candidate will transmit three offers and assume the role of the forwarder. This situation is pathological and should be corrected by fixing the over- loaded router. However, it is desirable that such an event can be detected. When a router becomes the DF for a link without receiving a Pass mes- sage from the known old DF, the PIM neighbor information for the old DF can be marked to this effect. Upon receiving the next PIM Hello message from the old DF, the router can retransmit Winner messages for all the RPs for which it acting as the DF. 11.2 Periodic Winner Announcement An additional degree of safety can be achieved by having the DF for each RP periodically announce its status in a Winner message. Having this periodic control traffic in areas of the network without senders or receivers for a particular RP can be avoided. Transmission of the periodic Winner message can be restricted to occur only for RPs which have active groups. 12 Acknowledgments The bidir proposal in this draft is heavily based on the ideas and text presented by Estrin and Farinacci in [2]. The main difference between the two proposals is in the method chosen for upstream for- warding. We would also like to thank Nidhi Bhaskar, Yiqun Cai, Tony Speakman, Rajitha Sumanasakera and Chris White at cisco for their contributions and comments to this draft. 13 Author Information Deborah Estrin ISI/USC estrin@usc.edu Mark Handley mjh@aciri.org AT&T Center for Internet Research at ICSI Isidor Kouvelas kouvelas@cisco.com cisco Systems Estrin, Handley, Kouvelas, Vicisano [Page 21] Internet Draft New bidir PIM October 1999 Lorenzo Vicisano lorenzo@cisco.com cisco Systems Estrin, Handley, Kouvelas, Vicisano [Page 22] From owner-pim@catarina.usc.edu Tue Oct 19 21:27:25 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA05091 for ; Tue, 19 Oct 1999 21:27:24 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id SAA17949 for pim-list; Tue, 19 Oct 1999 18:19:13 -0700 Received: from siara.com (gate.siara.com [209.31.24.134]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id SAA17942 for ; Tue, 19 Oct 1999 18:19:08 -0700 Received: from malt.mtv.siara.com (malt.mtv.siara.com [192.168.40.9]) by siara.com (8.9.3-LCCHA/8.9.3/lccha Siara hub 1.4) with ESMTP id SAA03820; Tue, 19 Oct 1999 18:18:28 -0700 (PDT) Received: (from lwei@localhost) by malt.mtv.siara.com (8.9.3-LCCHA/8.9.3/lccha Siara client 1.5) id SAA25680; Tue, 19 Oct 1999 18:18:13 -0700 (PDT) Date: Tue, 19 Oct 1999 18:18:13 -0700 (PDT) Message-Id: <199910200118.SAA25680@malt.mtv.siara.com> From: Liming Wei To: kouvelas@cisco.com CC: pusateri@juniper.net, pim@catarina.usc.edu, estrin@usc.edu, mjh@aciri.org, kouvelas@cisco.com, lorenzo@cisco.com In-reply-to: <199910200025.RAA07230@kouvelas-u10.cisco.com> (message from Isidor Kouvelas on Tue, 19 Oct 1999 17:25:04 -0700) Subject: Re: Alternative bidir PIM proposal Reply-to: lwei@siara.com Sender: owner-pim@catarina.usc.edu Precedence: bulk > From: Isidor Kouvelas > > Liming, Tom, > > We would like a slot in the Washington meeting for presenting the draft > below. The draft has been submitted today to the ID directories. Isidor and Lorenzo, if you have passed the ID submission deadline, can you post it to the WG mailing list as well ? If not, never mind. How much time do you need for the presentation ? -Liming > > thanks > Lorenzo Vicisano > Isidor Kouvelas > > > > > PIM Working Group Deborah Estrin > Internet Draft ISI/USC > Expiration Date: May, 2000 Mark Handley > ACIRI > Isidor Kouvelas > cisco Systems > Lorenzo Vicisano > cisco Systems > October 19, 1999 > > > A New Proposal for Bi-directional PIM > > From owner-pim@catarina.usc.edu Wed Oct 20 17:33:29 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24242 for ; Wed, 20 Oct 1999 17:33:25 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id OAA24480 for pim-list; Wed, 20 Oct 1999 14:16:18 -0700 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id OAA24476 for ; Wed, 20 Oct 1999 14:16:12 -0700 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (MOT-ftpbox 1.0) with ESMTP id QAA18322 for ; Wed, 20 Oct 1999 16:16:06 -0500 (CDT)] Received: [from s-il02-d.comm.mot.com (s-il02-d.comm.mot.com [145.1.204.14]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id QAA04806 for ; Wed, 20 Oct 1999 16:16:05 -0500 (CDT)] Received: by s-il02-d.comm.mot.com with Internet Mail Service (5.5.2580.0) id ; Wed, 20 Oct 1999 16:16:05 -0500 Message-ID: <0F762B016151D2118F8900805FA795AF0216CCDC@s-il02-n.comm.mot.com> From: Narayanan Vidya-CVN065 To: "'pim'" Subject: Question on GenID Date: Wed, 20 Oct 1999 16:16:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2580.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-pim@catarina.usc.edu Precedence: bulk Hi, I was reading the draft "PIM Neighbor Hello GenID Option" and had a question on its operation. According to the draft, if the GenID in an incoming Hello packet is different from the last time, then the DR will unicast its most recent RP-Set information to the rebooted neighbor. If the rebooted neighbor was the DR, the next highest IP address or DR priority neighbor will unicast this information. Now, what if the rebooting router was just an intermediate router? That is, it is neither the DR (the router is not on a multi-access LAN), nor the BSR/CBSR/RP/CRP. In this case, when the router reboots, how will the genID help in getting the latest RP-Set information? Which router would send this to the rebooted router? If it has more than one PIM neighbor, will it get multiple copies of the information? Thanks, Vidya From owner-pim@catarina.usc.edu Wed Oct 20 17:54:04 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24472 for ; Wed, 20 Oct 1999 17:54:02 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id OAA24774 for pim-list; Wed, 20 Oct 1999 14:44:33 -0700 Received: from baynet.baynetworks.com (ns1.BayNetworks.COM [134.177.3.20]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id OAA24770 for ; Wed, 20 Oct 1999 14:44:08 -0700 Received: from mailhost.BayNetworks.COM (h8754.s84f5.BayNetworks.COM [132.245.135.84]) by baynet.baynetworks.com (8.9.1/8.9.1) with ESMTP id OAA29695; Wed, 20 Oct 1999 14:41:08 -0700 (PDT) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id RAA08743; Wed, 20 Oct 1999 17:37:47 -0400 (EDT) Received: from bluebird.engeast (bluebird [192.32.224.91]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id RAA00199; Wed, 20 Oct 1999 17:41:51 -0400 for Received: by bluebird.engeast (SMI-8.6/SMI-SVR4) id RAA14442; Wed, 20 Oct 1999 17:41:50 -0400 Date: Wed, 20 Oct 1999 17:41:50 -0400 Message-Id: <199910202141.RAA14442@bluebird.engeast> From: Yunzhou Li To: Narayanan Vidya-CVN065 Cc: "'pim'" Subject: Re: Question on GenID In-Reply-To: <0F762B016151D2118F8900805FA795AF0216CCDC@s-il02-n.comm.mot.com> References: <0F762B016151D2118F8900805FA795AF0216CCDC@s-il02-n.comm.mot.com> Sender: owner-pim@catarina.usc.edu Precedence: bulk Narayanan, On Wed, 20 October, Narayanan Vidya-CVN (CVN065@lmpsil02.comm.mot.com) wrote: > Hi, > I was reading the draft "PIM Neighbor Hello GenID Option" and had a question > on its operation. According to the draft, if the GenID in an incoming Hello > packet is different from the last time, then the DR will unicast its most > recent RP-Set information to the rebooted neighbor. If the rebooted neighbor > was the DR, the next highest IP address or DR priority neighbor will unicast > this information. > > Now, what if the rebooting router was just an intermediate router? That is, > it is neither the DR (the router is not on a multi-access LAN), nor the > BSR/CBSR/RP/CRP. In this case, when the router reboots, how will the genID > help in getting the latest RP-Set information? Which router would send this > to the rebooted router? If it has more than one PIM neighbor, will it get > multiple copies of the information? Yes, neighbors from all links will unicast the latest RP-Set information to the rebooting router. At each instant, there is only a single copy of RP-Set info over the PIM domain. In fact, the rebooting router will be able to identify if they are indentical copy by looking at the Fragment Tag in the Bootstrap message. If two neighbors happen to have distinct copy, the RP-Set info should be able to converge in next Bootstrap cycle. Thanks, Yunzhou > > Thanks, > Vidya > From owner-pim@catarina.usc.edu Wed Oct 20 19:24:45 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25385 for ; Wed, 20 Oct 1999 19:24:43 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id QAA25332 for pim-list; Wed, 20 Oct 1999 16:14:46 -0700 Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id QAA25328 for ; Wed, 20 Oct 1999 16:14:37 -0700 Received: by dfssl with Internet Mail Service (5.5.2650.21) id <48A7T1BB>; Wed, 20 Oct 1999 16:14:05 -0700 Message-ID: <19398D273324D3118A2B0008C7E9A569055D6713@SIT.platinum.corp.microsoft.com> From: "Mohit Talwar (Exchange)" To: pim@catarina.usc.edu Cc: eddy@isi.edu Subject: The Assert Mechanism Date: Wed, 20 Oct 1999 16:14:04 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1252" Sender: owner-pim@catarina.usc.edu Precedence: bulk hi all, consider the following topology +---+ | A | +---+ . . . +-+-+ +-+-+ | B | | C | +-+-+ +-+-+ | | ----------+---------------------------------------+---------- | | R1 +---+ | D | +-+-+ | R2 A is the RP B is the DR on the LAN C is the RPF towards A for D now consider the following sequence of events... R1 joins a group G B creates (*,G) state and forwards the join upstream towards A R2 joins the group G D creates (*,G) state and sends the join on the LAN with C as the target C create (*,G) state and forwards the join upstream towards A --- a source starts sending data an assert elections takes place on the LAN C emerges the winner of the assert election! B deletes the oif and sends a prune upstream towards A --- R2 leaves the group G D sends a prune to C C keeps sending data on the LAN for R1 --- C dies R1 stops receiving any data sent for the group G!!! whew! so my question is ... "how does the assert loser (B) know that it has to now start forwarding data on the LAN for local receivers?" i looked at the spec and don't think it covers this case. but i may be wrong. i looked at rusty's notes on the web (thanx rusty :) and found that he had noted the same problem but dunno if it was ever discussed on the list. this is what he has to say... "If a router is the DR on an interface that belongs to a (*, G)'s downstream list and that interface has local recievers (igmp), some implementation dependent method must be used to ensure the interface (and joins to the RP) are re-instantiated when the assert winner quits forwarding traffic, if a no facility is added to the protocol to over come this. One method could be maintaining a timer on the loosing oif of the DR with local recievers. another method could be a hello option that the assert winner would add stating that it is actively forwarding (s,g) or (*,g) for a local reciever." another good solution would be to require that when a router loses a (*,G) or (S,G) assert election for an interface on which it is the DR and for which there are local receivers, the router associate that (*,G) or (S,G) entry with the assert winning neighbor. this list is also updated when IGMP declares that all local members for a group have left. when a neighbor dies and the router is the DR on that interface, the router should go ahead and add the interface to all tree entries in this list for that neighbor. thanx, mohit. From owner-pim@catarina.usc.edu Wed Oct 20 19:50:12 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25680 for ; Wed, 20 Oct 1999 19:50:11 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id QAA25569 for pim-list; Wed, 20 Oct 1999 16:42:54 -0700 Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id QAA25565 for ; Wed, 20 Oct 1999 16:42:46 -0700 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 5658B4CE3A; Wed, 20 Oct 1999 19:42:41 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id TAA21637; Wed, 20 Oct 1999 19:42:40 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id QAA09672; Wed, 20 Oct 1999 16:42:40 -0700 (PDT) Message-Id: <199910202342.QAA09672@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: mohitt@exchange.microsoft.com Subject: Re: The Assert Mechanism Cc: pim@catarina.usc.edu Date: Wed, 20 Oct 1999 16:42:40 -0700 Versions: dmail (solaris) 2.2e/makemail 2.8u Sender: owner-pim@catarina.usc.edu Precedence: bulk In PIM Dense Mode, the outgoing interface is "pruned" and a timer is associated with it, so that Asserts reoccur periodically to handle failures like this. Perhaps PIM-SM could use a similar mechanism. Bill From owner-pim@catarina.usc.edu Wed Oct 20 20:07:47 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA25867 for ; Wed, 20 Oct 1999 20:07:46 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id RAA25726 for pim-list; Wed, 20 Oct 1999 17:01:28 -0700 Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id RAA25722 for ; Wed, 20 Oct 1999 17:01:12 -0700 Received: from kouvelas-u10.cisco.com (kouvelas-u10.cisco.com [171.69.65.54]) by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with ESMTP id RAA22604; Wed, 20 Oct 1999 17:13:42 -0700 (PDT) Received: from localhost (kouvelas@localhost) by kouvelas-u10.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.WS.1.2) with ESMTP id RAA08349; Wed, 20 Oct 1999 17:00:30 -0700 (PDT) Message-Id: <199910210000.RAA08349@kouvelas-u10.cisco.com> X-Authentication-Warning: kouvelas-u10.cisco.com: kouvelas owned process doing -bs To: Bill Fenner cc: mohitt@exchange.microsoft.com, pim@catarina.usc.edu Subject: Re: The Assert Mechanism In-reply-to: Your message of "Wed, 20 Oct 1999 16:42:40 PDT." <199910202342.QAA09672@windsor.research.att.com> Date: Wed, 20 Oct 1999 17:00:30 -0700 From: Isidor Kouvelas Sender: owner-pim@catarina.usc.edu Precedence: bulk Bill Fenner writes: > >In PIM Dense Mode, the outgoing interface is "pruned" and a timer is >associated with it, so that Asserts reoccur periodically to handle >failures like this. Perhaps PIM-SM could use a similar mechanism. Right and in sparse-mode, to avoid the periodic reflood upstream of the assert loser, the assert winner can periodically re-assert as long as there is traffic for the source. Isidor From owner-pim@catarina.usc.edu Wed Oct 20 20:18:43 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA25987 for ; Wed, 20 Oct 1999 20:18:42 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id RAA25720 for pim-list; Wed, 20 Oct 1999 17:00:42 -0700 Received: from ntserver1.redstonecom.com (ntserver1.redstonecom.com [199.105.223.130]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id RAA25715 for ; Wed, 20 Oct 1999 17:00:28 -0700 Received: by NTSERVER1 with Internet Mail Service (5.0.1460.8) id <45HQPTY2>; Wed, 20 Oct 1999 20:00:07 -0400 Message-ID: <90ABC30C744ED311B16E00500464BEFC1ACBE5@NTSERVER1> From: "Shekhar, Ravi" To: "Mohit Talwar (Exchange)" , pim@catarina.usc.edu Cc: eddy@isi.edu Subject: RE: The Assert Mechanism Date: Wed, 20 Oct 1999 20:00:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pim@catarina.usc.edu Precedence: bulk > consider the following topology > > > +---+ > | A | > +---+ > . > . > . > +-+-+ +-+-+ > | B | | C | > +-+-+ +-+-+ > | | > ----------+---------------------------------------+---------- > | | > R1 +---+ > | D | > +-+-+ > | > R2 > > A is the RP > B is the DR on the LAN > C is the RPF towards A for D > > now consider the following sequence of events... > R1 joins a group G > B creates (*,G) state and forwards the join upstream towards A > R2 joins the group G > D creates (*,G) state and sends the join on the LAN with C as > the target > C create (*,G) state and forwards the join upstream towards A > --- > a source starts sending data > an assert elections takes place on the LAN > C emerges the winner of the assert election! > B deletes the oif and sends a prune upstream towards A > --- > R2 leaves the group G > D sends a prune to C > C keeps sending data on the LAN for R1 > --- > C dies > R1 stops receiving any data sent for the group G!!! > > whew! > > so my question is ... > "how does the assert loser (B) know that it has to now start > forwarding data on the LAN for local receivers?" > i looked at the spec and don't think it covers this case. > but i may be wrong. > > i looked at rusty's notes on the web (thanx rusty :) and found > that he had noted the same problem but dunno if it was ever > discussed on the list. this is what he has to say... > > "If a router is the DR on an interface that belongs to a (*, G)'s > downstream list and that interface has local recievers (igmp), > some implementation dependent method must be used to ensure > the interface (and joins to the RP) are re-instantiated when > the assert winner quits forwarding traffic, if a no facility > is added to the protocol to over come this. > > One method could be maintaining a timer on the loosing oif of > the DR with local recievers. another method could be a hello > option that the assert winner would add stating that it is > actively forwarding (s,g) or (*,g) for a local reciever." > > another good solution would be to require that when a router > loses a (*,G) > or (S,G) assert election for an interface on which it is the > DR and for > which there are local receivers, the router associate that > (*,G) or (S,G) > entry with the assert winning neighbor. this list is also > updated when > IGMP declares that all local members for a group have left. > > when a neighbor dies and the router is the DR on that > interface, the router > should go ahead and add the interface to all tree entries in > this list for > that neighbor. Although this mechanism will work if C dies, but this still leaves the hole as to what happens if C doesnt die AND D stops sending <*, G> joins to C. After 210 seconds, C will remove the oif and not forward any data (unless the implementation at C makes LastHopRouter to take on the responsibility of local group membership even after it doesnt have any downstream routers sending joins to it. But all implementations may not do that). Hence it is better if B keeps joining every 210 seconds if it has IGMP membership. This makes the situation look like as if B has been receiving joins from some downstream router every 210 seconds. Regards. - Ravi Shekhar. From owner-pim@catarina.usc.edu Wed Oct 20 20:24:26 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26045 for ; Wed, 20 Oct 1999 20:24:25 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id RAA26045 for pim-list; Wed, 20 Oct 1999 17:18:08 -0700 Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id RAA26036 for ; Wed, 20 Oct 1999 17:17:53 -0700 Received: from kouvelas-u10.cisco.com (kouvelas-u10.cisco.com [171.69.65.54]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id RAA11969; Wed, 20 Oct 1999 17:22:13 -0700 (PDT) Received: from localhost (kouvelas@localhost) by kouvelas-u10.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.WS.1.2) with ESMTP id RAA08383; Wed, 20 Oct 1999 17:17:15 -0700 (PDT) Message-Id: <199910210017.RAA08383@kouvelas-u10.cisco.com> X-Authentication-Warning: kouvelas-u10.cisco.com: kouvelas owned process doing -bs To: Bill Fenner cc: kouvelas@cisco.com, mohitt@exchange.microsoft.com, pim@catarina.usc.edu Subject: Re: The Assert Mechanism In-reply-to: Your message of "Wed, 20 Oct 1999 17:12:30 PDT." <199910210012.RAA10050@windsor.research.att.com> Date: Wed, 20 Oct 1999 17:17:15 -0700 From: Isidor Kouvelas Sender: owner-pim@catarina.usc.edu Precedence: bulk Bill Fenner writes: > >>to avoid the periodic reflood upstream of the >>assert loser, the assert winner can periodically re-assert as long as >>there is traffic for the source. > >You mean the winner would retransmit its Assert before the loser's >timer goes off to refresh the timer? (If the loser doesn't have a >timer then this doesn't help any when the winner dies). > >Of course, the DF election described in the new bidir spec could >be used to eliminate Asserts anyway =) Well shared trees in sparse-mode could benefit a lot by the DF mechanism (many of the more subtle SM problems would just go away). The problem is that you do not know specific sources in advance and hence cannot resolve interractions with source trees that way... Isidor From owner-pim@catarina.usc.edu Wed Oct 20 20:28:50 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26059 for ; Wed, 20 Oct 1999 20:28:49 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id RAA25948 for pim-list; Wed, 20 Oct 1999 17:12:40 -0700 Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id RAA25943 for ; Wed, 20 Oct 1999 17:12:33 -0700 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 6D8691E01B; Wed, 20 Oct 1999 20:12:31 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id UAA22255; Wed, 20 Oct 1999 20:12:30 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id RAA10050; Wed, 20 Oct 1999 17:12:30 -0700 (PDT) Message-Id: <199910210012.RAA10050@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: kouvelas@cisco.com Subject: Re: The Assert Mechanism Cc: mohitt@exchange.microsoft.com, pim@catarina.usc.edu Date: Wed, 20 Oct 1999 17:12:30 -0700 Versions: dmail (solaris) 2.2e/makemail 2.8u Sender: owner-pim@catarina.usc.edu Precedence: bulk >to avoid the periodic reflood upstream of the >assert loser, the assert winner can periodically re-assert as long as >there is traffic for the source. You mean the winner would retransmit its Assert before the loser's timer goes off to refresh the timer? (If the loser doesn't have a timer then this doesn't help any when the winner dies). Of course, the DF election described in the new bidir spec could be used to eliminate Asserts anyway =) Bill From owner-pim@catarina.usc.edu Wed Oct 20 20:41:08 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26197 for ; Wed, 20 Oct 1999 20:41:05 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id RAA26250 for pim-list; Wed, 20 Oct 1999 17:29:44 -0700 Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id RAA26245 for ; Wed, 20 Oct 1999 17:29:38 -0700 Received: by dfssl with Internet Mail Service (5.5.2650.21) id <48A7TGZ1>; Wed, 20 Oct 1999 17:29:06 -0700 Message-ID: <19398D273324D3118A2B0008C7E9A569055D6798@SIT.platinum.corp.microsoft.com> From: "Mohit Talwar (Exchange)" To: Bill Fenner , kouvelas@cisco.com Cc: "Mohit Talwar (Exchange)" , pim@catarina.usc.edu Subject: RE: The Assert Mechanism Date: Wed, 20 Oct 1999 17:28:57 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-pim@catarina.usc.edu Precedence: bulk > > >In PIM Dense Mode, the outgoing interface is "pruned" and a timer is > > >associated with it, so that Asserts reoccur periodically to handle > > >failures like this. Perhaps PIM-SM could use a similar mechanism. > > > >to avoid the periodic reflood upstream of the > >assert loser, the assert winner can periodically re-assert as long as > >there is traffic for the source. > > You mean the winner would retransmit its Assert before the loser's > timer goes off to refresh the timer? (If the loser doesn't have a > timer then this doesn't help any when the winner dies). > correct me if i am wrong... but this solution requires another timer per oif per tree entry and periodic generation of control (assert and joinprune) messages. what do u think about the alternative in which the DR on an interface keeps track of tree entries for which it has lost the interfacec and the neighbor to whom it lost it. so the interface can be added to those entries if the assert winner dies. this assumes that the assert winner takes responsibility for local group members, but don't existing pim implementations do that? anyway, i think the spec should say something about this so implementations are consistent. mohit. From owner-pim@catarina.usc.edu Wed Oct 20 20:54:00 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26263 for ; Wed, 20 Oct 1999 20:53:57 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id RAA26470 for pim-list; Wed, 20 Oct 1999 17:48:24 -0700 Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id RAA26466 for ; Wed, 20 Oct 1999 17:48:19 -0700 Received: from kouvelas-u10.cisco.com (kouvelas-u10.cisco.com [171.69.65.54]) by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with ESMTP id SAA06485; Wed, 20 Oct 1999 18:00:58 -0700 (PDT) Received: from localhost (kouvelas@localhost) by kouvelas-u10.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.WS.1.2) with ESMTP id RAA08425; Wed, 20 Oct 1999 17:47:46 -0700 (PDT) Message-Id: <199910210047.RAA08425@kouvelas-u10.cisco.com> X-Authentication-Warning: kouvelas-u10.cisco.com: kouvelas owned process doing -bs To: "Mohit Talwar (Exchange)" cc: Bill Fenner , kouvelas@cisco.com, pim@catarina.usc.edu Subject: Re: The Assert Mechanism In-reply-to: Your message of "Wed, 20 Oct 1999 17:28:57 PDT." <19398D273324D3118A2B0008C7E9A569055D6798@SIT.platinum.corp.microsoft.com> Date: Wed, 20 Oct 1999 17:47:46 -0700 From: Isidor Kouvelas Sender: owner-pim@catarina.usc.edu Precedence: bulk "Mohit Talwar (Exchange)" writes: >> > >In PIM Dense Mode, the outgoing interface is "pruned" and a timer is >> > >associated with it, so that Asserts reoccur periodically to handle >> > >failures like this. Perhaps PIM-SM could use a similar mechanism. >> > >> >to avoid the periodic reflood upstream of the >> >assert loser, the assert winner can periodically re-assert as long as >> >there is traffic for the source. >> >> You mean the winner would retransmit its Assert before the loser's >> timer goes off to refresh the timer? (If the loser doesn't have a >> timer then this doesn't help any when the winner dies). >> > >correct me if i am wrong... >but this solution requires another timer per oif per tree entry >and periodic generation of control (assert and joinprune) messages. > >what do u think about the alternative in which the DR on an >interface keeps track of tree entries for which it has lost >the interfacec and the neighbor to whom it lost it. so the >interface can be added to those entries if the assert winner >dies. This would only work if you can also detect that state has been cleared by configuration on the assert winner. To achieve this the GenID in Hello messages should change when state is cleared as well as on restarts. In either case, as Bill pointed out, on the loser you have to maintain information on the interface after you have stoped forwarding (keeping it in the list in pruned state). >this assumes that the assert winner takes responsibility for >local group members, but don't existing pim implementations >do that? The spec states that the assert winner takes over. >anyway, i think the spec should say something about this so >implementations are consistent. Agree. A fix for this problem should go in the spec. Isidor From owner-pim@catarina.usc.edu Wed Oct 20 21:52:29 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA27737 for ; Wed, 20 Oct 1999 21:52:28 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id SAA26880 for pim-list; Wed, 20 Oct 1999 18:46:25 -0700 Received: from ntserver1.redstonecom.com (ntserver1.redstonecom.com [199.105.223.130]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id SAA26876 for ; Wed, 20 Oct 1999 18:46:20 -0700 Received: by NTSERVER1 with Internet Mail Service (5.0.1460.8) id <45HQPT6X>; Wed, 20 Oct 1999 21:46:00 -0400 Message-ID: <90ABC30C744ED311B16E00500464BEFC1ACBED@NTSERVER1> From: "Shekhar, Ravi" To: Isidor Kouvelas , "Mohit Talwar (Exchange)" Cc: Bill Fenner , pim@catarina.usc.edu Subject: RE: The Assert Mechanism Date: Wed, 20 Oct 1999 21:45:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-pim@catarina.usc.edu Precedence: bulk > >this assumes that the assert winner takes responsibility for > >local group members, but don't existing pim implementations > >do that? > > The spec states that the assert winner takes over. Isidor, you are right. Section 2.9 states that. And it would work as long as all the PIM routers on the LAN are also running IGMP. But section 3.2.1 Periodic J/P point 1.2 2 The outgoing interface list in the (*,G) or (*,*,RP) entry is non-NULL, or the router is the DR on the same interface as the RPF neighbor. talks about sending joins even when oif list is NULL and RPF is on the same interface as DR. If all the routers on the LAN are running IGMP and know about local group memberships, is there a need for DR to send such joins? Last hop router (RPF nbr presumably in this case if there are no other joins) can take care of it. So then I assumed that probably this is done to take care of cases where all the routers on the LAN may not be running IGMP (but DR is running IGMP). And if that is the case, then assert-winner might not come to know of local group memberships existence/withdrawl. And DR would be responsible for sending/not-sending joins to assert-winner based on local group membership. - Ravi Shekhar. From owner-pim@catarina.usc.edu Wed Oct 20 22:13:46 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA27881 for ; Wed, 20 Oct 1999 22:13:43 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id TAA27076 for pim-list; Wed, 20 Oct 1999 19:05:42 -0700 Received: from siara.com (gate.siara.com [209.31.24.134]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id TAA27070 for ; Wed, 20 Oct 1999 19:05:37 -0700 Received: from malt.mtv.siara.com (malt.mtv.siara.com [192.168.40.9]) by siara.com (8.9.3-LCCHA/8.9.3/lccha Siara hub 1.4) with ESMTP id TAA01757; Wed, 20 Oct 1999 19:04:55 -0700 (PDT) Received: (from lwei@localhost) by malt.mtv.siara.com (8.9.3-LCCHA/8.9.3/lccha Siara client 1.5) id TAA20559; Wed, 20 Oct 1999 19:04:39 -0700 (PDT) Date: Wed, 20 Oct 1999 19:04:39 -0700 (PDT) Message-Id: <199910210204.TAA20559@malt.mtv.siara.com> From: Liming Wei To: mohitt@Exchange.Microsoft.com CC: pim@catarina.usc.edu, eddy@isi.edu In-reply-to: <19398D273324D3118A2B0008C7E9A569055D6713@SIT.platinum.corp.microsoft.com> (mohitt@Exchange.Microsoft.com) Subject: Re: The Assert Mechanism Reply-to: lwei@siara.com Sender: owner-pim@catarina.usc.edu Precedence: bulk > From: "Mohit Talwar (Exchange)" > > hi all, > > consider the following topology > > > +---+ > | A | > +---+ > . > . > . > +-+-+ +-+-+ > | B | | C | > +-+-+ +-+-+ > | | > ----------+---------------------------------------+---------- > | | > R1 +---+ > | D | > +-+-+ > | > R2 > > A is the RP > B is the DR on the LAN > C is the RPF towards A for D > > now consider the following sequence of events... > R1 joins a group G > B creates (*,G) state and forwards the join upstream towards A > R2 joins the group G > D creates (*,G) state and sends the join on the LAN with C as the target > C create (*,G) state and forwards the join upstream towards A > --- > a source starts sending data > an assert elections takes place on the LAN > C emerges the winner of the assert election! > B deletes the oif and sends a prune upstream towards A > --- > R2 leaves the group G > D sends a prune to C > C keeps sending data on the LAN for R1 > --- > C dies > R1 stops receiving any data sent for the group G!!! > > whew! > > so my question is ... > "how does the assert loser (B) know that it has to now start > forwarding data on the LAN for local receivers?" > i looked at the spec and don't think it covers this case. > but i may be wrong. When C dies, D's unicast path will switch to point to B. D should join B and forwarding should resume. -Liming From owner-pim@catarina.usc.edu Wed Oct 20 22:16:44 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA27899 for ; Wed, 20 Oct 1999 22:16:42 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id TAA27168 for pim-list; Wed, 20 Oct 1999 19:12:11 -0700 Received: from siara.com (gate.siara.com [209.31.24.134]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id TAA27161 for ; Wed, 20 Oct 1999 19:12:06 -0700 Received: from malt.mtv.siara.com (malt.mtv.siara.com [192.168.40.9]) by siara.com (8.9.3-LCCHA/8.9.3/lccha Siara hub 1.4) with ESMTP id TAA01971; Wed, 20 Oct 1999 19:11:24 -0700 (PDT) Received: (from lwei@localhost) by malt.mtv.siara.com (8.9.3-LCCHA/8.9.3/lccha Siara client 1.5) id TAA20805; Wed, 20 Oct 1999 19:11:08 -0700 (PDT) Date: Wed, 20 Oct 1999 19:11:08 -0700 (PDT) Message-Id: <199910210211.TAA20805@malt.mtv.siara.com> From: Liming Wei To: kouvelas@cisco.com CC: fenner@research.att.com, mohitt@exchange.microsoft.com, pim@catarina.usc.edu In-reply-to: <199910210000.RAA08349@kouvelas-u10.cisco.com> (message from Isidor Kouvelas on Wed, 20 Oct 1999 17:00:30 -0700) Subject: Re: The Assert Mechanism Reply-to: lwei@siara.com Sender: owner-pim@catarina.usc.edu Precedence: bulk > From: Isidor Kouvelas > > Bill Fenner writes: > > > >In PIM Dense Mode, the outgoing interface is "pruned" and a timer is > >associated with it, so that Asserts reoccur periodically to handle > >failures like this. Perhaps PIM-SM could use a similar mechanism. > > Right and in sparse-mode, to avoid the periodic reflood upstream of the > assert loser, the assert winner can periodically re-assert as long as > there is traffic for the source. The implementations of the existing spec will simply ignore the asserts received on pruned interfaces. -Liming From owner-pim@catarina.usc.edu Wed Oct 20 22:41:17 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA29053 for ; Wed, 20 Oct 1999 22:41:16 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id TAA27453 for pim-list; Wed, 20 Oct 1999 19:31:34 -0700 Received: from siara.com (gate.siara.com [209.31.24.134]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id TAA27449 for ; Wed, 20 Oct 1999 19:31:29 -0700 Received: from malt.mtv.siara.com (malt.mtv.siara.com [192.168.40.9]) by siara.com (8.9.3-LCCHA/8.9.3/lccha Siara hub 1.4) with ESMTP id TAA02789; Wed, 20 Oct 1999 19:30:48 -0700 (PDT) Received: (from lwei@localhost) by malt.mtv.siara.com (8.9.3-LCCHA/8.9.3/lccha Siara client 1.5) id TAA21501; Wed, 20 Oct 1999 19:30:32 -0700 (PDT) Date: Wed, 20 Oct 1999 19:30:32 -0700 (PDT) Message-Id: <199910210230.TAA21501@malt.mtv.siara.com> From: Liming Wei To: kouvelas@cisco.com CC: mohitt@Exchange.Microsoft.com, fenner@research.att.com, kouvelas@cisco.com, pim@catarina.usc.edu In-reply-to: <199910210047.RAA08425@kouvelas-u10.cisco.com> (message from Isidor Kouvelas on Wed, 20 Oct 1999 17:47:46 -0700) Subject: Re: The Assert Mechanism Reply-to: lwei@siara.com Sender: owner-pim@catarina.usc.edu Precedence: bulk > From: Isidor Kouvelas > > >this assumes that the assert winner takes responsibility for > >local group members, but don't existing pim implementations > >do that? > > The spec states that the assert winner takes over. This is what the spec says about the DR losing assert: From then on, the DR is no longer the last-hop router for local receivers and removes the LAN from its (*,G) oif list. The winning router becomes the last-hop router and is responsible for sending (*,G) join messages to the RP. > >anyway, i think the spec should say something about this so > >implementations are consistent. > > Agree. A fix for this problem should go in the spec. If it is broken, we'v got to fix it. No question about that. Lets concentrate on coming up with a good description of the problem, and have a well described/understood proposal for the fix. If I missed the complete description for the proposal, please resend it to me. Thanks. -Liming From owner-pim@catarina.usc.edu Wed Oct 20 23:09:50 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA29274 for ; Wed, 20 Oct 1999 23:09:49 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id UAA27664 for pim-list; Wed, 20 Oct 1999 20:03:31 -0700 Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id UAA27660 for ; Wed, 20 Oct 1999 20:03:26 -0700 Received: from kouvelas-u10.cisco.com (kouvelas-u10.cisco.com [171.69.65.54]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id UAA15885; Wed, 20 Oct 1999 20:07:53 -0700 (PDT) Received: from localhost (kouvelas@localhost) by kouvelas-u10.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.WS.1.2) with ESMTP id UAA08623; Wed, 20 Oct 1999 20:02:54 -0700 (PDT) Message-Id: <199910210302.UAA08623@kouvelas-u10.cisco.com> X-Authentication-Warning: kouvelas-u10.cisco.com: kouvelas owned process doing -bs To: lwei@siara.com cc: kouvelas@cisco.com, fenner@research.att.com, mohitt@exchange.microsoft.com, pim@catarina.usc.edu Subject: Re: The Assert Mechanism In-reply-to: Your message of "Wed, 20 Oct 1999 19:11:08 PDT." <199910210211.TAA20805@malt.mtv.siara.com> Date: Wed, 20 Oct 1999 20:02:54 -0700 From: Isidor Kouvelas Sender: owner-pim@catarina.usc.edu Precedence: bulk Liming Wei writes: >> From: Isidor Kouvelas >> >> Bill Fenner writes: >> > >> >In PIM Dense Mode, the outgoing interface is "pruned" and a timer is >> >associated with it, so that Asserts reoccur periodically to handle >> >failures like this. Perhaps PIM-SM could use a similar mechanism. >> >> Right and in sparse-mode, to avoid the periodic reflood upstream of the >> assert loser, the assert winner can periodically re-assert as long as >> there is traffic for the source. > >The implementations of the existing spec will simply ignore the >asserts received on pruned interfaces. I guess existing sparse-mode implementations do not allow pruned interfaces :-) Isidor From owner-pim@catarina.usc.edu Wed Oct 20 23:18:48 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA29324 for ; Wed, 20 Oct 1999 23:18:47 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id UAA27757 for pim-list; Wed, 20 Oct 1999 20:12:21 -0700 Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id UAA27753 for ; Wed, 20 Oct 1999 20:12:16 -0700 Received: from kouvelas-u10.cisco.com (kouvelas-u10.cisco.com [171.69.65.54]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id UAA22334; Wed, 20 Oct 1999 20:12:10 -0700 (PDT) Received: from localhost (kouvelas@localhost) by kouvelas-u10.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.WS.1.2) with ESMTP id UAA08630; Wed, 20 Oct 1999 20:11:44 -0700 (PDT) Message-Id: <199910210311.UAA08630@kouvelas-u10.cisco.com> X-Authentication-Warning: kouvelas-u10.cisco.com: kouvelas owned process doing -bs To: "Shekhar, Ravi" cc: Isidor Kouvelas , "Mohit Talwar (Exchange)" , Bill Fenner , pim@catarina.usc.edu Subject: Re: The Assert Mechanism In-reply-to: Your message of "Wed, 20 Oct 1999 21:45:58 EDT." <90ABC30C744ED311B16E00500464BEFC1ACBED@NTSERVER1> Date: Wed, 20 Oct 1999 20:11:44 -0700 From: Isidor Kouvelas Sender: owner-pim@catarina.usc.edu Precedence: bulk "Shekhar, Ravi" writes: >> >this assumes that the assert winner takes responsibility for >> >local group members, but don't existing pim implementations >> >do that? >> >> The spec states that the assert winner takes over. > > Isidor, you are right. Section 2.9 states that. And it would > work as long as all the PIM routers on the LAN are also running > IGMP. > > But section 3.2.1 Periodic J/P point 1.2 > > 2 The outgoing interface list in the (*,G) or (*,*,RP) > entry is non-NULL, or the router is the DR on the same > interface as the RPF neighbor. > > talks about sending joins even when oif list is NULL and RPF is > on the same interface as DR. If all the routers on the LAN are running > IGMP and know about local group memberships, is there a need for DR to > send such joins? > Last hop router (RPF nbr presumably in this case if there are no > other joins) can take care of it. This is done for the case when the DR is a downstream router. In this case it creates a (*,G) state because of the IGMP report but it cannot add the interface to the olist as it is the (*,G) incoming interface. However it still has to generate joins. > So then I assumed that probably this is done to take care of cases > where all the routers on the LAN may not be running IGMP (but DR > is running IGMP). And if that is the case, then assert-winner > might not come to know of local group memberships existence/withdrawl. > And DR would be responsible for sending/not-sending joins to assert-winner > based on local group membership. Normally all routers receive IGMP reports. The difference is that only the DR should act on the reports unless an assert happens in which case another router may take over. Isidor From owner-pim@catarina.usc.edu Wed Oct 20 23:24:04 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA29376 for ; Wed, 20 Oct 1999 23:24:03 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id UAA27835 for pim-list; Wed, 20 Oct 1999 20:17:49 -0700 Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id UAA27829 for ; Wed, 20 Oct 1999 20:17:44 -0700 Received: from kouvelas-u10.cisco.com (kouvelas-u10.cisco.com [171.69.65.54]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id UAA23010; Wed, 20 Oct 1999 20:17:07 -0700 (PDT) Received: from localhost (kouvelas@localhost) by kouvelas-u10.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.WS.1.2) with ESMTP id UAA08639; Wed, 20 Oct 1999 20:16:41 -0700 (PDT) Message-Id: <199910210316.UAA08639@kouvelas-u10.cisco.com> X-Authentication-Warning: kouvelas-u10.cisco.com: kouvelas owned process doing -bs To: lwei@siara.com cc: mohitt@Exchange.Microsoft.com, pim@catarina.usc.edu, eddy@isi.edu Subject: Re: The Assert Mechanism In-reply-to: Your message of "Wed, 20 Oct 1999 19:04:39 PDT." <199910210204.TAA20559@malt.mtv.siara.com> Date: Wed, 20 Oct 1999 20:16:41 -0700 From: Isidor Kouvelas Sender: owner-pim@catarina.usc.edu Precedence: bulk In message <199910210204.TAA20559@malt.mtv.siara.com>, Liming Wei writes: >> From: "Mohit Talwar (Exchange)" >> >> hi all, >> >> consider the following topology >> >> >> +---+ >> | A | >> +---+ >> . >> . >> . >> +-+-+ +-+-+ >> | B | | C | >> +-+-+ +-+-+ >> | | >> ----------+---------------------------------------+---------- >> | | >> R1 +---+ >> | D | >> +-+-+ >> | >> R2 >> >> A is the RP >> B is the DR on the LAN >> C is the RPF towards A for D >> >> now consider the following sequence of events... >> R1 joins a group G >> B creates (*,G) state and forwards the join upstream towards A >> R2 joins the group G >> D creates (*,G) state and sends the join on the LAN with C as the target >> C create (*,G) state and forwards the join upstream towards A >> --- >> a source starts sending data >> an assert elections takes place on the LAN >> C emerges the winner of the assert election! >> B deletes the oif and sends a prune upstream towards A >> --- >> R2 leaves the group G >> D sends a prune to C >> C keeps sending data on the LAN for R1 >> --- >> C dies >> R1 stops receiving any data sent for the group G!!! >> >> whew! >> >> so my question is ... >> "how does the assert loser (B) know that it has to now start >> forwarding data on the LAN for local receivers?" >> i looked at the spec and don't think it covers this case. >> but i may be wrong. > >When C dies, D's unicast path will switch to point to B. D should >join B and forwarding should resume. D has already left the group... I From owner-pim@catarina.usc.edu Thu Oct 21 01:07:32 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA00709 for ; Thu, 21 Oct 1999 01:07:31 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id VAA28285 for pim-list; Wed, 20 Oct 1999 21:56:36 -0700 Received: from fsnt.future.futsoft.com ([203.197.140.35]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id VAA28281 for ; Wed, 20 Oct 1999 21:56:21 -0700 Received: from kailash.future.futsoft.com (unverified [203.197.140.36]) by fsnt.future.futsoft.com (Integralis SMTPRS 2.04) with ESMTP id ; Thu, 21 Oct 1999 10:22:46 +0530 Received: from manim.future.futsoft.com ([10.0.14.25]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id KAA27230; Thu, 21 Oct 1999 10:24:18 +0530 Received: by manim.future.futsoft.com with Microsoft Mail id <01BF1BAD.CDB2C300@manim.future.futsoft.com>; Thu, 21 Oct 1999 10:19:48 +0530 Message-Id: <01BF1BAD.CDB2C300@manim.future.futsoft.com> From: Mani M To: "'Mohit Talwar (Exchange)'" Cc: "'pim@catarina.usc.edu'" Subject: RE: The Assert Mechanism Date: Thu, 21 Oct 1999 10:19:39 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA00709 Hi Mohit / ALL You have prescribed two solutions for the problem (i) Maintaining a timer in the Assert looser's oif . My question is how does this timer help in forwarding the packets to R1 and R2 . that is how does B know of C's death. how does the timer come into picture ? if we maintain a arbitrary timer value and evry time it expires assert has to take place and it'll increase the network overhead. if we maintain a large timer value data loss between C's death and timer expiry may be large (ii) In the second method of maintaing an option in the hello message ther is chance for data loss. (iii) In the third method you've told "another good solution would be to require that when a router loses a (*,G)or (S,G) assert election for an interface on which it is the DR and for which there are local receivers, the router associate that (*,G) or (S,G)entry with the assert winning neighbor" What is meant by the word associate ? Thanks Mani From owner-pim@catarina.usc.edu Thu Oct 21 02:50:39 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA11808 for ; Thu, 21 Oct 1999 02:50:38 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id XAA28654 for pim-list; Wed, 20 Oct 1999 23:46:55 -0700 Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id XAA28650 for ; Wed, 20 Oct 1999 23:46:51 -0700 Received: from ceng.usc.edu (helmy@ceng.usc.edu [128.125.253.190]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id XAA02035; Wed, 20 Oct 1999 23:46:49 -0700 (PDT) Received: from localhost (helmy@localhost) by ceng.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id XAA13264; Wed, 20 Oct 1999 23:46:49 -0700 (PDT) Date: Wed, 20 Oct 1999 23:46:49 -0700 (PDT) From: helmy To: Isidor Kouvelas cc: lwei@siara.com, mohitt@Exchange.Microsoft.com, pim@catarina.usc.edu, eddy@isi.edu Subject: Re: The Assert Mechanism In-Reply-To: <199910210316.UAA08639@kouvelas-u10.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pim@catarina.usc.edu Precedence: bulk On Wed, 20 Oct 1999, Isidor Kouvelas wrote: > In message <199910210204.TAA20559@malt.mtv.siara.com>, > Liming Wei writes: > >> From: "Mohit Talwar (Exchange)" > >> > >> hi all, > >> > >> consider the following topology > >> > >> > >> +---+ > >> | A | > >> +---+ > >> . > >> . > >> . > >> +-+-+ +-+-+ > >> | B | | C | > >> +-+-+ +-+-+ > >> | | > >> ----------+---------------------------------------+---------- > >> | | > >> R1 +---+ > >> | D | > >> +-+-+ > >> | > >> R2 > >> > >> A is the RP > >> B is the DR on the LAN > >> C is the RPF towards A for D > >> > >> now consider the following sequence of events... > >> R1 joins a group G > >> B creates (*,G) state and forwards the join upstream towards A > >> R2 joins the group G > >> D creates (*,G) state and sends the join on the LAN with C as the target > >> C create (*,G) state and forwards the join upstream towards A > >> --- > >> a source starts sending data > >> an assert elections takes place on the LAN > >> C emerges the winner of the assert election! > >> B deletes the oif and sends a prune upstream towards A > >> --- > >> R2 leaves the group G > >> D sends a prune to C > >> C keeps sending data on the LAN for R1 > >> --- > >> C dies > >> R1 stops receiving any data sent for the group G!!! > >> > >> whew! > >> > >> so my question is ... > >> "how does the assert loser (B) know that it has to now start > >> forwarding data on the LAN for local receivers?" > >> i looked at the spec and don't think it covers this case. > >> but i may be wrong. > > > >When C dies, D's unicast path will switch to point to B. D should > >join B and forwarding should resume. > > D has already left the group... > > I > B will be re-elected DR and will get the joins from R1 and will send joins to the RP. From owner-pim@catarina.usc.edu Thu Oct 21 03:05:06 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA11940 for ; Thu, 21 Oct 1999 03:05:05 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id AAA28787 for pim-list; Thu, 21 Oct 1999 00:01:36 -0700 Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id AAA28783 for ; Thu, 21 Oct 1999 00:01:29 -0700 Received: by dfssl with Internet Mail Service (5.5.2650.21) id <48A7T3D2>; Thu, 21 Oct 1999 00:00:57 -0700 Message-ID: <19398D273324D3118A2B0008C7E9A569055D6873@SIT.platinum.corp.microsoft.com> From: "Mohit Talwar (Exchange)" To: helmy , Isidor Kouvelas Cc: lwei@siara.com, "Mohit Talwar (Exchange)" , pim@catarina.usc.edu, eddy@isi.edu Subject: RE: The Assert Mechanism Date: Thu, 21 Oct 1999 00:00:55 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-pim@catarina.usc.edu Precedence: bulk > -----Original Message----- > From: helmy [mailto:helmy@ceng.usc.edu] > > On Wed, 20 Oct 1999, Isidor Kouvelas wrote: > > > In message <199910210204.TAA20559@malt.mtv.siara.com>, > > Liming Wei writes: > > >> From: "Mohit Talwar (Exchange)" > > >> > > >> hi all, > > >> > > >> consider the following topology > > >> > > >> > > >> +---+ > > >> | A | > > >> +---+ > > >> . > > >> . > > >> . > > >> +-+-+ +-+-+ > > >> | B | | C | > > >> +-+-+ +-+-+ > > >> | | > > >> ----------+---------------------------------------+---------- > > >> | | > > >> R1 +---+ > > >> | D | > > >> +-+-+ > > >> | > > >> R2 > > >> > > >> A is the RP > > >> B is the DR on the LAN > > >> C is the RPF towards A for D > > >> > > >> now consider the following sequence of events... > > >> R1 joins a group G > > >> B creates (*,G) state and forwards the join upstream towards A > > >> R2 joins the group G > > >> D creates (*,G) state and sends the join on the LAN with > C as the target > > >> C create (*,G) state and forwards the join upstream towards A > > >> --- > > >> a source starts sending data > > >> an assert elections takes place on the LAN > > >> C emerges the winner of the assert election! > > >> B deletes the oif and sends a prune upstream towards A > > >> --- > > >> R2 leaves the group G > > >> D sends a prune to C > > >> C keeps sending data on the LAN for R1 > > >> --- > > >> C dies > > >> R1 stops receiving any data sent for the group G!!! > > >> > > >> whew! > > >> > > >> so my question is ... > > >> "how does the assert loser (B) know that it has to now start > > >> forwarding data on the LAN for local receivers?" > > >> i looked at the spec and don't think it covers this case. > > >> but i may be wrong. > > > > > >When C dies, D's unicast path will switch to point to B. D should > > >join B and forwarding should resume. > > > > D has already left the group... > > > > I > > > B will be re-elected DR and will get the joins from R1 and > will send joins to the RP. but B was never voted out of office :) or are u saying that everytime a neighbor dies, the DR should reevaluate all local group membersips. but instead of reevaluating ALL local group memberships, the DR can associate with each neighbor, a set of (*,G) and (S,G) entries for which there are local group members and for which it had lost the assert to that neighbor. so when a neighbor dies the DR need consider only these entries. by keeping this extra state u can reduce processing cost and avoid triggering unnecessary asserts. thanx, mohit. From owner-pim@catarina.usc.edu Thu Oct 21 03:32:20 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA12206 for ; Thu, 21 Oct 1999 03:32:19 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id AAA28946 for pim-list; Thu, 21 Oct 1999 00:28:27 -0700 Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id AAA28942 for ; Thu, 21 Oct 1999 00:28:20 -0700 Received: by dfssl with Internet Mail Service (5.5.2650.21) id <48A7T3J6>; Thu, 21 Oct 1999 00:27:48 -0700 Message-ID: <19398D273324D3118A2B0008C7E9A569055D687B@SIT.platinum.corp.microsoft.com> From: "Mohit Talwar (Exchange)" To: Isidor Kouvelas , "Mohit Talwar (Exchange)" Cc: Bill Fenner , pim@catarina.usc.edu Subject: RE: The Assert Mechanism Date: Thu, 21 Oct 1999 00:27:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-pim@catarina.usc.edu Precedence: bulk > -----Original Message----- > From: Isidor Kouvelas [mailto:kouvelas@cisco.com] > Sent: Wednesday, October 20, 1999 5:48 PM > To: Mohit Talwar (Exchange) > Cc: Bill Fenner; kouvelas@cisco.com; pim@catarina.usc.edu > Subject: Re: The Assert Mechanism > > > "Mohit Talwar (Exchange)" writes: > > > >In PIM Dense Mode, the outgoing interface is "pruned" > > > >and a timer is associated with it, so that Asserts reoccur > > > >periodically to handle failures like this. Perhaps PIM-SM > > > >could use a similar mechanism. > > > > > > > >to avoid the periodic reflood upstream of the > > > >assert loser, the assert winner can periodically > > > >re-assert as long as there is traffic for the source. > > > > > >You mean the winner would retransmit its Assert before the loser's > > >timer goes off to refresh the timer? (If the loser doesn't have a > > >timer then this doesn't help any when the winner dies). > > > >correct me if i am wrong... > >but this solution requires another timer per oif per tree entry > >and periodic generation of control (assert and joinprune) messages. > > > >what do u think about the alternative in which the DR on an > >interface keeps track of tree entries for which it has lost > >the interface and the neighbor to whom it lost it. so the > >interface can be added to those entries if the assert winner > >dies. > > This would only work if you can also detect that state has > been cleared by configuration on the assert winner. To achieve > this the GenID in Hello messages should change when state > is cleared as well as on restarts. well, i don't understand this argument. the state could just as easily have been deleted on the DR (by configuration) when it has NOT lost the interface to an assert election. how is that any different from the state having been deleted from the assert winner? > In either case, as Bill pointed out, on the loser you have to maintain > information on the interface after you have stoped forwarding (keeping > it in the list in pruned state). my arguments in favor of the alternative proposal 1. the state has to be maintained (per interface, per neighbor) only at the DR and only for tree entries for which... - there are local receivers on the interface - the assert election was won by that neighbor but i agree, it's the same amount of state either way. 2. it does not need periodic asserts or join-prunes messages, basically lower control overhead. mohit. From owner-pim@catarina.usc.edu Thu Oct 21 03:43:09 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA12251 for ; Thu, 21 Oct 1999 03:43:08 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id AAA29058 for pim-list; Thu, 21 Oct 1999 00:37:24 -0700 Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id AAA29054 for ; Thu, 21 Oct 1999 00:37:17 -0700 Received: from ceng.usc.edu (helmy@ceng.usc.edu [128.125.253.190]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id AAA16736; Thu, 21 Oct 1999 00:37:16 -0700 (PDT) Received: from localhost (helmy@localhost) by ceng.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id AAA14075; Thu, 21 Oct 1999 00:37:16 -0700 (PDT) Date: Thu, 21 Oct 1999 00:37:16 -0700 (PDT) From: helmy To: "Mohit Talwar (Exchange)" cc: Isidor Kouvelas , lwei@siara.com, pim@catarina.usc.edu, eddy@isi.edu Subject: RE: The Assert Mechanism In-Reply-To: <19398D273324D3118A2B0008C7E9A569055D6873@SIT.platinum.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pim@catarina.usc.edu Precedence: bulk > > B will be re-elected DR and will get the joins from R1 and > > will send joins to the RP. > > but B was never voted out of office :) For *,G it has,... by the Assert, and my email was in that regard, that B should become the DR again for *,G on that LAN. That's the natural thing to do in my opinion, which I thought the spec already did using timers. > or are u saying that everytime a neighbor dies, the DR > should reevaluate all local group membersips. > > but instead of reevaluating ALL local group memberships, the > DR can associate with each neighbor, a set of (*,G) and (S,G) > entries for which there are local group members and for which > it had lost the assert to that neighbor. so when a neighbor > dies the DR need consider only these entries. by keeping this > extra state u can reduce processing cost and avoid triggering > unnecessary asserts. > > thanx, > mohit. > From owner-pim@catarina.usc.edu Thu Oct 21 04:09:38 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA12480 for ; Thu, 21 Oct 1999 04:09:37 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id AAA29204 for pim-list; Thu, 21 Oct 1999 00:50:43 -0700 Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id AAA29200 for ; Thu, 21 Oct 1999 00:50:36 -0700 Received: by dfssl with Internet Mail Service (5.5.2650.21) id <48A7T3PD>; Thu, 21 Oct 1999 00:50:04 -0700 Message-ID: <19398D273324D3118A2B0008C7E9A569055D687C@SIT.platinum.corp.microsoft.com> From: "Mohit Talwar (Exchange)" To: helmy Cc: pim@catarina.usc.edu Subject: RE: The Assert Mechanism Date: Thu, 21 Oct 1999 00:50:04 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-pim@catarina.usc.edu Precedence: bulk > From: helmy [mailto:helmy@ceng.usc.edu] > > > > B will be re-elected DR and will get the joins from R1 and > > > will send joins to the RP. > > > > but B was never voted out of office :) > > For *,G it has,... by the Assert, > and my email was in that regard, that B should become the DR > again for *,G > on that LAN. That's the natural thing to do in my opinion, > which I thought > the spec already did using timers. there is a single DR per LAN, not a DR per group. so how does B know that it is has to start sending joins (*become DR*) for group G? the assert timer is for downstream routers... --- spec --- * [Assert-Timer (per (S,G) or (*,G) route entry)] The Assert-Timer for an (S,G) or (*,G) route entry is used for timing out Asserts received. When an Assert is received and the RPF neighbor is changed to the Assert winner, the Assert- Timer is set to [Assert-Timeout], and is restarted to this value every time a subsequent Assert for the entry is received on its incoming interface. When the timer expires, the router resets its RPF neighbor according to its unicast routing table. --- the OIF timer is to time out oifs... --- spec --- * [Oif-Timer (kept per oif for each route entry)] A timer for each oif of a route entry is used to time out that oif. --- although i now see isidor's point that it could be used to add the OIF back in when the OIF was added by IGMP at the DR and is subsequently pruned by an assert. mohit. From owner-pim@catarina.usc.edu Thu Oct 21 04:38:51 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA12728 for ; Thu, 21 Oct 1999 04:38:49 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id BAA29402 for pim-list; Thu, 21 Oct 1999 01:28:28 -0700 Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id BAA29398 for ; Thu, 21 Oct 1999 01:28:24 -0700 Received: from ceng.usc.edu (helmy@ceng.usc.edu [128.125.253.190]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id BAA02338; Thu, 21 Oct 1999 01:28:22 -0700 (PDT) Received: from localhost (helmy@localhost) by ceng.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id BAA14309; Thu, 21 Oct 1999 01:28:19 -0700 (PDT) Date: Thu, 21 Oct 1999 01:28:19 -0700 (PDT) From: helmy To: "Mohit Talwar (Exchange)" cc: pim@catarina.usc.edu Subject: RE: The Assert Mechanism In-Reply-To: <19398D273324D3118A2B0008C7E9A569055D687C@SIT.platinum.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pim@catarina.usc.edu Precedence: bulk > there is a single DR per LAN, not a DR per group. > so how does B know that it is has to start sending > joins (*become DR*) for group G? when the DR loses the assert, it no longer is the DR for that group (as per the spec). In that sense, yes there is a DR per group. as for the rest of the email I thought we already had a timer that took care of this situation. I remember we've come across this problem before and it was solved... sigh.. it's been ages since I've read the whole spec again! > > the assert timer is for downstream routers... > > --- spec --- > > * [Assert-Timer (per (S,G) or (*,G) route entry)] The > Assert-Timer for an (S,G) or (*,G) route entry is used for > timing out Asserts received. When an Assert is received and > the RPF neighbor is changed to the Assert winner, the Assert- > Timer is set to [Assert-Timeout], and is restarted to this > value every time a subsequent Assert for the entry is received > on its incoming interface. When the timer expires, the router > resets its RPF neighbor according to its unicast routing > table. > > --- > > > the OIF timer is to time out oifs... > > --- spec --- > * [Oif-Timer (kept per oif for each route entry)] A timer for > each oif of a route entry is used to time out that oif. > --- > > although i now see isidor's point that it could be used to add the OIF > back in when the OIF was added by IGMP at the DR and is subsequently > pruned by an assert. > > mohit. > From owner-pim@catarina.usc.edu Thu Oct 21 11:29:39 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29747 for ; Thu, 21 Oct 1999 11:29:38 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id IAA01550 for pim-list; Thu, 21 Oct 1999 08:00:28 -0700 Received: from mailgate.fore.com (mailgate.fore.com [169.144.68.6]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id IAA01546 for ; Thu, 21 Oct 1999 08:00:13 -0700 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id KAA28268; Thu, 21 Oct 1999 10:51:59 -0400 (EDT) Received: from fore.com ([169.144.133.49]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id KAA28884; Thu, 21 Oct 1999 10:52:01 -0400 (EDT) Message-ID: <380F2904.9699EAB2@fore.com> Date: Thu, 21 Oct 1999 10:53:56 -0400 From: Ardas Cilingiroglu X-Mailer: Mozilla 4.06 [en] (WinNT; I) MIME-Version: 1.0 To: "Mohit Talwar (Exchange)" CC: pim@catarina.usc.edu, eddy@isi.edu Subject: Re: The Assert Mechanism References: <19398D273324D3118A2B0008C7E9A569055D6713@SIT.platinum.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I can think of two solutions that will take care of 2 different problems: Problem-1: C dies. Solution-1: For a solution on this I agree with Mohit that, the assert-loser oif (in case of a DR with local-receivers) can keep track of the neighbor that he lost assert to, and in case that neighbor dies he can remove the assert state. Problem-2: R2 leaves membership and oif on C gets pruned. Solution-2: For this we can have a timer, assert-oif-timer on both the winner and the loser guy. The winner guy assumes the DR role for the group G for the whole assert-period. It means even if C receives prune from D, C will not remove the oif because of the local member R1. Assert-oif-timer expires after the assert-period on both B and C, after which C will stop its DR role for G and therefore remove the oif, and B will resume its role and add the oif. thanks, Ardas Mohit Talwar (Exchange) wrote: > hi all, > > consider the following topology > > > +---+ > | A | > +---+ > . > . > . > +-+-+ +-+-+ > | B | | C | > +-+-+ +-+-+ > | | > ----------+---------------------------------------+---------- > | | > R1 +---+ > | D | > +-+-+ > | > R2 > > A is the RP > B is the DR on the LAN > C is the RPF towards A for D > > now consider the following sequence of events... > R1 joins a group G > B creates (*,G) state and forwards the join upstream towards A > R2 joins the group G > D creates (*,G) state and sends the join on the LAN with C as the target > C create (*,G) state and forwards the join upstream towards A > --- > a source starts sending data > an assert elections takes place on the LAN > C emerges the winner of the assert election! > B deletes the oif and sends a prune upstream towards A > --- > R2 leaves the group G > D sends a prune to C > C keeps sending data on the LAN for R1 > --- > C dies > R1 stops receiving any data sent for the group G!!! > > whew! > > so my question is ... > "how does the assert loser (B) know that it has to now start > forwarding data on the LAN for local receivers?" > i looked at the spec and don't think it covers this case. > but i may be wrong. > > i looked at rusty's notes on the web (thanx rusty :) and found > that he had noted the same problem but dunno if it was ever > discussed on the list. this is what he has to say... > > "If a router is the DR on an interface that belongs to a (*, G)'s > downstream list and that interface has local recievers (igmp), > some implementation dependent method must be used to ensure > the interface (and joins to the RP) are re-instantiated when > the assert winner quits forwarding traffic, if a no facility > is added to the protocol to over come this. > > One method could be maintaining a timer on the loosing oif of > the DR with local recievers. another method could be a hello > option that the assert winner would add stating that it is > actively forwarding (s,g) or (*,g) for a local reciever." > > another good solution would be to require that when a router loses a (*,G) > or (S,G) assert election for an interface on which it is the DR and for > which there are local receivers, the router associate that (*,G) or (S,G) > entry with the assert winning neighbor. this list is also updated when > IGMP declares that all local members for a group have left. > > when a neighbor dies and the router is the DR on that interface, the router > should go ahead and add the interface to all tree entries in this list for > that neighbor. > > thanx, > mohit. From owner-pim@catarina.usc.edu Thu Oct 21 12:05:18 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02219 for ; Thu, 21 Oct 1999 12:05:18 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id IAA01872 for pim-list; Thu, 21 Oct 1999 08:43:14 -0700 Received: from ntserver1.redstonecom.com (ntserver1.redstonecom.com [199.105.223.130]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id IAA01868 for ; Thu, 21 Oct 1999 08:42:59 -0700 Received: by NTSERVER1 with Internet Mail Service (5.0.1460.8) id <45HQPVG7>; Thu, 21 Oct 1999 11:42:30 -0400 Message-ID: <90ABC30C744ED311B16E00500464BEFC1B0723@NTSERVER1> From: "Shekhar, Ravi" To: Isidor Kouvelas , "Shekhar, Ravi" Cc: "Mohit Talwar (Exchange)" , Bill Fenner , pim@catarina.usc.edu Subject: RE: The Assert Mechanism Date: Thu, 21 Oct 1999 11:42:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-pim@catarina.usc.edu Precedence: bulk > This is done for the case when the DR is a downstream router. > In this case it > creates a (*,G) state because of the IGMP report but it cannot add the > interface to the olist as it is the (*,G) incoming interface. > However it still > has to generate joins. But the real question is that is it required for DR to inform RPF every 30 seconds "periodically"? Shouldnt there be a mechanism to do it only once when membership comes up (perhaps by forcing a phony assert on the LAN). And from then on, since assert-winner is running IGMP, it will know when local group membership is withdrawn and accordingly prune the oif. The only good explanation I could find for doing it periodically is that RPF nbr is _not_ running IGMP and hence doesnt know when to withdraw <*, G> join. Are there any other reasons? Anyways, I do not have a strong opinion about doing it either way and supporting both might be good. Mohit has already pointed out couple of advantages of doing it the way he suggested. I would like to add couple of observations about the other way (i.e. DR periodically sending join to the assert winner): Disadvantages: 1) Extra J/P messages. Advantages: 1) It requires running IGMP only on DR. This could become a useful feature, especially now that we have DR priority option and DR can be more deterministically pointed out on the LAN. Also it might be another point in favor of SM as opposed to dense-mode protocols that typically require IGMP to run on all the routers on the LAN with hosts. 2) In the example which Mohit pointed out, consider these two sequence of events: a) if C was never forwarding data, B would have been responsible for forwarding data for local members. b) - Next assume C was forwarding the data due to join from D. - Local member comes up and C wins the assert. B does not forward data for local memebers. C takes on the responsibility. - D withdraws its join but C still continues to forward data for local members. Now in both these cases, the end state of the network is same (local group member on the LAN and no other joins). But the end result is different. In one case B is forwarding data, and in other case C is forwarding data. This is not wrong, but it could add complexity while debugging the network. Forwarder on the LAN depends on the history of the network state as opposed to just current state. Please feel free to add to/correct the list. Thanks. - Ravi Shekhar. From owner-pim@catarina.usc.edu Thu Oct 21 12:11:06 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02639 for ; Thu, 21 Oct 1999 12:11:05 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id IAA01970 for pim-list; Thu, 21 Oct 1999 08:55:06 -0700 Received: from mailgate.fore.com (mailgate.fore.com [169.144.68.6]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id IAA01966 for ; Thu, 21 Oct 1999 08:54:56 -0700 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id LAA04754; Thu, 21 Oct 1999 11:53:45 -0400 (EDT) Received: from fore.com ([169.144.133.49]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id LAA21822; Thu, 21 Oct 1999 11:53:47 -0400 (EDT) Message-ID: <380F377E.34684D5B@fore.com> Date: Thu, 21 Oct 1999 11:55:42 -0400 From: Ardas Cilingiroglu X-Mailer: Mozilla 4.06 [en] (WinNT; I) MIME-Version: 1.0 To: "Mohit Talwar (Exchange)" , pim@catarina.usc.edu, eddy@isi.edu Subject: Re: The Assert Mechanism References: <19398D273324D3118A2B0008C7E9A569055D6713@SIT.platinum.corp.microsoft.com> <380F2904.9699EAB2@fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I just wanted to stress another version of the problem, where - B is the DR and has the (*,G) entry, and - C has an (S,G) entry (i.e. R2 takes a different path for joining to Shared-Tree) In this case, after assert B will create (S,G)RPT entry with oif removed. Note that the solutions can get modified to take care of these problems as well, as follows: - (S,G)RPT should keep track of the winner-neighbor on the lost-oif. - By using assert-oif-timers, C should assume the role of DRship for (S,G) and B should stop acting like DR for (S,G) for assert-period. > Mohit Talwar (Exchange) wrote: > > > hi all, > > > > consider the following topology > > > > > > +---+ > > | A | > > +---+ > > . > > . > > . > > +-+-+ +-+-+ > > | B | | C | > > +-+-+ +-+-+ > > | | > > ----------+---------------------------------------+---------- > > | | > > R1 +---+ > > | D | > > +-+-+ > > | > > R2 > > > > A is the RP > > B is the DR on the LAN > > C is the RPF towards A for D > > > > now consider the following sequence of events... > > R1 joins a group G > > B creates (*,G) state and forwards the join upstream towards A > > R2 joins the group G > > D creates (*,G) state and sends the join on the LAN with C as the target > > C create (*,G) state and forwards the join upstream towards A > > --- > > a source starts sending data > > an assert elections takes place on the LAN > > C emerges the winner of the assert election! > > B deletes the oif and sends a prune upstream towards A > > --- > > R2 leaves the group G > > D sends a prune to C > > C keeps sending data on the LAN for R1 > > --- > > C dies > > R1 stops receiving any data sent for the group G!!! > > > > whew! > > > > so my question is ... > > "how does the assert loser (B) know that it has to now start > > forwarding data on the LAN for local receivers?" > > i looked at the spec and don't think it covers this case. > > but i may be wrong. > > > > i looked at rusty's notes on the web (thanx rusty :) and found > > that he had noted the same problem but dunno if it was ever > > discussed on the list. this is what he has to say... > > > > "If a router is the DR on an interface that belongs to a (*, G)'s > > downstream list and that interface has local recievers (igmp), > > some implementation dependent method must be used to ensure > > the interface (and joins to the RP) are re-instantiated when > > the assert winner quits forwarding traffic, if a no facility > > is added to the protocol to over come this. > > > > One method could be maintaining a timer on the loosing oif of > > the DR with local recievers. another method could be a hello > > option that the assert winner would add stating that it is > > actively forwarding (s,g) or (*,g) for a local reciever." > > > > another good solution would be to require that when a router loses a (*,G) > > or (S,G) assert election for an interface on which it is the DR and for > > which there are local receivers, the router associate that (*,G) or (S,G) > > entry with the assert winning neighbor. this list is also updated when > > IGMP declares that all local members for a group have left. > > > > when a neighbor dies and the router is the DR on that interface, the router > > should go ahead and add the interface to all tree entries in this list for > > that neighbor. > > > > thanx, > > mohit. From owner-pim@catarina.usc.edu Thu Oct 21 13:43:04 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07996 for ; Thu, 21 Oct 1999 13:43:03 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id KAA02706 for pim-list; Thu, 21 Oct 1999 10:31:46 -0700 Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id KAA02702 for ; Thu, 21 Oct 1999 10:31:30 -0700 Received: by dfssl with Internet Mail Service (5.5.2650.21) id <48A7TZ3A>; Thu, 21 Oct 1999 10:30:50 -0700 Message-ID: <19398D273324D3118A2B0008C7E9A569055D6973@SIT.platinum.corp.microsoft.com> From: "Mohit Talwar (Exchange)" To: Ardas Cilingiroglu Cc: pim@catarina.usc.edu Subject: RE: The Assert Mechanism Date: Thu, 21 Oct 1999 10:30:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-pim@catarina.usc.edu Precedence: bulk hi ardas, > Solution-2: For this we can have a timer, assert-oif-timer on > both the winner and the loser guy. The winner guy assumes the > DR role for the group G for the whole assert-period. It means > even if C receives prune from D, C will not remove the oif > because of the local member R1. > Assert-oif-timer expires after the assert-period on both B and C, > after which C will stop its DR role for G and therefore remove the > oif, and B will resume its role and add the oif. i don't see why u need the assert-oif-timer. the DR (B) doesn't HAVE TO take over responsibility for local receivers necesarily. it should be happy as long as there is someone (C) doing it. it needs to take over only when that someone (C) stops doing it (dies). > I just wanted to stress another version of the problem, where > - B is the DR and has the (*,G) entry, and > - C has an (S,G) entry (i.e. R2 takes a different > path for joining to Shared-Tree) > > In this case, after assert B will create (S,G)RPT entry with > oif removed. Note that the solutions can get modified to take > care of these problems as well, as follows: > > - (S,G)RPT should keep track of the winner-neighbor on the lost-oif. that is what i had in mind too when i said that the DR keeps track of (*,g) and ***(S,G)*** entries. thanx for making this point. i think i have exhausted my quota of mails on this issue. so i'll stop now :) mohit. From owner-pim@catarina.usc.edu Thu Oct 21 14:12:15 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09316 for ; Thu, 21 Oct 1999 14:12:14 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id KAA02851 for pim-list; Thu, 21 Oct 1999 10:39:33 -0700 Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id KAA02847 for ; Thu, 21 Oct 1999 10:39:18 -0700 Received: from kouvelas-u10.cisco.com (kouvelas-u10.cisco.com [171.69.65.54]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id KAA20094; Thu, 21 Oct 1999 10:43:44 -0700 (PDT) Received: from localhost (kouvelas@localhost) by kouvelas-u10.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.WS.1.2) with ESMTP id KAA08886; Thu, 21 Oct 1999 10:38:39 -0700 (PDT) Message-Id: <199910211738.KAA08886@kouvelas-u10.cisco.com> X-Authentication-Warning: kouvelas-u10.cisco.com: kouvelas owned process doing -bs To: "Mohit Talwar (Exchange)" cc: Isidor Kouvelas , Bill Fenner , pim@catarina.usc.edu Subject: Re: The Assert Mechanism In-reply-to: Your message of "Thu, 21 Oct 1999 00:27:47 PDT." <19398D273324D3118A2B0008C7E9A569055D687B@SIT.platinum.corp.microsoft.com> Date: Thu, 21 Oct 1999 10:38:39 -0700 From: Isidor Kouvelas Sender: owner-pim@catarina.usc.edu Precedence: bulk "Mohit Talwar (Exchange)" writes: > > >> -----Original Message----- >> From: Isidor Kouvelas [mailto:kouvelas@cisco.com] >> Sent: Wednesday, October 20, 1999 5:48 PM >> To: Mohit Talwar (Exchange) >> Cc: Bill Fenner; kouvelas@cisco.com; pim@catarina.usc.edu >> Subject: Re: The Assert Mechanism >> >> >> "Mohit Talwar (Exchange)" writes: >> > > >In PIM Dense Mode, the outgoing interface is "pruned" >> > > >and a timer is associated with it, so that Asserts reoccur >> > > >periodically to handle failures like this. Perhaps PIM-SM >> > > >could use a similar mechanism. >> > > > >> > > >to avoid the periodic reflood upstream of the >> > > >assert loser, the assert winner can periodically >> > > >re-assert as long as there is traffic for the source. >> > > >> > >You mean the winner would retransmit its Assert before the loser's >> > >timer goes off to refresh the timer? (If the loser doesn't have a >> > >timer then this doesn't help any when the winner dies). >> > >> >correct me if i am wrong... >> >but this solution requires another timer per oif per tree entry > >and periodic generation of control (assert and joinprune) messages. >> > >> >what do u think about the alternative in which the DR on an >> >interface keeps track of tree entries for which it has lost >> >the interface and the neighbor to whom it lost it. so the >> >interface can be added to those entries if the assert winner >> >dies. >> >> This would only work if you can also detect that state has >> been cleared by configuration on the assert winner. To achieve >> this the GenID in Hello messages should change when state >> is cleared as well as on restarts. > >well, i don't understand this argument. the state could just >as easily have been deleted on the DR (by configuration) when >it has NOT lost the interface to an assert election. how is >that any different from the state having been deleted from the >assert winner? It is different as in the case that the state is cleared on the DR, on the next IGMP report the router will again create (*,G) and add the interface to the olist (since it is the DR) hence there is no problem. If the state is cleared on an assert winner that is not the DR, then it will lose its forwarding state and the DR will have no way of finding out. The only way to work around this is to change the GenID in the Hello message. >> In either case, as Bill pointed out, on the loser you have to maintain >> information on the interface after you have stoped forwarding (keeping >> it in the list in pruned state). > >my arguments in favor of the alternative proposal > >1. the state has to be maintained (per interface, per neighbor) > only at the DR and > only for tree entries for which... > - there are local receivers on the interface > - the assert election was won by that neighbor > > but i agree, it's the same amount of state either way. Right. Isidor >2. it does not need periodic asserts or join-prunes messages, > basically lower control overhead. > >mohit. From owner-pim@catarina.usc.edu Thu Oct 21 14:16:06 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09415 for ; Thu, 21 Oct 1999 14:16:05 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id KAA02980 for pim-list; Thu, 21 Oct 1999 10:48:09 -0700 Received: from ntserver1.redstonecom.com (ntserver1.redstonecom.com [199.105.223.130]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id KAA02976 for ; Thu, 21 Oct 1999 10:47:56 -0700 Received: by NTSERVER1 with Internet Mail Service (5.0.1460.8) id <45HQPVT7>; Thu, 21 Oct 1999 13:47:16 -0400 Message-ID: <90ABC30C744ED311B16E00500464BEFC1B2505@NTSERVER1> From: "Shekhar, Ravi" To: Vaishali Pandya , pim@catarina.usc.edu Subject: RE: PIMSM Date: Thu, 21 Oct 1999 13:47:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-pim@catarina.usc.edu Precedence: bulk > When RP receives register message, it will create SG with *G oif - > iif(SG). But, if *g and SG comes via the same interface, oif > for SG will be > null and join/prune towards S will not be send. So, How this > kind of case > will work??? Normally, RP will decapsulate the register message and forward it on oifs of <*, G> regardless of which intf it came in on. But if RP decides to switch to SPT, section 3.2.1 Periodic J/P point 2.3: > 2 A particular source address, S, is included in the join > list with the RPT and WC bits cleared under the following > conditions: > > 1 The Join/Prune message is being sent to the RPF > neighbor toward S, and > > 2 There exists an active (S,G) entry with the RPT-bit > flag cleared, and > > 3 The oif list in the (S,G) entry is not null. fails to cover it. I think it should be modified to "The oif list in the (S,G) entry is not null OR the router is the RP for <*, G>" And if its desirable to cover IGMPv3 style local group memberships, one can also add: "OR the router is the DR on the same interface as the RPF nbr and has SPT local group membership" Comments? - Ravi Shekhar. From owner-pim@catarina.usc.edu Thu Oct 21 14:51:34 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10596 for ; Thu, 21 Oct 1999 14:51:31 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id LAA03491 for pim-list; Thu, 21 Oct 1999 11:25:59 -0700 Received: from dthaler.microsoft.com ([131.107.152.20]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id LAA03487 for ; Thu, 21 Oct 1999 11:25:51 -0700 Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id NAA00477; Thu, 21 Oct 1999 13:05:14 -0700 (PDT) (envelope-from dthaler) From: Dave Thaler Message-Id: <199910212005.NAA00477@dthaler.microsoft.com> Subject: Re: The Assert Mechanism In-Reply-To: <90ABC30C744ED311B16E00500464BEFC1B0723@NTSERVER1> from "Shekhar, Ravi" at "Oct 21, 1999 11:42:28 am" To: rshekhar@unisphere.cc (Shekhar Ravi) Date: Thu, 21 Oct 1999 13:05:14 -0700 (PDT) Cc: pim@catarina.usc.edu X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Advantages: > > 1) It requires running IGMP only on DR. This could become a useful > feature, especially now that we have DR priority option and DR can > be more deterministically pointed out on the LAN. Also it might be > another point in favor of SM as opposed to dense-mode protocols that > typically require IGMP to run on all the routers on the LAN with hosts. That sounds like a bad idea to me. If all routers on the LAN aren't running IGMP, and you're turning on/off IGMP whenever you become/stop being a DR, that sounds like a convergence nightmare. You really want to run IGMP on all routers so that all routers have a consistent view of which groups have directly-connected members. -Dave From owner-pim@catarina.usc.edu Thu Oct 21 15:16:17 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11410 for ; Thu, 21 Oct 1999 15:16:16 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id LAA03672 for pim-list; Thu, 21 Oct 1999 11:49:04 -0700 Received: from ntserver1.redstonecom.com (ntserver1.redstonecom.com [199.105.223.130]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id LAA03668 for ; Thu, 21 Oct 1999 11:48:56 -0700 Received: by NTSERVER1 with Internet Mail Service (5.0.1460.8) id <45HQPV6H>; Thu, 21 Oct 1999 14:48:27 -0400 Message-ID: <90ABC30C744ED311B16E00500464BEFC1B256A@NTSERVER1> From: "Shekhar, Ravi" To: Dave Thaler , "Shekhar, Ravi" Cc: pim@catarina.usc.edu Subject: RE: The Assert Mechanism Date: Thu, 21 Oct 1999 14:48:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-pim@catarina.usc.edu Precedence: bulk > > Advantages: > > > > 1) It requires running IGMP only on DR. This could become a useful > > feature, especially now that we have DR priority option and DR can > > be more deterministically pointed out on the LAN. Also it might be > > another point in favor of SM as opposed to dense-mode protocols that > > typically require IGMP to run on all the routers on the LAN with hosts. > > That sounds like a bad idea to me. If all routers on the LAN aren't > running IGMP, and you're turning on/off IGMP whenever you become/stop > being a DR, that sounds like a convergence nightmare. Certainly thats true. If a router can be a potential DR, its better to run IGMP on it. When I stated that, I was thinking of possiblity of having PIMSM routers which are ineligible to be DR (like OSPF allows for routers with Router Priority set to 0). Such routers need not run IGMP. - Ravi Shekhar. From owner-pim@catarina.usc.edu Thu Oct 21 19:31:06 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15765 for ; Thu, 21 Oct 1999 19:31:04 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id QAA05442 for pim-list; Thu, 21 Oct 1999 16:23:02 -0700 Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id QAA05438 for ; Thu, 21 Oct 1999 16:22:57 -0700 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 13E8E4CE28; Thu, 21 Oct 1999 19:22:56 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id TAA18705; Thu, 21 Oct 1999 19:22:55 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id QAA16471; Thu, 21 Oct 1999 16:22:55 -0700 (PDT) Message-Id: <199910212322.QAA16471@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: kouvelas@cisco.com Subject: Re: The Assert Mechanism Cc: pim@catarina.usc.edu Date: Thu, 21 Oct 1999 16:22:55 -0700 Versions: dmail (solaris) 2.2e/makemail 2.8u Sender: owner-pim@catarina.usc.edu Precedence: bulk >...on the >next IGMP report the router will again create (*,G) and add the interface to >the olist... The IGMP spec doesn't say anything about informing the router component on every IGMP report (i.e. this is an implementation-dependent issue). I'd much rather see the PIM spec talk about not removing interfaces with group members in response to prunes or timeouts. Bill From owner-pim@catarina.usc.edu Thu Oct 21 20:11:02 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16159 for ; Thu, 21 Oct 1999 20:11:00 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id RAA05791 for pim-list; Thu, 21 Oct 1999 17:05:49 -0700 Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id RAA05787 for ; Thu, 21 Oct 1999 17:05:44 -0700 Received: from kouvelas-u10.cisco.com (kouvelas-u10.cisco.com [171.69.65.54]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id RAA28828; Thu, 21 Oct 1999 17:10:10 -0700 (PDT) Received: from localhost (kouvelas@localhost) by kouvelas-u10.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.WS.1.2) with ESMTP id RAA09024; Thu, 21 Oct 1999 17:04:52 -0700 (PDT) Message-Id: <199910220004.RAA09024@kouvelas-u10.cisco.com> X-Authentication-Warning: kouvelas-u10.cisco.com: kouvelas owned process doing -bs To: Bill Fenner cc: kouvelas@cisco.com, pim@catarina.usc.edu Subject: Re: The Assert Mechanism In-reply-to: Your message of "Thu, 21 Oct 1999 16:22:55 PDT." <199910212322.QAA16471@windsor.research.att.com> Date: Thu, 21 Oct 1999 17:04:52 -0700 From: Isidor Kouvelas Sender: owner-pim@catarina.usc.edu Precedence: bulk Bill Fenner writes: > >>...on the >>next IGMP report the router will again create (*,G) and add the interface to >>the olist... I was refering to the case where state is cleared by configuration on a router. In this case the next IGMP report will be the first the router hears of the group. >The IGMP spec doesn't say anything about informing the router component >on every IGMP report (i.e. this is an implementation-dependent issue). >I'd much rather see the PIM spec talk about not removing interfaces with >group members in response to prunes or timeouts. Same here. Isidor From owner-pim@catarina.usc.edu Fri Oct 22 06:43:00 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA05453 for ; Fri, 22 Oct 1999 06:42:59 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id DAA08031 for pim-list; Fri, 22 Oct 1999 03:28:43 -0700 Received: from hotmail.com (law-f88.hotmail.com [209.185.131.151]) by catarina.usc.edu (8.6.10/8.6.9) with SMTP id DAA08027 for ; Fri, 22 Oct 1999 03:28:38 -0700 Received: (qmail 52514 invoked by uid 0); 22 Oct 1999 10:28:07 -0000 Message-ID: <19991022102807.52513.qmail@hotmail.com> Received: from 192.135.245.219 by www.hotmail.com with HTTP; Fri, 22 Oct 1999 03:28:06 PDT X-Originating-IP: [192.135.245.219] From: "bhavesh pathak" To: pim@catarina.usc.edu Subject: doubt in PIM-REFRESH draft Date: Fri, 22 Oct 1999 03:28:06 PDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-pim@catarina.usc.edu Precedence: bulk Dear everyone I have following doubts in pim-refresh draft. 1. In section-3 first point, o Whenever a (S,G) State-Refresh message is received on the interface for RPF(S) by a router with no existing (S,G) entry, ^^^^^^ an (S,G) entry should be created. Question : does this mean that there can be more than one interfaces to reach RPF-neighbor? How? 2. With respect to section-4, it seems that in follwoing case two router will go in the forwarding state. R1 R2 R3 (upstream routes) | | | | | | ---------------------------------- Say, R1 had won assert and was forwarding data to LAN. If R1 goes down : - R2 and R3,(when holdtime passes) both will send State-Refresh message with assert-override flag set and make interface connected to LAN in the forwarding state. Is this expected behavior? thanks, bhavesh ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-pim@catarina.usc.edu Fri Oct 22 12:20:34 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21982 for ; Fri, 22 Oct 1999 12:20:34 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id IAA09433 for pim-list; Fri, 22 Oct 1999 08:58:34 -0700 Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id IAA09429 for ; Fri, 22 Oct 1999 08:58:29 -0700 Received: from kouvelas-u10.cisco.com (kouvelas-u10.cisco.com [171.69.65.54]) by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with ESMTP id JAA29097; Fri, 22 Oct 1999 09:11:08 -0700 (PDT) Received: from localhost (kouvelas@localhost) by kouvelas-u10.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.WS.1.2) with ESMTP id IAA09312; Fri, 22 Oct 1999 08:57:52 -0700 (PDT) Message-Id: <199910221557.IAA09312@kouvelas-u10.cisco.com> X-Authentication-Warning: kouvelas-u10.cisco.com: kouvelas owned process doing -bs To: "bhavesh pathak" cc: pim@catarina.usc.edu Subject: Re: doubt in PIM-REFRESH draft Date: Fri, 22 Oct 1999 08:57:52 -0700 From: Isidor Kouvelas Sender: owner-pim@catarina.usc.edu Precedence: bulk "bhavesh pathak" writes: > >Dear everyone >I have following doubts in pim-refresh draft. > >1. In section-3 first point, > > o Whenever a (S,G) State-Refresh message is received on the > interface for RPF(S) by a router with no existing (S,G) entry, > ^^^^^^ > an (S,G) entry should be created. > >Question : does this mean that there can be more than one > interfaces to reach RPF-neighbor? How? No. The point above means that you create state if the SR message is received on the expected incomming interface for the (S,G) entry. There is still only one incomming interface determined by unicast routing. >2. With respect to section-4, it seems that in follwoing > case two router will go in the forwarding state. > > > R1 R2 R3 (upstream routes) > | | | > | | | >---------------------------------- > >Say, R1 had won assert and was forwarding data to LAN. > >If R1 goes down : >- R2 and R3,(when holdtime passes) both will send State-Refresh > message with assert-override flag set and make > interface connected to LAN in the forwarding state. > >Is this expected behavior? This will not happen. R2 and R3 will keep on forwarding refresh messages on the LAN after R1 goes down. Lets say that R2 has the best metric and should become forwarder. In this case R3 will hear the refresh messages from R2 and since they contain a better metric will not attempt to take over using the AO flag. I have a slightly revised version of the draft which I will try to submit today to make the deadline. thanks Isidor From owner-pim@catarina.usc.edu Fri Oct 22 13:13:27 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25270 for ; Fri, 22 Oct 1999 13:13:26 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id JAA10013 for pim-list; Fri, 22 Oct 1999 09:56:00 -0700 Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id JAA10009 for ; Fri, 22 Oct 1999 09:55:55 -0700 Received: by dfssl with Internet Mail Service (5.5.2650.21) id <48A74XF8>; Fri, 22 Oct 1999 09:55:15 -0700 Message-ID: <19398D273324D3118A2B0008C7E9A56901EBF0B7@SIT.platinum.corp.microsoft.com> From: "Dave Thaler (Exchange)" To: "'pim@catarina.usc.edu'" Subject: PIM MIB update Date: Fri, 22 Oct 1999 09:55:14 -0700 X-Message-Flag: Follow up MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-pim@catarina.usc.edu Precedence: bulk FYI. Bert Wijnen writes: > Subject: IGMP,Multicast,PIM MIBs are ready for IETF Last Call or IESG > > Rob/Dave, > These 3 MIB documents are fine now to progress further onto the > standards track. They were reviewed by John Flick and myself. Rob Coltun writes: > Great news. > At what level should we move the PIM MIB forward? - my > suggestion is to wait for the PIM drafts to move forward as the current > PIM rfc is experimental. The others to proposed, right? Dino Farinacci writes: > Fine with me. -Dave From owner-pim@catarina.usc.edu Fri Oct 22 17:14:36 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07631 for ; Fri, 22 Oct 1999 17:14:33 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id LAA11002 for pim-list; Fri, 22 Oct 1999 11:57:33 -0700 Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id LAA10998 for ; Fri, 22 Oct 1999 11:57:27 -0700 Received: from kouvelas-u10.cisco.com (kouvelas-u10.cisco.com [171.69.65.54]) by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with ESMTP id MAA06109; Fri, 22 Oct 1999 12:09:31 -0700 (PDT) Received: from localhost (kouvelas@localhost) by kouvelas-u10.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.WS.1.2) with ESMTP id LAA09803; Fri, 22 Oct 1999 11:56:14 -0700 (PDT) Message-Id: <199910221856.LAA09803@kouvelas-u10.cisco.com> X-Authentication-Warning: kouvelas-u10.cisco.com: kouvelas owned process doing -bs To: pim@catarina.usc.edu cc: dino@procket.com, kurtw@antc.uoregon.edu, kouvelas@cisco.com Subject: Revised version of PIM DM State-Refresh draft Date: Fri, 22 Oct 1999 11:56:13 -0700 From: Isidor Kouvelas Sender: owner-pim@catarina.usc.edu Precedence: bulk A new version of this draft (draft-ietf-pim-refresh-01.txt) was submitted today to the ID directory. The most significant modification is the inclusion of the State-Refresh origination interval in the SR message and the SR Hello option. I am including the draft below. thanks Isidor Network Working Group Dino Farinacci Internet Draft Procket Networks Expiration Date: April, 2000 I. Kouvelas cisco Systems K. Windisch University of Oregon October 21, 1999 State Refresh in PIM-DM Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Introduction This proposal extends the PIM-DM [1] protocol specification by intro- ducing the PIM State-Refresh control message. When an (S,G) entry is created in a router for a directly connected source, if the interface directly connected to the source is the incoming interface for the entry, a new timer is started: the State- Refresh-Timer [SRT(S,G)]. The State-Refresh-Timer controls periodic transmission of the PIM State-Refresh message, which is propagated hop-by-hop down the (S,G) RPF tree. When received by a router on the RPF interface, the State-Refresh message causes existing prune state to be refreshed. Farinacci, Kouvelas, Windisch [Page 1] Internet Draft PIM-DM State Refresh October 1999 Addition of this heartbeat message solves many of the current prob- lems with PIM-DM. It prevents the periodic timeout of prune state in routers, greatly reducing the re-flooding of multicast traffic down the pruned branches that expire periodically. It also causes topology changes to be realised quicker than the traditional 3 minute timeout. 2. Sending State-Refresh For a given (S,G) tree, State-Refresh messages will be originated by all routers that use an interface directly connected to the source as the RPF interface for the source. Upon expiry of their (S,G) State- Refresh-Timer the PIM State-Refresh message will be sent on all PIM- DM interfaces with active PIM neighbors, except the interface con- necting the source. In addition, when the SRT(S,G) expires, the following timers are refreshed: SRT(S,G) is restarted with it's default value [Refresh- Interval], and all (S,G) pruned interface timers are refreshed. The first-hop router will no longer originate state refresh messages when the (S,G) entry times out. The (S,G) entry timer for the first- hop router is updated only by the receipt of data and not upon expiry of the SRT(S,G) timer. All other routers will forward state refresh messages only when receiving one from a neighbor, as described below. State-Refresh messages are multicast using address 224.0.0.13 (ALL- PIM ROUTERS group) with protocol number equal to PIMv2 and a TTL of 1. The IP source address is set to the outgoing interface address and is rewritten hop-by-hop when forwarding. The State-Refresh message contains the source and group the message is referring to, the originator address (for debugging purposes), routing information required by the LAN assert mechanism, a TTL value for scope control (different from header TTL), the state-refresh ori- gination interval and a number of flags described below. The routing information, TTL and flags can be rewritten hop-by-hop. The TTL value in the message is initialised by the originating router and can be either the result of local configuration, or the value of the largest TTL observed in data packets from the source so far. The TTL value will be decremented by downstream routers forwarding the State-Refresh message. Routers will only forward the State-Refresh message if the value of the TTL in the message is greater than 0 and larger than the configured local threshold. This will prevent State-Refresh messages from reaching areas of the network where data packets have not already created (S,G) state. Farinacci, Kouvelas, Windisch [Page 2] Internet Draft PIM-DM State Refresh October 1999 The flags in the message consist of the Prune-Indicator, Prune-Now and Assert-Override flags. The Prune-Indicator flag is cleared when the message is transmitted on an outgoing interface in forwarding state and set when the message is transmitted on a pruned interface. This mechanism is required to recover from situations where loss of consecutive refresh messages has caused an inconsistency in prune state on a branch of the (S,G) tree. The Prune-Now flag is required to provide a mechanism for rate-limiting control traffic on multi- access LANs. The Assert-Override flag is used to recover from assert winner failures. 3. Receiving State-Refresh PIM State-Refresh messages are RPF flooded down the (S,G) tree using the data source address included in the message to determine the RPF neighbor. When a PIM State-Refresh message is received for a given (S,G), the following steps are taken: o Whenever a (S,G) State-Refresh message is received on the interface for RPF(S) by a router with no existing (S,G) entry, an (S,G) entry should be created. If the Prune-Indicator flag in the message indi- cates a forwarding branch, then all non-iif interfaces with PIM neighbors are set to forwarding state in the new entry. Otherwise, the new entry is created with prune state on all non-iif inter- faces. o If the (S,G) State-Refresh message was received on an interface other than RPF(S) by a router with no existing (S,G) entry, then the message is ignored. o If the State-Refresh message was received on a (S,G) non-iif inter- face then the message is ignored. If the receiving interface corresponds to a LAN the message may still be processed according to the modified PIM Assert rules described in section 4. o If the State-Refresh was received on the (S,G) incoming interface from a PIM router other than the upstream neighbor (i.e, RPF neigh- bor or Assert winner), then the State-Refresh message is ignored. However, the message is still processed according to the modified PIM Assert rules described in section 4. o If the State-Refresh was received on the (S,G) incoming interface from the upstream neighbor (i.e, RPF neighbor or Assert winner), then all (S,G) pruned interface timers are refreshed. Further, if (S,G) is a negative cache entry, then the entry timer is also refreshed to its default value. o If the State-Refresh was received on the (S,G) incoming interface Farinacci, Kouvelas, Windisch [Page 3] Internet Draft PIM-DM State Refresh October 1999 from the upstream neighbor (i.e, RPF neighbor or Assert winner) and the Prune-Indicator flag in the message is set, indicating that it was forwarded down a pruned branch, but the local (S,G) entry is not a negative cache entry, then the Prune-Indicator flag in the message is cleared and a Join is sent upstream. To avoid duplicate Join generation from different downstream routers responding to a State-Refresh message, sending the Join is delayed by a random interval smaller than 3 seconds and a scheduled Join is canceled if one is received from another router on the LAN. o If the State-Refresh was received on the (S,G) incoming interface from the upstream neighbor (i.e, RPF neighbor or Assert winner) and the Prune-Indicator flag in the message is not set, indicating that it was forwarded down a forwarding branch, but the local (S,G) entry is a negative cache entry, then the Prune-Indicator flag in the message is set and a Prune is sent upstream. To avoid dupli- cate Prune generation from different downstream routers responding to a State-Refresh message, sending the Prune is delayed by a ran- dom interval smaller than 3 seconds and a scheduled Prune is can- celed if one is received from another router on the LAN. In a scenario where there are multiple downstream routers, some with forwarding and some with negative cache entries, the routers with the negative caches will generate a prune on each State- Refresh message and the routers with the forwarding entries will have to Join override. To reduce the amount of control traffic created by such behavior, it is mandatory for a negative cache router to respond with a Prune to a State-Refresh message with a clear Prune-Indicator if the Prune-Now flag is set in the State- Refresh message. This flag will be set by the State-Refresh origi- nator in one out of 3 messages transmitted. Downstream routers may also respond with a Prune to State-Refresh messages with the Prune-Now flag cleared. o If the State-Refresh was received on the (S,G) incoming interface from the upstream neighbor (i.e, RPF neighbor or Assert winner), then the Refresh message is retransmitted on all PIM interfaces other than the (S,G) incoming interface, provided that the TTL in the message is greater than 0 and larger than the configured thres- hold for the interface and that the interface does not have multi- cast boundary addresses configured for the group specified in the message. The IP header specifies the outgoing interface address as the source and the Refresh Packet is rewritten with the local router's preference, metric and mask for reaching S. If the (S,G) entry has prune state for the interface on which the refresh mes- sage is being sent, the Prune-Indicator flag in the message is set to indicate a pruned branch. The TTL in the forwarded message is one less than that of the received message. Farinacci, Kouvelas, Windisch [Page 4] Internet Draft PIM-DM State Refresh October 1999 4. State-Refresh processing on LANs On multi-access LANs, State-Refresh messages double as Asserts. Pos- sible forwarders and downstream routers use the routing metric infor- mation in the State-Refresh messages to decide who is the assert winner. In most ways the processing of such messages is identical to the assert processing rules described in [1]. The assert rules described in [1] rely on the periodic timeout of prune state in routers to recover from situations where the assert winner on a LAN goes away. When operating under State-Refresh this no longer happens. In particular on a leaf LAN with multiple forwarders there are no downstream routers to timeout and join towards the new forwarder if the assert winner dies. Possible remaining forwarders that keep receiving State-Refresh messages will refresh their outgo- ing interface prune timers and will not time out and start forward- ing. To recover from this scenario, the assert processing needs to be slightly modified when operating under State-Refresh. Assert losers need to remember the last time they have heard a State-Refresh from a router on the LAN that has a better routing metric to the source. If a period of three times the [Refresh-Interval] elapses with no such report, then the Assert-Override flag will be set in the next for- warded State-Refresh message. If there are directly connected members reported by IGMP, the interface to the LAN will transition into forwarding state. The value of the Refresh-Interval used for timing out the winner, is extracted from the forwarded message (see section 5). Downstream routers on a LAN that receive a State-Refresh message with the Assert-Override flag set, will discard the stored routing metric values for the assert winner and use the State-Refresh sender as their new RPF neighbor. 5. State-Refresh Message Packet Format This section described the details of the packet format for the PIM DM State-Refresh Message. As with all PIM control messages, the State-Refresh message uses protocol number 103. It is multicast hop- by-hop to the `ALL-PIM-ROUTERS' group `224.0.0.13'. Farinacci, Kouvelas, Windisch [Page 5] Internet Draft PIM-DM State Refresh October 1999 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type | Reserved | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Group Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Unicast-Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Unicast-Originator Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| Metric Preference | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Masklen | TTL |P|N|O|Reserved | Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PIM Version, Reserved, Checksum Described in [2]. Type State-Refresh message type value is 9. See [2] for types of other PIM control messages. Encoded-Group Address The group address to which the data packets were addressed, and which triggered the State-Refresh-Timer. Format described in [2]. Encoded-Unicast-Source Address The address of the data packet source. Format described in [2]. Encoded-Unicast-Originator Address The address of the first hop router that originated the State-Refresh message. Format described in [2]. Metric Preference, Metric, Masklen Preference value assigned to the unicast routing protocol that provided the route to Host address, the metric in units applicable to the unicast routing protocol and the mask length used (needed for assert logic as described in [1]). TTL This is set by the originating router to either a locally configured value or the TTL observed in the data packets for the group and is decremented each time the State-Refresh Farinacci, Kouvelas, Windisch [Page 6] Internet Draft PIM-DM State Refresh October 1999 message is forwarded. P The Prune-Indicator flag. This is set if the State-Refresh message was forwarded on a pruned interface and cleared oth- erwise. N The Prune-Now flag. This is set by the State-Refresh origi- nator on one out of three transmitted messages and is used by downstream routers on LANs to rate-control Prune transmission. O The Assert-Override flag. This is set by candidate forward- ers on a LAN if a State-Refresh message has not been heard by the assert winner over the period of three times the [Refresh-Interval]. Reserved Set to zero and ignored upon receipt. Interval Set by the originating router to the interval between con- secutive State-Refresh messages for this source [Refresh- Interval]. 6. Handling Router Failures PIM Hello messages will contain a Generation ID (GenID) in a Hello option [3]. When a PIM Hello is received from an existing neighbor and the GenID differs from the previous ID, the neighbor has res- tarted and may not contain (S,G) state. In order to recreate the missing state, for each (S,G), all routers upstream of the failed router (i.e. those receiving the Hello on a non-iif) can send a new (S,G) PIM State-Refresh message on the interface that the Hello mes- sage was received. In order to avoid a burst of incoming State- Refresh messages at the recovering router, transmission of messages for different (S,G) entries has to be randomly spaced over a period of time. The duration of this period can be configured locally and a default value of 3 seconds is recommended. The Prune-Indicator flag of the State-Refresh message should be set to indicate if the recov- ering router is on a forwarding or pruned branch of the (S,G) tree. 7. Compatibility with Legacy PIM Routers In order to enable incremental deployment of State-Refresh capable routers, additional mechanisms have to be used to prevent holes in Farinacci, Kouvelas, Windisch [Page 7] Internet Draft PIM-DM State Refresh October 1999 the distribution tree. These holes can be created because downstream routers without the State-Refresh capability will not send PIM grafts when (S,G) prune state times out. Upstream state-refresh capable routers will maintain (S,G) prune state. If a new receiver joins on a legacy branch, data will never reach this receiver. Legacy routers are detected through the use of a new capability indi- cator in PIM Hello messages that can be used to inform neighbors whether a router is State-Refresh capable. The format of this option is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OptionType = 21 | OptionLength = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ | Version = 1 | Interval | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Interval field is used to advertise the [Refresh-Interval] used by the router for originating SR messages for directly connected sources on this interface. Using this field, inconsistencies in ori- gination intervals between first-hop routers for the same source can be detected. The only protocol modification that is required to enable interopera- bility with detected legacy routers is in the procedures for packet reception: o When a State-Refresh message is received on the (S,G) incoming interface from the upstream neighbor (i.e, RPF neighbor or Assert winner), then all (S,G) outgoing interface prune timers are refreshed except those leading to directly connected legacy routers. Further if all outgoing interfaces leading to State- Refresh capable routers are pruned then the entry timer is refreshed to its default value. This will allow the prune state of the outgoing interface leading to the legacy router to timeout and change to forwarding state. As the entry timer will be updated by State-Refresh messages, the entry will persist even after the transition. If the entry was a negative cache entry a graft will be sent upstream as a result. The above modifications will enable prune state to persist in sub- trees of a source distribution tree that fulfill the following two conditions: Farinacci, Kouvelas, Windisch [Page 8] Internet Draft PIM-DM State Refresh October 1999 a) The subtree is entirely State-Refresh capable. b) The path from the source to the subtree in entirely State-Refresh capable. A subtree of the source distribution tree rooted at a legacy router as well as the path from the source to the subtree will not benefit from State-Refresh messages and will experience traditional dense mode flood and prune behavior. Farinacci, Kouvelas, Windisch [Page 9] Internet Draft PIM-DM State Refresh October 1999 8. References [1] Deering, et al., "Protocol Independent Multicast Version 2 Dense Mode Specification", draft-ietf-pim-v2-dm-01.txt, November 1998. [2] Estrin, et al., "Protocol Independent Multicast-Sparse Mode (PIM- SM): Protocol Specification", RFC 2362, June 1998. [3] Li, et al., "PIM Neighbor Hello GenId Option", draft-ietf-idmr-pim-hello-genid-00.txt, February 1999. 9. Acknowledgments The authors would like to acknowledge Liming Wei (cisco), Tony Speak- man (cisco) and John Zwiebel (cisco) for their comments and contribu- tions to this specification. 10. Author Information Dino Farinacci Procket Networks dino@procket.com Isidor Kouvelas cisco Systems, Inc. kouvelas@cisco.com Kurt Windisch Advanced Network Technolgy Center University of Oregon kurtw@antc.uoregon.edu Farinacci, Kouvelas, Windisch [Page 10] From owner-pim@catarina.usc.edu Fri Oct 22 18:40:49 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11260 for ; Fri, 22 Oct 1999 18:40:48 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id PAA12549 for pim-list; Fri, 22 Oct 1999 15:34:34 -0700 Received: from ntserver1.redstonecom.com (ntserver1.redstonecom.com [199.105.223.130]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id PAA12545 for ; Fri, 22 Oct 1999 15:34:28 -0700 Received: by NTSERVER1 with Internet Mail Service (5.0.1460.8) id <45HQPZJQ>; Fri, 22 Oct 1999 18:34:05 -0400 Message-ID: <90ABC30C744ED311B16E00500464BEFC1BDF2D@NTSERVER1> From: "Wadhwa, Sanjay" To: pim@catarina.usc.edu Subject: pim-dm state refresh.. Date: Fri, 22 Oct 1999 18:34:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-pim@catarina.usc.edu Precedence: bulk This is on pim-refresh draft... In section 7. it is stated that "holes can be created because downstream routers without the state refresh capability will not sent PIM grafts when (S,G) prune state times out".... However pim-dm draft mandates sending grafts upstream when (S,G) prune state times out (even when the entry and prune timers expire at the same time)... From pim-dm draft section 5.6 : " If the prune timers on different outgoing interfaces are different, the pruned interface with the shortest remaining timer may expire first and turn the negative cache entry into forwarding state. When this happens, a graft should be triggered upstream" It also says... " If the prune timer expires at the exactly same time as the (S,G) entry timer, a graft should still be triggered upstream." Looks like the problem stated in the state-refresh draft should not happen if this is followed... -Sanjay From owner-pim@catarina.usc.edu Sun Oct 24 23:51:00 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA18410 for ; Sun, 24 Oct 1999 23:50:59 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id UAA20421 for pim-list; Sun, 24 Oct 1999 20:40:06 -0700 Received: from baynet.baynetworks.com (ns1.BayNetworks.COM [134.177.3.20]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id UAA20417 for ; Sun, 24 Oct 1999 20:40:01 -0700 Received: from mailhost.BayNetworks.COM (h8754.s84f5.BayNetworks.COM [132.245.135.84]) by baynet.baynetworks.com (8.9.1/8.9.1) with ESMTP id UAA04821; Sun, 24 Oct 1999 20:37:33 -0700 (PDT) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id XAA15700; Sun, 24 Oct 1999 23:34:13 -0400 (EDT) Received: from diamante.engeast (diamante [192.32.148.62]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id XAA01292; Sun, 24 Oct 1999 23:38:18 -0400 for Received: by diamante.engeast (SMI-8.6/SMI-SVR4) id XAA08037; Sun, 24 Oct 1999 23:38:18 -0400 Date: Sun, 24 Oct 1999 23:38:18 -0400 From: bng@BayNetworks.COM (Billy Ng) Message-Id: <199910250338.XAA08037@diamante.engeast> To: kouvelas@cisco.com Subject: Re: Alternative bidir PIM proposal Cc: pim@catarina.usc.edu X-Sun-Charset: US-ASCII Sender: owner-pim@catarina.usc.edu Precedence: bulk Some comments to your draft (since I will not be able to make the next IETF): .... When a router receives a Join message addressed to it for a bidir group G with rendezvous point RP, it must determine if it is the DF on the link for this group. To do this it consults (*,G) state or the RP election information if no (*,G) state exists. If the router is not the DF, it must ignore the Join message. If it is the DF, then the following steps are taken: In the unidirectional case, a join is sent toward the RPF neighbor. With this new bidir case, what if the targetted RPF neighbor is not the DF? or are you saying this should never happen so the upstream always accepts the downstream join if it is the DF on the lan? .... 3.2.1 Source-only Branches Source-only branches of the distribution tree for a group are branches which do not lead to any receivers, but which are used to forward packets traveling upstream from sources towards the RP. Routers along source-only branches do not have an olist for the group and hence do not need to maintain (*,G) state. Upstream forwarding can be performed using (*,*,RP) state. An implementation may decide doesn't (*,*,RP) pulls down all other sources back to the source only tree? can you explain in more detail on how this state is created? A scenario with source sending should be given. I am still not clear when the (*,*,RP) state should be created. .... 4.2.6 Winner Dies Whenever the DF dies, a new DF has to be elected. The speed at which this can be achieved depends on whether there are any downstream routers on the link. If there are downstream routers, then typically their RPF neighbor reported by the unicast routing protocol will be the DF. They will therefore notice a change in RPF neighbor away from the DF. They will then restart the election by transmitting Offer messages. If the RP is now reachable through the link via another upstream router, then they will use an infinite metric in the Offer. If no downstream routers are present then the only way for other upstream routers to detect a DF failure is by the timeout of the PIM neighbor information, which will take significantly longer. since there are periodic winner message from the DF, other neighbor could time out on this message which could be made shorter than the PIM hello timeout. .... 4.3.2 Message Summary The election uses the following control messages: Offer (OfferingID, Metric) Sent by routers that believe they have a better metric to the RP than the metric that has been on offer so far. Winner (DF-ID, DF-Metric) Sent by a router when assuming the role of the DF or when re-asserting in response to worse offers. Backoff (DF-ID, DF-Metric, OfferingID, OfferMetric, BackoffInterval) Used by the DF to acknowledge better offers. It instructs other routers with equal or worse offers to wait till the DF passes responsibility to the sender of the offer. Pass (Old-DF-ID, Old-DF-Metric, New-DF-ID, New-DF-Metric) Used by the old DF to pass forwarding responsibility to a router that has previously made an offer. The Old-DF-Metric is the current metric of the DF at the time the pass is sent. it would be nice to draw a flow diagram of the above transitions. Thanks, --Billy From owner-pim@catarina.usc.edu Mon Oct 25 01:45:03 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA23609 for ; Mon, 25 Oct 1999 01:45:03 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id WAA21047 for pim-list; Sun, 24 Oct 1999 22:41:31 -0700 Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id WAA21043 for ; Sun, 24 Oct 1999 22:41:27 -0700 Received: from kouvelas-u10.cisco.com (kouvelas-u10.cisco.com [171.69.65.54]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id WAA22829; Sun, 24 Oct 1999 22:41:18 -0700 (PDT) Received: from localhost (kouvelas@localhost) by kouvelas-u10.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.WS.1.2) with ESMTP id WAA10376; Sun, 24 Oct 1999 22:40:48 -0700 (PDT) Message-Id: <199910250540.WAA10376@kouvelas-u10.cisco.com> X-Authentication-Warning: kouvelas-u10.cisco.com: kouvelas owned process doing -bs To: bng@BayNetworks.COM (Billy Ng) cc: kouvelas@cisco.com, pim@catarina.usc.edu Subject: Re: Alternative bidir PIM proposal In-reply-to: Your message of "Sun, 24 Oct 1999 23:38:18 EDT." <199910250338.XAA08037@diamante.engeast> Date: Sun, 24 Oct 1999 22:40:48 -0700 From: Isidor Kouvelas Sender: owner-pim@catarina.usc.edu Precedence: bulk Billy Ng writes: >Some comments to your draft (since I will not be able to make the next >IETF): Thanks for the comments. Reply is inline. >.... > > When a router receives a Join message addressed to it for a bidir > group G with rendezvous point RP, it must determine if it is the DF > on the link for this group. To do this it consults (*,G) state or > the RP election information if no (*,G) state exists. If the router > is not the DF, it must ignore the Join message. If it is the DF, > then the following steps are taken: > >In the unidirectional case, a join is sent toward the RPF neighbor. With >this new bidir case, what if the targetted RPF neighbor is not the DF? >or are you saying this should never happen so the upstream always accepts >the downstream join if it is the DF on the lan? Right this shouldn't happen. Even if it did, a non DF router will ignore the Join and optionally the DF can intercept it and send a Winner message. >.... > >3.2.1 Source-only Branches > > Source-only branches of the distribution tree for a group are > branches which do not lead to any receivers, but which are used to > forward packets traveling upstream from sources towards the RP. > Routers along source-only branches do not have an olist for the group > and hence do not need to maintain (*,G) state. Upstream forwarding > can be performed using (*,*,RP) state. An implementation may decide > >doesn't (*,*,RP) pulls down all other sources back to the source only tree? >can you explain in more detail on how this state is created? > >A scenario with source sending should be given. I am still not clear >when the (*,*,RP) state should be created. In case no "downstream" routers have joined for a particular source, there will be no olist and hence (*,G) state at a DF. If data packets for that source are received that need to be forwarded upstream, then the DF can create (*,G) state to do the upstream forwarding. RP | Rtr-A |DF -------------- | | Src1 Src2 In the example above, if src1 sends to group G1 and src2 sends to group G2, then router A can create (*,G1) and (*,G2) state to forward packets upstream to the RP. As both (*,G1) and (*,G2) will have a NULL olist, creating them is not necessary and (*,*,RP) state can be created instead to forward both groups. The (*,*,RP) state will also have a NULL olist and hence no Join will be generated upstream and it will not pull any traffic from the RP. >.... > >4.2.6 Winner Dies > > Whenever the DF dies, a new DF has to be elected. The speed at which > this can be achieved depends on whether there are any downstream > routers on the link. > > If there are downstream routers, then typically their RPF neighbor > reported by the unicast routing protocol will be the DF. They will > therefore notice a change in RPF neighbor away from the DF. They > will then restart the election by transmitting Offer messages. If > the RP is now reachable through the link via another upstream router, > then they will use an infinite metric in the Offer. > > If no downstream routers are present then the only way for other > upstream routers to detect a DF failure is by the timeout of the PIM > neighbor information, which will take significantly longer. > >since there are periodic winner message from the DF, other neighbor >could time out on this message which could be made shorter than the >PIM hello timeout. There are no periodic winner messages. We have tried to avoid constant control traffic. >.... > >4.3.2 Message Summary > > The election uses the following control messages: > > Offer (OfferingID, Metric) > Sent by routers that believe they have a better metric to > the RP than the metric that has been on offer so far. > > Winner (DF-ID, DF-Metric) > Sent by a router when assuming the role of the DF or when > re-asserting in response to worse offers. > > Backoff (DF-ID, DF-Metric, OfferingID, OfferMetric, > BackoffInterval) > Used by the DF to acknowledge better offers. It instructs > other routers with equal or worse offers to wait till the DF > passes responsibility to the sender of the offer. > > Pass (Old-DF-ID, Old-DF-Metric, New-DF-ID, New-DF-Metric) > Used by the old DF to pass forwarding responsibility to a > router that has previously made an offer. The Old-DF-Metric > is the current metric of the DF at the time the pass is > sent. > >it would be nice to draw a flow diagram of the above transitions. Will work on one. thanks Isidor From owner-pim@catarina.usc.edu Mon Oct 25 18:47:50 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA06921 for ; Mon, 25 Oct 1999 18:47:48 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id PAA25173 for pim-list; Mon, 25 Oct 1999 15:36:39 -0700 Received: from southpass.baynetworks.com (ns2.BayNetworks.COM [134.177.3.16]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id PAA25169 for ; Mon, 25 Oct 1999 15:36:32 -0700 Received: from mailhost.BayNetworks.COM (h8754.s84f5.BayNetworks.COM [132.245.135.84]) by southpass.baynetworks.com (8.9.1/8.9.1) with ESMTP id PAA07097; Mon, 25 Oct 1999 15:30:27 -0700 (PDT) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id SAA04210; Mon, 25 Oct 1999 18:31:47 -0400 (EDT) Received: from diamante.engeast (diamante [192.32.148.62]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id SAA10421; Mon, 25 Oct 1999 18:35:53 -0400 for Received: by diamante.engeast (SMI-8.6/SMI-SVR4) id SAA10521; Mon, 25 Oct 1999 18:35:52 -0400 Date: Mon, 25 Oct 1999 18:35:52 -0400 From: bng@BayNetworks.COM (Billy Ng) Message-Id: <199910252235.SAA10521@diamante.engeast> To: kouvelas@cisco.com Subject: Re: Alternative bidir PIM proposal Cc: pim@catarina.usc.edu X-Sun-Charset: US-ASCII Sender: owner-pim@catarina.usc.edu Precedence: bulk > From kouvelas@cisco.com Mon Oct 25 01:45:00 1999 > > > > >4.2.6 Winner Dies > > > > Whenever the DF dies, a new DF has to be elected. The speed at which > > this can be achieved depends on whether there are any downstream > > routers on the link. > > > > If there are downstream routers, then typically their RPF neighbor > > reported by the unicast routing protocol will be the DF. They will > > therefore notice a change in RPF neighbor away from the DF. They > > will then restart the election by transmitting Offer messages. If > > the RP is now reachable through the link via another upstream router, > > then they will use an infinite metric in the Offer. > > > > If no downstream routers are present then the only way for other > > upstream routers to detect a DF failure is by the timeout of the PIM > > neighbor information, which will take significantly longer. > > > >since there are periodic winner message from the DF, other neighbor > >could time out on this message which could be made shorter than the > >PIM hello timeout. > > There are no periodic winner messages. We have tried to avoid constant control > traffic. > The O-timer was giving me the impression that the winner message is periodic, but now I see you send it 3 times for reliability. Thanks, --Billy From owner-pim@catarina.usc.edu Tue Oct 26 13:06:32 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14354 for ; Tue, 26 Oct 1999 13:06:31 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id JAA29230 for pim-list; Tue, 26 Oct 1999 09:56:34 -0700 Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id JAA29226 for ; Tue, 26 Oct 1999 09:56:12 -0700 Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id BAA22717; Wed, 27 Oct 1999 01:46:17 +0900 (JST) Date: Wed, 27 Oct 1999 01:52:23 +0900 Message-ID: <14357.56391.879936.85469U@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: pim@catarina.usc.edu Cc: ipng@sunroof.eng.sun.com Subject: question about checksum calculation of PIM for IPv6 User-Agent: Wanderlust/2.2.5 (Come Undone) Emacs/20.4 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 26 Sender: owner-pim@catarina.usc.edu Precedence: bulk In RFC 2362 and draft-ietf-pim-v2-sm-00, there is description about the checksum field of PIM packets; Checksum The checksum is the 16-bit one's complement of the one's complement sum of the entire PIM message, (excluding the data portion in the Register message). For computing the checksum, the checksum field is zeroed. i.e. the checksum is calculated without a pseudo-IP header. Should this be applied to IPv6 as well as to IPv4? As far as I know, all upper layer checksums for IPv6 (including ICMPv6 and OSPFv6) are calculated with an IPv6 pseudo-header, mainly because IPv6 does not have an IP layer checksum. IMO, the checksum for PIMv6 should obey the same rule for the same reason. I've read draft-ietf-pim-ipv6-01 as well, but have not seen any specification about the checksum calculation. I'd like to know PIM specialists' opinion. Thanks in advance, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-pim@catarina.usc.edu Tue Oct 26 14:46:12 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19205 for ; Tue, 26 Oct 1999 14:46:10 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id LAA29993 for pim-list; Tue, 26 Oct 1999 11:37:33 -0700 Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id LAA29989 for ; Tue, 26 Oct 1999 11:37:23 -0700 Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <42Y7AN7D>; Tue, 26 Oct 1999 11:36:49 -0700 Message-ID: <19398D273324D3118A2B0008C7E9A5690592C371@SIT.platinum.corp.microsoft.com> From: "Mohit Talwar (Exchange)" To: pim@catarina.usc.edu Subject: The Assert Mechanism: Part 2 :) Date: Tue, 26 Oct 1999 11:36:35 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-pim@catarina.usc.edu Precedence: bulk hi all, i think there is a rule missing from section 3.5.1 (Sending Asserts) which will prevent the assert mechanism from stopping duplicates downstream. consider the following topology... +---+ | A | +---+ . . . +-+-+ +-+-+ | B | | C | +-+-+ +-+-+ | | ----------+---------------------------------------+---------- | | S +---+ | D | +-+-+ | R A is the RP B is the DR on the LAN C is the RPF towards A for D R is a receiver S is a source now consider the following sequence of events... R joins a group G D creates (*,G) state and sends the join on the LAN with C as the target C create (*,G) state and forwards the join upstream towards A --- S (source) starts sending data B creates (S,G) state and sends the data packet in a register to A D receives the data packet on the right incoming interface and forwards it to R. C receives the data packet on an interface in its OIL (outgoing interface list) and sends an assert. however the assert is ignored by both B and D since none of them have the interface in their matching OILs. hence C would not create an (S,G,RPT) tree entry and delete the interface from its OIL. --- the register is de-encapsulated by A and sent downstream towards C. C will eventually forward this data packet on the LAN which again succeeds the incoming interface check at D and is forwarded to R. R keeps getting dups of each data packet sent by S to G! i think the solution is to modify section 3.5.1 thus... " The following Assert rules are provided when a multicast packet is received on an outgoing multi-access interface "I" of an existing active (S,G), (*,G) or (*,*,RP) entry: 0. if the source of the data packet is a local, directly connected the router and the matching entry is (*,G), or (*,*,RP), the router creates a (S,G)RPT-bit entry. Otherwise, no new entry is created in response to the Assert. the router should then delete the interface from the entry and restart the entry-timer. " basically the router should behave as if it lost the assert election when the source is directly connected. thanx, mohit. From owner-pim@catarina.usc.edu Tue Oct 26 14:56:43 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19755 for ; Tue, 26 Oct 1999 14:56:41 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id LAA00298 for pim-list; Tue, 26 Oct 1999 11:48:01 -0700 Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id LAA00290 for ; Tue, 26 Oct 1999 11:47:52 -0700 Received: from ceng.usc.edu (helmy@ceng.usc.edu [128.125.253.190]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id LAA11480; Tue, 26 Oct 1999 11:47:50 -0700 (PDT) Received: from localhost (helmy@localhost) by ceng.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id LAA27570; Tue, 26 Oct 1999 11:47:49 -0700 (PDT) Date: Tue, 26 Oct 1999 11:47:49 -0700 (PDT) From: helmy To: "Mohit Talwar (Exchange)" cc: pim@catarina.usc.edu Subject: Re: The Assert Mechanism: Part 2 :) In-Reply-To: <19398D273324D3118A2B0008C7E9A5690592C371@SIT.platinum.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pim@catarina.usc.edu Precedence: bulk If I remember correctly, I have studied Register looping in my research and added a rule that a packet is never forwarded back onto the LAN from which is originated, i.e., C should never forward the packets onto the LAN to which S is attached. On Tue, 26 Oct 1999, Mohit Talwar (Exchange) wrote: > hi all, > > i think there is a rule missing from section 3.5.1 (Sending Asserts) > which will prevent the assert mechanism from stopping duplicates > downstream. > > consider the following topology... > > > +---+ > | A | > +---+ > . > . > . > +-+-+ +-+-+ > | B | | C | > +-+-+ +-+-+ > | | > ----------+---------------------------------------+---------- > | | > S +---+ > | D | > +-+-+ > | > R > > A is the RP > B is the DR on the LAN > C is the RPF towards A for D > R is a receiver > S is a source > > now consider the following sequence of events... > R joins a group G > D creates (*,G) state and sends the join on the LAN with C as the target > C create (*,G) state and forwards the join upstream towards A > --- > S (source) starts sending data > B creates (S,G) state and sends the data packet in a register to A > D receives the data packet on the right incoming interface and forwards it > to R. > C receives the data packet on an interface in its OIL (outgoing > interface list) and sends an assert. however the assert is ignored > by both B and D since none of them have the interface in their matching > OILs. hence C would not create an (S,G,RPT) tree entry and delete the > interface from its OIL. > --- > the register is de-encapsulated by A and sent downstream towards C. > C will eventually forward this data packet on the LAN which again succeeds > the > incoming interface check at D and is forwarded to R. > > R keeps getting dups of each data packet sent by S to G! > > i think the solution is to modify section 3.5.1 thus... > > " > The following Assert rules are provided when a multicast packet is > received on an outgoing multi-access interface "I" of an existing > active (S,G), (*,G) or (*,*,RP) entry: > > 0. if the source of the data packet is a local, directly connected > the router and the matching entry is (*,G), or (*,*,RP), the > router creates a (S,G)RPT-bit entry. Otherwise, no new entry is > created in response to the Assert. the router should then delete > the interface from the entry and restart the entry-timer. > " > > basically the router should behave as if it lost the > assert election when the source is directly connected. > > thanx, > mohit. > From owner-pim@catarina.usc.edu Tue Oct 26 15:13:23 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20769 for ; Tue, 26 Oct 1999 15:13:22 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id MAA00461 for pim-list; Tue, 26 Oct 1999 12:05:35 -0700 Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id MAA00457 for ; Tue, 26 Oct 1999 12:05:27 -0700 Received: from [171.71.38.63] (deering-office-mac.cisco.com [171.71.38.63]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id MAA18356; Tue, 26 Oct 1999 12:03:54 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <14357.56391.879936.85469U@condor.isl.rdc.toshiba.co.jp> References: <14357.56391.879936.85469U@condor.isl.rdc.toshiba.co.jp> Date: Tue, 26 Oct 1999 12:03:56 -0700 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Steve Deering Subject: Re: question about checksum calculation of PIM for IPv6 Cc: pim@catarina.usc.edu, ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-pim@catarina.usc.edu Precedence: bulk At 1:52 AM +0900 10/27/99, JINMEI Tatuya / >i.e. the checksum is calculated without a pseudo-IP header. Should >this be applied to IPv6 as well as to IPv4? As far as I know, all >upper layer checksums for IPv6 (including ICMPv6 and OSPFv6) are >calculated with an IPv6 pseudo-header, mainly because IPv6 does not >have an IP layer checksum. IMO, the checksum for PIMv6 should obey the >same rule for the same reason. Including a pseudo-header in an upper-layer checksum is necessary only for those higher-layer protocols that depend on the contents of some IP-layer fields for their own correct operation. For example, TCP uses the addresses from the IP header as part of the identity of TCP connection state, and uses the IP length field to determine the size of the TCP payload. An upper-layer protocol that had no dependencies on any IP header fields would not need to use a pseudo-header. (I don't know, off hand, whether or not PIMv6 is such a protocol.) Steve From owner-pim@catarina.usc.edu Tue Oct 26 15:58:56 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23388 for ; Tue, 26 Oct 1999 15:58:55 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id MAA00800 for pim-list; Tue, 26 Oct 1999 12:51:20 -0700 Received: from dthaler.microsoft.com ([131.107.152.20]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id MAA00796 for ; Tue, 26 Oct 1999 12:51:11 -0700 Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id OAA10993; Tue, 26 Oct 1999 14:30:06 -0700 (PDT) (envelope-from dthaler) From: Dave Thaler Message-Id: <199910262130.OAA10993@dthaler.microsoft.com> Subject: Re: source address in assert packet. In-Reply-To: from Liming Wei at "Oct 11, 1999 12:27:56 pm" To: lwei@siara.com Date: Tue, 26 Oct 1999 14:30:03 -0700 (PDT) Cc: rshekhar@unisphere.cc, pim@catarina.usc.edu X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Sorry to bring this back up, but I think the current "protocol actions" cause black holes... Liming writes: > > From: "Shekhar, Ravi" > > Text in the draft requires source addresss in the assert packet to be that > > of source address in the data packet which triggered the assert. > > But to identify the RP in case of <*, *, RP> assert, isnt it required to > > have the source address in the assert packet be address of RP? > > > > Although not necessarily required for identification of <*, G> asserts > > (due > > to R bit), is it also desirable to have RP address as the source address > > in > > case of <*, G> asserts? [ If I remember right, there was some discussion > > regarding this on the mailing list already. Archive is currently > > unavailable. > > Could someone recap? ] > > I don't have the archive either. It should be the source address, > because that is the "raw" information about the packets causing such > asserts. Also in case of error, the local box may have a different > idea of who the RP should be. Instead of changing the protocol > actions, we would be better off keeping the source address in the > asserts. For (*,G) state, I believe the metrics included must be the metrics towards the RP, not the source which triggered the assert, or black holes result since all routers can think they're the loser for (*,G) because of different source addresses in different asserts. Example: S1 RP S2 A has metric 2 for S1 / \ B has metric 4 for S1 A B | | A has metric 5 for S2 ----------------- B has metric 3 for S2 (downstream rtrs and hosts) Situation: Both A and B start with the LAN in the oiflist Due to queuing delays/drops/whatever, A forwards the packet from S2 onto the LAN first, whereas B forwards the packet from S1 onto the LAN first. B sees the packet from S2 on the LAN from A and sends an assert for S2 with metric 3. Meanwhile, A sees the packet from S1 on the LAN from B, and sends an assert for S1 with metric 2. Each receives the other's assert and loses to it. Both remove the oif, and a black hole results. In other situations, using the source metric in a (*,G) assert can cause the assert winner to change every time the assert occurs (since a different source address could be used each time). The above example is solved by both A and B using the metric towards the RP. -Dave From owner-pim@catarina.usc.edu Tue Oct 26 16:24:33 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24778 for ; Tue, 26 Oct 1999 16:24:32 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id NAA01039 for pim-list; Tue, 26 Oct 1999 13:15:36 -0700 Received: from ntserver1.redstonecom.com (ntserver1.redstonecom.com [199.105.223.130]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id NAA01035 for ; Tue, 26 Oct 1999 13:15:26 -0700 Received: by NTSERVER1 with Internet Mail Service (5.0.1460.8) id <45HQP0TD>; Tue, 26 Oct 1999 16:14:56 -0400 Message-ID: <90ABC30C744ED311B16E00500464BEFC1D4C92@NTSERVER1> From: "Shekhar, Ravi" To: Dave Thaler , lwei@siara.com Cc: "Shekhar, Ravi" , pim@catarina.usc.edu Subject: RE: source address in assert packet. Date: Tue, 26 Oct 1999 16:14:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-pim@catarina.usc.edu Precedence: bulk Dave, although this is not mentioned in the draft explicitly, but there had been an earlier discussion (by Billy NG/Hal Sandick) on the mailing list which said that rpf check should be done towards RP (eddy's pim notes page has an excerpt from there). My interpretation was that both RPF check and metrics used are for RP (if RPT bit is set), only the source address is the address of the source whose data caused assert. In a way it is misleading because metric is not that of source, but as Liming points out, it has useful info for debugging as it tells us about the source which forwarded the data. RP address is not really required as its implied by G (unless G is 224.0.0.0 but then <*, *, RP> asserts are not allowed). Am I missing something? Regards. - Ravi Shekhar. > Sorry to bring this back up, but I think the current > "protocol actions" > cause black holes... > > Liming writes: > > > From: "Shekhar, Ravi" > > > Text in the draft requires source addresss in the > assert packet to be that > > > of source address in the data packet which triggered the assert. > > > But to identify the RP in case of <*, *, RP> assert, > isnt it required to > > > have the source address in the assert packet be address of RP? > > > > > > Although not necessarily required for identification of > <*, G> asserts > > > (due > > > to R bit), is it also desirable to have RP address as > the source address > > > in > > > case of <*, G> asserts? [ If I remember right, there > was some discussion > > > regarding this on the mailing list already. Archive is currently > > > unavailable. > > > Could someone recap? ] > > > > I don't have the archive either. It should be the source address, > > because that is the "raw" information about the packets causing such > > asserts. Also in case of error, the local box may have a different > > idea of who the RP should be. Instead of changing the protocol > > actions, we would be better off keeping the source address in the > > asserts. > > For (*,G) state, I believe the metrics included must be the metrics > towards the RP, not the source which triggered the assert, or black > holes result since all routers can think they're the loser for (*,G) > because of different source addresses in different asserts. > > Example: > S1 RP S2 A has metric 2 for S1 > / \ B has metric 4 for S1 > A B > | | A has metric 5 for S2 > ----------------- B has metric 3 for S2 > (downstream rtrs and hosts) > > Situation: > Both A and B start with the LAN in the oiflist > Due to queuing delays/drops/whatever, > A forwards the packet from S2 onto the LAN first, > whereas B forwards the packet from S1 onto the LAN first. > B sees the packet from S2 on the LAN from A and sends > an assert for S2 with metric 3. > Meanwhile, A sees the packet from S1 on the LAN from B, > and sends an assert for S1 with metric 2. > Each receives the other's assert and loses to it. > Both remove the oif, and a black hole results. > > In other situations, using the source metric in a (*,G) > assert can cause the assert winner to change every time > the assert occurs (since a different source address could > be used each time). > > The above example is solved by both A and B using the metric > towards the RP. > > -Dave > From owner-pim@catarina.usc.edu Tue Oct 26 16:39:48 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25646 for ; Tue, 26 Oct 1999 16:39:47 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id NAA01258 for pim-list; Tue, 26 Oct 1999 13:35:02 -0700 Received: from ntserver1.redstonecom.com (ntserver1.redstonecom.com [199.105.223.130]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id NAA01254 for ; Tue, 26 Oct 1999 13:34:52 -0700 Received: by NTSERVER1 with Internet Mail Service (5.0.1460.8) id <45HQP0VS>; Tue, 26 Oct 1999 16:34:24 -0400 Message-ID: <90ABC30C744ED311B16E00500464BEFC1D4CBB@NTSERVER1> From: "Shekhar, Ravi" To: helmy , "Mohit Talwar (Exchange)" Cc: pim@catarina.usc.edu Subject: RE: The Assert Mechanism: Part 2 :) Date: Tue, 26 Oct 1999 16:34:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pim@catarina.usc.edu Precedence: bulk I raised this question of data looping earlier (http://netweb.usc.edu/pim/mail-archive/pim/archive.98.12). And I recvd two different answers indicating two different ways to handle it if I understood it right. One was what Helmy pointed out and this is covered in 3.4: 1 Forward the packet to the oif list for that entry, excluding the subnet containing S, and restart the Entry- timer if the matching entry is (S,G). Optionally, the (S,G) Entry-timer may be restarted by periodic checking of the matching packet count. C gets data from RP in this case. The other answer was from Dino, and as I understood it, it suggested that since all the routers(not just DR) attached to the subnet are already getting the data directly, they might as well create SPT entry and send a prune for towards RP. C gets data directly in this case. I dont think this is documented in the draft. Is there preferred way of doing it? - Ravi Shekhar. > -----Original Message----- > From: helmy [mailto:helmy@ceng.usc.edu] > Sent: Tuesday, October 26, 1999 2:48 PM > To: Mohit Talwar (Exchange) > Cc: pim@catarina.usc.edu > Subject: Re: The Assert Mechanism: Part 2 :) > > > If I remember correctly, I have studied Register looping in > my research > and added a rule that a packet is never forwarded back onto > the LAN from > which is originated, i.e., C should never forward the packets > onto the LAN > to which S is attached. > > On Tue, 26 Oct 1999, Mohit Talwar (Exchange) wrote: > > > hi all, > > > > i think there is a rule missing from section 3.5.1 (Sending > Asserts) > > which will prevent the assert mechanism from stopping duplicates > > downstream. > > > > consider the following topology... > > > > > > +---+ > > | A | > > +---+ > > . > > . > > . > > +-+-+ +-+-+ > > | B | | C | > > +-+-+ +-+-+ > > | | > > ----------+---------------------------------------+---------- > > | | > > S +---+ > > | D | > > +-+-+ > > | > > R > > > > A is the RP > > B is the DR on the LAN > > C is the RPF towards A for D > > R is a receiver > > S is a source > > > > now consider the following sequence of events... > > R joins a group G > > D creates (*,G) state and sends the join on the LAN with C > as the target > > C create (*,G) state and forwards the join upstream towards A > > --- > > S (source) starts sending data > > B creates (S,G) state and sends the data packet in a register to A > > D receives the data packet on the right incoming interface > and forwards it > > to R. > > C receives the data packet on an interface in its OIL (outgoing > > interface list) and sends an assert. however the assert is ignored > > by both B and D since none of them have the interface in > their matching > > OILs. hence C would not create an (S,G,RPT) tree entry and > delete the > > interface from its OIL. > > --- > > the register is de-encapsulated by A and sent downstream > towards C. > > C will eventually forward this data packet on the LAN which > again succeeds > > the > > incoming interface check at D and is forwarded to R. > > > > R keeps getting dups of each data packet sent by S to G! > > > > i think the solution is to modify section 3.5.1 thus... > > > > " > > The following Assert rules are provided when a multicast > packet is > > received on an outgoing multi-access interface "I" of an existing > > active (S,G), (*,G) or (*,*,RP) entry: > > > > 0. if the source of the data packet is a local, directly > connected > > the router and the matching entry is (*,G), or (*,*,RP), the > > router creates a (S,G)RPT-bit entry. Otherwise, no > new entry is > > created in response to the Assert. the router should > then delete > > the interface from the entry and restart the entry-timer. > > " > > > > basically the router should behave as if it lost the > > assert election when the source is directly connected. > > > > thanx, > > mohit. > > > From owner-pim@catarina.usc.edu Tue Oct 26 16:45:26 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25981 for ; Tue, 26 Oct 1999 16:45:26 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id NAA01291 for pim-list; Tue, 26 Oct 1999 13:36:44 -0700 Received: from siara.com (gate.siara.com [209.31.24.134]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id NAA01287 for ; Tue, 26 Oct 1999 13:36:37 -0700 Received: from malt.mtv.siara.com (malt.mtv.siara.com [192.168.40.9]) by siara.com (8.9.3-LCCHA/8.9.3/lccha Siara hub 1.4) with ESMTP id NAA12255; Tue, 26 Oct 1999 13:35:56 -0700 (PDT) Received: (from lwei@localhost) by malt.mtv.siara.com (8.9.3-LCCHA/8.9.3/lccha Siara client 1.5) id NAA10806; Tue, 26 Oct 1999 13:35:31 -0700 (PDT) Date: Tue, 26 Oct 1999 13:35:31 -0700 (PDT) Message-Id: <199910262035.NAA10806@malt.mtv.siara.com> From: Liming Wei To: rshekhar@unisphere.cc CC: dthaler@dthaler.microsoft.com, pim@catarina.usc.edu In-reply-to: <90ABC30C744ED311B16E00500464BEFC1D4C92@NTSERVER1> (rshekhar@unisphere.cc) Subject: Re: source address in assert packet. Reply-to: lwei@siara.com Sender: owner-pim@catarina.usc.edu Precedence: bulk > From: "Shekhar, Ravi" > > Dave, although this is not mentioned in the draft explicitly, > but there had been an earlier discussion (by Billy NG/Hal Sandick) > on the mailing list which said that rpf check should be done > towards RP (eddy's pim notes page has an excerpt from there). > > My interpretation was that both RPF check and metrics used are > for RP (if RPT bit is set), only the source address is the > address of the source whose data caused assert. Yes, I thought this is what we were talking about :-). Dave, we are assuming that the metric does not always have to be that for the source in the assert. The RPT bit in the assert tells that. I'll check the draft again to make sure this is clear. -Liming > In a way it is misleading because metric is not that of source, > but as Liming points out, it has useful info for debugging as > it tells us about the source which forwarded the data. RP address > is not really required as its implied by G (unless G is 224.0.0.0 > but then <*, *, RP> asserts are not allowed). > > Am I missing something? > > Regards. > - Ravi Shekhar. > > > > Sorry to bring this back up, but I think the current > > "protocol actions" > > cause black holes... > > > > Liming writes: > > > > From: "Shekhar, Ravi" > > > > Text in the draft requires source addresss in the > > assert packet to be that > > > > of source address in the data packet which triggered the assert. > > > > But to identify the RP in case of <*, *, RP> assert, > > isnt it required to > > > > have the source address in the assert packet be address of RP? > > > > > > > > Although not necessarily required for identification of > > <*, G> asserts > > > > (due > > > > to R bit), is it also desirable to have RP address as > > the source address > > > > in > > > > case of <*, G> asserts? [ If I remember right, there > > was some discussion > > > > regarding this on the mailing list already. Archive is currently > > > > unavailable. > > > > Could someone recap? ] > > > > > > I don't have the archive either. It should be the source address, > > > because that is the "raw" information about the packets causing such > > > asserts. Also in case of error, the local box may have a different > > > idea of who the RP should be. Instead of changing the protocol > > > actions, we would be better off keeping the source address in the > > > asserts. > > > > For (*,G) state, I believe the metrics included must be the metrics > > towards the RP, not the source which triggered the assert, or black > > holes result since all routers can think they're the loser for (*,G) > > because of different source addresses in different asserts. > > > > Example: > > S1 RP S2 A has metric 2 for S1 > > / \ B has metric 4 for S1 > > A B > > | | A has metric 5 for S2 > > ----------------- B has metric 3 for S2 > > (downstream rtrs and hosts) > > > > Situation: > > Both A and B start with the LAN in the oiflist > > Due to queuing delays/drops/whatever, > > A forwards the packet from S2 onto the LAN first, > > whereas B forwards the packet from S1 onto the LAN first. > > B sees the packet from S2 on the LAN from A and sends > > an assert for S2 with metric 3. > > Meanwhile, A sees the packet from S1 on the LAN from B, > > and sends an assert for S1 with metric 2. > > Each receives the other's assert and loses to it. > > Both remove the oif, and a black hole results. > > > > In other situations, using the source metric in a (*,G) > > assert can cause the assert winner to change every time > > the assert occurs (since a different source address could > > be used each time). > > > > The above example is solved by both A and B using the metric > > towards the RP. > > > > -Dave > > > From owner-pim@catarina.usc.edu Tue Oct 26 18:37:46 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA02678 for ; Tue, 26 Oct 1999 18:37:44 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id PAA02199 for pim-list; Tue, 26 Oct 1999 15:20:05 -0700 Received: from miata.procket.com (miata.procket.com [205.253.146.45]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id PAA02192 for ; Tue, 26 Oct 1999 15:19:57 -0700 Received: (from dino@localhost) by miata.procket.com (8.9.3/8.8.7) id PAA14258; Tue, 26 Oct 1999 15:19:54 -0700 Date: Tue, 26 Oct 1999 15:19:54 -0700 Message-Id: <199910262219.PAA14258@miata.procket.com> X-Authentication-Warning: miata.procket.com: dino set sender to dino@miata.procket.com using -f From: Dino Farinacci To: helmy@ceng.usc.edu CC: mohitt@Exchange.Microsoft.com, pim@catarina.usc.edu In-reply-to: (message from helmy on Tue, 26 Oct 1999 11:47:49 -0700 (PDT)) Subject: Re: The Assert Mechanism: Part 2 :) References: Sender: owner-pim@catarina.usc.edu Precedence: bulk >> If I remember correctly, I have studied Register looping in my research >> and added a rule that a packet is never forwarded back onto the LAN from >> which is originated, i.e., C should never forward the packets onto the LAN >> to which S is attached. You don't need to add a rule. B and C, *both* should have created (S,G) state when S sent the packet. Then when C gets a packet from the shared tree it never forwards out the RPF interface for S. Dino From owner-pim@catarina.usc.edu Tue Oct 26 19:00:01 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA03781 for ; Tue, 26 Oct 1999 19:00:01 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id PAA02476 for pim-list; Tue, 26 Oct 1999 15:52:00 -0700 Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id PAA02472 for ; Tue, 26 Oct 1999 15:51:51 -0700 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 1164B1E029; Tue, 26 Oct 1999 18:51:49 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id SAA14526; Tue, 26 Oct 1999 18:51:46 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id PAA27139; Tue, 26 Oct 1999 15:51:45 -0700 (PDT) Message-Id: <199910262251.PAA27139@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: dino@procket.com Subject: Re: The Assert Mechanism: Part 2 :) Cc: pim@catarina.usc.edu References: <199910262219.PAA14258@miata.procket.com> Date: Tue, 26 Oct 1999 15:51:45 -0700 Versions: dmail (solaris) 2.2e/makemail 2.8u Sender: owner-pim@catarina.usc.edu Precedence: bulk > You don't need to add a rule. B and C, *both* should have created > (S,G) state when S sent the packet. This is not reflected in the spec. The spec only mentions the DR creating state when a locally-connected source starts sending. Bill From owner-pim@catarina.usc.edu Tue Oct 26 19:03:41 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA03997 for ; Tue, 26 Oct 1999 19:03:40 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id PAA02519 for pim-list; Tue, 26 Oct 1999 15:54:44 -0700 Received: from miata.procket.com (miata.procket.com [205.253.146.45]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id PAA02515 for ; Tue, 26 Oct 1999 15:54:36 -0700 Received: (from dino@localhost) by miata.procket.com (8.9.3/8.8.7) id PAA15436; Tue, 26 Oct 1999 15:54:33 -0700 Date: Tue, 26 Oct 1999 15:54:33 -0700 Message-Id: <199910262254.PAA15436@miata.procket.com> X-Authentication-Warning: miata.procket.com: dino set sender to dino@miata.procket.com using -f From: Dino Farinacci To: fenner@research.att.com CC: pim@catarina.usc.edu In-reply-to: <199910262251.PAA27139@windsor.research.att.com> (message from Bill Fenner on Tue, 26 Oct 1999 15:51:45 -0700) Subject: Re: The Assert Mechanism: Part 2 :) References: <199910262219.PAA14258@miata.procket.com> <199910262251.PAA27139@windsor.research.att.com> Sender: owner-pim@catarina.usc.edu Precedence: bulk >> This is not reflected in the spec. The spec only mentions the DR creating >> state when a locally-connected source starts sending. Definitely spec bug. Dino From owner-pim@catarina.usc.edu Tue Oct 26 20:00:55 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA06460 for ; Tue, 26 Oct 1999 20:00:54 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id QAA02996 for pim-list; Tue, 26 Oct 1999 16:52:04 -0700 Received: from siara.com (gate.siara.com [209.31.24.134]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id QAA02992 for ; Tue, 26 Oct 1999 16:51:57 -0700 Received: from malt.mtv.siara.com (malt.mtv.siara.com [192.168.40.9]) by siara.com (8.9.3-LCCHA/8.9.3/lccha Siara hub 1.4) with ESMTP id QAA24145; Tue, 26 Oct 1999 16:51:16 -0700 (PDT) Received: (from lwei@localhost) by malt.mtv.siara.com (8.9.3-LCCHA/8.9.3/lccha Siara client 1.5) id QAA16366; Tue, 26 Oct 1999 16:50:51 -0700 (PDT) Date: Tue, 26 Oct 1999 16:50:51 -0700 (PDT) Message-Id: <199910262350.QAA16366@malt.mtv.siara.com> From: Liming Wei To: fenner@research.att.com CC: dino@procket.com, pim@catarina.usc.edu In-reply-to: <199910262251.PAA27139@windsor.research.att.com> (message from Bill Fenner on Tue, 26 Oct 1999 15:51:45 -0700) Subject: Re: The Assert Mechanism: Part 2 :) Reply-to: lwei@siara.com Sender: owner-pim@catarina.usc.edu Precedence: bulk > From: Bill Fenner > > > You don't need to add a rule. B and C, *both* should have created > > (S,G) state when S sent the packet. > > This is not reflected in the spec. The spec only mentions the DR creating > state when a locally-connected source starts sending. It should soon. -Liming From owner-pim@catarina.usc.edu Tue Oct 26 20:03:02 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA06588 for ; Tue, 26 Oct 1999 20:03:01 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id QAA03099 for pim-list; Tue, 26 Oct 1999 16:59:09 -0700 Received: from siara.com (gate.siara.com [209.31.24.134]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id QAA03090 for ; Tue, 26 Oct 1999 16:58:48 -0700 Received: from malt.mtv.siara.com (malt.mtv.siara.com [192.168.40.9]) by siara.com (8.9.3-LCCHA/8.9.3/lccha Siara hub 1.4) with ESMTP id QAA24338; Tue, 26 Oct 1999 16:58:02 -0700 (PDT) Received: (from lwei@localhost) by malt.mtv.siara.com (8.9.3-LCCHA/8.9.3/lccha Siara client 1.5) id QAA16670; Tue, 26 Oct 1999 16:57:37 -0700 (PDT) Date: Tue, 26 Oct 1999 16:57:37 -0700 (PDT) Message-Id: <199910262357.QAA16670@malt.mtv.siara.com> From: Liming Wei To: dino@procket.com CC: fenner@research.att.com, pim@catarina.usc.edu In-reply-to: <199910262254.PAA15436@miata.procket.com> (message from Dino Farinacci on Tue, 26 Oct 1999 15:54:33 -0700) Subject: Re: The Assert Mechanism: Part 2 :) Reply-to: lwei@siara.com Sender: owner-pim@catarina.usc.edu Precedence: bulk > From: Dino Farinacci > > >> This is not reflected in the spec. The spec only mentions the DR creating > >> state when a locally-connected source starts sending. > > Definitely spec bug. To make it clear what I meant. The spec should state that (S,G) state is created if it does not already exist and a data packet is seen from a directly connected source. -Liming From owner-pim@catarina.usc.edu Tue Oct 26 22:05:47 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA12994 for ; Tue, 26 Oct 1999 22:05:46 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id SAA03738 for pim-list; Tue, 26 Oct 1999 18:58:38 -0700 Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id SAA03732 for ; Tue, 26 Oct 1999 18:58:29 -0700 Received: from localhost (condor.v6.kame.net [3ffe:501:4819:2000:2a0:24ff:fe66:1350]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id KAA24959; Wed, 27 Oct 1999 10:48:47 +0900 (JST) Date: Wed, 27 Oct 1999 10:25:10 +0900 Message-ID: <14358.21622.34253.39645R@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: deering@cisco.com Cc: pim@catarina.usc.edu, ipng@sunroof.eng.sun.com Subject: Re: question about checksum calculation of PIM for IPv6 In-Reply-To: In your message of "Tue, 26 Oct 1999 12:03:56 -0700" References: <14357.56391.879936.85469U@condor.isl.rdc.toshiba.co.jp> User-Agent: Wanderlust/2.2.5 (Come Undone) Emacs/20.4 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 28 Sender: owner-pim@catarina.usc.edu Precedence: bulk >>>>> On Tue, 26 Oct 1999 12:03:56 -0700, >>>>> Steve Deering said: >> i.e. the checksum is calculated without a pseudo-IP header. Should >> this be applied to IPv6 as well as to IPv4? As far as I know, all >> upper layer checksums for IPv6 (including ICMPv6 and OSPFv6) are >> calculated with an IPv6 pseudo-header, mainly because IPv6 does not >> have an IP layer checksum. IMO, the checksum for PIMv6 should obey the >> same rule for the same reason. > Including a pseudo-header in an upper-layer checksum is necessary only > for those higher-layer protocols that depend on the contents of some > IP-layer fields for their own correct operation. For example, TCP uses > the addresses from the IP header as part of the identity of TCP connection > state, and uses the IP length field to determine the size of the TCP > payload. An upper-layer protocol that had no dependencies on any IP > header fields would not need to use a pseudo-header. (I don't know, > off hand, whether or not PIMv6 is such a protocol.) PIM uses, for example, the value of the source address field of the IP(4 or 6) header to recognize PIM neighbors. The source adress is also used in order to elect the Designated Router. There is no different in these point between PIMv4 and PIMv6. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-pim@catarina.usc.edu Wed Oct 27 13:23:27 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24638 for ; Wed, 27 Oct 1999 13:23:23 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id KAA07623 for pim-list; Wed, 27 Oct 1999 10:05:06 -0700 Received: from mail2.packetengines.com (mail2.packetengines.com [208.227.187.173]) by catarina.usc.edu (8.6.10/8.6.9) with SMTP id KAA07619 for ; Wed, 27 Oct 1999 10:04:58 -0700 Received: from STEAM.corp.packetengines.com by mail2.packetengines.com via smtpd (for catarina.usc.edu [128.125.51.47]) with SMTP; 27 Oct 1999 17:04:58 UT Received: by STEAM.corp.packetengines.com with Internet Mail Service (5.5.2650.21) id ; Wed, 27 Oct 1999 10:02:10 -0700 Message-ID: From: Sudhir Cheruathur To: pim@catarina.usc.edu Subject: Source directly connected to the RP. Date: Wed, 27 Oct 1999 10:02:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pim@catarina.usc.edu Precedence: bulk Hi folks, When the RP receives a data packet from a directly connected source and the RP is the DR on this interface, the following state is created. (S,G) iif = source interface oif = oif's of (*,G) - iif. Register Suppression timer = on SPT bit = 0. Is this correct ? Is there a problem if we set the SPT bit for this case, we can "immediately" drop the packet arriving on the wrong interface. Thanks in advance, Regds Sudhir C From owner-pim@catarina.usc.edu Wed Oct 27 13:43:15 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25863 for ; Wed, 27 Oct 1999 13:43:14 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id KAA07903 for pim-list; Wed, 27 Oct 1999 10:34:25 -0700 Received: from kit.isi.edu (kit.isi.edu [128.9.160.207]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id KAA07894 for ; Wed, 27 Oct 1999 10:34:13 -0700 Received: (from eddy@localhost) by kit.isi.edu (8.9.2/8.8.7) id KAA66566; Wed, 27 Oct 1999 10:22:52 -0700 (PDT) (envelope-from eddy) From: Rusty Eddy Message-Id: <199910271722.KAA66566@kit.isi.edu> Subject: Re: Source directly connected to the RP. In-Reply-To: from Sudhir Cheruathur at "Oct 27, 1999 10: 2: 1 am" To: sudhir@packetengines.com (Sudhir Cheruathur) Date: Wed, 27 Oct 1999 10:22:52 -0700 (PDT) Cc: pim@catarina.usc.edu X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Hi folks, > > When the RP receives a data packet from a directly connected > source and the RP is the DR on this interface, the following state is > created. > > (S,G) iif = source interface oif = oif's of (*,G) - iif. > > Register Suppression timer = on > SPT bit = 0. > i would set the spt bit to 1, since it's on the shortest path, and not set the register suppression timer, presumably the router should know it's the RP, meaning the register bit or register iterface (depending on the implementation) should never get set. - rusty From owner-pim@catarina.usc.edu Thu Oct 28 01:21:09 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA00436 for ; Thu, 28 Oct 1999 01:21:08 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id VAA11032 for pim-list; Wed, 27 Oct 1999 21:30:50 -0700 Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id VAA11026 for ; Wed, 27 Oct 1999 21:30:42 -0700 Received: from ceng.usc.edu (helmy@ceng.usc.edu [128.125.253.190]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id VAA29658; Wed, 27 Oct 1999 21:30:35 -0700 (PDT) Received: from localhost (helmy@localhost) by ceng.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id VAA17885; Wed, 27 Oct 1999 21:30:36 -0700 (PDT) Date: Wed, 27 Oct 1999 21:30:36 -0700 (PDT) From: helmy To: "Mohit Talwar (Exchange)" cc: pim@catarina.usc.edu, sandeep@boole.usc.edu Subject: RE: The Assert Mechanism: Part 2 :) In-Reply-To: <19398D273324D3118A2B0008C7E9A5690592C409@SIT.platinum.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pim@catarina.usc.edu Precedence: bulk Hi Mohit, About 3 years ago or so, Deborah and I conducted a systematic testing of PIM through the "stress" methodology and unveiled some design errors (some relating to correctness, other to robustness or performance), on the Assert, Join/Prune and Register mechanisms in PIM-SM. This specific bug for register looping (that you alluded to) was detected, and fixes were suggested to it (as well as others) with the aid of the stress tools we've developed, and these fixes were added to the latest spec then. [Back then we sometimes argued if the bugs we found were so essoteric that they may not show up in reality.. look at us almost 3 years down the road, it actually showed up :-) We have published our results in a paper titled 'Simulation-based 'STRESS' Testing Case Study: A Multicast Routing Protocol', and you can find the reports on-line either through my web page http://netweb.usc.edu/ahelmy/resume.html Deborah's web page catarina.usc.edu/estrin [the figures should show on the printout, but they may not work for Win-based ghostscript software!] or through the technical reports page for the cs dept www.usc.edu/dept/cs/technical_reports.html We are extending our systematic testing methodology to be more automated and complete, and we have applied our latest test generation algorithm (called fault-oriented test generation) to PIM-DM and got some interesting results. You can also find our results in a paper titled 'Fault-oriented Test Generation for Multicast Routing Protocol Design' available through the same web sites as above. Thanks for your comments, Regards, -Ahmed > hi ahmed, > > u r right, > > i looked at the technical report and u do indeed talk about this > case, and a few others. > could u do me a favor and send me an unzipped copy of the > report. the one i got from the web refused to show the figures. > > i think that the spec should say something about issues discussed > by you in the report. maybe i'll bring that point up next. > > mohit. > > >-----Original Message----- > >From: helmy [mailto:helmy@ceng.usc.edu] > >Sent: Tuesday, October 26, 1999 11:48 AM > >To: Mohit Talwar (Exchange) > >Cc: pim@catarina.usc.edu > >Subject: Re: The Assert Mechanism: Part 2 :) > > > > > >If I remember correctly, I have studied Register looping in my research > >and added a rule that a packet is never forwarded back onto > >the LAN from > >which is originated, i.e., C should never forward the packets > >onto the LAN > >to which S is attached. > > > >On Tue, 26 Oct 1999, Mohit Talwar (Exchange) wrote: > > > >> hi all, > >> > >> i think there is a rule missing from section 3.5.1 (Sending Asserts) > >> which will prevent the assert mechanism from stopping duplicates > >> downstream. > >> > >> consider the following topology... > >> > >> > >> +---+ > >> | A | > >> +---+ > >> . > >> . > >> . > >> +-+-+ +-+-+ > >> | B | | C | > >> +-+-+ +-+-+ > >> | | > >> ----------+---------------------------------------+---------- > >> | | > >> S +---+ > >> | D | > >> +-+-+ > >> | > >> R > >> > >> A is the RP > >> B is the DR on the LAN > >> C is the RPF towards A for D > >> R is a receiver > >> S is a source > >> > >> now consider the following sequence of events... > >> R joins a group G > >> D creates (*,G) state and sends the join on the LAN with C > >as the target > >> C create (*,G) state and forwards the join upstream towards A > >> --- > >> S (source) starts sending data > >> B creates (S,G) state and sends the data packet in a register to A > >> D receives the data packet on the right incoming interface > >and forwards it > >> to R. > >> C receives the data packet on an interface in its OIL (outgoing > >> interface list) and sends an assert. however the assert is ignored > >> by both B and D since none of them have the interface in > >their matching > >> OILs. hence C would not create an (S,G,RPT) tree entry and > >delete the > >> interface from its OIL. > >> --- > >> the register is de-encapsulated by A and sent downstream towards C. > >> C will eventually forward this data packet on the LAN which > >again succeeds > >> the > >> incoming interface check at D and is forwarded to R. > >> > >> R keeps getting dups of each data packet sent by S to G! > >> > >> i think the solution is to modify section 3.5.1 thus... > >> > >> " > >> The following Assert rules are provided when a multicast packet is > >> received on an outgoing multi-access interface "I" of an existing > >> active (S,G), (*,G) or (*,*,RP) entry: > >> > >> 0. if the source of the data packet is a local, directly connected > >> the router and the matching entry is (*,G), or (*,*,RP), the > >> router creates a (S,G)RPT-bit entry. Otherwise, no > >new entry is > >> created in response to the Assert. the router should > >then delete > >> the interface from the entry and restart the entry-timer. > >> " > >> > >> basically the router should behave as if it lost the > >> assert election when the source is directly connected. > >> > >> thanx, > >> mohit. > >> > > > From owner-pim@catarina.usc.edu Thu Oct 28 07:18:41 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA14655 for ; Thu, 28 Oct 1999 07:18:40 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id EAA12609 for pim-list; Thu, 28 Oct 1999 04:10:36 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id EAA12605 for ; Thu, 28 Oct 1999 04:10:29 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14187; Thu, 28 Oct 1999 07:10:27 -0400 (EDT) Message-Id: <199910281110.HAA14187@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: pim@catarina.usc.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pim-refresh-01.txt Date: Thu, 28 Oct 1999 07:10:27 -0400 Sender: owner-pim@catarina.usc.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Protocol Independent Multicast Working Group of the IETF. Title : State Refresh in PIM-DM Author(s) : D. Farinacci, I. Kouvelas, K. Windisch Filename : draft-ietf-pim-refresh-01.txt Pages : 10 Date : 27-Oct-99 This proposal extends the PIM-DM [1] protocol specification by intro- ducing the PIM State-Refresh control message. When an (S,G) entry is created in a router for a directly connected source, if the interface directly connected to the source is the incoming interface for the entry, a new timer is started: the State- Refresh-Timer [SRT(S,G)]. The State-Refresh-Timer controls periodic transmission of the PIM State-Refresh message, which is propagated hop-by-hop down the (S,G) RPF tree. When received by a router on the RPF interface, the State-Refresh message causes existing prune state to be refreshed. Addition of this heartbeat message solves many of the current prob- lems with PIM-DM. It prevents the periodic timeout of prune state in routers, greatly reducing the re-flooding of multicast traffic down the pruned branches that expire periodically. It also causes topology changes to be realised quicker than the traditional 3 minute timeout. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pim-refresh-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pim-refresh-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pim-refresh-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991027140721.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pim-refresh-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pim-refresh-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991027140721.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-pim@catarina.usc.edu Thu Oct 28 14:19:58 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02975 for ; Thu, 28 Oct 1999 14:19:57 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id LAA14338 for pim-list; Thu, 28 Oct 1999 11:02:39 -0700 Received: from mail2.packetengines.com (mail2.packetengines.com [208.227.187.173]) by catarina.usc.edu (8.6.10/8.6.9) with SMTP id LAA14334 for ; Thu, 28 Oct 1999 11:02:25 -0700 Received: from STEAM.corp.packetengines.com by mail2.packetengines.com via smtpd (for catarina.usc.edu [128.125.52.1]) with SMTP; 28 Oct 1999 18:02:24 UT Received: by STEAM.corp.packetengines.com with Internet Mail Service (5.5.2650.21) id ; Thu, 28 Oct 1999 10:59:24 -0700 Message-ID: From: Sudhir Cheruathur To: pim@catarina.usc.edu Subject: Register message clarification. Date: Thu, 28 Oct 1999 10:59:24 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pim@catarina.usc.edu Precedence: bulk > Folks, > > Sorry don't mean to be picky but.. > > When a multicast data packet is encapsulated into a PIM-register packet, > the specification > says "The original packet sent by the source" (in the Register packet > format section) must > be encapsulated. > > I think it should say "The original packet sent by the source minus the > Layer 2 header or > IP header and above.". > > If the entire packet including L2 headers is encapsulated, in a > heterogenous network > the RP will not know how to decode the L2 info. Also, I don't think we > need the L2 header in the register message. Thanks in advance, Regds Sudhir C From owner-pim@catarina.usc.edu Fri Oct 29 17:21:11 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA28567 for ; Fri, 29 Oct 1999 17:21:10 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id OAA21608 for pim-list; Fri, 29 Oct 1999 14:12:00 -0700 Received: from mail1.cisco.com (mail1.cisco.com [171.68.225.60]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id OAA21600 for ; Fri, 29 Oct 1999 14:11:32 -0700 Received: from bwilliam-8000.cisco.com (bwilliam-isdn1.cisco.com [171.70.247.82]) by mail1.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id OAA17044; Fri, 29 Oct 1999 14:10:14 -0700 (PDT) Message-Id: <4.1.19991029160531.0098def0@sj-email.cisco.com> X-Sender: bwilliam@sj-email.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 29 Oct 1999 16:09:23 -0700 To: lwei@siara.com, dino@procket.com From: Beau Williamson Subject: Re: The Assert Mechanism: Part 2 :) Cc: fenner@research.att.com, pim@catarina.usc.edu In-Reply-To: <199910262357.QAA16670@malt.mtv.siara.com> References: <199910262254.PAA15436@miata.procket.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-pim@catarina.usc.edu Precedence: bulk At 04:57 PM 10/26/1999 -0700, Liming Wei wrote: >> From: Dino Farinacci >> >> >> This is not reflected in the spec. The spec only mentions the DR creating >> >> state when a locally-connected source starts sending. >> >> Definitely spec bug. > >To make it clear what I meant. The spec should state that (S,G) state >is created if it does not already exist and a data packet is seen from >a directly connected source. > I don't think it matters if it is a directly connected source or not. There are other cases (not necessarily applicable to this section of the spec) where a router can receive data packets from a source for which it has no (S,G) state. Unless I'm mistaken, the router needs to create state in these cases as well. Beau