Subject: Re: [magma] Question about proxy implemenation in RFC 4605

From: "Alvaro Fernandez" <[email-masked]>
Date: Mon, 1 Nov 2010 22:19:25 +0100

Hi Kunai,

I thing my previous Mail was wrong. I was thinking in once interface with múltiple host and this is not your question.

The proxy should apply same rules  explained inRFC3376 in the función IPMulticastListen when there are different sockets using the same multicast group.

I think there is no need for queries, just apply these rules.

Hope this will help

Álvaro 

-----Mensaje original-----
De: Kunal Shah [mailto:[email-masked]]
Enviado el: lun 01/11/2010 19:30
Para: Alvaro Fernandez
CC: [email-masked]
Asunto: RE: [magma] Question about proxy implemenation in RFC 4605
 
Hi Alvaro,

For a router to determine that there are no interested hosts on the LAN, it does send out group specific or source-group specific queries. Does this mean, that the proxy device should send out source-group specific queries on other interfaces when deemed required?? How will this scale if there are a large number of interfaces??

Kunal

________________________________
From: Alvaro Fernandez [mailto:[email-masked]]
Sent: Saturday, October 30, 2010 10:36 AM
To: Kunal Shah
Cc: [email-masked]
Subject: RE: [magma] Question about proxy implemenation in RFC 4605

Hi Kunal

I read it years ago but I think RFC 4605 explains that the downstream network interface should behave like a router, so the solution is in the state machine explained in RFC3376 for the IGMPv3 router

Álvaro

-----Mensaje original-----
De: [email-masked] en nombre de Kunal Shah
Enviado el: sáb 30/10/2010 2:46
Para: [email-masked]
Asunto: [magma] Question about proxy implemenation in RFC 4605

Hi all,

According to RFC 4605, a router creates a membership database after merging the subscriptions on individual interfaces. Lets say that 3 IGMPv3 capable interfaces are as follows:

Interface 1 has host reporting Include S1 -> I(S1)
Interface 2 has host reporting Exclude S2 -> E(0,S2)
Interface 3 has host reporting Exclude nothing -> E(0,0)

For a device doing IGMPv3 proxy, the final membership record for group G is (G, EXCLUDE, NULL). Now lets say the host on interface 3 goes away, because of which the subscription on interface 3 would expire and there wont be any IGMPv3 state on interface 3.  How would the new membership record for PROXY be calculated?? The RFC does not suggest any way to do this. Would IGMP process have to go through each interface again and then recompute the new membership record?? This would be very inefficient especially if there are multiple interfaces.
Is there a better way to recompute the new membership record??

Thanks
Kunal

---

From: Bharat Joshi <[email-masked]>
Date: Tue, 2 Nov 2010 08:53:53 +0530

Hi Kunal,

      When a box run IGMP proxy, it has router interfaces (interfaces that runs router part of IGMP) to collect membership information and host interface (interfaces that runs host part of IGMP) to report the membership to upstream router. Before reporting membership on host interface, it aggregates the membership collected from router interfaces. Now aggregating membership information in the box is done similar to how it is defined in RFC 3376 for hosts when multiple sockets are bound. So similar rules apply when any of these membership change (It will be similar to the case when one of the sockets are closed).

     In your case below, when join comes one by one, the next state is determined as explained in RFC 3376 ( as if a new socket is opened every time) and that is how you reach a particular state of EXC( G, NULL ). Similarly when one of the interface send a leave (on host interface side, this will be treated as if that socket is closed), it re-calculates the new state and use that.

     Let me know if this clears up things.

Thanks,
Bharat
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Kunal Shah [[email-masked]]
Sent: Saturday, October 30, 2010 6:16 AM
To: [email-masked]
Subject: [magma] Question about proxy implemenation in RFC 4605

Hi all,

Thanks
Kunal

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
for the use of the addressee(s). If you are not the intended recipient, please 
notify the sender by e-mail and delete the original message. Further, you are not 
to copy, disclose, or distribute this e-mail or its contents to any other person and 
any such actions are unlawful. This e-mail may contain viruses. Infosys has taken 
every reasonable precaution to minimize this risk, but is not liable for any damage 
you may sustain as a result of any virus in this e-mail. You should carry out your 
own virus checks before opening the e-mail or attachment. Infosys reserves the 
right to monitor and review the content of all messages sent to or from this e-mail 
address. Messages sent to or from this e-mail address may be stored on the 
Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***

---

From: "Alvaro Fernandez" <[email-masked]>
Date: Tue, 2 Nov 2010 09:38:01 +0100

Hi Kunan,
 
RFC 4605 refers to RFC 3376 for this:
 
>From RFC 4605. (4.1)
The membership database is a set of membership records of the form:
   (multicast-address, filter-mode, source-list)
   Each record is the result of the merge of all subscriptions for that
   record's multicast-address on downstream interfaces.  If some
   subscriptions are IGMPv1 or IGMPv2/MLDv1 subscriptions, these
   subscriptions are converted to IGMPv3/MLDv2 subscriptions.  The
   IGMPv3/MLDv2 and the converted subscriptions are first preprocessed
   to remove the timers in the subscriptions and, if the filter mode is
   EXCLUDE, to remove every source whose source timer > 0.  Then the
   preprocessed subscriptions are merged using the merging rules for
   multiple memberships on a single interface (specified in Section 3.2
   of the IGMPv3 specification [RFC3376] and in Section 4.2 of the MLDv2
   specification [MLDv2])

Section 3.2 of RFC 3376

3.2. Interface State
     In addition to the per-socket multicast reception state, a system
     must also maintain or compute multicast reception state for each of
     its interfaces.  That state conceptually consists of a set of
     records of the form:
        (multicast-address, filter-mode, source-list)
     At most one record per multicast-address exists for a given
     interface.  This per-interface state is derived from the per-socket
     state, but may differ from the per-socket state when different
     sockets have differing filter modes and/or source lists for the
     same multicast address and interface.  For example, suppose one
     application or process invokes the following operation on socket
     s1:
        IPMulticastListen ( s1, i, m, INCLUDE, {a, b, c} )
     requesting reception on interface i of packets sent to multicast
     address m, *only* if they come from source a, b, or c.  Suppose
     another application or process invokes the following operation on
     socket s2:
 
Cain, et. al.               Standards Track                     [Page 5]

RFC 3376                         IGMPv3                     October 2002

        IPMulticastListen ( s2, i, m, INCLUDE, {b, c, d} )
     requesting reception on the same interface i of packets sent to the
     same multicast address m, *only* if they come from sources b, c, or
     d.  In order to satisfy the reception requirements of both sockets,
     it is necessary for interface i to receive packets sent to m from
     any one of the sources a, b, c, or d.  Thus, in this example, the
     reception state of interface i for multicast address m has filter
     mode INCLUDE and source list {a, b, c, d}.
     After a multicast packet has been accepted from an interface by the
     IP layer, its subsequent delivery to the application or process
     listening on a particular socket depends on the multicast reception
     state of that socket [and possibly also on other conditions, such
     as what transport-layer port the socket is bound to].  So, in the
     above example, if a packet arrives on interface i, destined to
     multicast address m, with source address a, it will be delivered on
     socket s1 but not on socket s2.  Note that IGMP Queries and Reports
     are not subject to source filtering and must always be processed by
     hosts and routers.
     Filtering of packets based upon a socket's multicast reception
     state is a new feature of this service interface.  The previous
     service interface [RFC1112] described no filtering based upon
     multicast join state; rather, a join on a socket simply caused the
     host to join a group on the given interface, and packets destined
     for that group could be delivered to all sockets whether they had
     joined or not.
     The general rules for deriving the per-interface state from the
     per-socket state are as follows:  For each distinct (interface,
     multicast-address) pair that appears in any socket state, a per-
     interface record is created for that multicast address on that
     interface.  Considering all socket records containing the same
     (interface, multicast-address) pair,
   o if *any* such record has a filter mode of EXCLUDE, then the filter
     mode of the interface record is EXCLUDE, and the source list of the
     interface record is the intersection of the source lists of all
     socket records in EXCLUDE mode, minus those source addresses that
     appear in any socket record in INCLUDE mode.  For example, if the
     socket records for multicast address m on interface i are:
        from socket s1:  ( i, m, EXCLUDE, {a, b, c, d} )
        from socket s2:  ( i, m, EXCLUDE, {b, c, d, e} )
        from socket s3:  ( i, m, INCLUDE, {d, e, f} )

Cain, et. al.               Standards Track                     [Page 6]

RFC 3376                         IGMPv3                     October 2002

     then the corresponding interface record on interface i is:
                         ( m, EXCLUDE, {b, c} )
     If a fourth socket is added, such as:
        from socket s4:  ( i, m, EXCLUDE, {} )
     then the interface record becomes:
                         ( m, EXCLUDE, {} )
   o if *all* such records have a filter mode of INCLUDE, then the
     filter mode of the interface record is INCLUDE, and the source list
     of the interface record is the union of the source lists of all the
     socket records.  For example, if the socket records for multicast
     address m on interface i are:
        from socket s1:  ( i, m, INCLUDE, {a, b, c} )
        from socket s2:  ( i, m, INCLUDE, {b, c, d} )
        from socket s3:  ( i, m, INCLUDE, {e, f} )
     then the corresponding interface record on interface i is:
                         ( m, INCLUDE, {a, b, c, d, e, f} )
     An implementation MUST NOT use an EXCLUDE interface record to
     represent a group when all sockets for this group are in INCLUDE
     state.  If system resource limits are reached when an interface
     state source list is calculated, an error MUST be returned to the
     application which requested the operation.
   The above rules for deriving the interface state are (re-)evaluated
   whenever an IPMulticastListen invocation modifies the socket state by
   adding, deleting, or modifying a per-socket state record.  Note that
   a change  of socket state does not necessarily result in a change of
   interface state.
 
--------------
 
So I think just applying these rules there is no need for querys
 
Don't hesitate to contact me for a follow up
 
Alvaro

De: Kunal Shah [mailto:[email-masked]]
Enviado el: lun 01/11/2010 23:49
Para: Alvaro Fernandez
CC: [email-masked]
Asunto: RE: [magma] Question about proxy implemenation in RFC 4605

Hi Alvaro,
 
I dont think you have understood my question. The rules that you are suggesting from RFC 3376, are the rules used for aggregating the information on an interface with multiple sockets. What I am asking is what rules should be followed on a proxy device in order to aggregate the state of all the interfaces, after the state of one of the interfaces has changed. This is because, on a device doing proxy, the state that is created is an aggregate of the state of the interfaces; i.e the state that would exist if all the interfaces represented individual hosts on a single LAN. Now from RFC 3376, if a host goes away on an interface, there are certain rules that the router must follow regarding queries that need to be sent in order to arrive to the new state on that interface. My concern is, on a proxy device, if the same rules are followed, queries will need to be sent out on all the interfaces in order to make sure that the new state reflects the state of all the interfaces. This might not be efficient/scalable if the proxy device has interfaces in the order of hundreds. 
 
Or I have not understood the RFC 4605 correctly...
 
Kunal

From: Alvaro Fernandez [mailto:[email-masked]] 
Sent: Monday, November 01, 2010 2:19 PM
To: Kunal Shah
Cc: [email-masked]
Subject: RE: [magma] Question about proxy implemenation in RFC 4605

Hi Kunai,

Hope this will help

Álvaro

-----Mensaje original-----
De: Kunal Shah [mailto:[email-masked]]
Enviado el: lun 01/11/2010 19:30
Para: Alvaro Fernandez
CC: [email-masked]
Asunto: RE: [magma] Question about proxy implemenation in RFC 4605

Hi Alvaro,

Kunal

Hi Kunal

Álvaro

-----Mensaje original-----
De: [email-masked] en nombre de Kunal Shah
Enviado el: sáb 30/10/2010 2:46
Para: [email-masked]
Asunto: [magma] Question about proxy implemenation in RFC 4605

Hi all,

Thanks
Kunal

---

From: "Alvaro Fernandez" <[email-masked]>
Date: Tue, 2 Nov 2010 17:39:47 +0100

Hi Kunal

Just something else.

>From your last e-mail:  " i.e the state that would exist if all the interfaces represented individual hosts on a single LAN"

I think this is not true. Host connected to a proxy are not the same that host connected to the same LAN. The difference is that each host is connected to the Proxy by a different downstream network interface and this makes the rules in the proxy easier that the state machine of the IGMPv3 router. 

Regards

Alvaro

-----Mensaje original-----
De: Kunal Shah [mailto:[email-masked]]
Enviado el: lun 01/11/2010 23:49
Para: Alvaro Fernandez
CC: [email-masked]
Asunto: RE: [magma] Question about proxy implemenation in RFC 4605
 
Hi Alvaro,

Kunal

Hi Kunai,

Hope this will help

Álvaro

-----Mensaje original-----
De: Kunal Shah [mailto:[email-masked]]
Enviado el: lun 01/11/2010 19:30
Para: Alvaro Fernandez
CC: [email-masked]
Asunto: RE: [magma] Question about proxy implemenation in RFC 4605

Hi Alvaro,

Kunal

Hi Kunal

Álvaro

-----Mensaje original-----
De: [email-masked] en nombre de Kunal Shah
Enviado el: sáb 30/10/2010 2:46
Para: [email-masked]
Asunto: [magma] Question about proxy implemenation in RFC 4605

Hi all,

Thanks
Kunal

---

From: Kunal Shah <[email-masked]>
Date: Mon, 1 Nov 2010 14:30:55 -0400

Hi Alvaro,

Kunal

Hi Kunal

Álvaro

-----Mensaje original-----
De: [email-masked] en nombre de Kunal Shah
Enviado el: sáb 30/10/2010 2:46
Para: [email-masked]
Asunto: [magma] Question about proxy implemenation in RFC 4605

Hi all,

Thanks
Kunal

---

From: Kunal Shah <[email-masked]>
Date: Mon, 1 Nov 2010 18:49:32 -0400

Hi Alvaro,

Kunal

Hi Kunai,

Hope this will help

Álvaro

-----Mensaje original-----
De: Kunal Shah [mailto:[email-masked]]
Enviado el: lun 01/11/2010 19:30
Para: Alvaro Fernandez
CC: [email-masked]
Asunto: RE: [magma] Question about proxy implemenation in RFC 4605

Hi Alvaro,

Kunal

Hi Kunal

Álvaro

-----Mensaje original-----
De: [email-masked] en nombre de Kunal Shah
Enviado el: sáb 30/10/2010 2:46
Para: [email-masked]
Asunto: [magma] Question about proxy implemenation in RFC 4605

Hi all,

Thanks
Kunal

---

From: "Alvaro Fernandez" <[email-masked]>
Date: Tue, 2 Nov 2010 19:42:06 +0100

-----Mensaje original-----
De: Alvaro Fernandez
Enviado el: mar 02/11/2010 9:38
Para: Kunal Shah
CC: [email-masked]
Asunto: RE: [magma] Question about proxy implemenation in RFC 4605
 
Hi Kunan,

Section 3.2 of RFC 3376

3.2. Interface State

 
--------------

 
Alvaro

Hi Alvaro,

 
Kunal

Hi Kunai,

Hope this will help

Álvaro

-----Mensaje original-----
De: Kunal Shah [mailto:[email-masked]]
Enviado el: lun 01/11/2010 19:30
Para: Alvaro Fernandez
CC: [email-masked]
Asunto: RE: [magma] Question about proxy implemenation in RFC 4605

Hi Alvaro,

Kunal

Hi Kunal

Álvaro

-----Mensaje original-----
De: [email-masked] en nombre de Kunal Shah
Enviado el: sáb 30/10/2010 2:46
Para: [email-masked]
Asunto: [magma] Question about proxy implemenation in RFC 4605

Hi all,

Thanks
Kunal

---

From: "Alvaro Fernandez" <[email-masked]>
Date: Wed, 3 Nov 2010 08:58:27 +0100

Kunal
 
Not exactly. If a group expires in an interface just need to update in the proxy the state of only this group. No need to wait until all the doenstrem interfaces (behaving like routers) update their state. 
 
Also, for example removing an include source list of a multicast group is not computing intensive (easy with a listed link, but  depending on the type of cache used in the microprocesor a table could be faster than a linked list)
 
At the end you must apply the rules of RFC 3376, 3.2 and they are not computing intensive.
 
ALvaro

De: Kunal Shah [mailto:[email-masked]]
Enviado el: mié 03/11/2010 0:25
Para: Alvaro Fernandez
Asunto: RE: [magma] Question about proxy implemenation in RFC 4605

Hi Alvaro,
 
Ok I think I understand what you are saying. So now if the new PROXY state is recomputed when a group expires on an interface, is int this very CPU intensive because the new state would be generated after considering the state of all the interfaces??
 
Kunal

From: Alvaro Fernandez [mailto:[email-masked]] 
Sent: Tuesday, November 02, 2010 9:40 AM
To: Kunal Shah
Cc: [email-masked]
Subject: RE: [magma] Question about proxy implemenation in RFC 4605

Hi Kunal

Just something else.

Regards

Alvaro

-----Mensaje original-----
De: Kunal Shah [mailto:[email-masked]]
Enviado el: lun 01/11/2010 23:49
Para: Alvaro Fernandez
CC: [email-masked]
Asunto: RE: [magma] Question about proxy implemenation in RFC 4605

Hi Alvaro,

Kunal

Hi Kunai,

Hope this will help

Álvaro

-----Mensaje original-----
De: Kunal Shah [mailto:[email-masked]]
Enviado el: lun 01/11/2010 19:30
Para: Alvaro Fernandez
CC: [email-masked]
Asunto: RE: [magma] Question about proxy implemenation in RFC 4605

Hi Alvaro,

Kunal

Hi Kunal

Álvaro

-----Mensaje original-----
De: [email-masked] en nombre de Kunal Shah
Enviado el: sáb 30/10/2010 2:46
Para: [email-masked]
Asunto: [magma] Question about proxy implemenation in RFC 4605

Hi all,

Thanks
Kunal