From 558-mailing-list-admin@catarina.usc.edu Sun Dec 1 08:10:18 2002
Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04058
for ; Sun, 1 Dec 2002 08:10:18 -0500 (EST)
Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1])
by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gB1DAKD93410
for ; Sun, 1 Dec 2002 05:10:21 -0800 (PST)
(envelope-from 558-mailing-list-admin@catarina.usc.edu)
Date: Sun, 01 Dec 2002 05:10:20 -0800
Message-ID: <20021201131020.89665.77590.Mailman@catarina.usc.edu>
Subject: catarina.usc.edu mailing list memberships reminder
From: mailman-owner@catarina.usc.edu
To: pim-archive@ietf.org
X-No-Archive: yes
X-Ack: no
Sender: 558-mailing-list-admin@catarina.usc.edu
Errors-To: 558-mailing-list-admin@catarina.usc.edu
X-BeenThere: 558-mailing-list@catarina.usc.edu
X-Mailman-Version: 2.0.13
Precedence: bulk
This is a reminder, sent out once a month, about your catarina.usc.edu
mailing list memberships. It includes your subscription info and how
to use it to change it or unsubscribe from a list.
You can visit the URLs to change your membership status or
configuration, including unsubscribing, setting digest-style delivery
or disabling delivery altogether (e.g., for a vacation), and so on.
In addition to the URL interfaces, you can also use email to make such
changes. For more info, send a message to the '-request' address of
the list (for example, pim-request@catarina.usc.edu) containing just
the word 'help' in the message body, and an email message will be sent
to you with instructions.
If you have questions, problems, comments, etc, send them to
mailman-owner@catarina.usc.edu. Thanks!
Passwords for pim-archive@lists.ietf.org:
List Password // URL
---- --------
pim@catarina.usc.edu kimoit
http://catarina.usc.edu/mailman/options/pim/pim-archive%40lists.ietf.org
From pim-admin@catarina.usc.edu Sun Dec 1 13:45:12 2002
Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13472
for ; Sun, 1 Dec 2002 13:45:11 -0500 (EST)
Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1])
by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gB1If3D97374;
Sun, 1 Dec 2002 10:41:03 -0800 (PST)
(envelope-from pim-admin@catarina.usc.edu)
Received: from webmail29.rediffmail.com (webmail29.rediffmail.com [203.199.83.39] (may be forged))
by catarina.usc.edu (8.11.6/8.11.6) with SMTP id gB1Ie3D97341
for ; Sun, 1 Dec 2002 10:40:03 -0800 (PST)
(envelope-from learning_pim@rediffmail.com)
Received: (qmail 31162 invoked by uid 510); 1 Dec 2002 18:40:54 -0000
Message-ID: <20021201184054.31161.qmail@webmail29.rediffmail.com>
Received: from unknown (195.207.101.112) by rediffmail.com via HTTP; 01 dec 2002 18:40:54 -0000
MIME-Version: 1.0
From: "Prashant Jhingran"
Reply-To: "Prashant Jhingran"
To: pim@catarina.usc.edu
Cc: "Bandi,Sarveshwar"
Subject: Re: [pim] A query about assertTrackingDesired and CouldAssert macros
Content-type: text/plain;
format=flowed
Content-Disposition: inline
Sender: pim-admin@catarina.usc.edu
Errors-To: pim-admin@catarina.usc.edu
X-BeenThere: pim@catarina.usc.edu
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Unsubscribe: ,
List-Id:
List-Post:
List-Help:
List-Subscribe: ,
List-Archive:
Date: 1 Dec 2002 18:40:54 -0000
hi Sarvesh,
Well in a nutshell yes it means the same.
If you look closely at the two macros, a part of it
(Interface I present in the downstream interface) is the same.
But in case of CouldAssert macro, RPF check towards the S or RP is
a MUST condition whereas its an optional condition in the other
macro.
These checks finally boil down to the fact that
AssertTrackingDesired can only be true for upstream interface
while the other on downstream interface.
regards,
Prashant
On Fri, 29 Nov 2002 Bandi, Sarveshwar wrote :
>Hi,
> Is it right to say that macros AssertTrackingDesired(*,G)
>and
>AssertTrackingDesired(S,G) macros return TRUE only for
>RPF_Interface(RP) and RPF_interface(S) respectively?
>
> Similarly is it right to say that macros CouldAssert(*,G)
>and
>CouldAssert(S,G) return TRUE only for downstream interfaces?
>
>
>Thanks and regards,
>Sarvesh
>
>Sarveshwar Bandi
>
>Senior Member, Technical Staff
>Netplane Network Technologies (India) Pvt. Ltd.
>http://www.netplane.com
>Ph: +91-40-355 3709/10/11/12 Extn: 1126
>Fax: +91-40-355 3713
>
>_______________________________________________
>pim mailing list
>pim@catarina.usc.edu
>http://catarina.usc.edu/mailman/listinfo/pim
________________________________________________________________
NIIT supports World Computer Literacy Day on 2nd December.
Enroll for NIIT SWIFT Jyoti till 2nd December for only Rs. 749
and get free Indian Languages Office software worth Rs. 2500.
For details contact your nearest NIIT centre, SWIFT Point
or click here http://swift.rediff.com/
_______________________________________________
pim mailing list
pim@catarina.usc.edu
http://catarina.usc.edu/mailman/listinfo/pim
From pim-admin@catarina.usc.edu Sun Dec 1 14:39:27 2002
Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13471
for ; Sun, 1 Dec 2002 13:45:11 -0500 (EST)
Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1])
by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gB1IecD97355;
Sun, 1 Dec 2002 10:40:38 -0800 (PST)
(envelope-from pim-admin@catarina.usc.edu)
Received: from webmail27.rediffmail.com (webmail27.rediffmail.com [203.199.83.37] (may be forged))
by catarina.usc.edu (8.11.6/8.11.6) with SMTP id gB1IdVD97323
for ; Sun, 1 Dec 2002 10:39:31 -0800 (PST)
(envelope-from learning_pim@rediffmail.com)
Received: (qmail 3545 invoked by uid 510); 1 Dec 2002 18:40:33 -0000
Message-ID: <20021201184033.3544.qmail@webmail27.rediffmail.com>
Received: from unknown (195.207.101.112) by rediffmail.com via HTTP; 01 dec 2002 18:40:33 -0000
MIME-Version: 1.0
From: "Prashant Jhingran"
Reply-To: "Prashant Jhingran"
To: pim@catarina.usc.edu
Cc: "Bandi,Sarveshwar"
Subject: Re: [pim] A query about assertTrackingDesired and CouldAssert macros
Content-type: text/plain;
format=flowed
Content-Disposition: inline
Sender: pim-admin@catarina.usc.edu
Errors-To: pim-admin@catarina.usc.edu
X-BeenThere: pim@catarina.usc.edu
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Unsubscribe: ,
List-Id:
List-Post:
List-Help:
List-Subscribe: ,
List-Archive:
Date: 1 Dec 2002 18:40:33 -0000
hi Sarvesh,
Well in a nutshell yes it means the same.
If you look closely at the two macros, a part of it
(Interface I present in the downstream interface) is the same.
But in case of CouldAssert macro, RPF check towards the S or RP is
a MUST condition whereas its an optional condition in the other
macro.
These checks finally boil down to the fact that
AssertTrackingDesired can only be true for upstream interface
while the other on downstream interface.
regards,
Prashant
On Fri, 29 Nov 2002 Bandi, Sarveshwar wrote :
>Hi,
> Is it right to say that macros AssertTrackingDesired(*,G)
>and
>AssertTrackingDesired(S,G) macros return TRUE only for
>RPF_Interface(RP) and RPF_interface(S) respectively?
>
> Similarly is it right to say that macros CouldAssert(*,G)
>and
>CouldAssert(S,G) return TRUE only for downstream interfaces?
>
>
>Thanks and regards,
>Sarvesh
>
>Sarveshwar Bandi
>
>Senior Member, Technical Staff
>Netplane Network Technologies (India) Pvt. Ltd.
>http://www.netplane.com
>Ph: +91-40-355 3709/10/11/12 Extn: 1126
>Fax: +91-40-355 3713
>
>_______________________________________________
>pim mailing list
>pim@catarina.usc.edu
>http://catarina.usc.edu/mailman/listinfo/pim
________________________________________________________________
NIIT supports World Computer Literacy Day on 2nd December.
Enroll for NIIT SWIFT Jyoti till 2nd December for only Rs. 749
and get free Indian Languages Office software worth Rs. 2500.
For details contact your nearest NIIT centre, SWIFT Point
or click here http://swift.rediff.com/
_______________________________________________
pim mailing list
pim@catarina.usc.edu
http://catarina.usc.edu/mailman/listinfo/pim
From pim-admin@catarina.usc.edu Wed Dec 4 20:18:43 2002
Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13704
for ; Wed, 4 Dec 2002 20:18:42 -0500 (EST)
Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1])
by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gB51BsD56321;
Wed, 4 Dec 2002 17:11:54 -0800 (PST)
(envelope-from pim-admin@catarina.usc.edu)
Received: from web41215.mail.yahoo.com (web41215.mail.yahoo.com [66.218.93.48])
by catarina.usc.edu (8.11.6/8.11.6) with SMTP id gB4Gg1D50391
for ; Wed, 4 Dec 2002 08:42:01 -0800 (PST)
(envelope-from docwatson22@yahoo.com)
Message-ID: <20021204164438.80213.qmail@web41215.mail.yahoo.com>
Received: from [64.198.3.162] by web41215.mail.yahoo.com via HTTP; Wed, 04 Dec 2002 08:44:38 PST
From: Chris Watson
Reply-To: docwatson223@comcast.net
To: pim@catarina.usc.edu
Cc: lou@lifeofrily.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1647349646-1039020278=:79689"
Subject: [pim] PIM V2
Sender: pim-admin@catarina.usc.edu
Errors-To: pim-admin@catarina.usc.edu
X-BeenThere: pim@catarina.usc.edu
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Unsubscribe: ,
List-Id:
List-Post:
List-Help:
List-Subscribe: ,
List-Archive:
Date: Wed, 4 Dec 2002 08:44:38 -0800 (PST)
--0-1647349646-1039020278=:79689
Content-Type: text/plain; charset=us-ascii
A few of us are getting ready for the CCIE Written and were wondering if PIM is tcp or udp and what port.
Thanks! =)
Chris Watson
Dan Conrad
Chris Watson, CCNP
docwatson@suscom.net
717-845-1492 h
717-542-1564 c
---------------------------------
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now
--0-1647349646-1039020278=:79689
Content-Type: text/html; charset=us-ascii
A few of us are getting ready for the CCIE Written and were wondering if PIM is tcp or udp and what port.
Thanks! =)
Chris Watson
Dan Conrad
Chris Watson, CCNP
docwatson@suscom.net
717-845-1492 h
717-542-1564 c
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now
--0-1647349646-1039020278=:79689--
_______________________________________________
pim mailing list
pim@catarina.usc.edu
http://catarina.usc.edu/mailman/listinfo/pim
From pim-admin@catarina.usc.edu Wed Dec 4 20:27:31 2002
Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13941
for ; Wed, 4 Dec 2002 20:27:31 -0500 (EST)
Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1])
by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gB51MkD56497;
Wed, 4 Dec 2002 17:22:46 -0800 (PST)
(envelope-from pim-admin@catarina.usc.edu)
Received: from possum.icir.org (possum.icir.org [192.150.187.67])
by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gB51JfD56453
for ; Wed, 4 Dec 2002 17:19:41 -0800 (PST)
(envelope-from pavlin@possum.icir.org)
Received: from possum.icir.org (localhost [127.0.0.1])
by possum.icir.org (8.12.3/8.11.3) with ESMTP id gB51MQoo081442;
Wed, 4 Dec 2002 17:22:26 -0800 (PST)
(envelope-from pavlin@possum.icir.org)
Message-Id: <200212050122.gB51MQoo081442@possum.icir.org>
To: docwatson223@comcast.net
cc: pim@catarina.usc.edu, lou@lifeofrily.org
Subject: Re: [pim] PIM V2
In-Reply-To: Message from Chris Watson
of "Wed, 04 Dec 2002 08:44:38 PST." <20021204164438.80213.qmail@web41215.mail.yahoo.com>
From: Pavlin Radoslavov
Sender: pim-admin@catarina.usc.edu
Errors-To: pim-admin@catarina.usc.edu
X-BeenThere: pim@catarina.usc.edu
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Unsubscribe: ,
List-Id:
List-Post:
List-Help:
List-Subscribe: ,
List-Archive:
Date: Wed, 04 Dec 2002 17:22:26 -0800
> A few of us are getting ready for the CCIE Written and were
> wondering if PIM is tcp or udp and what port.
Neither. PIM uses its own protocol number (=103). Though, there
is no reliability in the message exchange, so UDP is closer analogy
to it (except that there is no port number).
Regards,
Pavlin
_______________________________________________
pim mailing list
pim@catarina.usc.edu
http://catarina.usc.edu/mailman/listinfo/pim
From pim-admin@catarina.usc.edu Tue Dec 10 14:51:16 2002
Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19041
for ; Tue, 10 Dec 2002 14:51:16 -0500 (EST)
Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1])
by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gBAJiKD56004;
Tue, 10 Dec 2002 11:44:21 -0800 (PST)
(envelope-from pim-admin@catarina.usc.edu)
Received: from multicasttech.com (IDENT:root@lennon.multicasttech.com [63.105.122.7])
by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gBAJf8D55959
for ; Tue, 10 Dec 2002 11:41:08 -0800 (PST)
(envelope-from tme@multicasttech.com)
Received: from float56005.mcs.anl-external.org (account marshall_eubanks [140.221.56.5] verified)
by multicasttech.com (CommuniGate Pro SMTP 3.4.8)
with ESMTP-TLS id 1532115 for pim@catarina.usc.edu; Tue, 10 Dec 2002 14:44:37 -0500
Mime-Version: 1.0 (Apple Message framework v482)
Content-Type: text/plain; charset=US-ASCII; format=flowed
From: Marshall Eubanks
To: pim@catarina.usc.edu
Content-Transfer-Encoding: 7bit
Message-Id:
X-Mailer: Apple Mail (2.482)
Subject: [pim] PIM Draft
Sender: pim-admin@catarina.usc.edu
Errors-To: pim-admin@catarina.usc.edu
X-BeenThere: pim@catarina.usc.edu
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Unsubscribe: ,
List-Id:
List-Post:
List-Help:
List-Subscribe: ,
List-Archive:
Date: Tue, 10 Dec 2002 14:43:30 -0500
Content-Transfer-Encoding: 7bit
Hello;
What happened to the PIM v2 draft ?
Has -04 been superceeded or expired ?
The draft seems to have disappeared from the IETF site...
Regards
Marshall Eubanks
This e-mail may contain confidential and proprietary information of
Multicast Technologies, Inc, subject to Non-Disclosure Agreements
T.M. Eubanks
Multicast Technologies, Inc.
10301 Democracy Lane, Suite 410
Fairfax, Virginia 22030
Phone : 703-293-9624 Fax : 703-293-9609
e-mail : tme@multicasttech.com
http://www.multicasttech.com
Test your network for multicast :
http://www.multicasttech.com/mt/
Status of Multicast on the Web :
http://www.multicasttech.com/status/index.html
_______________________________________________
pim mailing list
pim@catarina.usc.edu
http://catarina.usc.edu/mailman/listinfo/pim
From pim-admin@catarina.usc.edu Tue Dec 10 15:16:32 2002
Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19752
for ; Tue, 10 Dec 2002 15:16:31 -0500 (EST)
Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1])
by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gBAKBID56458;
Tue, 10 Dec 2002 12:11:18 -0800 (PST)
(envelope-from pim-admin@catarina.usc.edu)
Received: from possum.icir.org (possum.icir.org [192.150.187.67])
by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gBAKA5D56436
for ; Tue, 10 Dec 2002 12:10:05 -0800 (PST)
(envelope-from pavlin@possum.icir.org)
Received: from possum.icir.org (localhost [127.0.0.1])
by possum.icir.org (8.12.3/8.12.3) with ESMTP id gBAKDflE033114;
Tue, 10 Dec 2002 12:13:41 -0800 (PST)
(envelope-from pavlin@possum.icir.org)
Message-Id: <200212102013.gBAKDflE033114@possum.icir.org>
To: Marshall Eubanks
cc: pim@catarina.usc.edu
Subject: Re: [pim] PIM Draft
In-Reply-To: Message from Marshall Eubanks
of "Tue, 10 Dec 2002 14:43:30 EST."
From: Pavlin Radoslavov
Sender: pim-admin@catarina.usc.edu
Errors-To: pim-admin@catarina.usc.edu
X-BeenThere: pim@catarina.usc.edu
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Unsubscribe: ,
List-Id:
List-Post:
List-Help:
List-Subscribe: ,
List-Archive:
Date: Tue, 10 Dec 2002 12:13:41 -0800
> Hello;
>
> What happened to the PIM v2 draft ?
> Has -04 been superceeded or expired ?
>
> The draft seems to have disappeared from the IETF site...
>
> Regards
> Marshall Eubanks
>
> This e-mail may contain confidential and proprietary information of
> Multicast Technologies, Inc, subject to Non-Disclosure Agreements
I am sorry, but I don't think that such disclaimer is appropriate
for email sent to a public mailing list. Myself (and I guess most of
the folks on this list) have not signed any such agreement.
Further, the email archive of this list is available open for the
public from http://netweb.usc.edu/pipermail/pim/ so you cannot
enforce NDA on people who read the archived email there.
Pavlin (speaking for myself only)
> T.M. Eubanks
> Multicast Technologies, Inc.
> 10301 Democracy Lane, Suite 410
> Fairfax, Virginia 22030
> Phone : 703-293-9624 Fax : 703-293-9609
> e-mail : tme@multicasttech.com
> http://www.multicasttech.com
>
> Test your network for multicast :
> http://www.multicasttech.com/mt/
> Status of Multicast on the Web :
> http://www.multicasttech.com/status/index.html
>
> _______________________________________________
> pim mailing list
> pim@catarina.usc.edu
> http://catarina.usc.edu/mailman/listinfo/pim
_______________________________________________
pim mailing list
pim@catarina.usc.edu
http://catarina.usc.edu/mailman/listinfo/pim
From pim-admin@catarina.usc.edu Tue Dec 10 18:11:55 2002
Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24508
for ; Tue, 10 Dec 2002 18:11:54 -0500 (EST)
Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1])
by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gBAN53D58601;
Tue, 10 Dec 2002 15:05:03 -0800 (PST)
(envelope-from pim-admin@catarina.usc.edu)
Received: from prattle.redback.com (hiddenuser@prattle.redback.com [155.53.12.9])
by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gBAN1RD58545
for ; Tue, 10 Dec 2002 15:01:27 -0800 (PST)
(envelope-from lwei@redback.com)
Received: from liming-pc.redback.com (liming-pc.redback.com [155.53.36.120])
by prattle.redback.com (Postfix) with ESMTP id 2E0F11E1262
for ; Tue, 10 Dec 2002 15:05:00 -0800 (PST)
Received: (from lwei@localhost)
by liming-pc.redback.com (8.11.3nb1/8.8.8/null redback bsdclient) id gBAN50n09691;
Tue, 10 Dec 2002 15:05:00 -0800 (PST)
Message-Id: <200212102305.gBAN50n09691@liming-pc.redback.com>
From: Liming Wei
To: pim@catarina.usc.edu
Subject: [fenner@research.att.com: Re: [tme@multicasttech.com: [pim] PIM Draft]]
Reply-To: lwei@redback.com
Sender: pim-admin@catarina.usc.edu
Errors-To: pim-admin@catarina.usc.edu
X-BeenThere: pim@catarina.usc.edu
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Unsubscribe: ,
List-Id:
List-Post:
List-Help:
List-Subscribe: ,
List-Archive:
Date: Tue, 10 Dec 2002 15:05:00 -0800 (PST)
FYI.
------- Start of forwarded message -------
From: Bill Fenner
To: lwei@redback.com
Subject: Re: [tme@multicasttech.com: [pim] PIM Draft]
Cc: mjh@aciri.org, holbrook@cisco.com, kouvelas@cisco.com,
tme@multicasttech.com, pusateri@juniper.net
Date: Tue, 10 Dec 2002 14:50:50 -0800
I just submitted -06, which is only different from -05 by having
two typos fixed.
Bill
------- End of forwarded message -------
_______________________________________________
pim mailing list
pim@catarina.usc.edu
http://catarina.usc.edu/mailman/listinfo/pim
From pim-admin@catarina.usc.edu Wed Dec 11 12:27:58 2002
Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13433
for ; Wed, 11 Dec 2002 12:27:57 -0500 (EST)
Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1])
by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gBBHNCD71629;
Wed, 11 Dec 2002 09:23:12 -0800 (PST)
(envelope-from pim-admin@catarina.usc.edu)
Received: from xover.netplane.com (fwout.maker.com [12.27.183.253] (may be forged))
by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gBBHLFD71595
for ; Wed, 11 Dec 2002 09:21:16 -0800 (PST)
(envelope-from sarveshwarb@netplane.com)
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19)
id <4B0HRXR6>; Wed, 11 Dec 2002 12:24:54 -0500
Message-ID:
From: "Bandi, Sarveshwar"
To: pim@catarina.usc.edu
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Subject: [pim] Query on the pseudocode in section 4.4.2
Sender: pim-admin@catarina.usc.edu
Errors-To: pim-admin@catarina.usc.edu
X-BeenThere: pim@catarina.usc.edu
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Unsubscribe: ,
List-Id:
List-Post:
List-Help:
List-Subscribe: ,
List-Archive:
Date: Wed, 11 Dec 2002 12:26:46 -0500
Hi All,
I would like to use an modified version of the pseudocode in section 4.4.2
(receiving register messages at RP) as follows
packet_arrives_on_rp_tunnel( pkt ) {
if( outer.dst is not one of my addresses ) {
drop the packet silently.
# note that this should not happen if the lower layer is
working
}
if( I_am_RP( G ) && outer.dst == RP(G) ) {
/*
--> Moving this action down.
--> restart KeepaliveTimer(S,G)
*/
if(( inherited_olist(S,G) == NULL ) OR SPTbit(S,G)) {
send RegisterStop(S,G) to outer.src
} else {
--> /* Moved restarting the timer over here */
restart KeepaliveTimer(S,G)
if( ! pkt.NullRegisterBit ) {
decapsulate and pass the inner packet to the normal
forwarding path for forwarding on the (*,G) tree.
}
}
} else {
send RegisterStop(S,G) to outer.src
# Note (*)
}
}
Basically what i would like to do is restart the keepalivetimer only if
there are interested listeners for this group G at the RP. I guess the
behaviour would be that, the SPT from RP to S would be created only when
someone joins the RPT. Once the SPT is created the SPTbit would be set and
the KeepAlivetimer would be restarted by the forwarding pseudocode. This
also would imply that SPT would not be formed unless someone joined the RPT.
I was just wondering if such an modification is ok. Would this affect the
functioning of the protocol in any other way? Also is the delay in forming
SPT after receivers join the RPT acceptable? Would this lead to any black
holes?
Would appreciate comments on this.
Thanks and regards,
Sarvesh
Sarveshwar Bandi
Senior Member, Technical Staff
Netplane Network Technologies (India) Pvt. Ltd.
http://www.netplane.com
Ph: +91-40-355 3709/10/11/12 Extn: 1126
Fax: +91-40-355 3713
_______________________________________________
pim mailing list
pim@catarina.usc.edu
http://catarina.usc.edu/mailman/listinfo/pim
From pim-admin@catarina.usc.edu Thu Dec 12 03:02:59 2002
Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16085
for ; Thu, 12 Dec 2002 03:02:58 -0500 (EST)
Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1])
by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gBC7v1D81602;
Wed, 11 Dec 2002 23:57:02 -0800 (PST)
(envelope-from pim-admin@catarina.usc.edu)
Received: from possum.icir.org (possum.icir.org [192.150.187.67])
by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gBC7rmD81546
for ; Wed, 11 Dec 2002 23:53:48 -0800 (PST)
(envelope-from pavlin@possum.icir.org)
Received: from possum.icir.org (localhost [127.0.0.1])
by possum.icir.org (8.12.3/8.12.3) with ESMTP id gBC7vWlE089079;
Wed, 11 Dec 2002 23:57:36 -0800 (PST)
(envelope-from pavlin@possum.icir.org)
Message-Id: <200212120757.gBC7vWlE089079@possum.icir.org>
To: "Bandi, Sarveshwar"
cc: pim@catarina.usc.edu
Subject: Re: [pim] Query on the pseudocode in section 4.4.2
In-Reply-To: Message from "Bandi, Sarveshwar"
of "Wed, 11 Dec 2002 12:26:46 EST."
From: Pavlin Radoslavov
Sender: pim-admin@catarina.usc.edu
Errors-To: pim-admin@catarina.usc.edu
X-BeenThere: pim@catarina.usc.edu
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Unsubscribe: ,
List-Id:
List-Post:
List-Help:
List-Subscribe: ,
List-Archive:
Date: Wed, 11 Dec 2002 23:57:32 -0800
You may want to check
http://netweb.usc.edu/pipermail/pim/2002-October/000259.html
(note that the archive for that thread was split between September
and October)
The original purpose of that pseudo code was different (i.e., not to
do SPT switch on the first packet received at the RP), but in
addition to that it does also what you want.
Regards,
Pavlin
> I would like to use an modified version of the pseudocode in section 4.4.2
> (receiving register messages at RP) as follows
> packet_arrives_on_rp_tunnel( pkt ) {
> if( outer.dst is not one of my addresses ) {
> drop the packet silently.
> # note that this should not happen if the lower layer is
> working
> }
> if( I_am_RP( G ) && outer.dst == RP(G) ) {
> /*
> --> Moving this action down.
> --> restart KeepaliveTimer(S,G)
> */
>
> if(( inherited_olist(S,G) == NULL ) OR SPTbit(S,G)) {
> send RegisterStop(S,G) to outer.src
> } else {
> --> /* Moved restarting the timer over here */
> restart KeepaliveTimer(S,G)
> if( ! pkt.NullRegisterBit ) {
> decapsulate and pass the inner packet to the normal
> forwarding path for forwarding on the (*,G) tree.
> }
> }
> } else {
> send RegisterStop(S,G) to outer.src
> # Note (*)
> }
> }
>
> Basically what i would like to do is restart the keepalivetimer only if
> there are interested listeners for this group G at the RP. I guess the
> behaviour would be that, the SPT from RP to S would be created only when
> someone joins the RPT. Once the SPT is created the SPTbit would be set and
> the KeepAlivetimer would be restarted by the forwarding pseudocode. This
> also would imply that SPT would not be formed unless someone joined the RPT.
>
>
> I was just wondering if such an modification is ok. Would this affect the
> functioning of the protocol in any other way? Also is the delay in forming
> SPT after receivers join the RPT acceptable? Would this lead to any black
> holes?
>
> Would appreciate comments on this.
>
> Thanks and regards,
> Sarvesh
>
>
> Sarveshwar Bandi
>
> Senior Member, Technical Staff
> Netplane Network Technologies (India) Pvt. Ltd.
> http://www.netplane.com
> Ph: +91-40-355 3709/10/11/12 Extn: 1126
> Fax: +91-40-355 3713
>
> _______________________________________________
> pim mailing list
> pim@catarina.usc.edu
> http://catarina.usc.edu/mailman/listinfo/pim
_______________________________________________
pim mailing list
pim@catarina.usc.edu
http://catarina.usc.edu/mailman/listinfo/pim
From pim-admin@catarina.usc.edu Thu Dec 12 08:08:48 2002
Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21850
for ; Thu, 12 Dec 2002 08:08:47 -0500 (EST)
Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1])
by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gBCD3lD85634;
Thu, 12 Dec 2002 05:03:47 -0800 (PST)
(envelope-from pim-admin@catarina.usc.edu)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gBCD1RD85594
for ; Thu, 12 Dec 2002 05:01:27 -0800 (PST)
(envelope-from nsyracus@cnri.reston.va.us)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21651;
Thu, 12 Dec 2002 08:02:21 -0500 (EST)
Message-Id: <200212121302.IAA21651@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: [pim] I-D ACTION:draft-ietf-pim-sm-v2-new-06.txt,.ps
Sender: pim-admin@catarina.usc.edu
Errors-To: pim-admin@catarina.usc.edu
X-BeenThere: pim@catarina.usc.edu
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Unsubscribe: ,
List-Id:
List-Post:
List-Help:
List-Subscribe: ,
List-Archive:
Date: Thu, 12 Dec 2002 08:02:20 -0500
--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 (Revised)
Author(s) : B. Fenner, M. Handley, H. Holbrook, I. Kouvelas
Filename : draft-ietf-pim-sm-v2-new-06.txt,.ps
Pages : 138
Date : 2002-12-11
This document specifies Protocol Independent Multicast -
Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol
that can use the underlying unicast routing information base
or a separate multicast-capable routing information base. It
builds unidirectional shared trees rooted at a Rendezvous
Point (RP) per group, and optionally creates shortest-path
trees per source.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pim-sm-v2-new-06.txt
To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.
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-sm-v2-new-06.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-sm-v2-new-06.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: <2002-12-11132841.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-pim-sm-v2-new-06.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pim-sm-v2-new-06.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <2002-12-11132841.I-D@ietf.org>
--OtherAccess--
--NextPart--
_______________________________________________
pim mailing list
pim@catarina.usc.edu
http://catarina.usc.edu/mailman/listinfo/pim
From pim-admin@catarina.usc.edu Fri Dec 13 19:24:27 2002
Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11095
for ; Fri, 13 Dec 2002 19:24:26 -0500 (EST)
Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1])
by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gBE0IvD10853;
Fri, 13 Dec 2002 16:18:57 -0800 (PST)
(envelope-from pim-admin@catarina.usc.edu)
Received: from web14505.mail.yahoo.com (web14505.mail.yahoo.com [216.136.224.68])
by catarina.usc.edu (8.11.6/8.11.6) with SMTP id gBE0GTD10817
for ; Fri, 13 Dec 2002 16:16:29 -0800 (PST)
(envelope-from dingping20002@yahoo.com)
Message-ID: <20021214002032.89313.qmail@web14505.mail.yahoo.com>
Received: from [129.210.16.144] by web14505.mail.yahoo.com via HTTP; Fri, 13 Dec 2002 16:20:32 PST
From: Ping Ding
To: pim@catarina.usc.edu
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-993122539-1039825232=:88281"
Subject: [pim] centralized multicast
Sender: pim-admin@catarina.usc.edu
Errors-To: pim-admin@catarina.usc.edu
X-BeenThere: pim@catarina.usc.edu
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Unsubscribe: ,
List-Id:
List-Post:
List-Help:
List-Subscribe: ,
List-Archive:
Date: Fri, 13 Dec 2002 16:20:32 -0800 (PST)
--0-993122539-1039825232=:88281
Content-Type: text/plain; charset=us-ascii
Hi,
Sorry for I will ask some stupid questions!
I am working on wired-cum-wireless model. I tried to realize broadcast between a Base-station and it's mobile-nodes. I just used centralized multicast to send packet for wired nodes to mobile-nodes. I always got some error. For example, cache miss, protocol(-1). Does anyone have such experence?
Please give me some suggestion!
Thanks a lot!
Ping Ding
---------------------------------
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now
--0-993122539-1039825232=:88281
Content-Type: text/html; charset=us-ascii
Hi,
Sorry for I will ask some stupid questions!
I am working on wired-cum-wireless model. I tried to realize broadcast between a Base-station and it's mobile-nodes. I just used centralized multicast to send packet for wired nodes to mobile-nodes. I always got some error. For example, cache miss, protocol(-1). Does anyone have such experence?
Please give me some suggestion!
Thanks a lot!
Ping Ding
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now
--0-993122539-1039825232=:88281--
_______________________________________________
pim mailing list
pim@catarina.usc.edu
http://catarina.usc.edu/mailman/listinfo/pim
From pim-admin@catarina.usc.edu Tue Dec 17 09:33:18 2002
Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14584
for ; Tue, 17 Dec 2002 09:33:16 -0500 (EST)
Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1])
by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gBHER1D72824;
Tue, 17 Dec 2002 06:27:01 -0800 (PST)
(envelope-from pim-admin@catarina.usc.edu)
Received: from xmxpita.excite.com (nn2.excitenetwork.com [207.159.120.56])
by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gBHENWD72768
for ; Tue, 17 Dec 2002 06:23:33 -0800 (PST)
(envelope-from smiley_raj@excite.com)
Received: by xmxpita.excite.com (Postfix, from userid 110)
id 35B8D1340C; Tue, 17 Dec 2002 09:28:00 -0500 (EST)
To: pim@catarina.usc.edu
Received: from [203.197.138.201] by xprdmailfe5.nwk.excite.com via HTTP; Tue, 17 Dec 2002 09:28:00 EST
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: ID = 60d69fc2429ac082130bd7435bf518fd
Reply-To: smiley_raj@excite.com
From: "smiley_raj@excite.com"
MIME-Version: 1.0
X-Sender: smiley_raj@excite.com
X-Mailer: PHP
Content-Type: multipart/alternative; boundary="EXCITEBOUNDARY_000__3168d51001d713bf405627029e4497a2";
Content-Transfer-Encoding: 7bit
Message-Id: <20021217142800.35B8D1340C@xmxpita.excite.com>
Subject: [pim] doubt regard RP absence in the network
Sender: pim-admin@catarina.usc.edu
Errors-To: pim-admin@catarina.usc.edu
X-BeenThere: pim@catarina.usc.edu
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Unsubscribe: ,
List-Id:
List-Post:
List-Help:
List-Subscribe: ,
List-Archive:
Date: Tue, 17 Dec 2002 09:28:00 -0500 (EST)
--EXCITEBOUNDARY_000__3168d51001d713bf405627029e4497a2
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Hi,
I have the following doubt,
If there is no RP in the network or all the RPs expire in the network. Can there be packet forwarding activity in a PIM-SM (only) domain. In clear my doubt is can the receivers switched over to the packet forwarding via SPT still continue to receive the data packets even if there is not RP information with him.
thanks in advance
rajesh,
_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!
--EXCITEBOUNDARY_000__3168d51001d713bf405627029e4497a2
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Hi,
I have the following doubt,
If there is no RP in the network or all the RPs expire in the network. Can there be packet forwarding activity in a PIM-SM (only) domain. In clear my doubt is can the receivers switched over to the packet forwarding via SPT still continue to receive the data packets even if there is not RP information with him.
thanks in advance
rajesh,
Join Excite! - http://www.excite.com
The most personalized portal on the Web!
--EXCITEBOUNDARY_000__3168d51001d713bf405627029e4497a2--
_______________________________________________
pim mailing list
pim@catarina.usc.edu
http://catarina.usc.edu/mailman/listinfo/pim
From pim-admin@catarina.usc.edu Tue Dec 17 10:09:52 2002
Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15237
for ; Tue, 17 Dec 2002 10:09:52 -0500 (EST)
Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1])
by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gBHF4lD73293;
Tue, 17 Dec 2002 07:04:47 -0800 (PST)
(envelope-from pim-admin@catarina.usc.edu)
Received: from web8207.mail.in.yahoo.com (web8207.mail.in.yahoo.com [203.199.70.76])
by catarina.usc.edu (8.11.6/8.11.6) with SMTP id gBHF3dD73273
for ; Tue, 17 Dec 2002 07:03:39 -0800 (PST)
(envelope-from jaganbabu_pim@yahoo.co.in)
Message-ID: <20021217150807.33006.qmail@web8207.mail.in.yahoo.com>
Received: from [12.27.183.253] by web8207.mail.in.yahoo.com via HTTP; Tue, 17 Dec 2002 15:08:07 GMT
From: =?iso-8859-1?q?Rajamanickam=20jaganbabu?=
Subject: Re: [pim] doubt regard RP absence in the network
To: smiley_raj@excite.com, pim@catarina.usc.edu
In-Reply-To: <20021217142800.35B8D1340C@xmxpita.excite.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-666609526-1040137687=:28395"
Content-Transfer-Encoding: 8bit
Sender: pim-admin@catarina.usc.edu
Errors-To: pim-admin@catarina.usc.edu
X-BeenThere: pim@catarina.usc.edu
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Unsubscribe: ,
List-Id:
List-Post:
List-Help:
List-Subscribe: ,
List-Archive:
Date: Tue, 17 Dec 2002 15:08:07 +0000 (GMT)
--0-666609526-1040137687=:28395
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Hi rajesh,
If the receiver and the source has the Source Path Tree established (i.e if we have (S,G) entry in the Multicast forwarding table), then irrespective of the RP information availability, the multicast packet will be forwarded.
I hope the above information will help you, if i have understood your question correctly.
Regards,
Jags
"smiley_raj@excite.com" wrote:Hi,
I have the following doubt,
If there is no RP in the network or all the RPs expire in the network. Can there be packet forwarding activity in a PIM-SM (only) domain. In clear my doubt is can the receivers switched over to the packet forwarding via SPT still continue to receive the data packets even if there is not RP information with him.
thanks in advance
rajesh,
---------------------------------
Join Excite! - http://www.excite.com
The most personalized portal on the Web!
Catch all the cricket action. Download Yahoo! Score tracker
--0-666609526-1040137687=:28395
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Hi rajesh,
If the receiver and the source has the Source Path Tree established (i.e if we have (S,G) entry in the Multicast forwarding table), then irrespective of the RP information availability, the multicast packet will be forwarded.
I hope the above information will help you, if i have understood your question correctly.
Regards,
Jags
"smiley_raj@excite.com" <smiley_raj@excite.com> wrote:
Hi,
I have the following doubt,
If there is no RP in the network or all the RPs expire in the network. Can there be packet forwarding activity in a PIM-SM (only) domain. In clear my doubt is can the receivers switched over to the packet forwarding via SPT still continue to receive the data packets even if there is not RP information with him.
thanks in advance
rajesh,
Join Excite! - http://www.excite.com
The most personalized portal on the Web!
Catch all the cricket action. Download
Yahoo! Score tracker
--0-666609526-1040137687=:28395--
_______________________________________________
pim mailing list
pim@catarina.usc.edu
http://catarina.usc.edu/mailman/listinfo/pim
From pim-admin@catarina.usc.edu Tue Dec 17 11:05:04 2002
Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16384
for ; Tue, 17 Dec 2002 11:05:03 -0500 (EST)
Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1])
by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gBHFxcD74010;
Tue, 17 Dec 2002 07:59:38 -0800 (PST)
(envelope-from pim-admin@catarina.usc.edu)
Received: from fsnt.future.futsoft.com ([203.197.140.35])
by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gBHFwRD73982
for ; Tue, 17 Dec 2002 07:58:28 -0800 (PST)
(envelope-from umac@future.futsoft.com)
Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com
(Content Technologies SMTPRS 2.0.15) with ESMTP id ;
Tue, 17 Dec 2002 21:36:39 +0530
Received: from umac (umac.future.futsoft.com [10.20.6.25])
by kailash.future.futsoft.com (8.12.2/8.12.2) with SMTP id gBHG0ICJ013761;
Tue, 17 Dec 2002 21:30:19 +0530
Reply-To:
From: "Uma C"
To: "'Rajamanickam jaganbabu'"
Cc: ,
Subject: RE: [pim] doubt regard RP absence in the network
Message-Id: <000f01c2a5e7$e936b420$1906140a@future.futsoft.com>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <20021217150807.33006.qmail@web8207.mail.in.yahoo.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0010_01C2A616.02EEF020"
Sender: pim-admin@catarina.usc.edu
Errors-To: pim-admin@catarina.usc.edu
X-BeenThere: pim@catarina.usc.edu
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Unsubscribe: ,
List-Id:
List-Post:
List-Help:
List-Subscribe: ,
List-Archive:
Date: Tue, 17 Dec 2002 21:48:17 +0530
This is a multi-part message in MIME format.
------=_NextPart_000_0010_01C2A616.02EEF020
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Hello Jags
When there is no RP information -
1. (*,G) entry would surely get deleted. Outgoing interface in that (*,G)
and (S,G) also gets deleted. So how are the packets still flowing ?
2. If the (*,G) entry alone gets deleted because of the RP information not
present and when the receiver leave the group, will the (S,G) entry get
deleted ?. If yes how ? On what basis will this (S,G) entry get deleted.
I guess the entries at SPT built routers would get deleted only when source
of the multicast packet stops sending packets.
I feel that, when the (*,G) entry gets deleted, (S,G) entry also would be
deleted and there want be a case in which multicast packets will be flowing.
Well I haven't thought about SSM case.
Pl correct me if I am in wrong in my understanding.
Thanks & Regards
C.Uma
-----Original Message-----
From: pim-admin@catarina.usc.edu [mailto:pim-admin@catarina.usc.edu]On
Behalf Of Rajamanickam jaganbabu
Sent: Tuesday, December 17, 2002 8:38 PM
To: smiley_raj@excite.com; pim@catarina.usc.edu
Subject: Re: [pim] doubt regard RP absence in the network
Hi rajesh,
If the receiver and the source has the Source Path Tree established (i.e
if we have (S,G) entry in the Multicast forwarding table), then irrespective
of the RP information availability, the multicast packet will be forwarded.
I hope the above information will help you, if i have understood your
question correctly.
Regards,
Jags
"smiley_raj@excite.com" wrote:
Hi,
I have the following doubt,
If there is no RP in the network or all the RPs expire in the network.
Can there be packet forwarding activity in a PIM-SM (only) domain. In clear
my doubt is can the receivers switched over to the packet forwarding via SPT
still continue to receive the data packets even if there is not RP
information with him.
thanks in advance
rajesh,
----------------------------------------------------------------------------
Join Excite! - http://www.excite.com
The most personalized portal on the Web!
Catch all the cricket action. Download Yahoo! Score tracker
***************************************************************************
This message is proprietary to Future Software Limited (FSL)
and is intended solely for the use of the individual to whom it
is addressed. It may contain privileged or confidential information
and should not be circulated or used for any purpose other than for
what it is intended.
If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message.
FSL accepts no responsibility for loss or damage arising from
the use of the information transmitted by this email including
damage from virus.
***************************************************************************
------=_NextPart_000_0010_01C2A616.02EEF020
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello=20
Jags
When=20
there is no RP information -
1.=20
(*,G) entry would surely get deleted. Outgoing interface in that =
(*,G) and=20
(S,G) also gets deleted. So how are the packets still flowing=20
?
2. If=20
the (*,G) entry alone gets deleted because of the RP information not =
present and=20
when the receiver leave the group, will the (S,G) entry get deleted ?. =
If yes=20
how ? On what basis will this (S,G) entry get =
deleted.
I=20
guess the entries at SPT built routers would get deleted only=20
when source of the multicast packet stops sending=20
packets.
I feel=20
that, when the (*,G) entry gets deleted, (S,G) entry also would be =
deleted and=20
there want be a case in which multicast packets will be flowing. Well I =
haven't=20
thought about SSM case.
Pl=20
correct me if I am in wrong in my understanding.
Thanks=20
& Regards
C.Uma
Hi rajesh,=20
If the receiver and the source has the Source Path Tree =
established=20
(i.e if we have (S,G) entry in the Multicast forwarding table), then=20
irrespective of the RP information availability, the multicast packet =
will be=20
forwarded.=20
I hope the above information will help you, if i have =
understood=20
your question correctly.=20
Regards,=20
Jags=20
"smiley_raj@excite.com" =
<smiley_raj@excite.com>=20
wrote:=20
Hi,
I=20
have the following doubt,
If there is no RP in the network or =
all the=20
RPs expire in the network. Can there be packet forwarding activity =
in a=20
PIM-SM (only) domain. In clear my doubt is can the receivers =
switched over=20
to the packet forwarding via SPT still continue to receive the data =
packets=20
even if there is not RP information with him.
thanks in=20
advance
rajesh,
Join Excite! - http://www.excite.com
The most =
personalized portal=20
on the Web!
Catch all the cricket action. Download Yahoo!=20
Score tracker
------=_NextPart_000_0010_01C2A616.02EEF020--
_______________________________________________
pim mailing list
pim@catarina.usc.edu
http://catarina.usc.edu/mailman/listinfo/pim
From pim-admin@catarina.usc.edu Tue Dec 17 23:07:47 2002
Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01627
for ; Tue, 17 Dec 2002 23:07:46 -0500 (EST)
Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1])
by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gBI422D82586;
Tue, 17 Dec 2002 20:02:02 -0800 (PST)
(envelope-from pim-admin@catarina.usc.edu)
Received: from xprdmailfe28.nwk.excite.com (nn8.excitenetwork.com [207.159.120.62])
by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gBI40YD82557
for ; Tue, 17 Dec 2002 20:00:34 -0800 (PST)
(envelope-from smiley_raj@excite.com)
Received: by xprdmailfe28.nwk.excite.com (Postfix, from userid 110)
id 0D6FFE520; Tue, 17 Dec 2002 23:05:02 -0500 (EST)
To: pim@catarina.usc.edu
Subject: RE: [pim] doubt regard RP absence in the network
Received: from [203.197.138.201] by xprdmailfe28.nwk.excite.com via HTTP; Tue, 17 Dec 2002 23:05:02 EST
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: ID = 60d69fc2429ac082130bd7435bf518fd
Reply-To: smiley_raj@excite.com
From: "smiley_raj@excite.com"
MIME-Version: 1.0
X-Sender: smiley_raj@excite.com
X-Mailer: PHP
Content-Type: multipart/alternative; boundary="EXCITEBOUNDARY_000__2121f719c7ebf4b518766c6be59b031e";
Content-Transfer-Encoding: 7bit
Message-Id: <20021218040502.0D6FFE520@xprdmailfe28.nwk.excite.com>
Sender: pim-admin@catarina.usc.edu
Errors-To: pim-admin@catarina.usc.edu
X-BeenThere: pim@catarina.usc.edu
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Unsubscribe: ,
List-Id:
List-Post:
List-Help:
List-Subscribe: ,
List-Archive:
Date: Tue, 17 Dec 2002 23:05:02 -0500 (EST)
--EXCITEBOUNDARY_000__2121f719c7ebf4b518766c6be59b031e
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Hi,
If you would see the macros pim_include(S, G) and pim_include(*, G).
They have a procedure through which the oifs can have a state established.
If iam correct it is through local_receiver_include, local_receiver_exclude mechanisms but with some other constraints also.
I will narrow my doubt now, will local_receive_include(S, G, I) for a particular source be true if I receive a IGMPv2 Join?
Logically seeing it should be valid for all sources. And hence packet flow should be there even when the RP is unavailable.
The answer to question on what basis the (S, G) entry would be deleted ( or (S, G) state goes to NI state) may be like this.
In the same way as local_receiver_include(S, G, I) is processed on (S, G) local_receiver_exclude(S, G, I) also should be processed for an IGMPv2 Leave.
Iam sorry for any mistakes in the answers above.
T & R
Rajesh Nataraja
--- On Tue 12/17, Uma C wrote:From: Uma C [mailto: umac@future.futsoft.com]To: jaganbabu_pim@yahoo.co.in Cc: smiley_raj@excite.com, pim@catarina.usc.eduDate: Tue, 17 Dec 2002 21:48:17 +0530Subject: RE: [pim] doubt regard RP absence in the network
Hello
Jags
When
there is no RP information -
1.
(*,G) entry would surely get deleted. Outgoing interface in that (*,G) and
(S,G) also gets deleted. So how are the packets still flowing
?
2. If
the (*,G) entry alone gets deleted because of the RP information not present and
when the receiver leave the group, will the (S,G) entry get deleted ?. If yes
how ? On what basis will this (S,G) entry get deleted.
I
guess the entries at SPT built routers would get deleted only
when source of the multicast packet stops sending
packets.
I feel
that, when the (*,G) entry gets deleted, (S,G) entry also would be deleted and
there want be a case in which multicast packets will be flowing. Well I haven't
thought about SSM case.
Pl
correct me if I am in wrong in my understanding.
Thanks
& Regards
C.Uma
-----Original Message-----From: pim-admin@catarina.usc.edu
[mailto:pim-admin@catarina.usc.edu]On Behalf Of Rajamanickam
jaganbabuSent: Tuesday, December 17, 2002 8:38 PMTo:
smiley_raj@excite.com; pim@catarina.usc.eduSubject: Re: [pim] doubt
regard RP absence in the network
Hi rajesh,
If the receiver and the source has the Source Path Tree established
(i.e if we have (S,G) entry in the Multicast forwarding table), then
irrespective of the RP information availability, the multicast packet will be
forwarded.
I hope the above information will help you, if i have understood
your question correctly.
Regards,
Jags
"smiley_raj@excite.com"
wrote:
Hi,I
have the following doubt,If there is no RP in the network or all the
RPs expire in the network. Can there be packet forwarding activity in a
PIM-SM (only) domain. In clear my doubt is can the receivers switched over
to the packet forwarding via SPT still continue to receive the data packets
even if there is not RP information with him.thanks in
advancerajesh,
Join Excite! - http://www.excite.comThe most personalized portal
on the Web!
Catch all the cricket action. Download Yahoo!
Score tracker
_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!
--EXCITEBOUNDARY_000__2121f719c7ebf4b518766c6be59b031e
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Hi,
If you would see the macros pim_include(S, G) and pim_include(*, G).
They have a procedure through which the oifs can have a state established.
If iam correct it is through local_receiver_include, local_receiver_exclude mechanisms but with some other constraints also.
I will narrow my doubt now, will local_receive_include(S, G, I) for a particular source be true if I receive a IGMPv2 Join?
Logically seeing it should be valid for all sources. And hence packet flow should be there even when the RP is unavailable.
The answer to question on what basis the (S, G) entry would be deleted ( or (S, G) state goes to NI state) may be like this.
In the same way as local_receiver_include(S, G, I) is processed on (S, G) local_receiver_exclude(S, G, I) also should be processed for an IGMPv2 Leave.
Iam sorry for any mistakes in the answers above.
T & R
Rajesh Nataraja
--- On Tue 12/17, Uma C < umac@future.futsoft.com > wrote:
From: Uma C [mailto: umac@future.futsoft.com]
To: jaganbabu_pim@yahoo.co.in
Cc: smiley_raj@excite.com, pim@catarina.usc.edu
Date: Tue, 17 Dec 2002 21:48:17 +0530
Subject: RE: [pim] doubt regard RP absence in the network
Hello
Jags
When
there is no RP information -
1.
(*,G) entry would surely get deleted. Outgoing interface in that (*,G) and
(S,G) also gets deleted. So how are the packets still flowing
?
2. If
the (*,G) entry alone gets deleted because of the RP information not present and
when the receiver leave the group, will the (S,G) entry get deleted ?. If yes
how ? On what basis will this (S,G) entry get deleted.
I
guess the entries at SPT built routers would get deleted only
when source of the multicast packet stops sending
packets.
I feel
that, when the (*,G) entry gets deleted, (S,G) entry also would be deleted and
there want be a case in which multicast packets will be flowing. Well I haven't
thought about SSM case.
Pl
correct me if I am in wrong in my understanding.
Thanks
& Regards
C.Uma
Hi rajesh,
If the receiver and the source has the Source Path Tree established
(i.e if we have (S,G) entry in the Multicast forwarding table), then
irrespective of the RP information availability, the multicast packet will be
forwarded.
I hope the above information will help you, if i have understood
your question correctly.
Regards,
Jags
"smiley_raj@excite.com"
wrote:
Hi,
I
have the following doubt,
If there is no RP in the network or all the
RPs expire in the network. Can there be packet forwarding activity in a
PIM-SM (only) domain. In clear my doubt is can the receivers switched over
to the packet forwarding via SPT still continue to receive the data packets
even if there is not RP information with him.
thanks in
advance
rajesh,
Join Excite! - http://www.excite.com
The most personalized portal
on the Web!
Catch all the cricket action. Download Yahoo!
Score tracker
Join Excite! - http://www.excite.com
The most personalized portal on the Web!
--EXCITEBOUNDARY_000__2121f719c7ebf4b518766c6be59b031e--
_______________________________________________
pim mailing list
pim@catarina.usc.edu
http://catarina.usc.edu/mailman/listinfo/pim
From pim-admin@catarina.usc.edu Wed Dec 18 00:47:49 2002
Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03321
for ; Wed, 18 Dec 2002 00:47:48 -0500 (EST)
Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1])
by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gBI5gYD83769;
Tue, 17 Dec 2002 21:42:34 -0800 (PST)
(envelope-from pim-admin@catarina.usc.edu)
Received: from web8202.mail.in.yahoo.com (web8202.mail.in.yahoo.com [203.199.70.115])
by catarina.usc.edu (8.11.6/8.11.6) with SMTP id gBI5fBD83739
for ; Tue, 17 Dec 2002 21:41:11 -0800 (PST)
(envelope-from jaganbabu_pim@yahoo.co.in)
Message-ID: <20021218054543.39195.qmail@web8202.mail.in.yahoo.com>
Received: from [12.27.183.253] by web8202.mail.in.yahoo.com via HTTP; Wed, 18 Dec 2002 05:45:43 GMT
From: =?iso-8859-1?q?Rajamanickam=20jaganbabu?=
Subject: RE: [pim] doubt regard RP absence in the network
To: umac@future.futsoft.com
Cc: smiley_raj@excite.com, pim@catarina.usc.edu
In-Reply-To: <000f01c2a5e7$e936b420$1906140a@future.futsoft.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1001864326-1040190343=:36298"
Content-Transfer-Encoding: 8bit
Sender: pim-admin@catarina.usc.edu
Errors-To: pim-admin@catarina.usc.edu
X-BeenThere: pim@catarina.usc.edu
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Unsubscribe: ,
List-Id:
List-Post:
List-Help:
List-Subscribe: ,
List-Archive:
Date: Wed, 18 Dec 2002 05:45:43 +0000 (GMT)
--0-1001864326-1040190343=:36298
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Hi Uma,
If there is an IGMPV3 request from the receiver, asking for (S,G,I) join to a particular source, then we will be having an (S,G) entry, which will be the super set of (*,G) outgoing list. If we lost (*,G) information, then it will affect (S,G) inherited outgoing list but there is a possible case where we can have immediate outgoing list exist for (S,G) (which is not in inherited outgoing list), so at this point even we delete (*,G) entry from our multicast forwarding table still (S,G) entry will be existing in the multicast forwarding table.
So my conclusion is, in the above case even if we lost our RP information, still we can forward the multicast packet using (S,G) information for a source "S".
Thanx,
Jags
Uma C wrote:Hello Jags When there is no RP information -1. (*,G) entry would surely get deleted. Outgoing interface in that (*,G) and (S,G) also gets deleted. So how are the packets still flowing ?2. If the (*,G) entry alone gets deleted because of the RP information not present and when the receiver leave the group, will the (S,G) entry get deleted ?. If yes how ? On what basis will this (S,G) entry get deleted.I guess the entries at SPT built routers would get deleted only when source of the multicast packet stops sending packets. I feel that, when the (*,G) entry gets deleted, (S,G) entry also would be deleted and there want be a case in which multicast packets will be flowing. Well I haven't thought about SSM case. Pl correct me if I am in wrong in my understanding. Thanks & RegardsC.Uma -----Original Message-----
From: pim-admin@catarina.usc.edu [mailto:pim-admin@catarina.usc.edu]On Behalf Of Rajamanickam jaganbabu
Sent: Tuesday, December 17, 2002 8:38 PM
To: smiley_raj@excite.com; pim@catarina.usc.edu
Subject: Re: [pim] doubt regard RP absence in the network
Hi rajesh,
If the receiver and the source has the Source Path Tree established (i.e if we have (S,G) entry in the Multicast forwarding table), then irrespective of the RP information availability, the multicast packet will be forwarded.
I hope the above information will help you, if i have understood your question correctly.
Regards,
Jags
"smiley_raj@excite.com" wrote: Hi,
I have the following doubt,
If there is no RP in the network or all the RPs expire in the network. Can there be packet forwarding activity in a PIM-SM (only) domain. In clear my doubt is can the receivers switched over to the packet forwarding via SPT still continue to receive the data packets even if there is not RP information with him.
thanks in advance
rajesh,
---------------------------------
Join Excite! - http://www.excite.com
The most personalized portal on the Web!
Catch all the cricket action. Download Yahoo! Score tracker
Catch all the cricket action. Download Yahoo! Score tracker
--0-1001864326-1040190343=:36298
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Hi Uma,
If there is an IGMPV3 request from the receiver, asking for (S,G,I) join to a particular source, then we will be having an (S,G) entry, which will be the super set of (*,G) outgoing list. If we lost (*,G) information, then it will affect (S,G) inherited outgoing list but there is a possible case where we can have immediate outgoing list exist for (S,G) (which is not in inherited outgoing list), so at this point even we delete (*,G) entry from our multicast forwarding table still (S,G) entry will be existing in the multicast forwarding table.
So my conclusion is, in the above case even if we lost our RP information, still we can forward the multicast packet using (S,G) information for a source "S".
Thanx,
Jags
Uma C <umac@future.futsoft.com> wrote:
Hello Jags
When there is no RP information -
1. (*,G) entry would surely get deleted. Outgoing interface in that (*,G) and (S,G) also gets deleted. So how are the packets still flowing ?
2. If the (*,G) entry alone gets deleted because of the RP information not present and when the receiver leave the group, will the (S,G) entry get deleted ?. If yes how ? On what basis will this (S,G) entry get deleted.
I guess the entries at SPT built routers would get deleted only when source of the multicast packet stops sending packets.
I feel that, when the (*,G) entry gets deleted, (S,G) entry also would be deleted and there want be a case in which multicast packets will be flowing. Well I haven't thought about SSM case.
Pl correct me if I am in wrong in my understanding.
Thanks & Regards
C.Uma
Hi rajesh,
If the receiver and the source has the Source Path Tree established (i.e if we have (S,G) entry in the Multicast forwarding table), then irrespective of the RP information availability, the multicast packet will be forwarded.
I hope the above information will help you, if i have understood your question correctly.
Regards,
Jags
"smiley_raj@excite.com" <smiley_raj@excite.com> wrote:
Hi,
I have the following doubt,
If there is no RP in the network or all the RPs expire in the network. Can there be packet forwarding activity in a PIM-SM (only) domain. In clear my doubt is can the receivers switched over to the packet forwarding via SPT still continue to receive the data packets even if there is not RP information with him.
thanks in advance
rajesh,
Join Excite! - http://www.excite.com
The most personalized portal on the Web!
Catch all the cricket action. Download Yahoo! Score tracker
Catch all the cricket action. Download
Yahoo! Score tracker
--0-1001864326-1040190343=:36298--
_______________________________________________
pim mailing list
pim@catarina.usc.edu
http://catarina.usc.edu/mailman/listinfo/pim
From pim-admin@catarina.usc.edu Wed Dec 18 02:04:05 2002
Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09547
for ; Wed, 18 Dec 2002 02:04:04 -0500 (EST)
Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1])
by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gBI6wZD84656;
Tue, 17 Dec 2002 22:58:35 -0800 (PST)
(envelope-from pim-admin@catarina.usc.edu)
Received: from fsnt.future.futsoft.com ([203.197.140.35])
by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gBI6v3D84628
for ; Tue, 17 Dec 2002 22:57:04 -0800 (PST)
(envelope-from umac@future.futsoft.com)
Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com
(Content Technologies SMTPRS 2.0.15) with ESMTP id ;
Wed, 18 Dec 2002 12:34:18 +0530
Received: from umac (umac.future.futsoft.com [10.20.6.25])
by kailash.future.futsoft.com (8.12.2/8.12.2) with SMTP id gBI6quCJ024301;
Wed, 18 Dec 2002 12:22:56 +0530
Reply-To:
From: "Uma C"
To: "'Rajamanickam jaganbabu'"
Cc: ,
Subject: RE: [pim] doubt regard RP absence in the network
Message-Id: <001101c2a664$9e2d3b20$1906140a@future.futsoft.com>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <20021218054543.39195.qmail@web8202.mail.in.yahoo.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0012_01C2A692.B7E57720"
Sender: pim-admin@catarina.usc.edu
Errors-To: pim-admin@catarina.usc.edu
X-BeenThere: pim@catarina.usc.edu
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Unsubscribe: ,
List-Id:
List-Post:
List-Help:
List-Subscribe: ,
List-Archive:
Date: Wed, 18 Dec 2002 12:40:59 +0530
This is a multi-part message in MIME format.
------=_NextPart_000_0012_01C2A692.B7E57720
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Hello Jags
I guess in the case of IGMPv3, we do not create any (*,G) entry as the Group
range for SSM is different. And as you said we can still forward the packets
whether there is RP information or not.
But in the case of SM only, where (*,G) and (S,G) entry exists and (S,G)
entry holds the oif of the (*,G), if the RP information is not present -
* (*,G) will be deleted and oif learnt from (*,G) will be deleted from (S,G)
also, irrespective of whether local receivers present or not.
* When the RP information is learnt again, (*,G) entry would be re-created
if the receivers are still present.
Do you still think if RP information is not present (in the case of SM
only), multicast packets would flow ?
Thanks & Regards
C.Uma
-----Original Message-----
From: Rajamanickam jaganbabu [mailto:jaganbabu_pim@yahoo.co.in]
Sent: Wednesday, December 18, 2002 11:16 AM
To: umac@future.futsoft.com
Cc: smiley_raj@excite.com; pim@catarina.usc.edu
Subject: RE: [pim] doubt regard RP absence in the network
Hi Uma,
If there is an IGMPV3 request from the receiver, asking for (S,G,I) join
to a particular source, then we will be having an (S,G) entry, which will be
the super set of (*,G) outgoing list. If we lost (*,G) information, then it
will affect (S,G) inherited outgoing list but there is a possible case where
we can have immediate outgoing list exist for (S,G) (which is not in
inherited outgoing list), so at this point even we delete (*,G) entry from
our multicast forwarding table still (S,G) entry will be existing in the
multicast forwarding table.
So my conclusion is, in the above case even if we lost our RP information,
still we can forward the multicast packet using (S,G) information for a
source "S".
Thanx,
Jags
Uma C wrote:
Hello Jags
When there is no RP information -
1. (*,G) entry would surely get deleted. Outgoing interface in that
(*,G) and (S,G) also gets deleted. So how are the packets still flowing ?
2. If the (*,G) entry alone gets deleted because of the RP information
not present and when the receiver leave the group, will the (S,G) entry get
deleted ?. If yes how ? On what basis will this (S,G) entry get deleted.
I guess the entries at SPT built routers would get deleted only when
source of the multicast packet stops sending packets.
I feel that, when the (*,G) entry gets deleted, (S,G) entry also would
be deleted and there want be a case in which multicast packets will be
flowing. Well I haven't thought about SSM case.
Pl correct me if I am in wrong in my understanding.
Thanks & Regards
C.Uma
-----Original Message-----
From: pim-admin@catarina.usc.edu [mailto:pim-admin@catarina.usc.edu]On
Behalf Of Rajamanickam jaganbabu
Sent: Tuesday, December 17, 2002 8:38 PM
To: smiley_raj@excite.com; pim@catarina.usc.edu
Subject: Re: [pim] doubt regard RP absence in the network
Hi rajesh,
If the receiver and the source has the Source Path Tree established
(i.e if we have (S,G) entry in the Multicast forwarding table), then
irrespective of the RP information availability, the multicast packet will
be forwarded.
I hope the above information will help you, if i have understood
your question correctly.
Regards,
Jags
"smiley_raj@excite.com" wrote:
Hi,
I have the following doubt,
If there is no RP in the network or all the RPs expire in the
network. Can there be packet forwarding activity in a PIM-SM (only) domain.
In clear my doubt is can the receivers switched over to the packet
forwarding via SPT still continue to receive the data packets even if there
is not RP information with him.
thanks in advance
rajesh,
------------------------------------------------------------------------
Join Excite! - http://www.excite.com
The most personalized portal on the Web!
Catch all the cricket action. Download Yahoo! Score tracker
Catch all the cricket action. Download Yahoo! Score tracker
***************************************************************************
This message is proprietary to Future Software Limited (FSL)
and is intended solely for the use of the individual to whom it
is addressed. It may contain privileged or confidential information
and should not be circulated or used for any purpose other than for
what it is intended.
If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message.
FSL accepts no responsibility for loss or damage arising from
the use of the information transmitted by this email including
damage from virus.
***************************************************************************
------=_NextPart_000_0012_01C2A692.B7E57720
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello=20
Jags
I=20
guess in the case of IGMPv3, we do not create any (*,G) entry as the =
Group range=20
for SSM is different. And as you said we can still forward the packets =
whether=20
there is RP information or not.
But in=20
the case of SM only, where (*,G) and (S,G) entry exists and (S,G) entry =
holds=20
the oif of the (*,G), if the RP information is not=20
present -
*=20
(*,G) will be deleted and oif learnt from (*,G) will be deleted from =
(S,G) also,=20
irrespective of whether local receivers present or =
not.
* When=20
the RP information is learnt again, (*,G) entry would be re-created if =
the=20
receivers are still present.
Do you=20
still think if RP information is not present (in the case of SM=20
only), multicast packets would flow ?
Thanks=20
& Regards
C.Uma
Hi Uma,
If there is an IGMPV3 request from the receiver, asking for (S,G,I) =
join to=20
a particular source, then we will be having an (S,G) entry, which will =
be the=20
super set of (*,G) outgoing list. If we lost (*,G) information, then =
it will=20
affect (S,G) inherited outgoing list but there is a possible case =
where we can=20
have immediate outgoing list exist for (S,G) (which is not in =
inherited=20
outgoing list), so at this point even we delete (*,G) entry from our =
multicast=20
forwarding table still (S,G) entry will be existing in the =
multicast=20
forwarding table.
So my conclusion is, in the above case even if we lost our RP =
information,=20
still we can forward the multicast packet using (S,G) information for =
a source=20
"S".
Thanx,
Jags
Uma C <umac@future.futsoft.com> wrote:=20
Hello Jags
When there is no RP information=20
-
1.=20
(*,G) entry would surely get deleted. Outgoing interface in =
that (*,G)=20
and (S,G) also gets deleted. So how are the packets still flowing=20
?
2.=20
If the (*,G) entry alone gets deleted because of the RP information =
not=20
present and when the receiver leave the group, will the (S,G) entry =
get=20
deleted ?. If yes how ? On what basis will this (S,G) entry get =
deleted.
I=20
guess the entries at SPT built routers would get deleted only=20
when source of the multicast packet stops sending=20
packets.
I=20
feel that, when the (*,G) entry gets deleted, (S,G) entry also would =
be=20
deleted and there want be a case in which multicast packets will be =
flowing.=20
Well I haven't thought about SSM case.
Pl=20
correct me if I am in wrong in my understanding.
Thanks & Regards
C.Uma
Hi rajesh,=20
If the receiver and the source has the Source Path Tree=20
established (i.e if we have (S,G) entry in the Multicast =
forwarding=20
table), then irrespective of the RP information availability, the=20
multicast packet will be forwarded.=20
I hope the above information will help you, if i have =
understood=20
your question correctly.=20
Regards,=20
Jags=20
"smiley_raj@excite.com"=20
<smiley_raj@excite.com> wrote:=20
Hi,
I=20
have the following doubt,
If there is no RP in the =
network or all=20
the RPs expire in the network. Can there be packet forwarding =
activity=20
in a PIM-SM (only) domain. In clear my doubt is can the =
receivers=20
switched over to the packet forwarding via SPT still continue to =
receive=20
the data packets even if there is not RP information with =
him.
thanks=20
in advance
rajesh,
Join Excite! - http://www.excite.com
The most =
personalized=20
portal on the Web!
Catch all the cricket action. Download Yahoo! Score =
tracker
Catch all the cricket action. Download Yahoo!=20
Score tracker
------=_NextPart_000_0012_01C2A692.B7E57720--
_______________________________________________
pim mailing list
pim@catarina.usc.edu
http://catarina.usc.edu/mailman/listinfo/pim
From pim-admin@catarina.usc.edu Wed Dec 18 03:12:03 2002
Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29361
for ; Wed, 18 Dec 2002 03:12:02 -0500 (EST)
Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1])
by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gBI86iD85577;
Wed, 18 Dec 2002 00:06:44 -0800 (PST)
(envelope-from pim-admin@catarina.usc.edu)
Received: from fsnt.future.futsoft.com ([203.197.140.35])
by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gBI85iD85557
for ; Wed, 18 Dec 2002 00:05:45 -0800 (PST)
(envelope-from umac@future.futsoft.com)
Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com
(Content Technologies SMTPRS 2.0.15) with ESMTP id ;
Wed, 18 Dec 2002 13:44:03 +0530
Received: from umac (umac.future.futsoft.com [10.20.6.25])
by kailash.future.futsoft.com (8.12.2/8.12.2) with SMTP id gBI87hCJ025634;
Wed, 18 Dec 2002 13:37:43 +0530
Reply-To:
From: "Uma C"
To:
Cc:
Subject: RE: [pim] doubt regard RP absence in the network
Message-Id: <001a01c2a66f$11465d80$1906140a@future.futsoft.com>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <20021218040502.0D6FFE520@xprdmailfe28.nwk.excite.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_001B_01C2A69D.2AFE9980"
Sender: pim-admin@catarina.usc.edu
Errors-To: pim-admin@catarina.usc.edu
X-BeenThere: pim@catarina.usc.edu
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Unsubscribe: ,
List-Id:
List-Post:
List-Help:
List-Subscribe: ,
List-Archive:
Date: Wed, 18 Dec 2002 13:55:47 +0530
This is a multi-part message in MIME format.
------=_NextPart_000_001B_01C2A69D.2AFE9980
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Hello Rajesh
Pl find my comments inlined with the tag .
In the case of SSM, I agree with what you had said. But in SM, I don't think
(S,G) entry would be present when (*,G) entries are getting deleted.
Regards
C. Uma
-----Original Message-----
From: pim-admin@catarina.usc.edu [mailto:pim-admin@catarina.usc.edu]On
Behalf Of smiley_raj@excite.com
Sent: Wednesday, December 18, 2002 9:35 AM
To: pim@catarina.usc.edu
Subject: RE: [pim] doubt regard RP absence in the network
Hi, If you would see the macros pim_include(S, G) and pim_include(*, G).
They have a procedure through which the oifs can have a state established.
If iam correct it is through local_receiver_include, local_receiver_exclude
mechanisms but with some other constraints also. I will narrow my doubt now,
will local_receive_include(S, G, I) for a particular source be true if I
receive a IGMPv2 Join?
[Uma C] local_receive_include(S, G, I) for a particular source would be
true if IGMPv2 Join is received and successful in (*,G) entry creation, not
otherwise in the case of SM.
==========
Logically seeing it should be valid for all sources. And hence packet flow
should be there even when the RP is unavailable. The answer to question on
what basis the (S, G) entry would be deleted ( or (S, G) state goes to NI
state) may be like this.
In the same way as local_receiver_include(S, G, I) is processed on (S, G)
local_receiver_exclude(S, G, I) also should be processed for an IGMPv2
Leave.
[Uma C] The interface "I" connected to the receiver gets added up to (S,G)
only through (*,G). So when the (*.G) entry is deleted, the Interface would
be deleted from (S,G) also.
If there is no (*,G) entry nor RP information, and as you had said when
(S,G,I) can process the IGMP Leave, can (S,G) add the interface "I" when an
IGMPv2 Join comes.
I think in the case of SSM what you had mentioned is applicable. But in
SM, without RP, packet flow should not happen. Anyway when the RP
information is got, the multicast tree is rebuilt.
Logically seeing, this can never happen in real time until someone is
playing around. If thats the case, packets loss should be fine. Pl correct
me if I am wrong.
============
Iam sorry for any mistakes in the answers above.
[Uma C] "Making mistake is human being's privilege". I also proved this
many times :-)
T & R Rajesh Nataraja
--- On Tue 12/17, Uma C < umac@future.futsoft.com > wrote:
From: Uma C [mailto: umac@future.futsoft.com]
To: jaganbabu_pim@yahoo.co.in
Cc: smiley_raj@excite.com, pim@catarina.usc.edu
Date: Tue, 17 Dec 2002 21:48:17 +0530
Subject: RE: [pim] doubt regard RP absence in the network
Hello Jags
When there is no RP information -
1. (*,G) entry would surely get deleted. Outgoing interface in that (*,G)
and (S,G) also gets deleted. So how are the packets still flowing ?
2. If the (*,G) entry alone gets deleted because of the RP information not
present and when the receiver leave the group, will the (S,G) entry get
deleted ?. If yes how ? On what basis will this (S,G) entry get deleted.
I guess the entries at SPT built routers would get deleted only when
source of the multicast packet stops sending packets.
I feel that, when the (*,G) entry gets deleted, (S,G) entry also would be
deleted and there want be a case in which multicast packets will be flowing.
Well I haven't thought about SSM case.
Pl correct me if I am in wrong in my understanding.
Thanks & Regards
C.Uma
***************************************************************************
This message is proprietary to Future Software Limited (FSL)
and is intended solely for the use of the individual to whom it
is addressed. It may contain privileged or confidential information
and should not be circulated or used for any purpose other than for
what it is intended.
If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message.
FSL accepts no responsibility for loss or damage arising from
the use of the information transmitted by this email including
damage from virus.
***************************************************************************
------=_NextPart_000_001B_01C2A69D.2AFE9980
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello=20
Rajesh
Pl=20
find my comments inlined with the tag <UMA>.
In the=20
case of SSM, I agree with what you had said. But in SM, I don't think =
(S,G)=20
entry would be present when (*,G) entries are getting=20
deleted.
Regards
C.=20
Uma
Hi, If you would see the macros pim_include(S, G) and=20
pim_include(*, G). They have a procedure through which the oifs can =
have a=20
state established. If iam correct it is through =
local_receiver_include,=20
local_receiver_exclude mechanisms but with some other constraints =
also. I will=20
narrow my doubt now, will local_receive_include(S, G, I) for a =
particular=20
source be true if I receive a IGMPv2 Join?
[Uma=20
C] local_receive_include(S, G, I) for a particular source =
would be=20
true if IGMPv2 Join is received and successful in (*,G) =
entry=20
creation, not otherwise in the case of SM.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Logically seeing it =
should be=20
valid for all sources. And hence packet flow should be there even when =
the RP=20
is unavailable. The answer to question on what basis the (S, G) entry =
would be=20
deleted ( or (S, G) state goes to NI state) may be like this.
In =
the same=20
way as local_receiver_include(S, G, I) is processed on (S, G)=20
local_receiver_exclude(S, G, I) also should be processed for an IGMPv2 =
Leave.
[Uma C] The interface "I" connected to the receiver gets =
added up=20
to (S,G) only through (*,G). So when the (*.G) entry is =
deleted, the=20
Interface would be deleted from (S,G) also.
If=20
there is no (*,G) entry nor RP information, and as you had said when =
(S,G,I)=20
can process the IGMP Leave, can (S,G) add the interface "I" when an =
IGMPv2=20
Join comes.
I=20
think in the case of SSM what you had mentioned is applicable. But =
in SM,=20
without RP, packet flow should not happen. Anyway when the RP =
information is=20
got, the multicast tree is rebuilt.
Logically seeing, this can never happen in =
real time=20
until someone is playing around. If thats the case, packets loss =
should be=20
fine. Pl correct me if I am wrong.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Iam sorry for any mistakes in the answers above.
[Uma=20
C] "Making mistake is human being's=20
privilege". I also =
proved this many=20
times :-)
T & R Rajesh Nataraja
--- On Tue 12/17, Uma C <=20
umac@future.futsoft.com > wrote:
From: Uma C [mailto:=20
umac@future.futsoft.com]
To: jaganbabu_pim@yahoo.co.in
Cc:=20
smiley_raj@excite.com, pim@catarina.usc.edu
Date: Tue, 17 Dec 2002 =
21:48:17=20
+0530
Subject: RE: [pim] doubt regard RP absence in the=20
network
Hello Jags
When=20
there is no RP information -
1.=20
(*,G) entry would surely get deleted. Outgoing interface in that =
(*,G)=20
and (S,G) also gets deleted. So how are the packets still flowing=20
?
2.=20
If the (*,G) entry alone gets deleted because of the RP information =
not=20
present and when the receiver leave the group, will the (S,G) entry =
get=20
deleted ?. If yes how ? On what basis will this (S,G) entry get=20
deleted.
I=20
guess the entries at SPT built routers would get deleted only=20
when source of the multicast packet stops sending=20
packets.
I=20
feel that, when the (*,G) entry gets deleted, (S,G) entry also would =
be=20
deleted and there want be a case in which multicast packets will be =
flowing.=20
Well I haven't thought about SSM case.
Pl=20
correct me if I am in wrong in my understanding.
Thanks & Regards
C.Uma
=
------=_NextPart_000_001B_01C2A69D.2AFE9980--
_______________________________________________
pim mailing list
pim@catarina.usc.edu
http://catarina.usc.edu/mailman/listinfo/pim
From pim-admin@catarina.usc.edu Wed Dec 18 04:18:34 2002
Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00398
for ; Wed, 18 Dec 2002 04:18:33 -0500 (EST)
Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1])
by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gBI9ClD86402;
Wed, 18 Dec 2002 01:12:47 -0800 (PST)
(envelope-from pim-admin@catarina.usc.edu)
Received: from web8203.mail.in.yahoo.com (web8203.mail.in.yahoo.com [203.199.70.117])
by catarina.usc.edu (8.11.6/8.11.6) with SMTP id gBI997D86345
for ; Wed, 18 Dec 2002 01:09:07 -0800 (PST)
(envelope-from jaganbabu_pim@yahoo.co.in)
Message-ID: <20021218091340.34440.qmail@web8203.mail.in.yahoo.com>
Received: from [12.27.183.253] by web8203.mail.in.yahoo.com via HTTP; Wed, 18 Dec 2002 09:13:40 GMT
From: =?iso-8859-1?q?Rajamanickam=20jaganbabu?=
Subject: RE: [pim] doubt regard RP absence in the network
To: umac@future.futsoft.com
Cc: pim@catarina.usc.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="0-812492770-1040202820=:33958"
Content-Transfer-Encoding: 8bit
Sender: pim-admin@catarina.usc.edu
Errors-To: pim-admin@catarina.usc.edu
X-BeenThere: pim@catarina.usc.edu
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Unsubscribe: ,
List-Id:
List-Post:
List-Help:
List-Subscribe: ,
List-Archive:
Date: Wed, 18 Dec 2002 09:13:40 +0000 (GMT)
--0-812492770-1040202820=:33958
Content-Type: multipart/alternative; boundary="0-1173773981-1040202820=:33958"
--0-1173773981-1040202820=:33958
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Hi uma,
1. Even in normal SM case, multicast forwarding is possible even if we don't have RP information.
2. When we are deleting (*,G) entry, it is not mandatory to remove all the (S,G) entry from the multicast forwarder unless and until all the outgoing interface list is null.
I have explained how it can happen using the following topology (fig. as an attachment).
Explanation:
1. If Rec_1 sends an (*,G) IGMP join to the PIM router "R1", then the PIM forwarding table at R1 look like
(*,G) - oiflist=1
2. After some time, if Rec_2 send (src,G,1) IGMPV3 join, then the PIM forwarding table at R1 looks like
(S,G) - oiflist=1,2
(*,G) - oiflist=1
In the above forwarding table while adding (S,G) entry, the inherited outgoing list will be 1 and the immediate outgoing list will be 2, so consolidating the outgoing interface for (S,G) will 1 and 2
3, In case, if RP goes off, then R1 has to remove the (*,G) entry from the forwarding table and remove the inherited outgoing list, so after the (*,G) removal, the multicast forwarder looks like this.
(S,G) - oiflist=2
So even in SM. it is not necessary to remove all the (S,G) entries if you remove (*,G) entry from the multicast forwarding table.
Regards,
Jags
Uma C wrote:
Hello Jags
I guess in the case of IGMPv3, we do not create any (*,G) entry as the Group range for SSM is different. And as you said we can still forward the packets whether there is RP information or not.
But in the case of SM only, where (*,G) and (S,G) entry exists and (S,G) entry holds the oif of the (*,G), if the RP information is not present -
* (*,G) will be deleted and oif learnt from (*,G) will be deleted from (S,G) also, irrespective of whether local receivers present or not.
* When the RP information is learnt again, (*,G) entry would be re-created if the receivers are still present.
Do you still think if RP information is not present (in the case of SM only), multicast packets would flow ?
Thanks & Regards
C.Uma
-----Original Message-----
From: Rajamanickam jaganbabu [mailto:jaganbabu_pim@yahoo.co.in]
Sent: Wednesday, December 18, 2002 11:16 AM
To: umac@future.futsoft.com
Cc: smiley_raj@excite.com; pim@catarina.usc.edu
Subject: RE: [pim] doubt regard RP absence in the network
Hi Uma,
If there is an IGMPV3 request from the receiver, asking for (S,G,I) join to a particular source, then we will be having an (S,G) entry, which will be the super set of (*,G) outgoing list. If we lost (*,G) information, then it will affect (S,G) inherited outgoing list but there is a possible case where we can have immediate outgoing list exist for (S,G) (which is not in inherited outgoing list), so at this point even we delete (*,G) entry from our multicast forwarding table still (S,G) entry will be existing in the multicast forwarding table.
So my conclusion is, in the above case even if we lost our RP information, still we can forward the multicast packet using (S,G) information for a source "S".
Thanx,
Jags
Uma C wrote:
Hello Jags
When there is no RP information -
1. (*,G) entry would surely get deleted. Outgoing interface in that (*,G) and (S,G) also gets deleted. So how are the packets still flowing ?
2. If the (*,G) entry alone gets deleted because of the RP information not present and when the receiver leave the group, will the (S,G) entry get deleted ?. If yes how ? On what basis will this (S,G) entry get deleted.
I guess the entries at SPT built routers would get deleted only when source of the multicast packet stops sending packets.
I feel that, when the (*,G) entry gets deleted, (S,G) entry also would be deleted and there want be a case in which multicast packets will be flowing. Well I haven't thought about SSM case.
Pl correct me if I am in wrong in my understanding.
Thanks & Regards
C.Uma
-----Original Message-----
From: pim-admin@catarina.usc.edu [mailto:pim-admin@catarina.usc.edu]On Behalf Of Rajamanickam jaganbabu
Sent: Tuesday, December 17, 2002 8:38 PM
To: smiley_raj@excite.com; pim@catarina.usc.edu
Subject: Re: [pim] doubt regard RP absence in the network
Hi rajesh,
If the receiver and the source has the Source Path Tree established (i.e if we have (S,G) entry in the Multicast forwarding table), then irrespective of the RP information availability, the multicast packet will be forwarded.
I hope the above information will help you, if i have understood your question correctly.
Regards,
Jags
"smiley_raj@excite.com" wrote:
Hi,
I have the following doubt,
If there is no RP in the network or all the RPs expire in the network. Can there be packet forwarding activity in a PIM-SM (only) domain. In clear my doubt is can the receivers switched over to the packet forwarding via SPT still continue to receive the data packets even if there is not RP information with him.
thanks in advance
rajesh,
Join Excite! -
The most personalized portal on the Web!
Catch all the cricket action. Download Yahoo! Score tracker
Catch all the cricket action. Download Yahoo! Score tracker
Catch all the cricket action. Download Yahoo! Score tracker
--0-1173773981-1040202820=:33958
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Hi uma,
1. Even in normal SM case, multicast forwarding is possible even if we don't have RP information.
2. When we are deleting (*,G) entry, it is not mandatory to remove all the (S,G) entry from the multicast forwarder unless and until all the outgoing interface list is null.
I have explained how it can happen using the following topology (fig. as an attachment).
Explanation:
1. If Rec_1 sends an (*,G) IGMP join to the PIM router "R1", then the PIM forwarding table at R1 look like
(*,G) - oiflist=1
2. After some time, if Rec_2 send (src,G,1) IGMPV3 join, then the PIM forwarding table at R1 looks like
(S,G) - oiflist=1,2
(*,G) - oiflist=1
In the above forwarding table while adding (S,G) entry, the inherited outgoing list will be 1 and the immediate outgoing list will be 2, so consolidating the outgoing interface for (S,G) will 1 and 2
3, In case, if RP goes off, then R1 has to remove the (*,G) entry from the forwarding table and remove the inherited outgoing list, so after the (*,G) removal, the multicast forwarder looks like this.
(S,G) - oiflist=2
So even in SM. it is not necessary to remove all the (S,G) entries if you remove (*,G) entry from the multicast forwarding table.
Regards,
Jags
Uma C <umac@future.futsoft.com>
wrote:
Hello Jags
I guess in the case of IGMPv3, we do not create any (*,G) entry as the Group range for SSM is different. And as you said we can still forward the packets whether there is RP information or not.
But in the case of SM only, where (*,G) and (S,G) entry exists and (S,G) entry holds the oif of the (*,G), if the RP information is not present -
* (*,G) will be deleted and oif learnt from (*,G) will be deleted from (S,G) also, irrespective of whether local receivers present or not.
* When the RP information is learnt again, (*,G) entry would be re-created if the receivers are still present.
Do you still think if RP information is not present (in the case of SM only), multicast packets would flow ?
Thanks & Regards
C.Uma
-----Original Message-----
From: Rajamanickam jaganbabu [mailto:jaganbabu_pim@yahoo.co.in]
Sent: Wednesday, December 18, 2002 11:16 AM
To: umac@future.futsoft.com
Cc: smiley_raj@excite.com; pim@catarina.usc.edu
Subject: RE: [pim] doubt regard RP absence in the network
Hi Uma,
If there is an IGMPV3 request from the receiver, asking for (S,G,I) join to a particular source, then we will be having an (S,G) entry, which will be the super set of (*,G) outgoing list. If we lost (*,G) information, then it will affect (S,G) inherited outgoing list but there is a possible case where we can have immediate outgoing list exist for (S,G) (which is not in inherited outgoing list), so at this point even we delete (*,G) entry from our multicast forwarding table still (S,G) entry will be existing in the multicast forwarding table.
So my conclusion is, in the above case even if we lost our RP information, still we can forward the multicast packet using (S,G) information for a source "S".
Thanx,
Jags
Uma C <umac@future.futsoft.com> wrote:
Hello Jags
When there is no RP information -
1. (*,G) entry would surely get deleted. Outgoing interface in that (*,G) and (S,G) also gets deleted. So how are the packets still flowing ?
2. If the (*,G) entry alone gets deleted because of the RP information not present and when the receiver leave the group, will the (S,G) entry get deleted ?. If yes how ? On what basis will this (S,G) entry get deleted.
I guess the entries at SPT built routers would get deleted only when source of the multicast packet stops sending packets.
I feel that, when the (*,G) entry gets deleted, (S,G) entry also would be deleted and there want be a case in which multicast packets will be flowing. Well I haven't thought about SSM case.
Pl correct me if I am in wrong in my understanding.
Thanks & Regards
C.Uma
-----Original Message-----
From: pim-admin@catarina.usc.edu [mailto:pim-admin@catarina.usc.edu]On Behalf Of Rajamanickam jaganbabu
Sent: Tuesday, December 17, 2002 8:38 PM
To: smiley_raj@excite.com; pim@catarina.usc.edu
Subject: Re: [pim] doubt regard RP absence in the network
Hi rajesh,
If the receiver and the source has the Source Path Tree established (i.e if we have (S,G) entry in the Multicast forwarding table), then irrespective of the RP information availability, the multicast packet will be forwarded.
I hope the above information will help you, if i have understood your question correctly.
Regards,
Jags
"smiley_raj@excite.com" <smiley_raj@excite.com> wrote:
Hi,
I have the following doubt,
If there is no RP in the network or all the RPs expire in the network. Can there be packet forwarding activity in a PIM-SM (only) domain. In clear my doubt is can the receivers switched over to the packet forwarding via SPT still continue to receive the data packets even if there is not RP information with him.
thanks in advance
rajesh,
Join Excite! -
<http://www.excite.com/>
The most personalized portal on the Web!
Catch all the cricket action. Download Yahoo! Score tracker <http://in.sports.yahoo.com/cricket/tracker.html>
Catch all the cricket action. Download Yahoo! Score tracker <http://in.sports.yahoo.com/cricket/tracker.html>
Catch all the cricket action. Download
Yahoo! Score tracker
--0-1173773981-1040202820=:33958--
--0-812492770-1040202820=:33958
Content-Type: text/plain; name="pim_main_list.txt"
Content-Description: pim_main_list.txt
Content-Disposition: inline; filename="pim_main_list.txt"
+------+
| |
| RP |
| |
+------+
1 |
|
|
|
+----------+
|
|
|
| 4
+-------+
1 | | 3
+----| R1 |----------------------+
| | | |
| +-------+ |
| | 2 |1
| 1 | +------+
+------+ | | |
| | +-----+ | src |
|Rec_1 | | | |
| | | +------+
+------+ |
| 1
+------+
| |
|Rec_2 |
| |
+------+
--0-812492770-1040202820=:33958--
_______________________________________________
pim mailing list
pim@catarina.usc.edu
http://catarina.usc.edu/mailman/listinfo/pim
From pim-admin@catarina.usc.edu Wed Dec 18 04:43:37 2002
Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00959
for ; Wed, 18 Dec 2002 04:43:37 -0500 (EST)
Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1])
by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gBI9cED86753;
Wed, 18 Dec 2002 01:38:14 -0800 (PST)
(envelope-from pim-admin@catarina.usc.edu)
Received: from xover.netplane.com (fwout.maker.com [12.27.183.253] (may be forged))
by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gBI9ZnD86713
for ; Wed, 18 Dec 2002 01:35:49 -0800 (PST)
(envelope-from sarveshwarb@netplane.com)
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19)
id <4B0HSBVK>; Wed, 18 Dec 2002 04:40:25 -0500
Message-ID:
From: "Bandi, Sarveshwar"
To: pim@catarina.usc.edu
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Subject: [pim] Query on Upstream(S,G,rpt) State machine for triggered messages
Sender: pim-admin@catarina.usc.edu
Errors-To: pim-admin@catarina.usc.edu
X-BeenThere: pim@catarina.usc.edu
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Unsubscribe: ,
List-Id:
List-Post:
List-Help:
List-Subscribe: ,
List-Archive:
Date: Wed, 18 Dec 2002 04:42:17 -0500
Hi,
In the state machine for (S,G,rpt) triggered messages (Section 4.5.9) the
state tranistions from "RPTNotJoined" to "Not Pruned" occurs when
"inherited_olist(S,G,rpt)--> NON-NULL" and the reverse state tranistion from
"Not Pruned" to "RPTNotJoined" occurs when "RPTJoinDesired(G)-->False". My
question is why shouldnt we use the "RPTJoinDesired(G)--> TRUE" event for
the former state tranistion (i.e) from "RPTNotJoined" to "Not Pruned".
Doesnt this event itself convey that we have joined the RPT and thus should
be in the Not Pruned state?
Thanks and Regards,
Sarveshwar Bandi
Senior Member, Technical Staff
Netplane Network Technologies (India) Pvt. Ltd.
http://www.netplane.com
Ph: +91-40-355 3709/10/11/12 Extn: 1126
Fax: +91-40-355 3713
_______________________________________________
pim mailing list
pim@catarina.usc.edu
http://catarina.usc.edu/mailman/listinfo/pim
From pim-admin@catarina.usc.edu Wed Dec 18 07:09:36 2002
Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03253
for ; Wed, 18 Dec 2002 07:09:34 -0500 (EST)
Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1])
by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gBIC3tD89130;
Wed, 18 Dec 2002 04:03:55 -0800 (PST)
(envelope-from pim-admin@catarina.usc.edu)
Received: from fsnt.future.futsoft.com ([203.197.140.35])
by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gBIC28D89097
for ; Wed, 18 Dec 2002 04:02:09 -0800 (PST)
(envelope-from umac@future.futsoft.com)
Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com
(Content Technologies SMTPRS 2.0.15) with ESMTP id ;
Wed, 18 Dec 2002 17:39:10 +0530
Received: from umac (umac.future.futsoft.com [10.20.6.25])
by kailash.future.futsoft.com (8.12.2/8.12.2) with SMTP id gBIC2nCJ029814;
Wed, 18 Dec 2002 17:32:49 +0530
Reply-To:
From: "Uma C"
To: "'Rajamanickam jaganbabu'"
Cc:
Subject: RE: [pim] doubt regard RP absence in the network
Message-Id: <002a01c2a68f$e948ed40$1906140a@future.futsoft.com>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <20021218091340.34440.qmail@web8203.mail.in.yahoo.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_002B_01C2A6BE.03012940"
Sender: pim-admin@catarina.usc.edu
Errors-To: pim-admin@catarina.usc.edu
X-BeenThere: pim@catarina.usc.edu
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Unsubscribe: ,
List-Id:
List-Post:
List-Help:
List-Subscribe: ,
List-Archive:
Date: Wed, 18 Dec 2002 17:50:53 +0530
This is a multi-part message in MIME format.
------=_NextPart_000_002B_01C2A6BE.03012940
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Hello Jags
Pl find my response inlined with the tag .
Regards
C.Uma
-----Original Message-----
From: pim-admin@catarina.usc.edu [mailto:pim-admin@catarina.usc.edu]On
Behalf Of Rajamanickam jaganbabu
Sent: Wednesday, December 18, 2002 2:44 PM
To: umac@future.futsoft.com
Cc: pim@catarina.usc.edu
Subject: RE: [pim] doubt regard RP absence in the network
Hi uma,
1. Even in normal SM case, multicast forwarding is possible even if we
don't have RP information.
[Uma C] I guess not. In the example you had given includes SSM also.
=========
2. When we are deleting (*,G) entry, it is not mandatory to remove all the
(S,G) entry from the multicast forwarder unless and until all the outgoing
interface list is null.
[Uma C] I agree with you. And in the SM case there cannot be a situation
when (*,G) is deleted but (S,G) still remains.
==================
I have explained how it can happen using the following topology (fig. as
an attachment).
Explanation:
1. If Rec_1 sends an (*,G) IGMP join to the PIM router "R1", then the PIM
forwarding table at R1 look like
(*,G) - oiflist=1
2. After some time, if Rec_2 send (src,G,1) IGMPV3 join, then the PIM
forwarding table at R1 looks like
(S,G) - oiflist=1,2
(*,G) - oiflist=1
In the above forwarding table while adding (S,G) entry, the inherited
outgoing list will be 1 and the immediate outgoing list will be 2, so
consolidating the outgoing interface for (S,G) will 1 and 2
3, In case, if RP goes off, then R1 has to remove the (*,G) entry from the
forwarding table and remove the inherited outgoing list, so after the (*,G)
removal, the multicast forwarder looks like this.
(S,G) - oiflist=2
[Uma C] Yes, multicast packets should flow on interface 2. I agree with
this. But the discussion started with whether multicast packets can be
forwarded in PIM-SM domain only (This is want Rajesh asked for) when RP
information is not present. In this case do not execute the step 2, so the
(*,G) and (S,G) will hold the same oif, and hence both of these entries get
deleted. So the multicast packets stop flowing.
================
So even in SM. it is not necessary to remove all the (S,G) entries if you
remove (*,G) entry from the multicast forwarding table.
[Uma C] I guess not in the SM domain (which doesnot include SSM). I
apreciate the interest you had taken to explain the situation with a
topology. Thanks Jags.
=================
Regards,
Jags
Uma C wrote:
Hello Jags
I guess in the case of IGMPv3, we do not create any (*,G) entry as the
Group range for SSM is different. And as you said we can still forward the
packets whether there is RP information or not.
But in the case of SM only, where (*,G) and (S,G) entry exists and (S,G)
entry holds the oif of the (*,G), if the RP information is not present -
* (*,G) will be deleted and oif learnt from (*,G) will be deleted from
(S,G) also, irrespective of whether local receivers present or not.
* When the RP information is learnt again, (*,G) entry would be re-created
if the receivers are still present.
Do you still think if RP information is not present (in the case of SM
only), multicast packets would flow ?
Thanks & Regards
C.Uma
-----Original Message-----
From: Rajamanickam jaganbabu [mailto:jaganbabu_pim@yahoo.co.in]
Sent: Wednesday, December 18, 2002 11:16 AM
To: umac@future.futsoft.com
Cc: smiley_raj@excite.com; pim@catarina.usc.edu
Subject: RE: [pim] doubt regard RP absence in the network
Hi Uma,
If there is an IGMPV3 request from the receiver, asking for (S,G,I) join
to a particular source, then we will be having an (S,G) entry, which will be
the super set of (*,G) outgoing list. If we lost (*,G) information, then it
will affect (S,G) inherited outgoing list but there is a possible case where
we can have immediate outgoing list exist for (S,G) (which is not in
inherited outgoing list), so at this point even we delete (*,G) entry from
our multicast forwarding table still (S,G) entry will be existing in the
multicast forwarding table.
So my conclusion is, in the above case even if we lost our RP information,
still we can forward the multicast packet using (S,G) information for a
source "S".
Thanx,
Jags
Uma C wrote:
Hello Jags
When there is no RP information -
1. (*,G) entry would surely get deleted. Outgoing interface in that (*,G)
and (S,G) also gets deleted. So how are the packets still flowing ?
2. If the (*,G) entry alone gets deleted because of the RP information not
present and when the receiver leave the group, will the (S,G) entry get
deleted ?. If yes how ? On what basis will this (S,G) entry get deleted.
I guess the entries at SPT built routers would get deleted only when
source of the multicast packet stops sending packets.
I feel that, when the (*,G) entry gets deleted, (S,G) entry also would be
deleted and there want be a case in which multicast packets will be flowing.
Well I haven't thought about SSM case.
Pl correct me if I am in wrong in my understanding.
Thanks & Regards
C.Uma
-----Original Message-----
From: pim-admin@catarina.usc.edu [mailto:pim-admin@catarina.usc.edu]On
Behalf Of Rajamanickam jaganbabu
Sent: Tuesday, December 17, 2002 8:38 PM
To: smiley_raj@excite.com; pim@catarina.usc.edu
Subject: Re: [pim] doubt regard RP absence in the network
Hi rajesh,
If the receiver and the source has the Source Path Tree established (i.e
if we have (S,G) entry in the Multicast forwarding table), then irrespective
of the RP information availability, the multicast packet will be forwarded.
I hope the above information will help you, if i have understood your
question correctly.
Regards,
Jags
"smiley_raj@excite.com" wrote:
Hi,
I have the following doubt,
If there is no RP in the network or all the RPs expire in the network. Can
there be packet forwarding activity in a PIM-SM (only) domain. In clear my
doubt is can the receivers switched over to the packet forwarding via SPT
still continue to receive the data packets even if there is not RP
information with him.
thanks in advance
rajesh,
Join Excite! -
The most personalized portal on the Web!
Catch all the cricket action. Download Yahoo! Score tracker
Catch all the cricket action. Download Yahoo! Score tracker
Catch all the cricket action. Download Yahoo! Score tracker
***************************************************************************
This message is proprietary to Future Software Limited (FSL)
and is intended solely for the use of the individual to whom it
is addressed. It may contain privileged or confidential information
and should not be circulated or used for any purpose other than for
what it is intended.
If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message.
FSL accepts no responsibility for loss or damage arising from
the use of the information transmitted by this email including
damage from virus.
***************************************************************************
------=_NextPart_000_002B_01C2A6BE.03012940
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello=20
Jags
Pl=20
find my response inlined with the tag <UMA>.
Regards
C.Uma
Hi uma,
1. Even in normal SM case, multicast forwarding is =
possible=20
even if we don't have RP information.
[Uma C] I guess not. In the =
example you had=20
given includes SSM also.
=3D=3D=3D=3D=3D=3D=3D=3D=3D
2. When we are deleting (*,G) entry, it is not =
mandatory to=20
remove all the (S,G) entry from the multicast forwarder unless and =
until all=20
the outgoing interface list is null.
[Uma C] I agree with you. And =
in the SM=20
case there cannot be a situation when (*,G) is deleted but (S,G) =
still=20
remains.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
I have explained how it can happen using the =
following=20
topology (fig. as an attachment).
Explanation:
1. If Rec_1 sends an (*,G) IGMP join to the PIM =
router "R1",=20
then the PIM forwarding table at R1 look like
(*,G) - oiflist=3D1
2. After some time, if Rec_2 send (src,G,1) IGMPV3 =
join, then=20
the PIM forwarding table at R1 looks like
(S,G) - oiflist=3D1,2
(*,G) - oiflist=3D1
In the above forwarding table while adding (S,G) =
entry, the=20
inherited outgoing list will be 1 and the immediate outgoing list will =
be 2,=20
so consolidating the outgoing interface for (S,G) will 1 and =
2
3, In case, if RP goes off, then R1 has to remove =
the (*,G)=20
entry from the forwarding table and remove the inherited outgoing =
list, so=20
after the (*,G) removal, the multicast forwarder looks like =
this.
(S,G) - oiflist=3D2
[Uma C] Yes, multicast packets =
should=20
flow on interface 2. I agree with this. But the discussion =
started=20
with whether multicast packets can be forwarded in PIM-SM domain =
only=20
(This is want Rajesh asked for) when RP information is not present. In =
this=20
case do not execute the step 2, so the (*,G) and (S,G) will hold the =
same oif,=20
and hence both of these entries get deleted. So the multicast packets =
stop=20
flowing.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
So even in SM. it is not necessary to remove all the =
(S,G)=20
entries if you remove (*,G) entry from the multicast forwarding=20
table.
[Uma=20
C] I guess not in the SM domain (which doesnot include=20
SSM). I apreciate =
the interest you=20
had taken to explain the situation with a topology. Thanks=20
Jags.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Regards,
Jags
Uma C <umac@future.futsoft.com>
wrote:
Hello Jags
I guess in the case of IGMPv3, we do not create any (*,G) entry as =
the=20
Group range for SSM is different. And as you said we can still forward =
the=20
packets whether there is RP information or not.
But in the case of SM only, where (*,G) and (S,G) entry exists and =
(S,G)=20
entry holds the oif of the (*,G), if the RP information is not present =
-
* (*,G) will be deleted and oif learnt from (*,G) will be deleted =
from=20
(S,G) also, irrespective of whether local receivers present or=20
not.
* When the RP information is learnt again, (*,G) entry would be =
re-created=20
if the receivers are still present.
=20
Do you still think if RP information is not present (in the case of =
SM=20
only), multicast packets would flow ?
=20
Thanks & Regards
=
C.Uma
-----Original Message-----
From: Rajamanickam jaganbabu=20
[mailto:jaganbabu_pim@yahoo.co.in]
Sent: Wednesday, December =
18,=20
2002 11:16 AM
To: umac@future.futsoft.com
Cc:=20
smiley_raj@excite.com; pim@catarina.usc.edu
Subject: RE: =
[pim] doubt=20
regard RP absence in the network
Hi Uma,
If there is an IGMPV3 request from the receiver, asking for (S,G,I) =
join to=20
a particular source, then we will be having an (S,G) entry, which will =
be the=20
super set of (*,G) outgoing list. If we lost (*,G) information, then =
it will=20
affect (S,G) inherited outgoing list but there is a possible case =
where we can=20
have immediate outgoing list exist for (S,G) (which is not in =
inherited=20
outgoing list), so at this point even we delete (*,G) entry from our =
multicast=20
forwarding table still (S,G) entry will be existing in the multicast=20
forwarding table.
So my conclusion is, in the above case even if we lost our RP =
information,=20
still we can forward the multicast packet using (S,G) information for =
a source=20
"S".
Thanx,
Jags
Uma C <umac@future.futsoft.com> wrote:
Hello Jags
When there is no RP information -
=20
1. (*,G) entry would surely get deleted. Outgoing interface in that =
(*,G)=20
and (S,G) also gets deleted. So how are the packets still flowing=20
?
2. If the (*,G) entry alone gets deleted because of the RP =
information not=20
present and when the receiver leave the group, will the (S,G) entry =
get=20
deleted ?. If yes how ? On what basis will this (S,G) entry get=20
deleted.
I guess the entries at SPT built routers would get deleted only =
when source=20
of the multicast packet stops sending packets.
I feel that, when the (*,G) entry gets deleted, (S,G) entry also =
would be=20
deleted and there want be a case in which multicast packets will be =
flowing.=20
Well I haven't thought about SSM case.
=20
Pl correct me if I am in wrong in my understanding.
Thanks & Regards
C.Uma
-----Original Message-----
From: =
pim-admin@catarina.usc.edu=20
[mailto:pim-admin@catarina.usc.edu]On Behalf Of Rajamanickam=20
jaganbabu
Sent: Tuesday, December 17, 2002 8:38 =
PM
To:=20
smiley_raj@excite.com; pim@catarina.usc.edu
Subject: Re: =
[pim] doubt=20
regard RP absence in the network
Hi rajesh,
If the receiver and the source has the Source Path Tree established =
(i.e if=20
we have (S,G) entry in the Multicast forwarding table), then =
irrespective of=20
the RP information availability, the multicast packet will be =
forwarded.
I hope the above information will help you, if i have understood =
your=20
question correctly.
Regards,
Jags
"smiley_raj@excite.com" <smiley_raj@excite.com> =
wrote:
Hi,
I have the following doubt,
If there is no RP in the =
network=20
or all the RPs expire in the network. Can there be packet forwarding =
activity=20
in a PIM-SM (only) domain. In clear my doubt is can the receivers =
switched=20
over to the packet forwarding via SPT still continue to receive the =
data=20
packets even if there is not RP information with him.
thanks in=20
advance
rajesh,
Join Excite! -
<http://www.excite.com/>
The most personalized portal on the Web!
Catch all the =
cricket action.=20
Download Yahoo! Score=20
tracker=20
=
<http://in.sports.yahoo.com/cricket/tracker.html>=
U>
Catch all the =
cricket action.=20
Download Yahoo! Score=20
tracker=20
=
<http://in.sports.yahoo.com/cricket/tracker.html>
Catch all the cricket action. Download Yahoo!=20
Score tracker
------=_NextPart_000_002B_01C2A6BE.03012940--
_______________________________________________
pim mailing list
pim@catarina.usc.edu
http://catarina.usc.edu/mailman/listinfo/pim
From pim-admin@catarina.usc.edu Wed Dec 18 10:13:44 2002
Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10336
for ; Wed, 18 Dec 2002 10:13:43 -0500 (EST)
Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1])
by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gBIF7mD91528;
Wed, 18 Dec 2002 07:07:48 -0800 (PST)
(envelope-from pim-admin@catarina.usc.edu)
Received: from web8205.mail.in.yahoo.com (web8205.mail.in.yahoo.com [203.199.70.126])
by catarina.usc.edu (8.11.6/8.11.6) with SMTP id gBIF5jD91500
for ; Wed, 18 Dec 2002 07:05:45 -0800 (PST)
(envelope-from jaganbabu_pim@yahoo.co.in)
Message-ID: <20021218151022.91347.qmail@web8205.mail.in.yahoo.com>
Received: from [12.27.183.253] by web8205.mail.in.yahoo.com via HTTP; Wed, 18 Dec 2002 15:10:22 GMT
From: =?iso-8859-1?q?Rajamanickam=20jaganbabu?=
Subject: RE: [pim] doubt regard RP absence in the network
To: umac@future.futsoft.com
Cc: pim@catarina.usc.edu
In-Reply-To: <002a01c2a68f$e948ed40$1906140a@future.futsoft.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-260930108-1040224222=:91139"
Content-Transfer-Encoding: 8bit
Sender: pim-admin@catarina.usc.edu
Errors-To: pim-admin@catarina.usc.edu
X-BeenThere: pim@catarina.usc.edu
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Unsubscribe: ,
List-Id:
List-Post:
List-Help:
List-Subscribe: ,
List-Archive:
Date: Wed, 18 Dec 2002 15:10:22 +0000 (GMT)
--0-260930108-1040224222=:91139
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Hi uma,
Whatever I have mentioned below was only with respect to SM domain (I haven't mentioned SSM case, which is altogether a different story). I don't understand why you need to delete even (S,G) if you don't have (*,G), draft doesn't say that. But according to the draft, we need to remove only inherited outlist from (S,G) entry, but in our case we have immediate outgoing list in (S,G) which is not a part of inherited list (if the (S,G) immediate outlist and inherited outlist are same then only we should remove (S,G) entry from your multicast forwarding table), so there is no point and we should not delete (S,G) entry from the multicast routing table even if (*,G) entry is deleted.
I hope u understand the logic.
Regards,
Jags
Uma C wrote:Hello Jags Pl find my response inlined with the tag . RegardsC.Uma -----Original Message-----
From: pim-admin@catarina.usc.edu [mailto:pim-admin@catarina.usc.edu]On Behalf Of Rajamanickam jaganbabu
Sent: Wednesday, December 18, 2002 2:44 PM
To: umac@future.futsoft.com
Cc: pim@catarina.usc.edu
Subject: RE: [pim] doubt regard RP absence in the network
Hi uma,
1. Even in normal SM case, multicast forwarding is possible even if we don't have RP information.
[Uma C] I guess not. In the example you had given includes SSM also.
=========
2. When we are deleting (*,G) entry, it is not mandatory to remove all the (S,G) entry from the multicast forwarder unless and until all the outgoing interface list is null.
[Uma C] I agree with you. And in the SM case there cannot be a situation when (*,G) is deleted but (S,G) still remains.
==================
I have explained how it can happen using the following topology (fig. as an attachment).
Explanation:
1. If Rec_1 sends an (*,G) IGMP join to the PIM router "R1", then the PIM forwarding table at R1 look like
(*,G) - oiflist=1
2. After some time, if Rec_2 send (src,G,1) IGMPV3 join, then the PIM forwarding table at R1 looks like
(S,G) - oiflist=1,2
(*,G) - oiflist=1
In the above forwarding table while adding (S,G) entry, the inherited outgoing list will be 1 and the immediate outgoing list will be 2, so consolidating the outgoing interface for (S,G) will 1 and 2
3, In case, if RP goes off, then R1 has to remove the (*,G) entry from the forwarding table and remove the inherited outgoing list, so after the (*,G) removal, the multicast forwarder looks like this.
(S,G) - oiflist=2
[Uma C] Yes, multicast packets should flow on interface 2. I agree with this. But the discussion started with whether multicast packets can be forwarded in PIM-SM domain only (This is want Rajesh asked for) when RP information is not present. In this case do not execute the step 2, so the (*,G) and (S,G) will hold the same oif, and hence both of these entries get deleted. So the multicast packets stop flowing.
================
So even in SM. it is not necessary to remove all the (S,G) entries if you remove (*,G) entry from the multicast forwarding table.
[Uma C] I guess not in the SM domain (which doesnot include SSM). I apreciate the interest you had taken to explain the situation with a topology. Thanks Jags.
=================
Regards,
Jags
Uma C wrote:
Hello Jags
I guess in the case of IGMPv3, we do not create any (*,G) entry as the Group range for SSM is different. And as you said we can still forward the packets whether there is RP information or not.
But in the case of SM only, where (*,G) and (S,G) entry exists and (S,G) entry holds the oif of the (*,G), if the RP information is not present -
* (*,G) will be deleted and oif learnt from (*,G) will be deleted from (S,G) also, irrespective of whether local receivers present or not.
* When the RP information is learnt again, (*,G) entry would be re-created if the receivers are still present.
Do you still think if RP information is not present (in the case of SM only), multicast packets would flow ?
Thanks & Regards
C.Uma
-----Original Message-----
From: Rajamanickam jaganbabu [mailto:jaganbabu_pim@yahoo.co.in]
Sent: Wednesday, December 18, 2002 11:16 AM
To: umac@future.futsoft.com
Cc: smiley_raj@excite.com; pim@catarina.usc.edu
Subject: RE: [pim] doubt regard RP absence in the network
Hi Uma,
If there is an IGMPV3 request from the receiver, asking for (S,G,I) join to a particular source, then we will be having an (S,G) entry, which will be the super set of (*,G) outgoing list. If we lost (*,G) information, then it will affect (S,G) inherited outgoing list but there is a possible case where we can have immediate outgoing list exist for (S,G) (which is not in inherited outgoing list), so at this point even we delete (*,G) entry from our multicast forwarding table still (S,G) entry will be existing in the multicast forwarding table.
So my conclusion is, in the above case even if we lost our RP information, still we can forward the multicast packet using (S,G) information for a source "S".
Thanx,
Jags
Uma C wrote:
Hello Jags
When there is no RP information -
1. (*,G) entry would surely get deleted. Outgoing interface in that (*,G) and (S,G) also gets deleted. So how are the packets still flowing ?
2. If the (*,G) entry alone gets deleted because of the RP information not present and when the receiver leave the group, will the (S,G) entry get deleted ?. If yes how ? On what basis will this (S,G) entry get deleted.
I guess the entries at SPT built routers would get deleted only when source of the multicast packet stops sending packets.
I feel that, when the (*,G) entry gets deleted, (S,G) entry also would be deleted and there want be a case in which multicast packets will be flowing. Well I haven't thought about SSM case.
Pl correct me if I am in wrong in my understanding.
Thanks & Regards
C.Uma
-----Original Message-----
From: pim-admin@catarina.usc.edu [mailto:pim-admin@catarina.usc.edu]On Behalf Of Rajamanickam jaganbabu
Sent: Tuesday, December 17, 2002 8:38 PM
To: smiley_raj@excite.com; pim@catarina.usc.edu
Subject: Re: [pim] doubt regard RP absence in the network
Hi rajesh,
If the receiver and the source has the Source Path Tree established (i.e if we have (S,G) entry in the Multicast forwarding table), then irrespective of the RP information availability, the multicast packet will be forwarded.
I hope the above information will help you, if i have understood your question correctly.
Regards,
Jags
"smiley_raj@excite.com" wrote:
Hi,
I have the following doubt,
If there is no RP in the network or all the RPs expire in the network. Can there be packet forwarding activity in a PIM-SM (only) domain. In clear my doubt is can the receivers switched over to the packet forwarding via SPT still continue to receive the data packets even if there is not RP information with him.
thanks in advance
rajesh,
Join Excite! -
The most personalized portal on the Web!
Catch all the cricket action. Download Yahoo! Score tracker
Catch all the cricket action. Download Yahoo! Score tracker
Catch all the cricket action. Download Yahoo! Score tracker
Catch all the cricket action. Download Yahoo! Score tracker
--0-260930108-1040224222=:91139
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Hi uma,
Whatever I have mentioned below was only with respect to SM domain (I haven't mentioned SSM case, which is altogether a different story). I don't understand why you need to delete even (S,G) if you don't have (*,G), draft doesn't say that. But according to the draft, we need to remove only inherited outlist from (S,G) entry, but in our case we have immediate outgoing list in (S,G) which is not a part of inherited list (if the (S,G) immediate outlist and inherited outlist are same then only we should remove (S,G) entry from your multicast forwarding table), so there is no point and we should not delete (S,G) entry from the multicast routing table even if (*,G) entry is deleted.
I hope u understand the logic.
Regards,
Jags
Uma C <umac@future.futsoft.com> wrote:
Hello Jags
Pl find my response inlined with the tag <UMA>.
Regards
C.Uma
Hi uma,
1. Even in normal SM case, multicast forwarding is possible even if we don't have RP information.
[Uma C] I guess not. In the example you had given includes SSM also.
=========
2. When we are deleting (*,G) entry, it is not mandatory to remove all the (S,G) entry from the multicast forwarder unless and until all the outgoing interface list is null.
[Uma C] I agree with you. And in the SM case there cannot be a situation when (*,G) is deleted but (S,G) still remains.
==================
I have explained how it can happen using the following topology (fig. as an attachment).
Explanation:
1. If Rec_1 sends an (*,G) IGMP join to the PIM router "R1", then the PIM forwarding table at R1 look like
(*,G) - oiflist=1
2. After some time, if Rec_2 send (src,G,1) IGMPV3 join, then the PIM forwarding table at R1 looks like
(S,G) - oiflist=1,2
(*,G) - oiflist=1
In the above forwarding table while adding (S,G) entry, the inherited outgoing list will be 1 and the immediate outgoing list will be 2, so consolidating the outgoing interface for (S,G) will 1 and 2
3, In case, if RP goes off, then R1 has to remove the (*,G) entry from the forwarding table and remove the inherited outgoing list, so after the (*,G) removal, the multicast forwarder looks like this.
(S,G) - oiflist=2
[Uma C] Yes, multicast packets should flow on interface 2. I agree with this. But the discussion started with whether multicast packets can be forwarded in PIM-SM domain only (This is want Rajesh asked for) when RP information is not present. In this case do not execute the step 2, so the (*,G) and (S,G) will hold the same oif, and hence both of these entries get deleted. So the multicast packets stop flowing.
================
So even in SM. it is not necessary to remove all the (S,G) entries if you remove (*,G) entry from the multicast forwarding table.
[Uma C] I guess not in the SM domain (which doesnot include SSM). I apreciate the interest you had taken to explain the situation with a topology. Thanks Jags.
=================
Regards,
Jags
Uma C <umac@future.futsoft.com>
wrote:
Hello Jags
I guess in the case of IGMPv3, we do not create any (*,G) entry as the Group range for SSM is different. And as you said we can still forward the packets whether there is RP information or not.
But in the case of SM only, where (*,G) and (S,G) entry exists and (S,G) entry holds the oif of the (*,G), if the RP information is not present -
* (*,G) will be deleted and oif learnt from (*,G) will be deleted from (S,G) also, irrespective of whether local receivers present or not.
* When the RP information is learnt again, (*,G) entry would be re-created if the receivers are still present.
Do you still think if RP information is not present (in the case of SM only), multicast packets would flow ?
Thanks & Regards
C.Uma
-----Original Message-----
From: Rajamanickam jaganbabu [mailto:jaganbabu_pim@yahoo.co.in]
Sent: Wednesday, December 18, 2002 11:16 AM
To: umac@future.futsoft.com
Cc: smiley_raj@excite.com; pim@catarina.usc.edu
Subject: RE: [pim] doubt regard RP absence in the network
Hi Uma,
If there is an IGMPV3 request from the receiver, asking for (S,G,I) join to a particular source, then we will be having an (S,G) entry, which will be the super set of (*,G) outgoing list. If we lost (*,G) information, then it will affect (S,G) inherited outgoing list but there is a possible case where we can have immediate outgoing list exist for (S,G) (which is not in inherited outgoing list), so at this point even we delete (*,G) entry from our multicast forwarding table still (S,G) entry will be existing in the multicast forwarding table.
So my conclusion is, in the above case even if we lost our RP information, still we can forward the multicast packet using (S,G) information for a source "S".
Thanx,
Jags
Uma C <umac@future.futsoft.com> wrote:
Hello Jags
When there is no RP information -
1. (*,G) entry would surely get deleted. Outgoing interface in that (*,G) and (S,G) also gets deleted. So how are the packets still flowing ?
2. If the (*,G) entry alone gets deleted because of the RP information not present and when the receiver leave the group, will the (S,G) entry get deleted ?. If yes how ? On what basis will this (S,G) entry get deleted.
I guess the entries at SPT built routers would get deleted only when source of the multicast packet stops sending packets.
I feel that, when the (*,G) entry gets deleted, (S,G) entry also would be deleted and there want be a case in which multicast packets will be flowing. Well I haven't thought about SSM case.
Pl correct me if I am in wrong in my understanding.
Thanks & Regards
C.Uma
-----Original Message-----
From: pim-admin@catarina.usc.edu [mailto:pim-admin@catarina.usc.edu]On Behalf Of Rajamanickam jaganbabu
Sent: Tuesday, December 17, 2002 8:38 PM
To: smiley_raj@excite.com; pim@catarina.usc.edu
Subject: Re: [pim] doubt regard RP absence in the network
Hi rajesh,
If the receiver and the source has the Source Path Tree established (i.e if we have (S,G) entry in the Multicast forwarding table), then irrespective of the RP information availability, the multicast packet will be forwarded.
I hope the above information will help you, if i have understood your question correctly.
Regards,
Jags
"smiley_raj@excite.com" <smiley_raj@excite.com> wrote:
Hi,
I have the following doubt,
If there is no RP in the network or all the RPs expire in the network. Can there be packet forwarding activity in a PIM-SM (only) domain. In clear my doubt is can the receivers switched over to the packet forwarding via SPT still continue to receive the data packets even if there is not RP information with him.
thanks in advance
rajesh,
Join Excite! -
<http://www.excite.com/>
The most personalized portal on the Web!
Catch all the cricket action. Download Yahoo! Score tracker <http://in.sports.yahoo.com/cricket/tracker.html>
Catch all the cricket action. Download Yahoo! Score tracker <http://in.sports.yahoo.com/cricket/tracker.html>
Catch all the cricket action. Download Yahoo! Score tracker
Catch all the cricket action. Download
Yahoo! Score tracker
--0-260930108-1040224222=:91139--
_______________________________________________
pim mailing list
pim@catarina.usc.edu
http://catarina.usc.edu/mailman/listinfo/pim
From pim-admin@catarina.usc.edu Wed Dec 18 10:40:30 2002
Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10962
for ; Wed, 18 Dec 2002 10:40:29 -0500 (EST)
Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1])
by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gBIFZFD91929;
Wed, 18 Dec 2002 07:35:15 -0800 (PST)
(envelope-from pim-admin@catarina.usc.edu)
Received: from web8206.mail.in.yahoo.com (web8206.mail.in.yahoo.com [203.199.70.75])
by catarina.usc.edu (8.11.6/8.11.6) with SMTP id gBIFYfD91899
for ; Wed, 18 Dec 2002 07:34:42 -0800 (PST)
(envelope-from john_nowa@yahoo.co.in)
Message-ID: <20021218153919.77202.qmail@web8206.mail.in.yahoo.com>
Received: from [12.27.183.253] by web8206.mail.in.yahoo.com via HTTP; Wed, 18 Dec 2002 15:39:19 GMT
From: =?iso-8859-1?q?john=20nowa?=
Subject: RE: [pim] doubt regard RP absence in the network
To: Rajamanickam jaganbabu ,
umac@future.futsoft.com
Cc: pim@catarina.usc.edu
In-Reply-To: <20021218151022.91347.qmail@web8205.mail.in.yahoo.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-153565159-1040225959=:76763"
Content-Transfer-Encoding: 8bit
Sender: pim-admin@catarina.usc.edu
Errors-To: pim-admin@catarina.usc.edu
X-BeenThere: pim@catarina.usc.edu
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Unsubscribe: ,
List-Id:
List-Post:
List-Help:
List-Subscribe: ,
List-Archive:
Date: Wed, 18 Dec 2002 15:39:19 +0000 (GMT)
--0-153565159-1040225959=:76763
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
hello umaaa,
I guess, whatever jags referring is correct. According to his topology, we can still forward the multicast packet for (S,G).
John
Rajamanickam jaganbabu wrote:
Hi uma,
Whatever I have mentioned below was only with respect to SM domain (I haven't mentioned SSM case, which is altogether a different story). I don't understand why you need to delete even (S,G) if you don't have (*,G), draft doesn't say that. But according to the draft, we need to remove only inherited outlist from (S,G) entry, but in our case we have immediate outgoing list in (S,G) which is not a part of inherited list (if the (S,G) immediate outlist and inherited outlist are same then only we should remove (S,G) entry from your multicast forwarding table), so there is no point and we should not delete (S,G) entry from the multicast routing table even if (*,G) entry is deleted.
I hope u understand the logic.
Regards,
Jags
Uma C wrote: Hello Jags Pl find my response inlined with the tag . RegardsC.Uma -----Original Message-----
From: pim-admin@catarina.usc.edu [mailto:pim-admin@catarina.usc.edu]On Behalf Of Rajamanickam jaganbabu
Sent: Wednesday, December 18, 2002 2:44 PM
To: umac@future.futsoft.com
Cc: pim@catarina.usc.edu
Subject: RE: [pim] doubt regard RP absence in the network
Hi uma,
1. Even in normal SM case, multicast forwarding is possible even if we don't have RP information.
[Uma C] I guess not. In the example you had given includes SSM also.
=========
2. When we are deleting (*,G) entry, it is not mandatory to remove all the (S,G) entry from the multicast forwarder unless and until all the outgoing interface list is null.
[Uma C] I agree with you. And in the SM case there cannot be a situation when (*,G) is deleted but (S,G) still remains.
==================
I have explained how it can happen using the following topology (fig. as an attachment).
Explanation:
1. If Rec_1 sends an (*,G) IGMP join to the PIM router "R1", then the PIM forwarding table at R1 look like
(*,G) - oiflist=1
2. After some time, if Rec_2 send (src,G,1) IGMPV3 join, then the PIM forwarding table at R1 looks like
(S,G) - oiflist=1,2
(*,G) - oiflist=1
In the above forwarding table while adding (S,G) entry, the inherited outgoing list will be 1 and the immediate outgoing list will be 2, so consolidating the outgoing interface for (S,G) will 1 and 2
3, In case, if RP goes off, then R1 has to remove the (*,G) entry from the forwarding table and remove the inherited outgoing list, so after the (*,G) removal, the multicast forwarder looks like this.
(S,G) - oiflist=2
[Uma C] Yes, multicast packets should flow on interface 2. I agree with this. But the discussion started with whether multicast packets can be forwarded in PIM-SM domain only (This is want Rajesh asked for) when RP information is not present. In this case do not execute the step 2, so the (*,G) and (S,G) will hold the same oif, and hence both of these entries get deleted. So the multicast packets stop flowing.
================
So even in SM. it is not necessary to remove all the (S,G) entries if you remove (*,G) entry from the multicast forwarding table.
[Uma C] I guess not in the SM domain (which doesnot include SSM). I apreciate the interest you had taken to explain the situation with a topology. Thanks Jags.
=================
Regards,
Jags
Uma C wrote:
Hello Jags
I guess in the case of IGMPv3, we do not create any (*,G) entry as the Group range for SSM is different. And as you said we can still forward the packets whether there is RP information or not.
But in the case of SM only, where (*,G) and (S,G) entry exists and (S,G) entry holds the oif of the (*,G), if the RP information is not present -
* (*,G) will be deleted and oif learnt from (*,G) will be deleted from (S,G) also, irrespective of whether local receivers present or not.
* When the RP information is learnt again, (*,G) entry would be re-created if the receivers are still present.
Do you still think if RP information is not present (in the case of SM only), multicast packets would flow ?
Thanks & Regards
C.Uma
-----Original Message-----
From: Rajamanickam jaganbabu [mailto:jaganbabu_pim@yahoo.co.in]
Sent: Wednesday, December 18, 2002 11:16 AM
To: umac@future.futsoft.com
Cc: smiley_raj@excite.com; pim@catarina.usc.edu
Subject: RE: [pim] doubt regard RP absence in the network
Hi Uma,
If there is an IGMPV3 request from the receiver, asking for (S,G,I) join to a particular source, then we will be having an (S,G) entry, which will be the super set of (*,G) outgoing list. If we lost (*,G) information, then it will affect (S,G) inherited outgoing list but there is a possible case where we can have immediate outgoing list exist for (S,G) (which is not in inherited outgoing list), so at this point even we delete (*,G) entry from our multicast forwarding table still (S,G) entry will be existing in the multicast forwarding table.
So my conclusion is, in the above case even if we lost our RP information, still we can forward the multicast packet using (S,G) information for a source "S".
Thanx,
Jags
Uma C wrote:
Hello Jags
When there is no RP information -
1. (*,G) entry would surely get deleted. Outgoing interface in that (*,G) and (S,G) also gets deleted. So how are the packets still flowing ?
2. If the (*,G) entry alone gets deleted because of the RP information not present and when the receiver leave the group, will the (S,G) entry get deleted ?. If yes how ? On what basis will this (S,G) entry get deleted.
I guess the entries at SPT built routers would get deleted only when source of the multicast packet stops sending packets.
I feel that, when the (*,G) entry gets deleted, (S,G) entry also would be deleted and there want be a case in which multicast packets will be flowing. Well I haven't thought about SSM case.
Pl correct me if I am in wrong in my understanding.
Thanks & Regards
C.Uma
-----Original Message-----
From: pim-admin@catarina.usc.edu [mailto:pim-admin@catarina.usc.edu]On Behalf Of Rajamanickam jaganbabu
Sent: Tuesday, December 17, 2002 8:38 PM
To: smiley_raj@excite.com; pim@catarina.usc.edu
Subject: Re: [pim] doubt regard RP absence in the network
Hi rajesh,
If the receiver and the source has the Source Path Tree established (i.e if we have (S,G) entry in the Multicast forwarding table), then irrespective of the RP information availability, the multicast packet will be forwarded.
I hope the above information will help you, if i have understood your question correctly.
Regards,
Jags
"smiley_raj@excite.com" wrote:
Hi,
I have the following doubt,
If there is no RP in the network or all the RPs expire in the network. Can there be packet forwarding activity in a PIM-SM (only) domain. In clear my doubt is can the receivers switched over to the packet forwarding via SPT still continue to receive the data packets even if there is not RP information with him.
thanks in advance
rajesh,
Join Excite! -
The most personalized portal on the Web!
Catch all the cricket action. Download Yahoo! Score tracker
Catch all the cricket action. Download Yahoo! Score tracker
Catch all the cricket action. Download Yahoo! Score tracker
Catch all the cricket action. Download Yahoo! Score tracker
Catch all the cricket action. Download Yahoo! Score tracker
--0-153565159-1040225959=:76763
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
hello umaaa,
I guess, whatever jags referring is correct. According to his topology, we can still forward the multicast packet for (S,G).
John
Rajamanickam jaganbabu <jaganbabu_pim@yahoo.co.in> wrote:
Hi uma,
Whatever I have mentioned below was only with respect to SM domain (I haven't mentioned SSM case, which is altogether a different story). I don't understand why you need to delete even (S,G) if you don't have (*,G), draft doesn't say that. But according to the draft, we need to remove only inherited outlist from (S,G) entry, but in our case we have immediate outgoing list in (S,G) which is not a part of inherited list (if the (S,G) immediate outlist and inherited outlist are same then only we should remove (S,G) entry from your multicast forwarding table), so there is no point and we should not delete (S,G) entry from the multicast routing table even if (*,G) entry is deleted.
I hope u understand the logic.
Regards,
Jags
Uma C <umac@future.futsoft.com> wrote:
Hello Jags
Pl find my response inlined with the tag <UMA>.
Regards
C.Uma
Hi uma,
1. Even in normal SM case, multicast forwarding is possible even if we don't have RP information.
[Uma C] I guess not. In the example you had given includes SSM also.
=========
2. When we are deleting (*,G) entry, it is not mandatory to remove all the (S,G) entry from the multicast forwarder unless and until all the outgoing interface list is null.
[Uma C] I agree with you. And in the SM case there cannot be a situation when (*,G) is deleted but (S,G) still remains.
==================
I have explained how it can happen using the following topology (fig. as an attachment).
Explanation:
1. If Rec_1 sends an (*,G) IGMP join to the PIM router "R1", then the PIM forwarding table at R1 look like
(*,G) - oiflist=1
2. After some time, if Rec_2 send (src,G,1) IGMPV3 join, then the PIM forwarding table at R1 looks like
(S,G) - oiflist=1,2
(*,G) - oiflist=1
In the above forwarding table while adding (S,G) entry, the inherited outgoing list will be 1 and the immediate outgoing list will be 2, so consolidating the outgoing interface for (S,G) will 1 and 2
3, In case, if RP goes off, then R1 has to remove the (*,G) entry from the forwarding table and remove the inherited outgoing list, so after the (*,G) removal, the multicast forwarder looks like this.
(S,G) - oiflist=2
[Uma C] Yes, multicast packets should flow on interface 2. I agree with this. But the discussion started with whether multicast packets can be forwarded in PIM-SM domain only (This is want Rajesh asked for) when RP information is not present. In this case do not execute the step 2, so the (*,G) and (S,G) will hold the same oif, and hence both of these entries get deleted. So the multicast packets stop flowing.
================
So even in SM. it is not necessary to remove all the (S,G) entries if you remove (*,G) entry from the multicast forwarding table.
[Uma C] I guess not in the SM domain (which doesnot include SSM). I apreciate the interest you had taken to explain the situation with a topology. Thanks Jags.
=================
Regards,
Jags
Uma C <umac@future.futsoft.com>
wrote:
Hello Jags
I guess in the case of IGMPv3, we do not create any (*,G) entry as the Group range for SSM is different. And as you said we can still forward the packets whether there is RP information or not.
But in the case of SM only, where (*,G) and (S,G) entry exists and (S,G) entry holds the oif of the (*,G), if the RP information is not present -
* (*,G) will be deleted and oif learnt from (*,G) will be deleted from (S,G) also, irrespective of whether local receivers present or not.
* When the RP information is learnt again, (*,G) entry would be re-created if the receivers are still present.
Do you still think if RP information is not present (in the case of SM only), multicast packets would flow ?
Thanks & Regards
C.Uma
-----Original Message-----
From: Rajamanickam jaganbabu [mailto:jaganbabu_pim@yahoo.co.in]
Sent: Wednesday, December 18, 2002 11:16 AM
To: umac@future.futsoft.com
Cc: smiley_raj@excite.com; pim@catarina.usc.edu
Subject: RE: [pim] doubt regard RP absence in the network
Hi Uma,
If there is an IGMPV3 request from the receiver, asking for (S,G,I) join to a particular source, then we will be having an (S,G) entry, which will be the super set of (*,G) outgoing list. If we lost (*,G) information, then it will affect (S,G) inherited outgoing list but there is a possible case where we can have immediate outgoing list exist for (S,G) (which is not in inherited outgoing list), so at this point even we delete (*,G) entry from our multicast forwarding table still (S,G) entry will be existing in the multicast forwarding table.
So my conclusion is, in the above case even if we lost our RP information, still we can forward the multicast packet using (S,G) information for a source "S".
Thanx,
Jags
Uma C <umac@future.futsoft.com> wrote:
Hello Jags
When there is no RP information -
1. (*,G) entry would surely get deleted. Outgoing interface in that (*,G) and (S,G) also gets deleted. So how are the packets still flowing ?
2. If the (*,G) entry alone gets deleted because of the RP information not present and when the receiver leave the group, will the (S,G) entry get deleted ?. If yes how ? On what basis will this (S,G) entry get deleted.
I guess the entries at SPT built routers would get deleted only when source of the multicast packet stops sending packets.
I feel that, when the (*,G) entry gets deleted, (S,G) entry also would be deleted and there want be a case in which multicast packets will be flowing. Well I haven't thought about SSM case.
Pl correct me if I am in wrong in my understanding.
Thanks & Regards
C.Uma
-----Original Message-----
From: pim-admin@catarina.usc.edu [mailto:pim-admin@catarina.usc.edu]On Behalf Of Rajamanickam jaganbabu
Sent: Tuesday, December 17, 2002 8:38 PM
To: smiley_raj@excite.com; pim@catarina.usc.edu
Subject: Re: [pim] doubt regard RP absence in the network
Hi rajesh,
If the receiver and the source has the Source Path Tree established (i.e if we have (S,G) entry in the Multicast forwarding table), then irrespective of the RP information availability, the multicast packet will be forwarded.
I hope the above information will help you, if i have understood your question correctly.
Regards,
Jags
"smiley_raj@excite.com" <smiley_raj@excite.com> wrote:
Hi,
I have the following doubt,
If there is no RP in the network or all the RPs expire in the network. Can there be packet forwarding activity in a PIM-SM (only) domain. In clear my doubt is can the receivers switched over to the packet forwarding via SPT still continue to receive the data packets even if there is not RP information with him.
thanks in advance
rajesh,
Join Excite! -
<http://www.excite.com/>
The most personalized portal on the Web!
Catch all the cricket action. Download Yahoo! Score tracker <http://in.sports.yahoo.com/cricket/tracker.html>
Catch all the cricket action. Download Yahoo! Score tracker <http://in.sports.yahoo.com/cricket/tracker.html>
Catch all the cricket action. Download Yahoo! Score tracker
Catch all the cricket action. Download Yahoo! Score tracker
Catch all the cricket action. Download
Yahoo! Score tracker
--0-153565159-1040225959=:76763--
_______________________________________________
pim mailing list
pim@catarina.usc.edu
http://catarina.usc.edu/mailman/listinfo/pim
From pim-admin@catarina.usc.edu Wed Dec 18 18:31:50 2002
Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21926
for ; Wed, 18 Dec 2002 18:31:49 -0500 (EST)
Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1])
by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gBINPsD97570;
Wed, 18 Dec 2002 15:25:54 -0800 (PST)
(envelope-from pim-admin@catarina.usc.edu)
Received: from possum.icir.org (possum.icir.org [192.150.187.67])
by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gBINOUD97534
for ; Wed, 18 Dec 2002 15:24:30 -0800 (PST)
(envelope-from pavlin@possum.icir.org)
Received: from possum.icir.org (localhost [127.0.0.1])
by possum.icir.org (8.12.3/8.12.3) with ESMTP id gBINTG2U093046;
Wed, 18 Dec 2002 15:29:16 -0800 (PST)
(envelope-from pavlin@possum.icir.org)
Message-Id: <200212182329.gBINTG2U093046@possum.icir.org>
To: "Bandi, Sarveshwar"
cc: pim@catarina.usc.edu
Subject: Re: [pim] Query on Upstream(S,G,rpt) State machine for triggered messages
In-Reply-To: Message from "Bandi, Sarveshwar"
of "Wed, 18 Dec 2002 04:42:17 EST."
From: Pavlin Radoslavov
Sender: pim-admin@catarina.usc.edu
Errors-To: pim-admin@catarina.usc.edu
X-BeenThere: pim@catarina.usc.edu
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Unsubscribe: ,
List-Id:
List-Post:
List-Help:
List-Subscribe: ,
List-Archive:
Date: Wed, 18 Dec 2002 15:29:16 -0800
> Hi,
> In the state machine for (S,G,rpt) triggered messages (Section 4.5.9) the
> state tranistions from "RPTNotJoined" to "Not Pruned" occurs when
> "inherited_olist(S,G,rpt)--> NON-NULL" and the reverse state tranistion from
> "Not Pruned" to "RPTNotJoined" occurs when "RPTJoinDesired(G)-->False". My
> question is why shouldnt we use the "RPTJoinDesired(G)--> TRUE" event for
> the former state tranistion (i.e) from "RPTNotJoined" to "Not Pruned".
> Doesnt this event itself convey that we have joined the RPT and thus should
> be in the Not Pruned state?
My guess is:
(a) We want the "Not Pruned" to "RPTNotJoined" transaction to occur
when "RPTJoinDesired(G)-->False", because the "RPTNotJoined" state
is the equivalent of the state when we don't need the (S,G,rpt)
state. Keeping the (S,G,rpt) state makes sense only if there is
(*,G) or (*,*,RP) Join, hence the "granularity" of this
transaction happening is "per (*,G)" or "per (*,*,RP)"
(by "granularity" here I mean that it happens when there is (*,G)
or (*,*,RP)-specific event such as (*,*,RP) or (*,G) Join).
(b) The "RPTNotJoined" to "Not Pruned" transaction uses the
"inherited_olist(S,G,rpt)--> NON-NULL" event, because for
data forwarding purpose the granularity is "per source-group", and
therefore it needs to consider things like "lost_assert(S,G,rpt)"
which are used in the computation of "inherited_olist(S,G,rpt),
but are NOT used in the computation of "RPTJoinDesired(G)"
Regards,
Pavlin
_______________________________________________
pim mailing list
pim@catarina.usc.edu
http://catarina.usc.edu/mailman/listinfo/pim
From pim-admin@catarina.usc.edu Thu Dec 19 00:48:04 2002
Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29830
for ; Thu, 19 Dec 2002 00:48:03 -0500 (EST)
Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1])
by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gBJ5fsD02285;
Wed, 18 Dec 2002 21:41:54 -0800 (PST)
(envelope-from pim-admin@catarina.usc.edu)
Received: from fsnt.future.futsoft.com ([203.197.140.35])
by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gBJ5eoD02262
for ; Wed, 18 Dec 2002 21:40:51 -0800 (PST)
(envelope-from umac@future.futsoft.com)
Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com
(Content Technologies SMTPRS 2.0.15) with ESMTP id ;
Thu, 19 Dec 2002 11:18:44 +0530
Received: from umac (umac.future.futsoft.com [10.20.6.25])
by kailash.future.futsoft.com (8.12.2/8.12.2) with SMTP id gBJ5VxUi008827;
Thu, 19 Dec 2002 11:01:59 +0530
Reply-To:
From: "Uma C"
To: "'john nowa'" ,
"'Rajamanickam jaganbabu'"
Cc:
Subject: RE: [pim] doubt regard RP absence in the network
Message-Id: <001201c2a722$7d313a20$1906140a@future.futsoft.com>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Importance: Normal
In-Reply-To: <20021218153919.77202.qmail@web8206.mail.in.yahoo.com>
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0013_01C2A750.96E97620"
Sender: pim-admin@catarina.usc.edu
Errors-To: pim-admin@catarina.usc.edu
X-BeenThere: pim@catarina.usc.edu
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Unsubscribe: ,
List-Id:
List-Post:
List-Help:
List-Subscribe: ,
List-Archive:
Date: Thu, 19 Dec 2002 11:20:07 +0530
This is a multi-part message in MIME format.
------=_NextPart_000_0013_01C2A750.96E97620
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Hello John & Jags
I also agreed upon what Jags has mentioned in his topology.
>>> 3, In case, if RP goes off, then R1 has to remove the (*,G) entry from
the forwarding table and remove the inherited outgoing list, so after the
(*,G) removal, the multicast forwarder looks like this.
>>> (S,G) - oiflist=2
>>> [Uma C] Yes, multicast packets should flow on interface 2. I agree with
this.
Pl confirm only this -
* Received IGMPv2 Join, created a (*,G) entry.
* Switched to SPT, hence (S,G) entry is created. (*, G) and (S, G) entry
holds the same oif.
* Packets are flowing through SPT.
* Now when the RP information is not present. (*,G) entry is deleted.
Will the (S,G) entry exists ? Would the data packets flow ?.
Note:- In all this discussion I was only referring to receivers joining
through IGMPv2 Join. In the case of IGMPv3 Join ie., source specific Join I
agree that packets will be flowing irrespective of RP informations present
or not.
Hope this time I have expressed my thoughts clearly.
Thanks & Regards
C.Uma
-----Original Message-----
From: john nowa [mailto:john_nowa@yahoo.co.in]
Sent: Wednesday, December 18, 2002 9:09 PM
To: Rajamanickam jaganbabu; umac@future.futsoft.com
Cc: pim@catarina.usc.edu
Subject: RE: [pim] doubt regard RP absence in the network
hello umaaa,
I guess, whatever jags referring is correct. According to his
topology, we can still forward the multicast packet for (S,G).
John
Rajamanickam jaganbabu wrote:
Hi uma,
Whatever I have mentioned below was only with respect to SM domain (I
haven't mentioned SSM case, which is altogether a different story). I don't
understand why you need to delete even (S,G) if you don't have (*,G), draft
doesn't say that. But according to the draft, we need to remove only
inherited outlist from (S,G) entry, but in our case we have immediate
outgoing list in (S,G) which is not a part of inherited list (if the (S,G)
immediate outlist and inherited outlist are same then only we should remove
(S,G) entry from your multicast forwarding table), so there is no point and
we should not delete (S,G) entry from the multicast routing table even if
(*,G) entry is deleted.
I hope u understand the logic.
Regards,
Jags
Uma C wrote:
Hello Jags
Pl find my response inlined with the tag .
Regards
C.Uma
-----Original Message-----
From: pim-admin@catarina.usc.edu
[mailto:pim-admin@catarina.usc.edu]On Behalf Of Rajamanickam jaganbabu
Sent: Wednesday, December 18, 2002 2:44 PM
To: umac@future.futsoft.com
Cc: pim@catarina.usc.edu
Subject: RE: [pim] doubt regard RP absence in the network
Hi uma,
1. Even in normal SM case, multicast forwarding is possible even if
we don't have RP information.
[Uma C] I guess not. In the example you had given includes SSM also.
=========
2. When we are deleting (*,G) entry, it is not mandatory to remove
all the (S,G) entry from the multicast forwarder unless and until all the
outgoing interface list is null.
[Uma C] I agree with you. And in the SM case there cannot be a
situation when (*,G) is deleted but (S,G) still remains.
==================
I have explained how it can happen using the following topology
(fig. as an attachment).
Explanation:
1. If Rec_1 sends an (*,G) IGMP join to the PIM router "R1", then
the PIM forwarding table at R1 look like
(*,G) - oiflist=1
2. After some time, if Rec_2 send (src,G,1) IGMPV3 join, then the
PIM forwarding table at R1 looks like
(S,G) - oiflist=1,2
(*,G) - oiflist=1
In the above forwarding table while adding (S,G) entry, the
inherited outgoing list will be 1 and the immediate outgoing list will be 2,
so consolidating the outgoing interface for (S,G) will 1 and 2
3, In case, if RP goes off, then R1 has to remove the (*,G) entry
from the forwarding table and remove the inherited outgoing list, so after
the (*,G) removal, the multicast forwarder looks like this.
(S,G) - oiflist=2
[Uma C] Yes, multicast packets should flow on interface 2. I agree
with this. But the discussion started with whether multicast packets can be
forwarded in PIM-SM domain only (This is want Rajesh asked for) when RP
information is not present. In this case do not execute the step 2, so the
(*,G) and (S,G) will hold the same oif, and hence both of these entries get
deleted. So the multicast packets stop flowing.
================
So even in SM. it is not necessary to remove all the (S,G) entries
if you remove (*,G) entry from the multicast forwarding table.
[Uma C] I guess not in the SM domain (which doesnot include SSM). I
apreciate the interest you had taken to explain the situation with a
topology. Thanks Jags.
=================
Regards,
Jags
Uma C wrote:
Hello Jags
I guess in the case of IGMPv3, we do not create any (*,G) entry as
the Group range for SSM is different. And as you said we can still forward
the packets whether there is RP information or not.
But in the case of SM only, where (*,G) and (S,G) entry exists and
(S,G) entry holds the oif of the (*,G), if the RP information is not
present -
* (*,G) will be deleted and oif learnt from (*,G) will be deleted
from (S,G) also, irrespective of whether local receivers present or not.
* When the RP information is learnt again, (*,G) entry would be
re-created if the receivers are still present.
Do you still think if RP information is not present (in the case of
SM only), multicast packets would flow ?
Thanks & Regards
C.Uma
-----Original Message-----
From: Rajamanickam jaganbabu [mailto:jaganbabu_pim@yahoo.co.in]
Sent: Wednesday, December 18, 2002 11:16 AM
To: umac@future.futsoft.com
Cc: smiley_raj@excite.com; pim@catarina.usc.edu
Subject: RE: [pim] doubt regard RP absence in the network
Hi Uma,
If there is an IGMPV3 request from the receiver, asking for (S,G,I)
join to a particular source, then we will be having an (S,G) entry, which
will be the super set of (*,G) outgoing list. If we lost (*,G) information,
then it will affect (S,G) inherited outgoing list but there is a possible
case where we can have immediate outgoing list exist for (S,G) (which is not
in inherited outgoing list), so at this point even we delete (*,G) entry
from our multicast forwarding table still (S,G) entry will be existing in
the multicast forwarding table.
So my conclusion is, in the above case even if we lost our RP
information, still we can forward the multicast packet using (S,G)
information for a source "S".
Thanx,
Jags
Uma C wrote:
Hello Jags
When there is no RP information -
1. (*,G) entry would surely get deleted. Outgoing interface in that
(*,G) and (S,G) also gets deleted. So how are the packets still flowing ?
2. If the (*,G) entry alone gets deleted because of the RP
information not present and when the receiver leave the group, will the
(S,G) entry get deleted ?. If yes how ? On what basis will this (S,G) entry
get deleted.
I guess the entries at SPT built routers would get deleted only when
source of the multicast packet stops sending packets.
I feel that, when the (*,G) entry gets deleted, (S,G) entry also
would be deleted and there want be a case in which multicast packets will be
flowing. Well I haven't thought about SSM case.
Pl correct me if I am in wrong in my understanding.
Thanks & Regards
C.Uma
-----Original Message-----
From: pim-admin@catarina.usc.edu
[mailto:pim-admin@catarina.usc.edu]On Behalf Of Rajamanickam jaganbabu
Sent: Tuesday, December 17, 2002 8:38 PM
To: smiley_raj@excite.com; pim@catarina.usc.edu
Subject: Re: [pim] doubt regard RP absence in the network
Hi rajesh,
If the receiver and the source has the Source Path Tree established
(i.e if we have (S,G) entry in the Multicast forwarding table), then
irrespective of the RP information availability, the multicast packet will
be forwarded.
I hope the above information will help you, if i have understood
your question correctly.
Regards,
Jags
"smiley_raj@excite.com" wrote:
Hi,
I have the following doubt,
If there is no RP in the network or all the RPs expire in the
network. Can there be packet forwarding activity in a PIM-SM (only) domain.
In clear my doubt is can the receivers switched over to the packet
forwarding via SPT still continue to receive the data packets even if there
is not RP information with him.
thanks in advance
rajesh,
Join Excite! -
The most personalized portal on the Web!
Catch all the cricket action. Download Yahoo! Score tracker
Catch all the cricket action. Download Yahoo! Score tracker
Catch all the cricket action. Download Yahoo! Score tracker
Catch all the cricket action. Download Yahoo! Score tracker
Catch all the cricket action. Download Yahoo! Score tracker
------=_NextPart_000_0013_01C2A750.96E97620
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello=20
John & Jags
I=20
also agreed upon what Jags has mentioned in his topology.=20
>>> 3, In case, if RP goes off, =
then R1 has=20
to remove the (*,G) entry from the forwarding table and remove the =
inherited=20
outgoing list, so after the =
(*,G)=20
removal, the multicast forwarder looks like this.
>>> (S,G) =
-=20
oiflist=3D2
>>>=20
[Uma C] Yes, multicast packets should flow on =
interface=20
2. I agree with this.
Pl=20
confirm only this -
*=20
Received IGMPv2 Join, created a (*,G) entry.
*=20
Switched to SPT, hence (S,G) entry is created. (*, G) and (S, G) entry =
holds the=20
same oif.
*=20
Packets are flowing through SPT.
* Now=20
when the RP information is not present. (*,G) entry is=20
deleted.
Will=20
the (S,G) entry exists ? Would the data packets flow ?. =
Note:-=20
In all this discussion I was only referring to receivers joining through =
IGMPv2=20
Join. In the case of IGMPv3 Join ie., source specific Join I agree that =
packets=20
will be flowing irrespective of RP informations present or=20
not.
Hope=20
this time I have expressed my thoughts clearly.
Thanks=20
& Regards
C.Uma
hello umaaa,=20
I guess, whatever jags =
referring is=20
correct. According to his topology, we can still forward the multicast =
packet=20
for (S,G).=20
John=20
Rajamanickam jaganbabu=20
<jaganbabu_pim@yahoo.co.in> wrote:=20
Hi uma,
Whatever I have mentioned below was only with respect to SM =
domain (I=20
haven't mentioned SSM case, which is altogether a different story). =
I don't=20
understand why you need to delete even (S,G) if you don't have =
(*,G), draft=20
doesn't say that. But according to the draft, we need to remove only =
inherited outlist from (S,G) entry, but in our case we have =
immediate=20
outgoing list in (S,G) which is not a part of inherited list (if the =
(S,G)=20
immediate outlist and inherited outlist are same then only we should =
remove=20
(S,G) entry from your multicast forwarding table), so there is no =
point and=20
we should not delete (S,G) entry from the multicast routing table =
even if=20
(*,G) entry is deleted.
I hope u understand the logic.
Regards,
Jags
Uma C <umac@future.futsoft.com> wrote:=20
Hello Jags
Pl find my response inlined with the =
tag=20
<UMA>.
Regards
C.Uma
Hi uma,
1. Even in normal SM case, multicast =
forwarding is=20
possible even if we don't have RP information.
[Uma C] I =
guess=20
not. In the example you had given includes SSM=20
also.
=3D=3D=3D=3D=3D=3D=3D=3D=3D
2. When we are deleting (*,G) entry, it is not =
mandatory=20
to remove all the (S,G) entry from the multicast forwarder =
unless and=20
until all the outgoing interface list is null.
[Uma C] I =
agree with you.=20
And in the SM case there cannot be a situation when =
(*,G) is=20
deleted but (S,G) still remains.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
I have explained how it can happen using the =
following=20
topology (fig. as an attachment).
Explanation:
1. If Rec_1 sends an (*,G) IGMP join to the =
PIM router=20
"R1", then the PIM forwarding table at R1 look like
(*,G) - oiflist=3D1
2. After some time, if Rec_2 send (src,G,1) =
IGMPV3 join,=20
then the PIM forwarding table at R1 looks like
(S,G) - oiflist=3D1,2
(*,G) - oiflist=3D1
In the above forwarding table while adding =
(S,G) entry,=20
the inherited outgoing list will be 1 and the immediate outgoing =
list=20
will be 2, so consolidating the outgoing interface for (S,G) =
will 1 and=20
2
3, In case, if RP goes off, then R1 has to =
remove the=20
(*,G) entry from the forwarding table and remove the inherited =
outgoing=20
list, so after the (*,G) removal, the multicast forwarder looks =
like=20
this.
(S,G) - oiflist=3D2
[Uma C] =20
Yes, multicast packets should flow on interface 2. I =
agree=20
with this. But the discussion started with whether =
multicast=20
packets can be forwarded in PIM-SM domain only (This is =
want Rajesh=20
asked for) when RP information is not present. In this case do =
not=20
execute the step 2, so the (*,G) and (S,G) will hold the same =
oif, and=20
hence both of these entries get deleted. So the multicast =
packets stop=20
flowing.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
So even in SM. it is not necessary to remove =
all the=20
(S,G) entries if you remove (*,G) entry from the multicast =
forwarding=20
table.
[Uma C] I guess not in the SM =
domain=20
(which doesnot include SSM). I=20
apreciate the interest you had taken to explain the =
situation with=20
a topology. Thanks Jags.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Regards,
Jags
Uma C <umac@future.futsoft.com>
wrote:
Hello Jags
=
I guess in the case of IGMPv3, we do not create any (*,G) =
entry as=20
the Group range for SSM is different. And as you said we can =
still=20
forward the packets whether there is RP information or =
not.
But in the case of SM only, where (*,G) and (S,G) entry =
exists and=20
(S,G) entry holds the oif of the (*,G), if the RP information is =
not=20
present -
* (*,G) will be deleted and oif learnt from (*,G) will be =
deleted=20
from (S,G) also, irrespective of whether local receivers present =
or=20
not.
* When the RP information is learnt again, (*,G) entry would =
be=20
re-created if the receivers are still present.
Do you still think if RP information is not present (in the =
case of=20
SM only), multicast packets would flow ?
Thanks & Regards
=20
C.Uma
-----Original Message-----
From: Rajamanickam =
jaganbabu=20
[mailto:jaganbabu_pim@yahoo.co.in]
Sent: Wednesday, =
December=20
18, 2002 11:16 AM
To: =
umac@future.futsoft.com
Cc:=20
smiley_raj@excite.com; pim@catarina.usc.edu
Subject: =
RE: [pim]=20
doubt regard RP absence in the network
Hi Uma,
If there is an IGMPV3 request from the receiver, asking for =
(S,G,I)=20
join to a particular source, then we will be having an (S,G) =
entry,=20
which will be the super set of (*,G) outgoing list. If we lost =
(*,G)=20
information, then it will affect (S,G) inherited outgoing list =
but there=20
is a possible case where we can have immediate outgoing list =
exist for=20
(S,G) (which is not in inherited outgoing list), so at this =
point even=20
we delete (*,G) entry from our multicast forwarding table still =
(S,G)=20
entry will be existing in the multicast forwarding table.
So my conclusion is, in the above case even if we lost our RP =
information, still we can forward the multicast packet using =
(S,G)=20
information for a source "S".
Thanx,
Jags
Uma C <umac@future.futsoft.com> wrote:
Hello Jags
=
When there is no RP information -
=20
1. (*,G) entry would surely get deleted. Outgoing interface =
in that=20
(*,G) and (S,G) also gets deleted. So how are the packets still =
flowing=20
?
2. If the (*,G) entry alone gets deleted because of the RP=20
information not present and when the receiver leave the group, =
will the=20
(S,G) entry get deleted ?. If yes how ? On what basis will this =
(S,G)=20
entry get deleted.
=
I guess the entries at SPT built routers would get deleted =
only when=20
source of the multicast packet stops sending =
packets.
I feel that, when the (*,G) entry gets deleted, (S,G) entry =
also=20
would be deleted and there want be a case in which multicast =
packets=20
will be flowing. Well I haven't thought about SSM =
case.
Pl correct me if I am in wrong in my understanding.
Thanks & Regards
C.Uma
-----Original Message-----
From: =
pim-admin@catarina.usc.edu=20
[mailto:pim-admin@catarina.usc.edu]On Behalf Of =
Rajamanickam=20
jaganbabu
Sent: Tuesday, December 17, 2002 8:38=20
PM
To: smiley_raj@excite.com;=20
pim@catarina.usc.edu
Subject: Re: [pim] doubt regard =
RP=20
absence in the network
Hi rajesh,
If the receiver and the source has the Source Path Tree =
established=20
(i.e if we have (S,G) entry in the Multicast forwarding table), =
then=20
irrespective of the RP information availability, the multicast =
packet=20
will be forwarded.
I hope the above information will help you, if i have =
understood your=20
question correctly.
Regards,
Jags
"smiley_raj@excite.com" <smiley_raj@excite.com> =
wrote:=20
Hi,
I have the following doubt,
If there is no RP =
in the=20
network or all the RPs expire in the network. Can there be =
packet=20
forwarding activity in a PIM-SM (only) domain. In clear my doubt =
is can=20
the receivers switched over to the packet forwarding via SPT =
still=20
continue to receive the data packets even if there is not RP =
information=20
with him.
thanks in advance
rajesh,
Join Excite! -
<http://www.excite.com/>
The most personalized portal on the =
Web!
Catch all the=20
cricket action. Download Yahoo! Score tracker=20
=
<http://in.sports.yahoo.com/cricket/tracker.html>=
U>
Catch all the=20
cricket action. Download Yahoo! Score tracker=20
=
<http://in.sports.yahoo.com/cricket/tracker.html>
Catch all the cricket action. Download =
Yahoo! Score =
tracker
Catch all the cricket action. Download Yahoo!=20
Score tracker
Catch all the cricket action. Download Yahoo!=20
Score tracker
------=_NextPart_000_0013_01C2A750.96E97620--
_______________________________________________
pim mailing list
pim@catarina.usc.edu
http://catarina.usc.edu/mailman/listinfo/pim
From pim-admin@catarina.usc.edu Thu Dec 19 03:55:05 2002
Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11887
for ; Thu, 19 Dec 2002 03:55:04 -0500 (EST)
Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1])
by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gBJ8ltD04625;
Thu, 19 Dec 2002 00:47:55 -0800 (PST)
(envelope-from pim-admin@catarina.usc.edu)
Received: from web8204.mail.in.yahoo.com (web8204.mail.in.yahoo.com [203.199.70.124])
by catarina.usc.edu (8.11.6/8.11.6) with SMTP id gBJ8k4D04600
for ; Thu, 19 Dec 2002 00:46:04 -0800 (PST)
(envelope-from jaganbabu_pim@yahoo.co.in)
Message-ID: <20021219085047.47593.qmail@web8204.mail.in.yahoo.com>
Received: from [12.27.183.253] by web8204.mail.in.yahoo.com via HTTP; Thu, 19 Dec 2002 08:50:47 GMT
From: =?iso-8859-1?q?Rajamanickam=20jaganbabu?=
Subject: RE: [pim] doubt regard RP absence in the network
To: umac@future.futsoft.com, "'john nowa'"
Cc: pim@catarina.usc.edu
In-Reply-To: <001201c2a722$7d313a20$1906140a@future.futsoft.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1429828762-1040287847=:46093"
Content-Transfer-Encoding: 8bit
Sender: pim-admin@catarina.usc.edu
Errors-To: pim-admin@catarina.usc.edu
X-BeenThere: pim@catarina.usc.edu
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Unsubscribe: ,
List-Id:
List-Post:
List-Help:
List-Subscribe: ,
List-Archive:
Date: Thu, 19 Dec 2002 08:50:47 +0000 (GMT)
--0-1429828762-1040287847=:46093
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Hi Uma,
I think, you need to read my topology properly, where i have mensioned about IGMPV3 and not IGMPV2. If you spend some time to read the topology properly, you might not be having such a doubts (IGMPV3/V2).
Regards,
Jags
Uma C wrote:Hello John & Jags I also agreed upon what Jags has mentioned in his topology.
>>> 3, In case, if RP goes off, then R1 has to remove the (*,G) entry from the forwarding table and remove the inherited outgoing list, so after the (*,G) removal, the multicast forwarder looks like this.
>>> (S,G) - oiflist=2
>>> [Uma C] Yes, multicast packets should flow on interface 2. I agree with this.
Pl confirm only this -* Received IGMPv2 Join, created a (*,G) entry. * Switched to SPT, hence (S,G) entry is created. (*, G) and (S, G) entry holds the same oif. * Packets are flowing through SPT.* Now when the RP information is not present. (*,G) entry is deleted. Will the (S,G) entry exists ? Would the data packets flow ?. Note:- In all this discussion I was only referring to receivers joining through IGMPv2 Join. In the case of IGMPv3 Join ie., source specific Join I agree that packets will be flowing irrespective of RP informations present or not. Hope this time I have expressed my thoughts clearly. Thanks & RegardsC.Uma -----Original Message-----
From: john nowa [mailto:john_nowa@yahoo.co.in]
Sent: Wednesday, December 18, 2002 9:09 PM
To: Rajamanickam jaganbabu; umac@future.futsoft.com
Cc: pim@catarina.usc.edu
Subject: RE: [pim] doubt regard RP absence in the network
hello umaaa,
I guess, whatever jags referring is correct. According to his topology, we can still forward the multicast packet for (S,G).
John
Rajamanickam jaganbabu wrote:
Hi uma,
Whatever I have mentioned below was only with respect to SM domain (I haven't mentioned SSM case, which is altogether a different story). I don't understand why you need to delete even (S,G) if you don't have (*,G), draft doesn't say that. But according to the draft, we need to remove only inherited outlist from (S,G) entry, but in our case we have immediate outgoing list in (S,G) which is not a part of inherited list (if the (S,G) immediate outlist and inherited outlist are same then only we should remove (S,G) entry from your multicast forwarding table), so there is no point and we should not delete (S,G) entry from the multicast routing table even if (*,G) entry is deleted.
I hope u understand the logic.
Regards,
Jags
Uma C wrote: Hello Jags Pl find my response inlined with the tag . RegardsC.Uma -----Original Message-----
From: pim-admin@catarina.usc.edu [mailto:pim-admin@catarina.usc.edu]On Behalf Of Rajamanickam jaganbabu
Sent: Wednesday, December 18, 2002 2:44 PM
To: umac@future.futsoft.com
Cc: pim@catarina.usc.edu
Subject: RE: [pim] doubt regard RP absence in the network
Hi uma,
1. Even in normal SM case, multicast forwarding is possible even if we don't have RP information.
[Uma C] I guess not. In the example you had given includes SSM also.
=========
2. When we are deleting (*,G) entry, it is not mandatory to remove all the (S,G) entry from the multicast forwarder unless and until all the outgoing interface list is null.
[Uma C] I agree with you. And in the SM case there cannot be a situation when (*,G) is deleted but (S,G) still remains.
==================
I have explained how it can happen using the following topology (fig. as an attachment).
Explanation:
1. If Rec_1 sends an (*,G) IGMP join to the PIM router "R1", then the PIM forwarding table at R1 look like
(*,G) - oiflist=1
2. After some time, if Rec_2 send (src,G,1) IGMPV3 join, then the PIM forwarding table at R1 looks like
(S,G) - oiflist=1,2
(*,G) - oiflist=1
In the above forwarding table while adding (S,G) entry, the inherited outgoing list will be 1 and the immediate outgoing list will be 2, so consolidating the outgoing interface for (S,G) will 1 and 2
3, In case, if RP goes off, then R1 has to remove the (*,G) entry from the forwarding table and remove the inherited outgoing list, so after the (*,G) removal, the multicast forwarder looks like this.
(S,G) - oiflist=2
[Uma C] Yes, multicast packets should flow on interface 2. I agree with this. But the discussion started with whether multicast packets can be forwarded in PIM-SM domain only (This is want Rajesh asked for) when RP information is not present. In this case do not execute the step 2, so the (*,G) and (S,G) will hold the same oif, and hence both of these entries get deleted. So the multicast packets stop flowing.
================
So even in SM. it is not necessary to remove all the (S,G) entries if you remove (*,G) entry from the multicast forwarding table.
[Uma C] I guess not in the SM domain (which doesnot include SSM). I apreciate the interest you had taken to explain the situation with a topology. Thanks Jags.
=================
Regards,
Jags
Uma C wrote:
Hello Jags
I guess in the case of IGMPv3, we do not create any (*,G) entry as the Group range for SSM is different. And as you said we can still forward the packets whether there is RP information or not.
But in the case of SM only, where (*,G) and (S,G) entry exists and (S,G) entry holds the oif of the (*,G), if the RP information is not present -
* (*,G) will be deleted and oif learnt from (*,G) will be deleted from (S,G) also, irrespective of whether local receivers present or not.
* When the RP information is learnt again, (*,G) entry would be re-created if the receivers are still present.
Do you still think if RP information is not present (in the case of SM only), multicast packets would flow ?
Thanks & Regards
C.Uma
-----Original Message-----
From: Rajamanickam jaganbabu [mailto:jaganbabu_pim@yahoo.co.in]
Sent: Wednesday, December 18, 2002 11:16 AM
To: umac@future.futsoft.com
Cc: smiley_raj@excite.com; pim@catarina.usc.edu
Subject: RE: [pim] doubt regard RP absence in the network
Hi Uma,
If there is an IGMPV3 request from the receiver, asking for (S,G,I) join to a particular source, then we will be having an (S,G) entry, which will be the super set of (*,G) outgoing list. If we lost (*,G) information, then it will affect (S,G) inherited outgoing list but there is a possible case where we can have immediate outgoing list exist for (S,G) (which is not in inherited outgoing list), so at this point even we delete (*,G) entry from our multicast forwarding table still (S,G) entry will be existing in the multicast forwarding table.
So my conclusion is, in the above case even if we lost our RP information, still we can forward the multicast packet using (S,G) information for a source "S".
Thanx,
Jags
Uma C wrote:
Hello Jags
When there is no RP information -
1. (*,G) entry would surely get deleted. Outgoing interface in that (*,G) and (S,G) also gets deleted. So how are the packets still flowing ?
2. If the (*,G) entry alone gets deleted because of the RP information not present and when the receiver leave the group, will the (S,G) entry get deleted ?. If yes how ? On what basis will this (S,G) entry get deleted.
I guess the entries at SPT built routers would get deleted only when source of the multicast packet stops sending packets.
I feel that, when the (*,G) entry gets deleted, (S,G) entry also would be deleted and there want be a case in which multicast packets will be flowing. Well I haven't thought about SSM case.
Pl correct me if I am in wrong in my understanding.
Thanks & Regards
C.Uma
-----Original Message-----
From: pim-admin@catarina.usc.edu [mailto:pim-admin@catarina.usc.edu]On Behalf Of Rajamanickam jaganbabu
Sent: Tuesday, December 17, 2002 8:38 PM
To: smiley_raj@excite.com; pim@catarina.usc.edu
Subject: Re: [pim] doubt regard RP absence in the network
Hi rajesh,
If the receiver and the source has the Source Path Tree established (i.e if we have (S,G) entry in the Multicast forwarding table), then irrespective of the RP information availability, the multicast packet will be forwarded.
I hope the above information will help you, if i have understood your question correctly.
Regards,
Jags
"smiley_raj@excite.com" wrote:
Hi,
I have the following doubt,
If there is no RP in the network or all the RPs expire in the network. Can there be packet forwarding activity in a PIM-SM (only) domain. In clear my doubt is can the receivers switched over to the packet forwarding via SPT still continue to receive the data packets even if there is not RP information with him.
thanks in advance
rajesh,
Join Excite! -
The most personalized portal on the Web!
Catch all the cricket action. Download Yahoo! Score tracker
Catch all the cricket action. Download Yahoo! Score tracker
Catch all the cricket action. Download Yahoo! Score tracker
Catch all the cricket action. Download Yahoo! Score tracker
Catch all the cricket action. Download Yahoo! Score tracker
Catch all the cricket action. Download Yahoo! Score tracker
--0-1429828762-1040287847=:46093
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Hi Uma,
I think, you need to read my topology properly, where i have mensioned about IGMPV3 and not IGMPV2. If you spend some time to read the topology properly, you might not be having such a doubts (IGMPV3/V2).
Regards,
Jags
Uma C <umac@future.futsoft.com> wrote:
Hello John & Jags
I also agreed upon what Jags has mentioned in his topology.
>>> 3, In case, if RP goes off, then R1 has to remove the (*,G) entry from the forwarding table and remove the inherited outgoing list, so after the (*,G) removal, the multicast forwarder looks like this.
>>> (S,G) - oiflist=2
>>> [Uma C] Yes, multicast packets should flow on interface 2. I agree with this.
Pl confirm only this -
* Received IGMPv2 Join, created a (*,G) entry.
* Switched to SPT, hence (S,G) entry is created. (*, G) and (S, G) entry holds the same oif.
* Packets are flowing through SPT.
* Now when the RP information is not present. (*,G) entry is deleted.
Will the (S,G) entry exists ? Would the data packets flow ?.
Note:- In all this discussion I was only referring to receivers joining through IGMPv2 Join. In the case of IGMPv3 Join ie., source specific Join I agree that packets will be flowing irrespective of RP informations present or not.
Hope this time I have expressed my thoughts clearly.
Thanks & Regards
C.Uma
hello umaaa,
I guess, whatever jags referring is correct. According to his topology, we can still forward the multicast packet for (S,G).
John
Rajamanickam jaganbabu <jaganbabu_pim@yahoo.co.in> wrote:
Hi uma,
Whatever I have mentioned below was only with respect to SM domain (I haven't mentioned SSM case, which is altogether a different story). I don't understand why you need to delete even (S,G) if you don't have (*,G), draft doesn't say that. But according to the draft, we need to remove only inherited outlist from (S,G) entry, but in our case we have immediate outgoing list in (S,G) which is not a part of inherited list (if the (S,G) immediate outlist and inherited outlist are same then only we should remove (S,G) entry from your multicast forwarding table), so there is no point and we should not delete (S,G) entry from the multicast routing table even if (*,G) entry is deleted.
I hope u understand the logic.
Regards,
Jags
Uma C <umac@future.futsoft.com> wrote:
Hello Jags
Pl find my response inlined with the tag <UMA>.
Regards
C.Uma
Hi uma,
1. Even in normal SM case, multicast forwarding is possible even if we don't have RP information.
[Uma C] I guess not. In the example you had given includes SSM also.
=========
2. When we are deleting (*,G) entry, it is not mandatory to remove all the (S,G) entry from the multicast forwarder unless and until all the outgoing interface list is null.
[Uma C] I agree with you. And in the SM case there cannot be a situation when (*,G) is deleted but (S,G) still remains.
==================
I have explained how it can happen using the following topology (fig. as an attachment).
Explanation:
1. If Rec_1 sends an (*,G) IGMP join to the PIM router "R1", then the PIM forwarding table at R1 look like
(*,G) - oiflist=1
2. After some time, if Rec_2 send (src,G,1) IGMPV3 join, then the PIM forwarding table at R1 looks like
(S,G) - oiflist=1,2
(*,G) - oiflist=1
In the above forwarding table while adding (S,G) entry, the inherited outgoing list will be 1 and the immediate outgoing list will be 2, so consolidating the outgoing interface for (S,G) will 1 and 2
3, In case, if RP goes off, then R1 has to remove the (*,G) entry from the forwarding table and remove the inherited outgoing list, so after the (*,G) removal, the multicast forwarder looks like this.
(S,G) - oiflist=2
[Uma C] Yes, multicast packets should flow on interface 2. I agree with this. But the discussion started with whether multicast packets can be forwarded in PIM-SM domain only (This is want Rajesh asked for) when RP information is not present. In this case do not execute the step 2, so the (*,G) and (S,G) will hold the same oif, and hence both of these entries get deleted. So the multicast packets stop flowing.
================
So even in SM. it is not necessary to remove all the (S,G) entries if you remove (*,G) entry from the multicast forwarding table.
[Uma C] I guess not in the SM domain (which doesnot include SSM). I apreciate the interest you had taken to explain the situation with a topology. Thanks Jags.
=================
Regards,
Jags
Uma C <umac@future.futsoft.com>
wrote:
Hello Jags
I guess in the case of IGMPv3, we do not create any (*,G) entry as the Group range for SSM is different. And as you said we can still forward the packets whether there is RP information or not.
But in the case of SM only, where (*,G) and (S,G) entry exists and (S,G) entry holds the oif of the (*,G), if the RP information is not present -
* (*,G) will be deleted and oif learnt from (*,G) will be deleted from (S,G) also, irrespective of whether local receivers present or not.
* When the RP information is learnt again, (*,G) entry would be re-created if the receivers are still present.
Do you still think if RP information is not present (in the case of SM only), multicast packets would flow ?
Thanks & Regards
C.Uma
-----Original Message-----
From: Rajamanickam jaganbabu [mailto:jaganbabu_pim@yahoo.co.in]
Sent: Wednesday, December 18, 2002 11:16 AM
To: umac@future.futsoft.com
Cc: smiley_raj@excite.com; pim@catarina.usc.edu
Subject: RE: [pim] doubt regard RP absence in the network
Hi Uma,
If there is an IGMPV3 request from the receiver, asking for (S,G,I) join to a particular source, then we will be having an (S,G) entry, which will be the super set of (*,G) outgoing list. If we lost (*,G) information, then it will affect (S,G) inherited outgoing list but there is a possible case where we can have immediate outgoing list exist for (S,G) (which is not in inherited outgoing list), so at this point even we delete (*,G) entry from our multicast forwarding table still (S,G) entry will be existing in the multicast forwarding table.
So my conclusion is, in the above case even if we lost our RP information, still we can forward the multicast packet using (S,G) information for a source "S".
Thanx,
Jags
Uma C <umac@future.futsoft.com> wrote:
Hello Jags
When there is no RP information -
1. (*,G) entry would surely get deleted. Outgoing interface in that (*,G) and (S,G) also gets deleted. So how are the packets still flowing ?
2. If the (*,G) entry alone gets deleted because of the RP information not present and when the receiver leave the group, will the (S,G) entry get deleted ?. If yes how ? On what basis will this (S,G) entry get deleted.
I guess the entries at SPT built routers would get deleted only when source of the multicast packet stops sending packets.
I feel that, when the (*,G) entry gets deleted, (S,G) entry also would be deleted and there want be a case in which multicast packets will be flowing. Well I haven't thought about SSM case.
Pl correct me if I am in wrong in my understanding.
Thanks & Regards
C.Uma
-----Original Message-----
From: pim-admin@catarina.usc.edu [mailto:pim-admin@catarina.usc.edu]On Behalf Of Rajamanickam jaganbabu
Sent: Tuesday, December 17, 2002 8:38 PM
To: smiley_raj@excite.com; pim@catarina.usc.edu
Subject: Re: [pim] doubt regard RP absence in the network
Hi rajesh,
If the receiver and the source has the Source Path Tree established (i.e if we have (S,G) entry in the Multicast forwarding table), then irrespective of the RP information availability, the multicast packet will be forwarded.
I hope the above information will help you, if i have understood your question correctly.
Regards,
Jags
"smiley_raj@excite.com" <smiley_raj@excite.com> wrote:
Hi,
I have the following doubt,
If there is no RP in the network or all the RPs expire in the network. Can there be packet forwarding activity in a PIM-SM (only) domain. In clear my doubt is can the receivers switched over to the packet forwarding via SPT still continue to receive the data packets even if there is not RP information with him.
thanks in advance
rajesh,
Join Excite! -
<http://www.excite.com/>
The most personalized portal on the Web!
Catch all the cricket action. Download Yahoo! Score tracker <http://in.sports.yahoo.com/cricket/tracker.html>
Catch all the cricket action. Download Yahoo! Score tracker <http://in.sports.yahoo.com/cricket/tracker.html>
Catch all the cricket action. Download Yahoo! Score tracker
Catch all the cricket action. Download Yahoo! Score tracker
Catch all the cricket action. Download Yahoo! Score tracker
Catch all the cricket action. Download
Yahoo! Score tracker
--0-1429828762-1040287847=:46093--
_______________________________________________
pim mailing list
pim@catarina.usc.edu
http://catarina.usc.edu/mailman/listinfo/pim
From pim-admin@catarina.usc.edu Fri Dec 27 01:44:32 2002
Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22726
for ; Fri, 27 Dec 2002 01:44:30 -0500 (EST)
Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1])
by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gBR6gbL93035;
Thu, 26 Dec 2002 22:42:37 -0800 (PST)
(envelope-from pim-admin@catarina.usc.edu)
Received: from mta0 ([61.144.161.10])
by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gBR6daL92995
for ; Thu, 26 Dec 2002 22:39:45 -0800 (PST)
(envelope-from leh10814@huawei.com)
Received: from l10814 (mta0 [172.17.1.62])
by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12
2002)) with ESMTPA id <0H7R004DPMGGSA@mta0.huawei.com> for
pim@catarina.usc.edu; Fri, 27 Dec 2002 14:38:45 +0800 (CST)
From: Enhui Liu
To: pim@catarina.usc.edu
Reply-to: Enhui Liu
Message-id: <005301c2ad72$c4d0f220$33436e0a@HUAWEI.COM>
Organization: HUAWEI TECHNOLOGIES CO. LTD.
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200
X-Mailer: Microsoft Outlook Express 5.00.2615.200
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <200212121302.IAA21651@ietf.org>
Subject: [pim] Comments on section 4.4 of draft-ietf-pim-sm-v2-new-06
Sender: pim-admin@catarina.usc.edu
Errors-To: pim-admin@catarina.usc.edu
X-BeenThere: pim@catarina.usc.edu
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Unsubscribe: ,
List-Id:
List-Post:
List-Help:
List-Subscribe: ,
List-Archive:
Date: Fri, 27 Dec 2002 14:39:55 +0800
Content-Transfer-Encoding: 7BIT
In section 4.4,it is written:
"When the DR receives a Register Stop message from
the RP, it starts a Register Stop timer to maintain this state. Just
before the Register Stop timer expires, the DR sends a Null-Register
Message to the RP to allow the RP to refresh the Register Stop
information at the DR. If the Register Stop timer actually expires, the
DR will resume encapsulating packets from the source to the RP."
In brief, DR send Null-Register messages for (S,G) periodically to RP ,so as not that
KeepaliveTimer(S,G) expires at the RP and the RP romoves the (S,G) from its mroute list.
If there are N local S connected to an DR ( i.e. DR is an egress router of IDC),
DR will send N Null-Register messages per Register_stop_time to RP, and RP will
response N Register Stop messages. So more local S, more Null-Register and Register
Stop messages between DR and RP.
Hence, it is worthwhile to decrease the expense of periodical Register messages
where multicast source servers are arranged concentratedly. The following is our idea.
The first Register/Redister-Stop round is the same as PIM-SM v2.
But instead of Null-Register/Register-Stop mechanism, Heart-Beat/Cancel-Register mechanism
can be used to maintain the validity of the DR's (S,G) at the RP.
(1) The DR records the relations between (S,G) and RP, as the RP records the relations
between (S,G) and DR.
(2) The DR sends one Heart-Beat message periodically instead of N Null-Register mesages to the RP
in order that the RP refreshs all (S,G) register information from the DR.
(3) The RP Responses one Heart-Beat message periodically instead of N Register-Stop messages
to acknowledge the DR to resume sending Heart-Beat message.
(4) When one of Local S stops multicasting, the DR send a Cancel-Register message to the RP
to allow the RP to remove the (S,G) from RP's mroute list.
Besides, it's very important that this Heart-Beat/Cancel-Register mechanism is compatible
with PIM-SIM v2.
_______________________________________________
pim mailing list
pim@catarina.usc.edu
http://catarina.usc.edu/mailman/listinfo/pim
From pim-admin@catarina.usc.edu Fri Dec 27 02:26:00 2002
Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02969
for ; Fri, 27 Dec 2002 02:25:59 -0500 (EST)
Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1])
by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gBR7N9L93483;
Thu, 26 Dec 2002 23:23:09 -0800 (PST)
(envelope-from pim-admin@catarina.usc.edu)
Received: from dmz1.procket.com (dmz1.procket.com [65.174.124.36])
by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gBR7MjL93467
for ; Thu, 26 Dec 2002 23:22:45 -0800 (PST)
(envelope-from John.Zwiebel@procket.com)
Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60])
by dmz1.procket.com (Postfix) with ESMTP
id CB45B23C46; Thu, 26 Dec 2002 23:17:46 -0800 (PST)
Received: from exchangefe1.na.procket.com (exchangefe1.na.procket.com [10.1.7.251])
by miata.procket.com (8.12.1/8.12.1) with ESMTP id gBR7Ncie023610;
Thu, 26 Dec 2002 23:23:38 -0800 (PST)
Received: from procket.com ([10.1.1.1]) by exchangefe1.na.procket.com with Microsoft SMTPSVC(5.0.2195.5329);
Thu, 26 Dec 2002 23:23:38 -0800
Subject: Re: [pim] Comments on section 4.4 of draft-ietf-pim-sm-v2-new-06
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
Cc: John Zwiebel , pim@catarina.usc.edu
To: Enhui Liu
From: John Zwiebel
In-Reply-To: <005301c2ad72$c4d0f220$33436e0a@HUAWEI.COM>
Message-Id: <61EB8076-196C-11D7-A006-00039307689E@procket.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.551)
X-OriginalArrivalTime: 27 Dec 2002 07:23:38.0604 (UTC) FILETIME=[E00722C0:01C2AD78]
Sender: pim-admin@catarina.usc.edu
Errors-To: pim-admin@catarina.usc.edu
X-BeenThere: pim@catarina.usc.edu
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Unsubscribe: ,
List-Id:
List-Post:
List-Help:
List-Subscribe: ,
List-Archive:
Date: Thu, 26 Dec 2002 23:25:32 -0800
Content-Transfer-Encoding: 7bit
I don't want to discourage you, but I doubt anyone will implement
this suggestion at this time, at least not until someone shows that
the number of sources connected to a single DR becomes significant.
IMHO that would have to be at least 10.
There is another aspect for you to consider and that is whether or not
PIM as it currently exists has real long-term viability. PIM has been
around for nearly 10 years and still multicast isn't taking off except
for
folks who use the TIBCO bus applications. (If someone knows of
something
else, I'd be happy to hear about it.)
The discussions I've had with prospective customers is that they are
looking
for ways of moving to SSM to get away from the data-driven nature of
PIM-SM. Again, if you have good reasons to not move toward SSM, I'd
be interested in hearing them. (And, IMHO, after all this time working
on PIM-SM, believe SSM is the right choice.)
thanks
z
On Thursday, December 26, 2002, at 10:39 PM, Enhui Liu wrote:
> In section 4.4,it is written:
> "When the DR receives a Register Stop message from
> the RP, it starts a Register Stop timer to maintain this state. Just
> before the Register Stop timer expires, the DR sends a Null-Register
> Message to the RP to allow the RP to refresh the Register Stop
> information at the DR. If the Register Stop timer actually expires,
> the
> DR will resume encapsulating packets from the source to the RP."
>
> In brief, DR send Null-Register messages for (S,G) periodically to RP
> ,so as not that
> KeepaliveTimer(S,G) expires at the RP and the RP romoves the (S,G)
> from its mroute list.
> If there are N local S connected to an DR ( i.e. DR is an egress
> router of IDC),
> DR will send N Null-Register messages per Register_stop_time to RP,
> and RP will
> response N Register Stop messages. So more local S, more Null-Register
> and Register
> Stop messages between DR and RP.
>
> Hence, it is worthwhile to decrease the expense of periodical Register
> messages
> where multicast source servers are arranged concentratedly. The
> following is our idea.
>
> The first Register/Redister-Stop round is the same as PIM-SM v2.
> But instead of Null-Register/Register-Stop mechanism,
> Heart-Beat/Cancel-Register mechanism
> can be used to maintain the validity of the DR's (S,G) at the RP.
>
> (1) The DR records the relations between (S,G) and RP, as the RP
> records the relations
> between (S,G) and DR.
>
> (2) The DR sends one Heart-Beat message periodically instead of N
> Null-Register mesages to the RP
> in order that the RP refreshs all (S,G) register information from the
> DR.
>
> (3) The RP Responses one Heart-Beat message periodically instead of N
> Register-Stop messages
> to acknowledge the DR to resume sending Heart-Beat message.
>
> (4) When one of Local S stops multicasting, the DR send a
> Cancel-Register message to the RP
> to allow the RP to remove the (S,G) from RP's mroute list.
>
> Besides, it's very important that this Heart-Beat/Cancel-Register
> mechanism is compatible
> with PIM-SIM v2.
> _______________________________________________
> pim mailing list
> pim@catarina.usc.edu
> http://catarina.usc.edu/mailman/listinfo/pim
_______________________________________________
pim mailing list
pim@catarina.usc.edu
http://catarina.usc.edu/mailman/listinfo/pim
From pim-admin@catarina.usc.edu Mon Dec 30 23:45:30 2002
Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07763
for ; Mon, 30 Dec 2002 23:45:29 -0500 (EST)
Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1])
by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gBV4fuL66045;
Mon, 30 Dec 2002 20:41:56 -0800 (PST)
(envelope-from pim-admin@catarina.usc.edu)
Received: from mta0 ([61.144.161.10])
by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gBV4cYL65999
for ; Mon, 30 Dec 2002 20:38:35 -0800 (PST)
(envelope-from leh10814@huawei.com)
Received: from l10814 (mta0 [172.17.1.62])
by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12
2002)) with ESMTPA id <0H7Y00M64VJSFA@mta0.huawei.com> for
pim@catarina.usc.edu; Tue, 31 Dec 2002 12:38:17 +0800 (CST)
From: Enhui Liu
Subject: Re: [pim] Comments on section 4.4 of draft-ietf-pim-sm-v2-new-06
To: John Zwiebel
Cc: pim@catarina.usc.edu
Reply-to: Enhui Liu
Message-id: <002b01c2b086$9bf62020$33436e0a@HUAWEI.COM>
Organization: HUAWEI TECHNOLOGIES CO. LTD.
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200
X-Mailer: Microsoft Outlook Express 5.00.2615.200
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <61EB8076-196C-11D7-A006-00039307689E@procket.com>
Sender: pim-admin@catarina.usc.edu
Errors-To: pim-admin@catarina.usc.edu
X-BeenThere: pim@catarina.usc.edu
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Unsubscribe: ,
List-Id:
List-Post:
List-Help:
List-Subscribe: ,
List-Archive:
Date: Tue, 31 Dec 2002 12:08:44 +0800
Content-Transfer-Encoding: 7BIT
John,
I agree with you that SSM is a right choice for future and I'm studying in it.
But I don't think that it is meaningless to improve PIM v2. That's like why PIM
work group exists.
It's not seldom that a number of sources are connected to a single DR and
send multicast messages to various groups for IDC(Internet Data Center)
and ICP(Internet Content Provider) . "10" is just an example .
And our proposal is easily compatible with PIM V2. The cost of upgrade is very small.
Thanks,
Enhui Liu
----- Original Message -----
From: John Zwiebel
To: Enhui Liu
Cc: John Zwiebel ;
Sent: Friday, December 27, 2002 3:25 PM
Subject: Re: [pim] Comments on section 4.4 of draft-ietf-pim-sm-v2-new-06
> I don't want to discourage you, but I doubt anyone will implement
> this suggestion at this time, at least not until someone shows that
> the number of sources connected to a single DR becomes significant.
> IMHO that would have to be at least 10.
>
> There is another aspect for you to consider and that is whether or not
> PIM as it currently exists has real long-term viability. PIM has been
> around for nearly 10 years and still multicast isn't taking off except
> for
> folks who use the TIBCO bus applications. (If someone knows of
> something
> else, I'd be happy to hear about it.)
>
> The discussions I've had with prospective customers is that they are
> looking
> for ways of moving to SSM to get away from the data-driven nature of
> PIM-SM. Again, if you have good reasons to not move toward SSM, I'd
> be interested in hearing them. (And, IMHO, after all this time working
> on PIM-SM, believe SSM is the right choice.)
>
> thanks
>
> z
>
> On Thursday, December 26, 2002, at 10:39 PM, Enhui Liu wrote:
>
> > In section 4.4,it is written:
> > "When the DR receives a Register Stop message from
> > the RP, it starts a Register Stop timer to maintain this state. Just
> > before the Register Stop timer expires, the DR sends a Null-Register
> > Message to the RP to allow the RP to refresh the Register Stop
> > information at the DR. If the Register Stop timer actually expires,
> > the
> > DR will resume encapsulating packets from the source to the RP."
> >
> > In brief, DR send Null-Register messages for (S,G) periodically to RP
> > ,so as not that
> > KeepaliveTimer(S,G) expires at the RP and the RP romoves the (S,G)
> > from its mroute list.
> > If there are N local S connected to an DR ( i.e. DR is an egress
> > router of IDC),
> > DR will send N Null-Register messages per Register_stop_time to RP,
> > and RP will
> > response N Register Stop messages. So more local S, more Null-Register
> > and Register
> > Stop messages between DR and RP.
> >
> > Hence, it is worthwhile to decrease the expense of periodical Register
> > messages
> > where multicast source servers are arranged concentratedly. The
> > following is our idea.
> >
> > The first Register/Redister-Stop round is the same as PIM-SM v2.
> > But instead of Null-Register/Register-Stop mechanism,
> > Heart-Beat/Cancel-Register mechanism
> > can be used to maintain the validity of the DR's (S,G) at the RP.
> >
> > (1) The DR records the relations between (S,G) and RP, as the RP
> > records the relations
> > between (S,G) and DR.
> >
> > (2) The DR sends one Heart-Beat message periodically instead of N
> > Null-Register mesages to the RP
> > in order that the RP refreshs all (S,G) register information from the
> > DR.
> >
> > (3) The RP Responses one Heart-Beat message periodically instead of N
> > Register-Stop messages
> > to acknowledge the DR to resume sending Heart-Beat message.
> >
> > (4) When one of Local S stops multicasting, the DR send a
> > Cancel-Register message to the RP
> > to allow the RP to remove the (S,G) from RP's mroute list.
> >
> > Besides, it's very important that this Heart-Beat/Cancel-Register
> > mechanism is compatible
> > with PIM-SIM v2.
> > _______________________________________________
> > pim mailing list
> > pim@catarina.usc.edu
> > http://catarina.usc.edu/mailman/listinfo/pim
>
> _______________________________________________
> pim mailing list
> pim@catarina.usc.edu
> http://catarina.usc.edu/mailman/listinfo/pim
_______________________________________________
pim mailing list
pim@catarina.usc.edu
http://catarina.usc.edu/mailman/listinfo/pim