Subject: (S,G) Keepalive Timer

From: "karim Zamani" <[email-masked]>
Date: Thu, 4 Jan 2001 20:22:19 -0500

The new revised spec says:
"The (S,G) Keepalive Timer is updated by data being forwarded using this
(S,G) forwarding state.  It is used to keep (S,G) state alive in the
absence of explicit (S,G) Joins. Amongst other things, this is
necessary for the so-called "turnaround rules" - when the RP uses (S,G)
joins to stop encapsulation, and then (S,G) prunes to prevent traffic
from unnecessarily reaching the RP."

When its Not a turnaround case, is the KAT used to for maintaining a (S,G)
in the absence of  (S,G) Join messages? (page 90)
What happened if an (S,G) ExpiryTimer (ET) expires while the KAT is still
running?
The (S,G) Join/Prune state machine indicates that an ET expiration causes
the (S,G) state to be deleted.

I also noticed that the older spec says that the KAT is used for deleting an
(S,G) state for a silent source.

Regards,

Karim.

---

From: Hugh Holbrook <[email-masked]>
Date: Sat, 6 Jan 2001 09:54:11 -0800 (PST)

> From: "karim Zamani" <[email-masked]>
> Date: Thu, 4 Jan 2001 20:22:19 -0500
> 

It's used at the first-hop router to keep track of locally-sourced
(S,G)s for which it may be sending register-encapsulating packets or
for which it may have received a register-stop. (4.3.1).

It's used at the RP to keep (S,G) state alive in order to keep track
of the (S,G)s for which it has sent a Register-Stop.  Rationale for
this is in 4.3.2.

> the (S,G) state to be deleted.

Remember that downstream (S,G) and upstream (S,G) state are logically
separate.  The (S,G) ET controls the downstream (S,G) state machine.
The KAT controls the expiration of state in the upstream (S,G) state
machine through the JoinDesired function (4.4.7):

  bool JoinDesired(S,G) {
      return( immediate_olist(S,G) != NULL
              OR ( KeepaliveTimer(S,G) is running
                   AND inherited_olist(S,G) != NULL ) )
  }

Whenever an (S,G) ET expires for interface I the (S,G,I) downstream
state machine transitions to the NoInfo state, regardless of the KAT.
This only affects the upstream state machine if it changes
JoinDesired(S,G).  For instance, the router will continue to receive
(S,G) traffic and forward it out I if there is some (*,G) member on
interface I.

> (S,G) state for a silent source.

The new spec achieves this by folding the KAT into the computation of
JoinDesired.

Hope that helps.

-Hugh

---

From: "karim Zamani" <[email-masked]>
Date: Tue, 9 Jan 2001 17:15:57 -0500

My question is about setting the RP RPT-bit in a (*,G) join message.

I looked through the new spec and It doesn't seem to mention anything about
setting the RPT-bit in a (*,G) Join message when a receiver is joining the
RP tree.

The older spec (again :-) ) says:
3.2.1.1
1. Each router determines the RP for a (*,G) entry by using the hash
function described. The RP address (with RPT and WC bit set) is included in
the join list of a periodic Join/Prune message (...)

I think this would create a compatibility problem between implementations
based on the older spec, in which I assume they would check if WC and RPT
are set for a (*,G) Join, and implementations based on the new spec where
(*,G) Joins can be sent without RPT-bit set.

Please correct me if I missing something here.

Thanks,

Karim.

---

From: Isidor Kouvelas <[email-masked]>
Date: Tue, 09 Jan 2001 14:54:10 -0800

The new spec is missing some text about how the bits are set when
building J/P messages. Effectively the same happens with the new spec.
(*,G) J/P entries have the WC and RPT bits set.
(S,G,rpt) J/P entries only have the RPT bit set.

thanks
I

---

From: Bill Fenner <[email-masked]>
Date: Tue, 9 Jan 2001 15:32:22 -0800

If the RPT bit is not set, then it is not a (*,G) join.  This is
incompletely described in section 4.9.1 and could probably use more
words.  I just added a sentence that says that if the WC bit is
set then the RPT bit must be set.

  Bill

---

From: "karim Zamani" <[email-masked]>
Date: Mon, 15 Jan 2001 17:32:07 -0500

There is not much info about the (S,G) state initiated by a register message
at the RP. 4.3.2 talks about receiving register messages at the RP, but
there is no mention as to when a (S,G) state should be created etc.
This concerns the new spec.

Regards,
Karim.

---

From: Isidor Kouvelas <[email-masked]>
Date: Mon, 15 Jan 2001 18:21:23 -0800

The only state that is created by the receipt of the register message
is the update of the (S,G) KAT (section 4.3.2). This triggers all the
necessary actions.

thanks
I

---

From: Isidor Kouvelas <[email-masked]>
Date: Tue, 16 Jan 2001 10:40:55 -0800

"karim Zamani" writes:
>My concern was actually about issues raised by Pavlin. The (S,G) state
>wouldn't have to be created (therefore no (S,G) KAT) if there was a
>rate-limit based switch scheme. Section 4.3.2 only talks about an _existing_
>(S,G) state (and about when to delete it).

The new spec does not talk in terms of creating or deleting state.
It just talks in terms of assigning values to various variables and
starting timers. When some piece of state has a default value it does not
need to be maintained. Hence in the section about receiving a register,
when the (S,G)KAT is updated, there is no assumption that the (S,G) state
"existed" before.

>There is no mention of the "border bit" in a register message either.

There is some text in the packet format section.

thanks
I

>Thanks,
>Karim.
>
>----- Original Message -----
>From: "Isidor Kouvelas" <[email-masked]>
>>
>----- Original Message -----
>From: "Pavlin Ivanov Radoslavov" <[email-masked]>
>>
>> In the original spec, the (S,G) switch by the RP was rate-based
>> (i.e. after the data rate of a source exceeds some limit). Here it
>> seems that the normal procedure is for the RP to originate the (S,G)
>> Join right after the first pkt.
>> In the new document I didn't see the rate-limit based switch
>> mentioned at all. Is it intentionally, and if "yes", what is the
>> reason behind it?
>
>

---

From: "karim Zamani" <[email-masked]>
Date: Tue, 16 Jan 2001 13:28:04 -0500

My concern was actually about issues raised by Pavlin. The (S,G) state
wouldn't have to be created (therefore no (S,G) KAT) if there was a
rate-limit based switch scheme. Section 4.3.2 only talks about an _existing_
(S,G) state (and about when to delete it). There is no mention of the
"border bit" in a register message either.

Thanks,
Karim.