Ramrao Deshpande | 2 Apr 11:35 2007

Issue:SSM snooping implementation in switch


Hi All,

Here i have some issue in implementing ssm-snooping in  the switch

                                                 Upstream Router
                                                           |
                                                           |
                                                  ----------------
                                                |  switch        |        Snooping Enabled for IGMPV3
                                                |                      |
                                                 ------------------
                                                          |                            
                               ------------------------------------------------
                                 |                                              |
                                 |                                              |
                          -----------                                   -----------
                         |    H1    |                                  |    H2    |
                         ------------                                  -----------

In above diagram if Host H1/H2 sends following request to upstream router

H1 --------> (S,G,F)   (135.0.0.1,232.0.0.1,INCLUDE)

H2--------->(S,G,F)   (135.0.0.1,232.0.0.1,EXCLUDE)

In this scenario how the switch and router should maintain snooping and membership information.

Thanks,

Regards,

Ramrao G Deshpande

***********************  Aricent-Unclassified   ***********************
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."
_______________________________________________
magma mailing list
magma <at> ietf.org
https://www1.ietf.org/mailman/listinfo/magma
Prashant Jhingran | 2 Apr 12:08 2007

RE: Issue:SSM snooping implementation in switch

Refer RFC 3376: Section 6.4.

Old State       Report Rcvd        New State

INCLUDE (A)       IS_EX (B) ==> EXCLUDE (A*B,B-A)

and also

INCLUDE (A)       TO_EX (B)  ==>EXCLUDE (A*B,B-A)

Note: Replace, "B" with "A" and you'll get the solution!

Regards,
Prashant Jhingran

Huawei Technologies
+91-80-41117676 Ext -5129
Mobile:+91-9448927814

============================================
"Sing, dance, serve, meditate and celebrate"
- Sri Sri Ravi Shankar      www.artofliving.org
============================================

This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
=========

 

From: Ramrao Deshpande [mailto:Ramrao.Deshpande <at> aricent.com]
Sent: Monday, April 02, 2007 3:06 PM
To: magma <at> ietf.org
Subject: [magma] Issue:SSM snooping implementation in switch


Hi All,

Here i have some issue in implementing ssm-snooping in  the switch

                                                 Upstream Router
                                                           |
                                                           |
                                                  ----------------
                                                |  switch        |        Snooping Enabled for IGMPV3
                                                |                      |
                                                 ------------------
                                                          |                            
                               ------------------------------------------------
                                 |                                              |
                                 |                                              |
                          -----------                                   -----------
                         |    H1    |                                  |    H2    |
                         ------------                                  -----------

In above diagram if Host H1/H2 sends following request to upstream router

H1 --------> (S,G,F)   (135.0.0.1,232.0.0.1,INCLUDE)

H2--------->(S,G,F)   (135.0.0.1,232.0.0.1,EXCLUDE)

In this scenario how the switch and router should maintain snooping and membership information.

Thanks,

Regards,

Ramrao G Deshpande

***********************  Aricent-Unclassified   ***********************
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."
_______________________________________________
magma mailing list
magma <at> ietf.org
https://www1.ietf.org/mailman/listinfo/magma
Jayanth Chennamangalam | 3 Apr 16:23 2007
Picon

IGMP/MLD Proxy Upstream Interface Learning

Hi!

IGMP/MLD Proxy Upstream Interface Learning (draft-vijay-magma-igmpproxy-upstream-intf-learning-00) specifies a mechanism for the dynamic determination of the upstream interface of a device running IGMP/MLD Proxy, as opposed to manual configuration. The learning of the upstream interface is achieved by listening for IGMP/MLD General Query messages on the interfaces of the proxy device.

I would greatly appreciate it if the WG members could review the draft and send me comments.

The draft is available at: http://www.ietf.org/internet-drafts/draft-vijay-magma-igmpproxy-upstream-intf-learning-00.txt

Thanks and regards,

Jayanth

_______________________________________________
magma mailing list
magma <at> ietf.org
https://www1.ietf.org/mailman/listinfo/magma
Gorry Fairhurst | 3 Apr 17:52 2007
Picon
Picon

Re: IGMP/MLD Proxy Upstream Interface Learning


I'm not sure I understand this. I thought a key issue was the detection
of multicast router interfaces (which may be PIM routers, but need not
necessarily be queriers). Whereas this document only seems to talk about the
querier.

So - how does this document relate to using MRD to configure the upstream
interface (RFC4286)?

Gorry 

On 3/4/07 15:23, "Jayanth Chennamangalam" <jayanthc <at> gmail.com> wrote:

> Hi!
> 
> IGMP/MLD Proxy Upstream Interface Learning (
> draft-vijay-magma-igmpproxy-upstream-intf-learning-00<http://www.ietf.org/inte
> rnet-drafts/draft-vijay-magma-igmpproxy-upstream-intf-learning-00.txt>)
> specifies a mechanism for the dynamic determination of the upstream
> interface of a device running IGMP/MLD Proxy, as opposed to manual
> configuration. The learning of the upstream interface is achieved by
> listening for IGMP/MLD General Query messages on the interfaces of the proxy
> device.
> 
> I would greatly appreciate it if the WG members could review the draft and
> send me comments.
> 
> The draft is available at:
> http://www.ietf.org/internet-drafts/draft-vijay-magma-igmpproxy-upstream-intf-
> learning-00.txt
> 
> Thanks and regards,
> 
> Jayanth
> _______________________________________________
> magma mailing list
> magma <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/magma
Jayanth Chennamangalam | 4 Apr 14:45 2007
Picon

Re: IGMP/MLD Proxy Upstream Interface Learning

Hi Gorry,

Thank you for your interest in the document.

The detection of multicast router interfaces is a key issue in the case of snooping switches, not devices which proxy IGMP/MLD group membership information.

For a snooping switch, as shown in the diagram below, there may be multiple routers connected to its ports. One of them would become the Querier (denoted by Q), while the others would be the Non-Queriers (NQ). In this scenario, there has to be some method by which the snooping switch has to determine which ports are connected to routers, and MRD is used to address this problem.

 Q             NQ           NQ
+--+          +--+         +--+
|R1|          |R2|          |R3|
++-+          ++-+         ++-+
 |             |             |
 |              |            |
 |            +++            |
 +------------+S+-----------+
              +-+

In the case of a proxy device (quoting from RFC 4605):

1. The topology that the device is part of "is limited to a tree".
2. The proxy device "has a single upstream interface".

The upstream interface ("host interface") is connected to an IGMP/MLD router. If the proxy device is a switch, the Spanning Tree Protocol ensures that there is only one upstream. If the proxy device is a router, this has to be done administratively. In any case, there is no question of Querier Election happening on the upstream interface and Queries getting suppressed (for Non-Queriers), as the proxy device does not flood recieved Queries, but rather, generates its own Queries to be sent on the downstream interfaces ("router interfaces"). Besides, since there is only one router in the tree (which is the Querier), detecting it by relying on General Query messages is simpler than running MRD on the devices.

The applicability of IGMP/MLD Proxy Upstream Interface Learning is mainly when STP reconfigures the tree, so that the upstream interface changes. Here, it is not the router which is discovered, but the upstream interface.

Hope this clarifies your doubt.

Thanks and regards,

Jayanth


On 4/3/07, Gorry Fairhurst <gorry <at> erg.abdn.ac.uk> wrote:
>
> I'm not sure I understand this. I thought a key issue was the detection
> of multicast router interfaces (which may be PIM routers, but need not
> necessarily be queriers). Whereas this document only seems to talk about the
> querier.
>
> So - how does this document relate to using MRD to configure the upstream
> interface (RFC4286)?
>
> Gorry
>
> On 3/4/07 15:23, "Jayanth Chennamangalam" <jayanthc <at> gmail.com> wrote:
>
> > Hi!
> >
> > IGMP/MLD Proxy Upstream Interface Learning (
> > draft-vijay-magma-igmpproxy-upstream-intf-learning-00<http://www.ietf.org/inte
> > rnet-drafts/draft- vijay-magma-igmpproxy-upstream-intf-learning-00.txt>)
> > specifies a mechanism for the dynamic determination of the upstream
> > interface of a device running IGMP/MLD Proxy, as opposed to manual
> > configuration. The learning of the upstream interface is achieved by
> > listening for IGMP/MLD General Query messages on the interfaces of the proxy
> > device.
> >
> > I would greatly appreciate it if the WG members could review the draft and
> > send me comments.
> >
> > The draft is available at:
> > http://www.ietf.org/internet-drafts/draft-vijay-magma-igmpproxy-upstream-intf-
> > learning-00.txt
> >
> > Thanks and regards,
> >
> > Jayanth
> > _______________________________________________
> > magma mailing list
> > magma <at> ietf.org
> > https://www1.ietf.org/mailman/listinfo/magma
>
>
>

_______________________________________________
magma mailing list
magma <at> ietf.org
https://www1.ietf.org/mailman/listinfo/magma
Gorry Fairhurst | 4 Apr 16:20 2007
Picon
Picon

Re: IGMP/MLD Proxy Upstream Interface Learning


Seems to make sense, except my doubt was about:

" Besides, since there is only one router in the tree
(which is the Querier), detecting it by relying on General Query messages is
simpler than running MRD on the devices."

- In the networks we use, there are often more than two multicast routers
connected. It can be the case that only one is configured to run
IGMP-Querier (this simplifies things sometimes), but both do need to see
multicast traffic from the LAN (i.e. they are both part of the same L2
tree). 

If I understand, the devices cited in the draft rely on IGMP only for this,
and these devices will break the normal multicast behaviour.

Best wishes,

Gorry

On 4/4/07 13:45, "Jayanth Chennamangalam" <jayanthc <at> gmail.com> wrote:

> Hi Gorry,
> 
> Thank you for your interest in the document.
> 
> The detection of multicast router interfaces is a key issue in the case of
> snooping switches, not devices which proxy IGMP/MLD group membership
> information.
> 
> For a snooping switch, as shown in the diagram below, there may be multiple
> routers connected to its ports. One of them would become the Querier
> (denoted by Q), while the others would be the Non-Queriers (NQ). In this
> scenario, there has to be some method by which the snooping switch has to
> determine which ports are connected to routers, and MRD is used to address
> this problem.
> 
>  Q             NQ           NQ
> +--+          +--+         +--+
> |R1|          |R2|         |R3|
> ++-+          ++-+         ++-+
>  |             |            |
>  |             |            |
>  |            +++           |
>  +------------+S+-----------+
>               +-+
> 
> In the case of a proxy device (quoting from RFC 4605):
> 
> 1. The topology that the device is part of "is limited to a tree".
> 2. The proxy device "has a single upstream interface".
> 
> The upstream interface ("host interface") is connected to an IGMP/MLD
> router. If the proxy device is a switch, the Spanning Tree Protocol ensures
> that there is only one upstream. If the proxy device is a router, this has
> to be done administratively. In any case, there is no question of Querier
> Election happening on the upstream interface and Queries getting suppressed
> (for Non-Queriers), as the proxy device does not flood recieved Queries, but
> rather, generates its own Queries to be sent on the downstream interfaces
> ("router interfaces"). Besides, since there is only one router in the tree
> (which is the Querier), detecting it by relying on General Query messages is
> simpler than running MRD on the devices.
> 
> The applicability of IGMP/MLD Proxy Upstream Interface Learning is mainly
> when STP reconfigures the tree, so that the upstream interface changes.
> Here, it is not the router which is discovered, but the upstream interface.
> 
> Hope this clarifies your doubt.
> 
> Thanks and regards,
> 
> Jayanth
> 
> 
> On 4/3/07, Gorry Fairhurst <gorry <at> erg.abdn.ac.uk> wrote:
>> 
>> I'm not sure I understand this. I thought a key issue was the detection
>> of multicast router interfaces (which may be PIM routers, but need not
>> necessarily be queriers). Whereas this document only seems to talk about
> the
>> querier.
>> 
>> So - how does this document relate to using MRD to configure the upstream
>> interface (RFC4286)?
>> 
>> Gorry
>> 
>> On 3/4/07 15:23, "Jayanth Chennamangalam" <jayanthc <at> gmail.com> wrote:
>> 
>>> Hi!
>>> 
>>> IGMP/MLD Proxy Upstream Interface Learning (
>>> draft-vijay-magma-igmpproxy-upstream-intf-learning-00<
> http://www.ietf.org/inte
>>> rnet-drafts/draft-vijay-magma-igmpproxy-upstream-intf-learning-00.txt>)
>>> specifies a mechanism for the dynamic determination of the upstream
>>> interface of a device running IGMP/MLD Proxy, as opposed to manual
>>> configuration. The learning of the upstream interface is achieved by
>>> listening for IGMP/MLD General Query messages on the interfaces of the
> proxy
>>> device.
>>> 
>>> I would greatly appreciate it if the WG members could review the draft
> and
>>> send me comments.
>>> 
>>> The draft is available at:
>>> 
> http://www.ietf.org/internet-drafts/draft-vijay-magma-igmpproxy-upstream-intf-
>>> learning-00.txt
>>> 
>>> Thanks and regards,
>>> 
>>> Jayanth
>>> _______________________________________________
>>> magma mailing list
>>> magma <at> ietf.org
>>> https://www1.ietf.org/mailman/listinfo/magma
>> 
>> 
>> 
> _______________________________________________
> magma mailing list
> magma <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/magma
Jayanth Chennamangalam | 5 Apr 15:35 2007
Picon

Re: IGMP/MLD Proxy Upstream Interface Learning

Hi Gorry,

Quoting from RFC 4605:

   1.2.  Applicability Statement

      The IGMP/MLD-based forwarding only works in a simple tree topology.
      The tree must be manually configured by designating upstream and
      downstream interfaces on each proxy device.  In addition, the IP
      addressing scheme applied to the proxying tree topology SHOULD be
      configured to ensure that a proxy device can win the IGMP/MLD Querier
      election to be able to forward multicast traffic.  There are no other
      multicast routers except the proxy devices within the tree, and the
      root of the tree is expected to be connected to a wider multicast
      infrastructure.  This protocol is limited to a single administrative
      domain.

      In more complicated scenarios where the topology is not a tree, a
      more robust failover mechanism is desired, or more than one
      administrative domain is involved, a multicast routing protocol
      should be used.

RFC 4605 states that "there are no other multicast routers except the proxy
devices within the tree". STP will ensure that there is only one upstream
interface, which eventually connects to the multicast router.

If your question was regarding the case where there would be more than one
multicast router on the upstream, this is the solution that we see:

Connect the proxy device to both the routers. In this case, Querier Election
will not take place, as the proxy device will not forward the Queries from
one interface to the other. Here, the IGMP/MLD Proxy Upstream Interface
Learning algorithm will kick in, and try to converge on to one interface.
Since this configuration is intentional, the alarm that would be raised due
to non-convergence of the upstream interface can be ignored by the network
administrator. (Maybe we can have an option for administrative disabling of
the alarm in updates to the draft.) In any case, the proxy device will
continue to send the aggregated subscription messages to both the routers,
irrespective of whether convergence happened or not.

 +--+          +--+
 |R1|          |R2|
 ++-+          ++-+
  |             |
  |   +--+---+  |
  +---+Proxy +--+
      |Device|
      +--+---+
         |

Quoting from your mail:

"It can be the case that only one is configured to run IGMP-Querier (this
simplifies things sometimes)"

If you are referring to the case where only R1 is running IGMP, as far as we
understand it, this does not seem to simplify the scenario. Since R2 is not
IGMP-enabled, it will not process any multicast subscription requests and
thus multicast protocols might not be able to spawn trees (RPT/SPT). So why
would the proxy device need to send those messages to R2?

An alternative - and probably not ideal - solution would be to connect the proxy device through a
switch to the multicast routers. Here, Querier Election will take place
between R1 and R2 and only the elected router will subsequently send
Queries. Since the device which is upstream with respect to the proxy device
is a switch, it will send multicast subscription requests to both the
routers.

 +--+          +--+
 |R1|          |R2|
 ++-+          ++-+
  |             |
  |   +------+  |
  +---+Switch+--+
      +--+---+
         |
      +--+---+
      |Proxy |
      |Device|
      +--+---+
         |

Thanks and regards,

Jayanth


On 4/4/07, Gorry Fairhurst <gorry <at> erg.abdn.ac.uk> wrote:

Seems to make sense, except my doubt was about:

" Besides, since there is only one router in the tree
(which is the Querier), detecting it by relying on General Query messages is
simpler than running MRD on the devices."

- In the networks we use, there are often more than two multicast routers
connected. It can be the case that only one is configured to run
IGMP-Querier (this simplifies things sometimes), but both do need to see
multicast traffic from the LAN (i.e. they are both part of the same L2
tree).

If I understand, the devices cited in the draft rely on IGMP only for this,
and these devices will break the normal multicast behaviour.

Best wishes,

Gorry


On 4/4/07 13:45, "Jayanth Chennamangalam" <jayanthc <at> gmail.com> wrote:

> Hi Gorry,
>
> Thank you for your interest in the document.
>
> The detection of multicast router interfaces is a key issue in the case of
> snooping switches, not devices which proxy IGMP/MLD group membership
> information.
>
> For a snooping switch, as shown in the diagram below, there may be multiple
> routers connected to its ports. One of them would become the Querier
> (denoted by Q), while the others would be the Non-Queriers (NQ). In this
> scenario, there has to be some method by which the snooping switch has to
> determine which ports are connected to routers, and MRD is used to address
> this problem.
>
>  Q             NQ           NQ
> +--+          +--+         +--+
> |R1|          |R2|         |R3|
> ++-+          ++-+         ++-+
>  |             |            |
>  |             |            |
>  |            +++           |
>  +------------+S+-----------+
>               +-+
>
> In the case of a proxy device (quoting from RFC 4605):
>
> 1. The topology that the device is part of "is limited to a tree".
> 2. The proxy device "has a single upstream interface".
>
> The upstream interface ("host interface") is connected to an IGMP/MLD
> router. If the proxy device is a switch, the Spanning Tree Protocol ensures
> that there is only one upstream. If the proxy device is a router, this has
> to be done administratively. In any case, there is no question of Querier
> Election happening on the upstream interface and Queries getting suppressed
> (for Non-Queriers), as the proxy device does not flood recieved Queries, but
> rather, generates its own Queries to be sent on the downstream interfaces
> ("router interfaces"). Besides, since there is only one router in the tree
> (which is the Querier), detecting it by relying on General Query messages is
> simpler than running MRD on the devices.
>
> The applicability of IGMP/MLD Proxy Upstream Interface Learning is mainly
> when STP reconfigures the tree, so that the upstream interface changes.
> Here, it is not the router which is discovered, but the upstream interface.
>
> Hope this clarifies your doubt.
>
> Thanks and regards,
>
> Jayanth
>
>
> On 4/3/07, Gorry Fairhurst < gorry <at> erg.abdn.ac.uk> wrote:
>>
>> I'm not sure I understand this. I thought a key issue was the detection
>> of multicast router interfaces (which may be PIM routers, but need not
>> necessarily be queriers). Whereas this document only seems to talk about
> the
>> querier.
>>
>> So - how does this document relate to using MRD to configure the upstream
>> interface (RFC4286)?
>>
>> Gorry
>>
>> On 3/4/07 15:23, "Jayanth Chennamangalam" <jayanthc <at> gmail.com> wrote:
>>
>>> Hi!
>>>
>>> IGMP/MLD Proxy Upstream Interface Learning (
>>> draft-vijay-magma-igmpproxy-upstream-intf-learning-00<
> http://www.ietf.org/inte
>>> rnet-drafts/draft- vijay-magma-igmpproxy-upstream-intf-learning-00.txt>)
>>> specifies a mechanism for the dynamic determination of the upstream
>>> interface of a device running IGMP/MLD Proxy, as opposed to manual
>>> configuration. The learning of the upstream interface is achieved by
>>> listening for IGMP/MLD General Query messages on the interfaces of the
> proxy
>>> device.
>>>
>>> I would greatly appreciate it if the WG members could review the draft
> and
>>> send me comments.
>>>
>>> The draft is available at:
>>>
> http://www.ietf.org/internet-drafts/draft-vijay-magma-igmpproxy-upstream-intf-
>>> learning-00.txt
>>>
>>> Thanks and regards,
>>>
>>> Jayanth
>>> _______________________________________________
>>> magma mailing list
>>> magma <at> ietf.org
>>> https://www1.ietf.org/mailman/listinfo/magma
>>
>>
>>
> _______________________________________________
> magma mailing list
> magma <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/magma



_______________________________________________
magma mailing list
magma <at> ietf.org
https://www1.ietf.org/mailman/listinfo/magma

Gmane