RE: Patch the share tree

James,

Thank for you explanation. After carefully studying the state machines,
I agree with your answer to my question. If the authors of
draft-ietf-pim-sm-v2-new-11.txt agree with what you stated, then the
inconsistent statement "However Sparse-Mode PIM does not provide a
mechanism for switching back to the shared tree" in page 123 should be
removed in next revision of the draft.

Would any author be willing to response? Or I am still missing an
important point.

Kanchei
-------------------
loa <at> ieee.org

-----Original Message-----
From: James Lingard [mailto:James.Lingard <at> dataconnection.com] 
Sent: Friday, February 25, 2005 3:28 AM
To: Loa, Kanchei
Cc: pim <at> ietf.org
Subject: RE: [pim] Patch the share tree

Kanchei,

The paragraph you quote from the specification is not strictly correct.
After 210 seconds, when the (S,G) Keepalive Timer expires, the
specification _does_ cause the router to switch back to receiving that
source on the shared tree, by triggering a Join(S,G,rpt).

The details are in section 4.5.9 ("State Machine for (S,G,rpt) Triggered
Messages") of the specification.  When the router has switched to the
SPT, the state machine is in 'Pruned' state.  When the (S,G) Keepalive
Timer expires, PruneDesired(S,G,rpt) becomes False.  This event, in
'Pruned' state, triggers the action "Send Join(S,G,rpt)".

I hope this clarifies things.  Please let me know if you have any
further questions.

Regards,
James.

-----Original Message-----
From: pim-bounces <at> ietf.org [mailto:pim-bounces <at> ietf.org]
Sent: 19 January 2005 02:00
To: pim <at> ietf.org
Subject: [pim] Patch the share tree

In draft-ietf-pim-sm-v2-new-11.txt [page 123]
o The combination of a (S,G) Prune and a (S,G,rpt) Join could possibly
  be used by a router to switch from receiving a particular source on
  the shortest-path tree back to receiving it on the shared tree
  (provided that the RPF neighbor for the shortest-path and shared trees
  is common). However Sparse-Mode PIM does not provide a mechanism for
  switching back to the shared tree.

After the initial transmission is established, the switch-over to the
Shortest Path Tree occurs once a certain number of bits (the
SPT-Threshold) have been sent down the Shared Tree. This threshold seems
to be almost always set to zero, so that the transition starts
immediately. However, after the multicast source S is silent for 210
seconds, (S,G) entry timeout and there is no mechanism for switching
back to the shared tree. S must wait for max. 60 seconds ((*,G) Join
refresh from the receiver) before its multicast packet could flow
through the shared tree to the receiver again.

In general, this 60 seconds no-sending-period is not a problem for a
generic multimedia source that leaving and join the group. But, in the
scenario where the multicast source only sends short bursts of near
real-time traffic spontaneously. Thereby, no-sending-period become an
issue once the source goes silent for more than 210 seconds, then must
send some critical data right after (S,G) timeout.

To prevent multicast route flipping, I could understand the rational
choice of not implementing a mechanism for switching back to the shared
tree due to SPT-Threshold. However, a (S,G) entry timeout event should
logically triggers a Join (S,G rpt) sent to the shared tree from the
router which initiate Prune (S,G,rpt) to undo the source blocking in the
shared tree. Is there any reason why this is not part of the PIM
specification? Do I miss something important?

--

-- 
James Lingard
Data Connection Ltd (DCL)
http://www.dataconnection.com/