Subject: [pim] I-D ACTION:draft-ietf-pim-sm-v2-new-06.txt,.ps

From: [email-masked]
Date: Thu, 12 Dec 2002 08:02:20 -0500

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:
	[email-masked].
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.

---

From: Enhui Liu <[email-masked]>
Date: Fri, 27 Dec 2002 14:39:55 +0800

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
[email-masked]
http://catarina.usc.edu/mailman/listinfo/pim

---

From: John Zwiebel <[email-masked]>
Date: Thu, 26 Dec 2002 23:25:32 -0800

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

---

From: Enhui Liu <[email-masked]>
Date: Tue, 31 Dec 2002 12:08:44 +0800

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