From owner-pim@catarina.usc.edu Mon Jan 10 12:21:56 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08491 for ; Mon, 10 Jan 2000 12:21:55 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.9.3/8.9.3) id JAA05643 for pim-list; Mon, 10 Jan 2000 09:06:50 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordomo set sender to owner-pim@catarina.usc.edu using -f Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id JAA05639 for ; Mon, 10 Jan 2000 09:06:46 -0800 (PST) Received: from rhino (rhino.cisco.com [172.20.9.57]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id JAA10232; Mon, 10 Jan 2000 09:22:40 -0800 (PST) Received: from p7020-img-nt (fred-hm-dhcp3.cisco.com [171.69.128.118]) by rhino (SMI-8.6/CISCO.WS.1.1) with SMTP id JAA22316; Mon, 10 Jan 2000 09:11:19 -0800 Message-Id: <4.1.20000110082153.02068930@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 10 Jan 2000 08:36:25 -0800 To: pim@catarina.usc.edu From: Fred Baker Subject: FW: PIM-SM Register packets + RSVP Cc: "David R. Oran" , "Bruce Davie" , "Carol Iturralde" , rsvp@isi.udu In-Reply-To: <3875F526.F075B8AE@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-pim@catarina.usc.edu Precedence: bulk Comments below >When using RSVP with PIM-SM, the initial RSVP-PATH message for a multicast >destination would get PIM-Register-Encapsulated by the source's DR and >get unicasted to the RP. > >This suggests that none of the intermediate routers between the >source's DR and the RP would be able to process the RSVP message since the >protocol field in the outermost header of such an IP packet would be PIM >(103) instead of RSVP(46). If so, no RSVP state can be created between >the source's DR and the RP until a native multicast path gets established >between them. > >Once a native multicast path gets established between the source's DR and >the RP, then everything would be fine. The next RSVP-PATH message sent >would get processed by all intermediate routers between the source and the >RP. However, for shortlived sessions (eg. a "voice" call), one would only >get Best Effort forwarding between the source's DR and the RP. > >1) Are there documented mechanisms by which one could ensure that the > initial RSVP-PATH message gets honored by intermediate routers > between the source and the RP if it is encapsulated inside PIM-Register > packets? > >2) Does this fall under the charter of the PIM WG? > >thanks. >--Venu This was forwarded to me by Carol Iturralde. Let me make a couple of observations. Our implementation, at the moment, solves this in the simplest way imaginable. If there is no route for a multicast on a PIM-Sparse network, the initial RSVP PATH message will, as you say, get forwarded to the DR, which will set up a route. We refresh the PATH message a second later, when the route should have been set up. This seems to work in the cases our customers have tested it in. That said, there is a better approach in draft-ietf-rsvp-refresh-reduct-01.txt. This targets a number of instances where messages (new or changed reservations) may be lost in transit and thereby gum up the works, of which the PIM-SPARSE setup is an example. In essence, the proposal is to put an identifier on such a message and require it to be acknowledged. It might be sent fairly frequently, say on one-second intervals with an exponential back-off, until the Ack comes back, but once the Ack comes back, the RSVP Time out might be set quite high, limited to handling refresh and time-out issues. I would suggest - this is the chair's to decide, but I'll give my two cents - that starting RSVP Work in yet another working group is probably not the most efficient approach. Rather, I'd prefer to see work items identified by other working groups reflected back tot the RSVP folks. From owner-pim@catarina.usc.edu Mon Jan 10 16:01:44 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12588 for ; Mon, 10 Jan 2000 16:01:43 -0500 (EST) Received: by catarina.usc.edu (8.9.3/8.9.3) id MAA07031 for pim-list; Mon, 10 Jan 2000 12:45:35 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordomo set sender to owner-pim@catarina.usc.edu using -f Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id MAA07027 for ; Mon, 10 Jan 2000 12:45:31 -0800 (PST) Received: from rhino (rhino.cisco.com [172.20.9.57]) by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with ESMTP id MAA28608; Mon, 10 Jan 2000 12:46:59 -0800 (PST) Received: from p7020-img-nt (fred-hm-dhcp3.cisco.com [171.69.128.118]) by rhino (SMI-8.6/CISCO.WS.1.1) with SMTP id MAA22367; Mon, 10 Jan 2000 12:49:38 -0800 Message-Id: <4.1.20000110123721.01b4f3e0@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 10 Jan 2000 12:38:33 -0800 To: pim@catarina.usc.edu From: Fred Baker Subject: FW: PIM-SM Register packets + RSVP Cc: "David R. Oran" , "Bruce Davie" , "Carol Iturralde" , rsvp@isi.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-pim@catarina.usc.edu Precedence: bulk Sending again with the right mailing list for RSVP. Comments below >When using RSVP with PIM-SM, the initial RSVP-PATH message for a multicast >destination would get PIM-Register-Encapsulated by the source's DR and >get unicasted to the RP. > >This suggests that none of the intermediate routers between the >source's DR and the RP would be able to process the RSVP message since the >protocol field in the outermost header of such an IP packet would be PIM >(103) instead of RSVP(46). If so, no RSVP state can be created between >the source's DR and the RP until a native multicast path gets established >between them. > >Once a native multicast path gets established between the source's DR and >the RP, then everything would be fine. The next RSVP-PATH message sent >would get processed by all intermediate routers between the source and the >RP. However, for shortlived sessions (eg. a "voice" call), one would only >get Best Effort forwarding between the source's DR and the RP. > >1) Are there documented mechanisms by which one could ensure that the > initial RSVP-PATH message gets honored by intermediate routers > between the source and the RP if it is encapsulated inside PIM-Register > packets? > >2) Does this fall under the charter of the PIM WG? > >thanks. >--Venu This was forwarded to me by Carol Iturralde. Let me make a couple of observations. Our implementation, at the moment, solves this in the simplest way imaginable. If there is no route for a multicast on a PIM-Sparse network, the initial RSVP PATH message will, as you say, get forwarded to the DR, which will set up a route. We refresh the PATH message a second later, when the route should have been set up. This seems to work in the cases our customers have tested it in. That said, there is a better approach in draft-ietf-rsvp-refresh-reduct-01.txt. This targets a number of instances where messages (new or changed reservations) may be lost in transit and thereby gum up the works, of which the PIM-SPARSE setup is an example. In essence, the proposal is to put an identifier on such a message and require it to be acknowledged. It might be sent fairly frequently, say on one-second intervals with an exponential back-off, until the Ack comes back, but once the Ack comes back, the RSVP Time out might be set quite high, limited to handling refresh and time-out issues. I would suggest - this is the chair's to decide, but I'll give my two cents - that starting RSVP Work in yet another working group is probably not the most efficient approach. Rather, I'd prefer to see work items identified by other working groups reflected back tot the RSVP folks. From owner-pim@catarina.usc.edu Tue Jan 11 07:30:53 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05174 for ; Tue, 11 Jan 2000 07:30:53 -0500 (EST) Received: by catarina.usc.edu (8.9.3/8.9.3) id EAA10424 for pim-list; Tue, 11 Jan 2000 04:16:11 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordomo set sender to owner-pim@catarina.usc.edu using -f Received: from smtp1.cluster.oleane.net (smtp1.cluster.oleane.net [195.25.12.16]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id EAA10420 for ; Tue, 11 Jan 2000 04:16:07 -0800 (PST) Received: from oleane (dyn-1-1-205.Vin.dialup.oleane.fr [195.25.4.205]) by smtp1.cluster.oleane.net with SMTP id NAA46002; Tue, 11 Jan 2000 13:15:58 +0100 (CET) Message-ID: <001b01bf5c2d$41e873e0$0401a8c0@oleane.com> From: "Peter Lewis" To: Subject: Cellular Internet, Call for Paper Date: Tue, 11 Jan 2000 13:13:22 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01BF5C35.A2B8B7E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-pim@catarina.usc.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0018_01BF5C35.A2B8B7E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cellular Internet: The Micro-Mobility Approach The micro-mobility concept is the most recent and promising approach = proposed to add mobility to the Internet and packet data services to = third generation cellular systems. =20 A CFP is available at:=20 http://www.upperside.fr/baipcn.htm ------=_NextPart_000_0018_01BF5C35.A2B8B7E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Cellular Internet: The = Micro-Mobility=20 Approach

The micro-mobility concept is the most recent and = promising=20 approach proposed to add mobility to the Internet and packet data = services to=20 third generation cellular systems.
 
A CFP is available at:
http://www.upperside.fr/baipc= n.htm
------=_NextPart_000_0018_01BF5C35.A2B8B7E0-- From owner-pim@catarina.usc.edu Wed Jan 12 12:24:36 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20024 for ; Wed, 12 Jan 2000 12:24:29 -0500 (EST) Received: by catarina.usc.edu (8.9.3/8.9.3) id JAA16195 for pim-list; Wed, 12 Jan 2000 09:02:31 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordomo set sender to owner-pim@catarina.usc.edu using -f Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id JAA16191 for ; Wed, 12 Jan 2000 09:02:27 -0800 (PST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (VWALL-IN-motgate 2.0) with ESMTP id KAA19113 for ; Wed, 12 Jan 2000 10:02:25 -0700 (MST)] Received: [from s-il02-d.comm.mot.com (s-il02-d.comm.mot.com [145.1.204.14]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id KAA13610 for ; Wed, 12 Jan 2000 10:02:20 -0700 (MST)] Received: by s-il02-d.comm.mot.com with Internet Mail Service (5.5.2650.21) id ; Wed, 12 Jan 2000 11:02:20 -0600 Message-ID: <0F762B016151D2118F8900805FA795AF0216CD72@s-il02-n.comm.mot.com> From: Narayanan Vidya-CVN065 To: "'pim'" Subject: Join/Prune Messages Date: Wed, 12 Jan 2000 11:02:17 -0600 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 Hello, I have a question about the operation of Join/Prune Messages in PIM-SM. According to the RFC, the PIM Join/Prune messages are multicast to the "ALL PIM ROUTERS" group. However, in reality it is always sent to the unicast RPF neighbor whose address is set to the target address inside the message. How would unicasting this message make the operation of the protocol any different? Would it change anything at all in the operation? Thanks, Vidya From owner-pim@catarina.usc.edu Wed Jan 12 13:17:06 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21111 for ; Wed, 12 Jan 2000 13:17:04 -0500 (EST) Received: by catarina.usc.edu (8.9.3/8.9.3) id KAA16466 for pim-list; Wed, 12 Jan 2000 10:01:53 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordomo set sender to owner-pim@catarina.usc.edu using -f Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id KAA16462 for ; Wed, 12 Jan 2000 10:01:49 -0800 (PST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 7BF7E4CE02; Wed, 12 Jan 2000 13:01:47 -0500 (EST) 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 NAA26511; Wed, 12 Jan 2000 13:01:45 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id KAA13866; Wed, 12 Jan 2000 10:01:45 -0800 (PST) Message-Id: <200001121801.KAA13866@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: cvn065@lmpsil02.comm.mot.com Subject: Re: Join/Prune Messages Cc: pim@catarina.usc.edu Date: Wed, 12 Jan 2000 10:01:44 -0800 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-pim@catarina.usc.edu Precedence: bulk On LANs, Prune messages must be multicasted in order for other downstream routers that may still need the traffic to send Prune-Override Joins. Bill From owner-pim@catarina.usc.edu Wed Jan 12 13:21:48 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21199 for ; Wed, 12 Jan 2000 13:21:47 -0500 (EST) Received: by catarina.usc.edu (8.9.3/8.9.3) id KAA16550 for pim-list; Wed, 12 Jan 2000 10:14:45 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordomo set sender to owner-pim@catarina.usc.edu using -f Received: from dthaler.microsoft.com ([131.107.152.20]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id KAA16546 for ; Wed, 12 Jan 2000 10:14:41 -0800 (PST) Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id LAA16259; Wed, 12 Jan 2000 11:50:50 -0800 (PST) (envelope-from dthaler) From: Dave Thaler Message-Id: <200001121950.LAA16259@dthaler.microsoft.com> Subject: Re: Join/Prune Messages In-Reply-To: <0F762B016151D2118F8900805FA795AF0216CD72@s-il02-n.comm.mot.com> from Narayanan Vidya-CVN065 at "Jan 12, 2000 11: 2:17 am" To: CVN065@lmpsil02.comm.mot.com (Narayanan Vidya-CVN065) Date: Wed, 12 Jan 2000 11:50:50 -0800 (PST) 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 > Hello, > I have a question about the operation of Join/Prune Messages in PIM-SM. > According to the RFC, the PIM Join/Prune messages are multicast to the "ALL > PIM ROUTERS" group. However, in reality it is always sent to the unicast RPF > neighbor whose address is set to the target address inside the message. How > would unicasting this message make the operation of the protocol any > different? Would it change anything at all in the operation? Yes, it would cause black holes on LANs, since you wouldn't be able to override prunes. Search for "override" in RFC 2362. On point-to-point links, it makes no difference either way. -Dave From owner-pim@catarina.usc.edu Wed Jan 12 13:22:09 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21221 for ; Wed, 12 Jan 2000 13:22:07 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.9.3/8.9.3) id KAA16519 for pim-list; Wed, 12 Jan 2000 10:11:03 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordomo set sender to owner-pim@catarina.usc.edu using -f Received: from ntserver1.redstonecom.com (ntserver1.redstonecom.com [199.105.223.130]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id KAA16515 for ; Wed, 12 Jan 2000 10:10:59 -0800 (PST) Received: by NTSERVER1 with Internet Mail Service (5.0.1461.28) id ; Wed, 12 Jan 2000 13:10:30 -0500 Message-ID: <90ABC30C744ED311B16E00500464BEFC40815B@NTSERVER1> From: "Shekhar, Ravi" To: Narayanan Vidya-CVN065 , "'pim'" Subject: RE: Join/Prune Messages Date: Wed, 12 Jan 2000 13:10:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1461.28) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pim@catarina.usc.edu Precedence: bulk It is also used by other downstream routers to override prunes on a multi-access LAN. - Ravi Shekhar. > Hello, > I have a question about the operation of Join/Prune Messages > in PIM-SM. > According to the RFC, the PIM Join/Prune messages are > multicast to the "ALL > PIM ROUTERS" group. However, in reality it is always sent to > the unicast RPF > neighbor whose address is set to the target address inside > the message. How > would unicasting this message make the operation of the protocol any > different? Would it change anything at all in the operation? > > Thanks, > Vidya > From owner-pim@catarina.usc.edu Thu Jan 20 04:05:25 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23923 for ; Thu, 20 Jan 2000 04:05:24 -0500 (EST) Received: by catarina.usc.edu (8.9.3/8.9.3) id AAA21496 for pim-list; Thu, 20 Jan 2000 00:55:46 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordomo set sender to owner-pim@catarina.usc.edu using -f Received: from TYO202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.247.6.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id AAA21492 for ; Thu, 20 Jan 2000 00:55:33 -0800 (PST) Received: from mailsv4.nec.co.jp (mailsv4-le1 [192.168.1.93]) by TYO202.gate.nec.co.jp (8.9.3/3.7W99122211) with ESMTP id RAA00912 for ; Thu, 20 Jan 2000 17:55:25 +0900 (JST) Received: from gw.ccs.mt.nec.co.jp (gw.ccs.mt.nec.co.jp [133.201.4.2]) by mailsv4.nec.co.jp (8.9.3/3.7W-MAILSV4-NEC) with ESMTP id RAA13534 for ; Thu, 20 Jan 2000 17:55:24 +0900 (JST) Received: from mail.ccs.mt.nec.co.jp (mail.ccs.mt.nec.co.jp [133.201.3.22]) by gw.ccs.mt.nec.co.jp (8.9.3/3.7W-GW_CCS) with ESMTP id RAA24314 for ; Thu, 20 Jan 2000 17:55:24 +0900 (JST) Received: from splpe363.ccs.mt.nec.co.jp (splpe363.ccs.mt.nec.co.jp [172.16.5.77]) by mail.ccs.mt.nec.co.jp (8.9.1a/3.6W-CCS_Master) with ESMTP id RAA11616 for ; Thu, 20 Jan 2000 17:55:23 +0900 (JST) Received: from ccs.mt.nec.co.jp by splpe363.ccs.mt.nec.co.jp (8.8.8/6.4J.6-slave-1.0) id RAA27925; Thu, 20 Jan 2000 17:55:23 +0900 (JST) Message-ID: <3886CD52.865193B8@ccs.mt.nec.co.jp> Date: Thu, 20 Jan 2000 17:54:42 +0900 From: Masaaki Tsukioka X-Mailer: Mozilla 4.08 [Vine-ja] (X11; I; Linux 2.2.11 i686) MIME-Version: 1.0 To: pim@catarina.usc.edu Subject: creating of (*,G) entry on SP-tree Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I am studying and have a basic question about the specificaton of PIM-SM. Suppose a router (say router A) exist in the path upstream from the RP to the sender and it has (S,G) entry only, because the RP has joined to the sender and there is no receiver downstream from router A. The (S,G) entry at router A has been set SPT-bit flag already. If a new receiver joins to router A for the multicast group G, (*,G) entry will be created at router A. I am wondering, which state will exceed at this moment on router A, (*,G) or (S,G) ? If I am incorrect, How the entries will be set? I read RFC2362, but I couldn't find how it works. Thanks. --Masaaki From owner-pim@catarina.usc.edu Thu Jan 20 05:19:04 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24234 for ; Thu, 20 Jan 2000 05:19:03 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.9.3/8.9.3) id CAA22054 for pim-list; Thu, 20 Jan 2000 02:11:12 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordomo set sender to owner-pim@catarina.usc.edu using -f Received: from ficon-tech.com ([12.10.198.190]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id CAA22050 for ; Thu, 20 Jan 2000 02:10:58 -0800 (PST) Received: from ficon-tech.com (renu.india.ficon-tech.com [172.25.1.111] (may be forged)) by ficon-tech.com (8.9.3/8.8.7) with ESMTP id PAA17265; Thu, 20 Jan 2000 15:32:35 +0530 (IST) (envelope-from ragarwal@ficon-tech.com) Message-ID: <3886DE33.E86B2332@ficon-tech.com> Date: Thu, 20 Jan 2000 15:36:43 +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: Masaaki Tsukioka CC: pim@catarina.usc.edu Subject: Re: creating of (*,G) entry on SP-tree References: <3886CD52.865193B8@ccs.mt.nec.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello Masaaki, As I understand, the topology is like this: S----DR----B----A---RP And RP has joined the to S directly because of which a (S,G) gets created in the router A. The router A has no other downstream receivers except RP. Now there can be two cases at A: 1. A local host on A joins the group 2. Another downstream router say C sends a (*,G) join prune message to A. Case 1: In this case, the router A shall receive the IGMP join trigger. The router shall add the (*,G) entry in its routing table with outgoing interface as the new interface on which IGMP request was received. In addition, it shall also add the new interface as the oif into the existing (S,G) entry. The router A shall use the (S,G) entry to forward the data from S while the (*,G) entry shall be used to forward data from any other sources except S. The router shall also send the join-prune message to RP with (*,G) and Prune source as S. Case 2: In this case also, the processing shall be same except that the input trigger received will be a join-prune message. Hope I am able to clear your doubt, Regards, Renu Masaaki Tsukioka wrote: > > Hello, > > I am studying and have a basic question about the specificaton > of PIM-SM. > > Suppose a router (say router A) exist in the path upstream > from the RP to the sender and it has (S,G) entry only, because > the RP has joined to the sender and there is no receiver > downstream from router A. The (S,G) entry at router A has been > set SPT-bit flag already. > > If a new receiver joins to router A for the multicast group G, > (*,G) entry will be created at router A. I am wondering, which > state will exceed at this moment on router A, (*,G) or (S,G) ? > If I am incorrect, How the entries will be set? > > I read RFC2362, but I couldn't find how it works. > > Thanks. > --Masaaki From owner-pim@catarina.usc.edu Thu Jan 20 19:44:51 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17444 for ; Thu, 20 Jan 2000 19:44:50 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.9.3/8.9.3) id QAA25233 for pim-list; Thu, 20 Jan 2000 16:34:41 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordomo set sender to owner-pim@catarina.usc.edu using -f Received: from TYO202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.247.6.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id QAA25229 for ; Thu, 20 Jan 2000 16:34:31 -0800 (PST) Received: from mailsv4.nec.co.jp (mailsv4-le1 [192.168.1.93]) by TYO202.gate.nec.co.jp (8.9.3/3.7W99122211) with ESMTP id JAA20703; Fri, 21 Jan 2000 09:34:20 +0900 (JST) Received: from gw.ccs.mt.nec.co.jp (gw.ccs.mt.nec.co.jp [133.201.4.2]) by mailsv4.nec.co.jp (8.9.3/3.7W-MAILSV4-NEC) with ESMTP id JAA25087; Fri, 21 Jan 2000 09:34:20 +0900 (JST) Received: from mail.ccs.mt.nec.co.jp (mail.ccs.mt.nec.co.jp [133.201.3.22]) by gw.ccs.mt.nec.co.jp (8.9.3/3.7W-GW_CCS) with ESMTP id JAA28254; Fri, 21 Jan 2000 09:34:20 +0900 (JST) Received: from splpe363.ccs.mt.nec.co.jp (splpe363.ccs.mt.nec.co.jp [172.16.5.77]) by mail.ccs.mt.nec.co.jp (8.9.1a/3.6W-CCS_Master) with ESMTP id JAA19610; Fri, 21 Jan 2000 09:34:19 +0900 (JST) Received: from ccs.mt.nec.co.jp by splpe363.ccs.mt.nec.co.jp (8.8.8/6.4J.6-slave-1.0) id JAA02493; Fri, 21 Jan 2000 09:34:19 +0900 (JST) Message-ID: <3887A964.6A6E33D@ccs.mt.nec.co.jp> Date: Fri, 21 Jan 2000 09:33:40 +0900 From: Masaaki Tsukioka X-Mailer: Mozilla 4.08 [Vine-ja] (X11; I; Linux 2.2.11 i686) MIME-Version: 1.0 To: Renu Agarwal , pim@catarina.usc.edu Subject: Re: creating of (*,G) entry on SP-tree References: <3886CD52.865193B8@ccs.mt.nec.co.jp> <3886DE33.E86B2332@ficon-tech.com> Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Renu Thanks for the answer :) I asked the question because I was not sure how a router would create (*,G) state after (S,G) state. But now I figure it works normally. Thanks, --Masaaki Renu Agarwal wrote: > > Hello Masaaki, > > As I understand, the topology is like this: > > S----DR----B----A---RP > > And RP has joined the to S directly because of which a (S,G) gets > created in the router A. The router A has no other downstream receivers > except RP. Now there can be two cases at A: > > 1. A local host on A joins the group > 2. Another downstream router say C sends a (*,G) join prune message to > A. > > > Case 1: In this case, the router A shall receive the IGMP join trigger. > The router shall add the (*,G) entry in its routing table with outgoing > interface as the new interface on which IGMP request was received. > > In addition, it shall also add the new interface as the oif into the > existing (S,G) entry. > > The router A shall use the (S,G) entry to forward the data from S while > the (*,G) entry shall be used to forward data from any other sources > except S. > > The router shall also send the join-prune message to RP with (*,G) and > Prune source as S. > > Case 2: In this case also, the processing shall be same except that the > input trigger received will be a join-prune message. > > Hope I am able to clear your doubt, > > Regards, > Renu > -- -- -- -- -- -- -- -- -- -- (株)日本ネットシステム 外線 TEL: (03)5476-1071 月岡 正明(つきおか まさあき) 内線 TEL: 8-20-24879 E-Mail: m-tukiok@ccs.mt.nec.co.jp From owner-pim@catarina.usc.edu Thu Jan 27 14:27:38 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12738 for ; Thu, 27 Jan 2000 14:27:37 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.9.3/8.9.3) id LAA00742 for pim-list; Thu, 27 Jan 2000 11:11:13 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordomo set sender to owner-pim@catarina.usc.edu using -f Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id LAA00738 for ; Thu, 27 Jan 2000 11:11:08 -0800 (PST) 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.1) with ESMTP id DAA16210; Fri, 28 Jan 2000 03:48:04 +0900 (JST) Date: Fri, 28 Jan 2000 03:58:48 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: haberman@nortelnetworks.com Cc: pim@catarina.usc.edu, ipng@sunroof.eng.sun.com Subject: Re: updated PIM for IPv6 draft In-Reply-To: In your message of "Tue, 21 Dec 1999 12:44:53 -0500" <385FBC94.F5B27045@nortelnetworks.com> References: <3835BBF9.1CCC1D9F@nortelnetworks.com> <385FBC94.F5B27045@nortelnetworks.com> User-Agent: Wanderlust/2.2.15 (More Than Words) Emacs/20.5 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 26 Sender: owner-pim@catarina.usc.edu Precedence: bulk >>>>> On Tue, 21 Dec 1999 12:44:53 -0500, >>>>> "Brian Haberman" said: > Your approach would be consistent with what OSPF for IPv6 does. > The draft could be changed to require that change, but I would like > some input from the working groups. >> i.e. the checksum is calculated without a pseudo-IP header. However, I >> believe it should be calculated *with* a pseudo-IP header for IPv6 PIM >> packets, because IPv6 does not have an IP layer checksum and because >> PIM depends on some fileds of received IP packets (e.g. the source >> address field). >> >> If it's reasonable, I hope it will be described in a future version of >> the pim-ipv6 draft and/or the pim-v2 draft. I've been watching the list, but I've not seen any opinions on this issue (sorry if I missed something). Does this mean that everyone agrees on the change? Or do I miss something fundamental? Thanks again. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-pim@catarina.usc.edu Thu Jan 27 14:56:04 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13567 for ; Thu, 27 Jan 2000 14:56:03 -0500 (EST) Received: by catarina.usc.edu (8.9.3/8.9.3) id LAA00961 for pim-list; Thu, 27 Jan 2000 11:41:25 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordomo set sender to owner-pim@catarina.usc.edu using -f Received: from roll.mentat.com (mentat.com [192.88.122.129]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id LAA00957 for ; Thu, 27 Jan 2000 11:41:21 -0800 (PST) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id LAA26711; Thu, 27 Jan 2000 11:23:26 -0800 (PST) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id LAA05806; Thu, 27 Jan 2000 11:23:26 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.1) id LAA05775; Thu, 27 Jan 2000 11:24:54 -0800 (PST) Date: Thu, 27 Jan 2000 11:24:54 -0800 (PST) From: Tim Hartrick Message-Id: <200001271924.LAA05775@feller.mentat.com> To: haberman@nortelnetworks.com, jinmei@isl.rdc.toshiba.co.jp Subject: Re: updated PIM for IPv6 draft Cc: pim@catarina.usc.edu, ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-pim@catarina.usc.edu Precedence: bulk Jinmei, > > > Your approach would be consistent with what OSPF for IPv6 does. > > The draft could be changed to require that change, but I would like > > some input from the working groups. > > >> i.e. the checksum is calculated without a pseudo-IP header. However, I > >> believe it should be calculated *with* a pseudo-IP header for IPv6 PIM > >> packets, because IPv6 does not have an IP layer checksum and because > >> PIM depends on some fileds of received IP packets (e.g. the source > >> address field). > >> > >> If it's reasonable, I hope it will be described in a future version of > >> the pim-ipv6 draft and/or the pim-v2 draft. > > I've been watching the list, but I've not seen any opinions on this > issue (sorry if I missed something). Does this mean that everyone > agrees on the change? Or do I miss something fundamental? > For what it is worth I agree with you. Any upper level protocol that depends on the fields of the IPv6 header which are covered by the standard TCP/UDP pseudo header checksum calculation should specify the same pseudo header checksum calculation. Without this integrity check, misdelivered or intentially forged datagrams could cause serious problems absent some other form of integrity check. Tim Hartrick Mentat Inc. From owner-pim@catarina.usc.edu Thu Jan 27 17:38:14 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16233 for ; Thu, 27 Jan 2000 17:38:13 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.9.3/8.9.3) id OAA01887 for pim-list; Thu, 27 Jan 2000 14:21:25 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordomo set sender to owner-pim@catarina.usc.edu using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id OAA01883 for ; Thu, 27 Jan 2000 14:21:21 -0800 (PST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id XAA00803; Thu, 27 Jan 2000 23:21:17 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id XAA02816; Thu, 27 Jan 2000 23:21:16 +0100 (MET) Message-Id: <200001272221.XAA02816@givry.inria.fr> From: Francis Dupont To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: haberman@nortelnetworks.com, pim@catarina.usc.edu, ipng@sunroof.eng.sun.com Subject: Re: updated PIM for IPv6 draft In-reply-to: Your message of Fri, 28 Jan 2000 03:58:48 +0900. Date: Thu, 27 Jan 2000 23:21:15 +0100 Sender: owner-pim@catarina.usc.edu Precedence: bulk In your previous mail you wrote: Does this mean that everyone agrees on the change? => I agree (ie. the rationate for ICMPv6 checksum applies to PIMv6 one). Regards Francis.Dupont@inria.fr PS: we need a way (flag day?) to solve the interopability issue introduced by this change.