Subject: [magma] MLDv2: operation without state change reports: periodic queries

From: Erik Nordmark <[email-masked]>
Date: Fri, 14 Feb 2003 18:28:22 +0100 (CET)

I see nothing in section 6 which says that the router periodically does
a general query and how it rebuilds the state from that query.

The only loose reference is in 6.4.2 which says:
   Routers must query sources or multicast addresses that are requested
   to be no longer forwarded.  When a router queries or receives a query
   for a specific set of sources, it lowers its source timers for those
   sources to a small interval of Last Listener Query Time milliseconds.
   If multicast address records are received in response to the queries
   which express interest in listening the queried sources, the
   corresponding timers are updated.
and this doesn't mention periodic queries!

Are periodic queries not needed?

The above text also seems to only apply to listeners in INCLUDE state.
For those it is sufficient to reduce the lifetime in the source list
and send a query, which the resulting current state records increasing the
lifetime of the source list entries that are in use (and adding any missing
ones). Thus this will allow those INCLUDE source list entries that
are no longer used by any listener to time out quickly.

However, the "lowers its source timers" can't apply to the EXCLUDE state
list since those source timers are already zero perf section 6.4.1 (B)!

What seems to be needed to recover the state of the EXCLUDE listeners
is something like the following procedure:
 - create a temporary EXCLUDE source list which lists all possible
   sources (can be implemented by treating the first report differently
   than subsequent reports)
 - send a query for the multicast address (or a general query)
   and retransmit as usual
 - all IS_EX (and presumably TO_EX) reports received during the
   query interval are used to form the intersection in this temporary EXCLUDE
   list
 - at the end of the query interval replace the current EXCLUDE list with
   the temporary EXCLUDE list

I don't see anything in section 6.4 that seems to say this.
Is this because it isn't believed that periodic queries are needed?

There is a vague reference to having temporary state in 6.4.2 4th paragraph
but that wouldn't help be implementing the above type of scheme.

What am I missing?

  Erik

_______________________________________________
magma mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/magma

---

From: "Rolland Vida" <[email-masked]>
Date: Fri, 14 Feb 2003 23:04:51 +0100

> a general query and how it rebuilds the state from that query.

The first paragraph of 6.1 says

   Multicast routers send General Queries periodically to request
   Multicast Address Listener information from an attached link.  These
   queries are used to build and refresh the Multicast Address Listener
   state of routers on attached links.

The periodicity of the query is specified in section 8.2

   The Query Interval is the interval between General Queries sent by
   the Querier.  Default: 125 seconds.

> and this doesn't mention periodic queries!

Only general queries are sent periodically.
Source and address specific queries are sent only when needed. However, in
order to be conform to the robustness criteria, these specific queries are
sent several times, in order to assure that they are not lost. But this does
not mean that they are periodical queries.

> are no longer used by any listener to time out quickly.

Right.

> list since those source timers are already zero perf section 6.4.1 (B)!

The text says: "sources that are requested to be NO LONGER forwarded". This
means that they were forwarded before, and are not wanted anymore. Thus, the
text does not apply for sources that were blocked already, and have their
timers set to 0 (6.4.1 - (B))

> Is this because it isn't believed that periodic queries are needed?

As I said, General queries are sent periodically.
IMHO, the mechanim should work as it is now. Maybe the text is not clear
enough in the explanations, we could work a bit on that.

Thanks,
Rolland

---

From: "Rolland Vida" <[email-masked]>
Date: Fri, 14 Feb 2003 23:04:51 +0100

Right.

Thanks,
Rolland

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 18 Feb 2003 16:49:47 +0100 (CET)

>    state of routers on attached links.

Ack (I missed that in my first reading and found it in the second reading
today.)

But it doesn't have any high-level explanation of how the state
is built from the general queries.
What is the theory of operations that underlie the EXCLUDE (X, Y)
state that is used to derive how X and Y changes?

   Erik

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 18 Feb 2003 16:49:47 +0100 (CET)

Erik

---

From: "Rolland Vida" <[email-masked]>
Date: Thu, 20 Feb 2003 10:48:21 +0100

> is built from the general queries.

Section 6.4 presents the building of the router state, based on the received
reports.
If you consider that it is not high-level enough, we can include a short
description of the process in the enlarged introduction you asked for.

> state that is used to derive how X and Y changes?

I do not really understand your question. If it is about the significance of
X and Y, and how they are handled, I hope that my previous e-mails answered
that question.

Rolland

---

From: "Rolland Vida" <[email-masked]>
Date: Thu, 20 Feb 2003 10:48:21 +0100

Rolland

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 20 Feb 2003 19:09:49 +0100 (CET)

> description of the process in the enlarged introduction you asked for.

Please do.

> X and Y, and how they are handled, I hope that my previous e-mails answered

Didn't answer it satisfactory - I still have nothing but state machine 
transitions and no overall picture of how this works. But the multiple
messages in flight cause me to repeat this question for state management
overview over and over again.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 20 Feb 2003 19:09:49 +0100 (CET)

Please do.

  Erik

---

From: "Rolland Vida" <[email-masked]>
Date: Wed, 26 Feb 2003 09:59:30 +0100

> overview over and over again.

Erik,

First I will try to clarify the issue about the significance of X and Y in
the EXCLUDE (X,Y) state. Then I will try to answer the rest of your
questions.

Here is a proposal for an explanatory text about the router state. It could
be introduced in the extended introduction we talked about, or in the first
part of chapter 6 (describing router behavior)

*******
A router is in INCLUDE mode for a specific multicast address on a given
interface if all the listeners on the link interested in that address are in
INCLUDE mode.  The router state is represented through the notation INCLUDE
(A), where A is called the "Include List".  The Include List is the set of
sources that one or more listeners on the link have requested to receive.
All the sources from the Include List MUST be forwarded by the router.  Any
other source that is not in the Include List MUST be blocked by the router.

A source can be added to the current Include List, if a listener in INCLUDE
mode sends an IS_IN, TO_IN or ALLOW report including that source.  Each
source from the Include List is associated with a source timer, that is
updated whenever a listener in INCLUDE mode sends a report confirming its
interest in that specific source.  If the timer of a source from the Include
List expires, the source will be deleted from the Include List.  The exact
handling of the Include List, according to the received reports, is
presented in details in Tables 6.4.1 and 6.4.2.

A router is in EXCLUDE mode for a specific multicast address on a given
interface if there is at least one listener in EXCLUDE mode, interested in
that address on the link.  When the first IS_EX or TO_EX report is received
from such a listener, the router sets the Multicast Address Timer
corresponding to that address.  This Multicast Address Timer is reset each
time an EXCLUDE mode listener confirms its listening state through an IS_EX
or TO_EX report.  If the Multicast Address Timer expires, it means that
there are no more listeners in EXCLUDE mode on the link.  In this case, the
router switches back to INCLUDE mode for that multicast address.

When the router is in EXCLUDE mode, the router state is represented through
the notation EXCLUDE (X, Y), where X is called the "Requested List" and Y is
called the "Exclude List".  All the sources from the Exclude List MUST be
blocked by the router.  On the other
hand, both the sources from the Requested List, and the sources that are
neither in the Requested List, nor the Exclude List, MUST be forwarded by
the router.  Nevertheless, the router has to maintain the Requested List for
two reasons:

- To keep track of sources that listeners in INCLUDE mode listen to.  This
is necessary in order to assure a seamless transition of the router to
INCLUDE mode, when there will be no listener in EXCLUDE mode left.  This
transition should not interrupt the flow of traffic to the listeners in
INCLUDE mode still interested in that multicast address.  Therefore, at the
moment of the transition, the Requested List should represent the set of
sources that nodes in INCLUDE mode have explicitely requested.  When the
router switches to INCLUDE mode, the sources in the Requested List are moved
to the Include List, and the Exclude List is deleted.  Nevertheless, before
the transition, while the Multicast Address Timer is still running, the
router cannot be assured of having in its Requested List the exact list of
the sources explicitely requested by listeners in INCLUDE mode.  For
example, a TO_EX report received by the router might have been sent by a new
listener in EXCLUDE mode, or by an old listener that previously was in
INCLUDE mode, but it has changed now its filter mode.  Similarly, an IS_EX
report received by the router might have been sent by an old listener in
EXCLUDE mode, or by a listener that was previously in INCLUDE mode, but
whose TO_EX state change reports have been lost.  In such cases, the
Requested List is updated to *only* reflect the listening state of the
reporting node (the only state the router is sure about).  Thus, sources
might be deleted from the Requested List, as detailed in Tables 6.4.1 and
6.4.2.  Besides reflecting the only correct state the router can be sure
about, deleting "doubtful" sources also reduces router state.  On the other
hand, the Multicast Address Timer is refreshed by each IS_EX or TO_EX
report.  Therefore, if there is indeed a listener in INCLUDE mode
explicitely interested in sources that were deleted from the Requested List,
it will have enough time to confirm its interest before the Multicast
Address Timer expiration.  At that moment, the source is added again to the
Requested List.  Thus, when the router switches back to INCLUDE mode, the
Requested List will correctly reflect the listener state on the link.
Details about the transition of the router to INCLUDE mode are presented in
Appendix A3.

- To allow a fast blocking of previously unblocked sources.  If the router
receives a report containing such a request, the concerned sources are added
to the Requested List.  Their timers are set to Last Listener Query
Interval, and a Multicast Address and Source Specific Query is sent: the
router has to check if there are nodes on the link still interested in those
sources, or not. If no node confirms its interest in receiving a specific
source, the timer corresponding to that source expires. Then, the source is
moved from the Requested
List to the Exclude List.  From then on, the source will be blocked by the
router.

The exact handling of the EXCLUDE mode router state, according to the
received reports, is presented in details in Tables 6.4.1 and 6.4.2.
***********

Rolland

---

From: "Rolland Vida" <[email-masked]>
Date: Wed, 26 Feb 2003 09:59:30 +0100

Erik,

*******

Rolland