headers
David McWalter | 1 Feb 2006 13:37
Favicon

RE: PIM Hello Messages

Hi Nikhil.
 
A PIM router waits longer than the hello_period before removing its adjacency with a neighbor.
-  Periodic Hellos are sent every hello_period seconds (30s by default).
-  Adjacencies are removed when the neighbor liveness timer expires (105s by default).
 
See sections 4.3.1, 4.3.2 and 4.11 of the PIM spec for details.
 
Hope that's helpful.
DMcW.
 
-----Original Message-----
From: pim-bounces <at> ietf.org [mailto:pim-bounces <at> ietf.org]On Behalf Of Nikhil Ninan
Sent: 01 February 2006 12:04
To: pim <at> ietf.org
Subject: [pim] PIM Hello Messages
Importance: High

Hello,

          I have a query on PIM Hello Messages:

If a PIM router does not receive a Hello Message from one of its neighbors within the “hello_period” will it drop the router’s address from its list of neighbors or will it wait for the router to miss a few more “hello_period” ‘s before it completely removes the router from the list.

 

Any feedback on this would be very useful.

Cheers

Nikhil

_______________________________________________
pim mailing list
pim <at> ietf.org
https://www1.ietf.org/mailman/listinfo/pim
Permalink | Reply | 0 comments |
headers
Nikhil Ninan | 1 Feb 2006 13:03
Picon
Picon

PIM Hello Messages

Hello,

          I have a query on PIM Hello Messages:

If a PIM router does not receive a Hello Message from one of its neighbors within the “hello_period” will it drop the router’s address from its list of neighbors or will it wait for the router to miss a few more “hello_period” ‘s before it completely removes the router from the list.

 

Any feedback on this would be very useful.

Cheers

Nikhil

_______________________________________________
pim mailing list
pim <at> ietf.org
https://www1.ietf.org/mailman/listinfo/pim
Permalink | Reply | 1 comment |
headers
Nikhil Ninan | 1 Feb 2006 14:35
Picon
Picon

PIM Register & Register-Stop process

Hello,

         My next question, this is the situation:         

When a source DR gets multicast packets it encapsulates them and sends it to the RP by unicast. The RP will check, if there doesn’t exist receivers for the group, will send a Register-Stop message and also starts within itself for the group. The source DR as to keep sending null-register packets to the RP before the timer expires thereby maintaining the state for the group. Now if a receiver joins the group the RP will send a (S, G, spt) Join to the source DR. Now the source DR sends multicast data to the RP, which in turn will forward it to the receiver’s DR through the (*, G, rpt) Join that the receiver’s DR had sent earlier. Once the Receiver’s DR learns the address of the source, it sends a (S, G, spt) Join directly to the source DR and the source DR will forward multicast traffic directly to the receiver’s DR.

 

1.)     Now does the receiver’s DR send the prune to the RP tree first? And when does the source DR send a prune to the RP?

2.)     Now if this was the only receiver for the group & the traffic is flowing through the source tree then what states will be maintained by the RP for the group, assuming that the source is transmitting??

3.)     And does the RP know that there is direct forwarding of traffic between the source DR and receiver DR?

4.)     Is the multicast data forwarded to the RP always encapsulated, even if the RP sends (S, G, spt) Join to the source DR as above???

 

Cheers

Nikhil

_______________________________________________
pim mailing list
pim <at> ietf.org
https://www1.ietf.org/mailman/listinfo/pim
Permalink | Reply | 0 comments |
headers
David McWalter | 1 Feb 2006 15:00
Favicon

RE: PIM Register & Register-Stop process

1) This is in the overview, section 3.  The DR waits for the SPT data before pruning off the RPT.
..  When the first traffic starts to arrive from the SPT, the DR or
upstream router starts to drop the packets for G from S that arrive via
the RP tree.  In addition, it sends an (S,G) Prune message towards the
RP.  This is known as an (S,G,rpt) Prune.  ...
 
2) The RP will have keepalive timer KAT(S,G) from the Register messages, plus (*,G,I) and (S,G,rpt,I) state on the downstream interface from the Join(*,G) and Prune(S,G,rpt) it has received, and continues to receive periodically.
 
3) No.  PIM is pretty much hop-by-hop.  PIM routers don't try to work out the state of remote routers across the network; just adjacent ones.
 
4) No.  If the RP joins the SPT, it gets multicast data hop-by-hop just like anyone else.  When it gets the Prune(S,G,rpt), it'll leave the SPT again and not forward any (S,G) data at all.
 
Try searching for this stuff in the PIM spec.  It's all in there.
 
DMcW.
 
-----Original Message-----
From: pim-bounces <at> ietf.org [mailto:pim-bounces <at> ietf.org]On Behalf Of Nikhil Ninan
Sent: 01 February 2006 13:35
To: pim <at> ietf.org
Subject: [pim] PIM Register & Register-Stop process
Importance: High

Hello,

         My next question, this is the situation:         

When a source DR gets multicast packets it encapsulates them and sends it to the RP by unicast. The RP will check, if there doesn’t exist receivers for the group, will send a Register-Stop message and also starts within itself for the group. The source DR as to keep sending null-register packets to the RP before the timer expires thereby maintaining the state for the group. Now if a receiver joins the group the RP will send a (S, G, spt) Join to the source DR. Now the source DR sends multicast data to the RP, which in turn will forward it to the receiver’s DR through the (*, G, rpt) Join that the receiver’s DR had sent earlier. Once the Receiver’s DR learns the address of the source, it sends a (S, G, spt) Join directly to the source DR and the source DR will forward multicast traffic directly to the receiver’s DR.

 

1.)     Now does the receiver’s DR send the prune to the RP tree first? And when does the source DR send a prune to the RP?

2.)     Now if this was the only receiver for the group & the traffic is flowing through the source tree then what states will be maintained by the RP for the group, assuming that the source is transmitting??

3.)     And does the RP know that there is direct forwarding of traffic between the source DR and receiver DR?

4.)     Is the multicast data forwarded to the RP always encapsulated, even if the RP sends (S, G, spt) Join to the source DR as above???

 

Cheers

Nikhil

_______________________________________________
pim mailing list
pim <at> ietf.org
https://www1.ietf.org/mailman/listinfo/pim
Permalink | Reply | 0 comments |
headers
Internet-Drafts | 6 Feb 2006 21:50
Picon
Favicon

I-D ACTION:draft-ietf-pim-anycast-rp-06.txt

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		: Anycast-RP using PIM
	Author(s)	: D. Farinacci, Y. Cai
	Filename	: draft-ietf-pim-anycast-rp-06.txt
	Pages		: 12
	Date		: 2006-2-6
	
This specification allows Anycast-RP (Rendezvous Point) to be used
   inside a domain that runs Protocol Independent Multicast (PIM) only.
   There are no other multicast protocols required to support Anycast-
   RP, such as MSDP, which has been used traditionally to solve this
   problem.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pim-anycast-rp-06.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-anycast-rp-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 <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-pim-anycast-rp-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.
Attachment: message/external-body, 137 bytes
Attachment (draft-ietf-pim-anycast-rp-06.txt): message/external-body, 68 bytes
_______________________________________________
pim mailing list
pim <at> ietf.org
https://www1.ietf.org/mailman/listinfo/pim
Permalink | Reply | 0 comments |
headers
Dave Price | 7 Feb 2006 11:41
Picon

Minor comment plus question on draft-ietf-pim-anycast-rp-06.txt

Dear All,

First, minor comment.  There is a typo in 3.0
where half way down it says "Ancyast-RP" and not "Anycast-RP".

Second, question.

The ID does not explicitly consider the position
where the DR for a source is actually one of the RPs themselves.

E.g. in section 3.0, perhaps RP1 is indeed itself the DR for S1.
I think this all still works o.k. though, RP1 would
presumably still send the PIM-register to the RPA and
thus intercept it itself and behave as described
as though it had arrived from another DR.

I suppose the only potential problem is if it checked the source
of the PIM-register and then acted as though it had arrived
"from another RP" in the set... 

Dave Price
	---------------------------------------------------------
	| David Price, Computer Science				|
	|							|
	|  Computer Science, University of Wales, Aberystwyth,	|
	|  Penglais Campus, Aberystwyth, Ceredigion, SY23 3DB	|
	|                                                       |
	| Email: dap <at> aber.ac.uk WWW: http://www.aber.ac.uk/~dap |
	|  Phone: +44 1970 622428   FAX: +44 1970 622455	|
	---------------------------------------------------------
Permalink | Reply | 3 comments |
headers
Dino Farinacci | 7 Feb 2006 19:39
Picon
Favicon

Re: Minor comment plus question on draft-ietf-pim-anycast-rp-06.txt

>> First, minor comment.  There is a typo in 3.0
>> where half way down it says "Ancyast-RP" and not "Anycast-RP".

    Fixed. But not sure this justifies another rev of the spec. I'll let the
    working group chairs decide.

>> E.g. in section 3.0, perhaps RP1 is indeed itself the DR for S1.
>> I think this all still works o.k. though, RP1 would
>> presumably still send the PIM-register to the RPA and
>> thus intercept it itself and behave as described
>> as though it had arrived from another DR.

    Right, but the main PIM spec presumes this. This isn't anything speific
    to Anycast-PIM.

>> I suppose the only potential problem is if it checked the source
>> of the PIM-register and then acted as though it had arrived
>> "from another RP" in the set... 

    Yes, most implementations, the DR will send the PIM register to the RP
    address, which is itself. The packet is looped back into an input queue
    and processed like it came from another system. The same goes for the
    Register-Stop message that it returns to itself.

Thanks,
Dino
Permalink | Reply | 2 comments |
headers
Mike McBride | 7 Feb 2006 20:52
Picon
Favicon

Re: Minor comment plus question on draft-ietf-pim-anycast-rp-06.txt

>>> First, minor comment.  There is a typo in 3.0
>>> where half way down it says "Ancyast-RP" and not "Anycast-RP".
>
>    Fixed. But not sure this justifies another rev of the spec. I'll let the
>    working group chairs decide.

Probably not, but thanks for doing it anyway, will make the iesg process 
proceed that much more smoothly.

mike

>>> E.g. in section 3.0, perhaps RP1 is indeed itself the DR for S1.
>>> I think this all still works o.k. though, RP1 would
>>> presumably still send the PIM-register to the RPA and
>>> thus intercept it itself and behave as described
>>> as though it had arrived from another DR.
>
>    Right, but the main PIM spec presumes this. This isn't anything speific
>    to Anycast-PIM.
>
>>> I suppose the only potential problem is if it checked the source
>>> of the PIM-register and then acted as though it had arrived
>>> "from another RP" in the set...
>
>    Yes, most implementations, the DR will send the PIM register to the RP
>    address, which is itself. The packet is looped back into an input queue
>    and processed like it came from another system. The same goes for the
>    Register-Stop message that it returns to itself.
>
> Thanks,
> Dino
>
> _______________________________________________
> pim mailing list
> pim <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/pim
>
Permalink | Reply | 0 comments |
headers
Mike McBride | 7 Feb 2006 20:52
Picon
Favicon

Re: Minor comment plus question on draft-ietf-pim-anycast-rp-06.txt

>>> First, minor comment.  There is a typo in 3.0
>>> where half way down it says "Ancyast-RP" and not "Anycast-RP".
>
>    Fixed. But not sure this justifies another rev of the spec. I'll let the
>    working group chairs decide.

Probably not, but thanks for doing it anyway, will make the iesg process 
proceed that much more smoothly.

mike

>>> E.g. in section 3.0, perhaps RP1 is indeed itself the DR for S1.
>>> I think this all still works o.k. though, RP1 would
>>> presumably still send the PIM-register to the RPA and
>>> thus intercept it itself and behave as described
>>> as though it had arrived from another DR.
>
>    Right, but the main PIM spec presumes this. This isn't anything speific
>    to Anycast-PIM.
>
>>> I suppose the only potential problem is if it checked the source
>>> of the PIM-register and then acted as though it had arrived
>>> "from another RP" in the set...
>
>    Yes, most implementations, the DR will send the PIM register to the RP
>    address, which is itself. The packet is looped back into an input queue
>    and processed like it came from another system. The same goes for the
>    Register-Stop message that it returns to itself.
>
> Thanks,
> Dino
>
> _______________________________________________
> pim mailing list
> pim <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/pim
>
Permalink | Reply | 0 comments |
headers
Tom Pusateri | 8 Feb 2006 14:40
Gravatar

Working Group Last Call: PIM MIB

We are starting a Working Group Last Call for the PIM MIB. The lastest
verison was submitted January 25th.

The WGLC will expire at 5:00 PM PST on February 22nd 2006.

You can read it via this link:

http://www.ietf.org/internet-drafts/draft-ietf-pim-mib-v2-05.txt

See David McWalter's previous posts on this list to get more info
about the changes.

Please send your comments to the PIM list.

Thanks,
Tom & Mike
Permalink | Reply | 2 comments |

Gmane