Subject: Re: [multimob] [Fwd: New Version Notification for draft-schmidt-multimob-pmipv6-mcast-deployment-03]

From: "Luis M. Contreras" <[email-masked]>
Date: Tue, 05 Jan 2010 00:48:35 +0100

Happy 2010 to all members of the list.

After reading the new version of the 
draft-schmidt-multimob-pmipv6-mcast-deployment, I have some comments, 
thoughts and doubts on it, listed below.

1/ on page 4, second paragraph: "... group membership management as 
signaled by the Multicast Listener Discovery protocol [RFC3810], 
[RFC2710] requires a dedicated treatment at the network side ..."
Due to the fact that either MAG or LMA will be equipments of a core 
network, any modification or tuning of multicast-related protocol 
parameters will appply not only to mobile part, but also to potential 
fixed multicast users using multicast capabilities of both of them, if 
that equipment is shared between mobile and fixed parts of the network. 
That could be a deployment objective for a network operator, looking 
for network roll-out sinergies. For that reason, the tuning of such 
parameters could not be optimal for the mobile case, except if it is 
established that the multicast functionalities of such boxes are only 
focused on and applicable to mobile users.

2/ on page 6, second paragraph: "... the LMA will implement appropriate 
multicast forwarding states at its tunnel interface."
It could be the case in the network that some MAGs do not have 
multicast capabilities. Without extending the PMIPv6 protocol, the LMA 
is not able to know this fact in advance. So, the LMA could configure 
multicast capabilities and waiting for multicast related messages on a 
tunnel where the other end, the MAG, is not able to send them because 
it does not have multicast capabilities. Could be this a security 
threat?

3/ on page 7, first paragraph: " Such mobile node will use IGMPv3 
[RFC3376] signaling for multicast ..."
What about IGMPv2? Is there any reason for not including it?

4/ on page 8, fourth paragraph: "It therefore needs to implement an 
instance of the MLD proxy function [RFC4605] for each upstream tunnel 
interface that has been established with an LMA."
It could be the case that the tunnel between LMA and MAG is not shared 
among MNs, but dedicated per MN. In that case a new MLD proxy per 
upstream tunnel interface  imply an MLD proxy instance per MN, as worst 
case. Even if the shared tunnel seems to be the most logical way of 
solution deployment, these scalability issues should be reflected in 
the draft, with a recommendation or an advise of using shared tunnels 
for this solution to avoid such scalability problems.

5/ on page 8, fifth paragraph: "On the reception of MLD reports from an 
MN, the MAG MUST identify the corresponding proxy instance from the 
incoming interface and perform regular MLD proxy operations..."
Using the same arguments of a past discussion on the mailing list 
between Hitoshi, Thomas and me about what can be considered as a 
protocol extension, I think that some aspects of this solution could 
also fit on such categorization, because from my point of view some of 
the functions required for this solution can not be implemented based 
on existing RFCs. IMO, functions such as dynamic set up of an MLD proxy 
instance per tunnel, binding association between MLD proxy instance and 
a certain LMA, or MLD proxy instance identification for the General 
Query message delivery based on the LMA serving an MN during the 
handover process, are functions not yet documented on existing RFCs. 
So, this features could be seen also as protocol extension even if no 
new messages are introduced in this solution.

6/ on page 9, first paragraph: "To learn about multicast groups 
subscribed by a newly attaching MN, the MAG sends a General Query to 
the MN's link."
The MNs could use different operating systems with distinc support of 
group membership protocols. In an IPv6-based MN, the operating system 
could use either MLDv1 or v2 for subscribing multicast contents. In a 
similar way, IPv4-based MN could use IGMPv2 or v3. When a MN attaches 
to a new MAG. this new MAG ignores the group membership protocol in use 
by the operating system of the MN. For instance, in the IPv6 case, an 
MLD General Query is sent by the MAG, but if MAG runs MLDv2 and MN runs 
MLDv1, the query will be ignored. This could drive to inefficiencies 
and delay on delivering the multicast content to the MN.
So, two possible solutions could be envisioned: (1) send one query per 
group membership version; or (2) send just one query of the lower 
version of the group membership protocol, because backward 
compatibility is ensured from the higher to the lower version.

7/ on page 9, second paragraph: "To prevent erroneous query timeouts at 
the MAG, MLD parameters SHOULD be carefully adjusted to the mobility 
regime.  In particular, MLD timers and the Robustness Variable (see 
section 9 of [RFC3810]) MUST be chosen to be compliant with the time 
scale of handover operations in the PMIPv6 domain."
Comment 1 applies also here.

8/ on page 10, first bullet: "The LMA thus terminates multicast forwarding."
The LMA will terminate the multicast forwarding downstream, but should 
not terminate immediately the reception of the content (by means of an 
MLD Done message upstream, if LMA acts as MLD proxy, or PIM prune 
message signalling upstream, if it acts as mutlicast router) because 
the MN could attach to another MAG in a short time. This protocol 
timing needs also to be reviewed to fit the PMIPv6 scenarios.

9/ on page 11, last paragraph: "... no new threats arrive from 
procedures described in this document in excess to [RFC3810], [RFC4605] 
and [RFC5213] security concerns."
Comment 2 applies also here.

10/ on page 15, setting 2 evaluation.
I think that the value for the number of simultaneous streams at LMA in 
the case of dedicated multicast LMA is not correct. If I understand 
well, the topology under consideration is the following: MAG1 to MAG50 
are connected to LMA1, LMA2, LMA3 and LMA4 for unicast traffic, using 
one tunnel from every MAG to every LMA, and also they are connected to 
LMA-multicast for multicast traffic. Due that the multicast traffic is 
provided by a single LMA-multicast, each MAGs needs a single MLD proxy 
instance to manage such multicast traffic, and so, just one tunnel is 
required between any MAG to the LMA multicast. In this situation, the 
number of simultaneous streams at LMA-multicast is 50, not 200 as 
reported in the draft (200 would be the number obtained if we consider 
4 MLD proxy instances per MAG, as in the combined unicast/multicast 
case, but it has no sense when using a dedicated LMA-multicast box) 
[Maybe Guang or Juan Carlos could confirm this].
So, the numbers should be as follows:
Setting 2:
+===================+================+===================+
| PMIP multicast    | # of redundant | # of sim. streams |
| scheme            | streams at MAG | at LMA / LMA-M    |
+===================+================+===================+
| Combined Unicast/ |          4     |           50      |
| Multicast LMA     |                |                   |
+-------------------+----------------+-------------------+
| Dedicated         |          0     |           50      |
| Multicast LMA     |                |                   |
+-------------------+----------------+-------------------+

11/ on Appendix B.
As mentioned in Comment 4, the worst case for the combined 
unicast/multicast LMA solution proposed by your draft is the case in 
which a new tunnel is set up per MN, that is, the tunnels between MAG 
and LMA are not shared among MNs. IMO this would represent the extremal 
case for this solution. In that case, the numbers for setting two would 
be:
Setting 2:
+===================+================+===================+
| PMIP multicast    | # of redundant | # of sim. streams |
| scheme            | streams at MAG | at LMA / LMA-M    |
+===================+================+===================+
| Combined Unicast/ |      20000     |           50      |
| Multicast LMA     |                |                   |
+-------------------+----------------+-------------------+
| Dedicated         |          0     |           50      |
| Multicast LMA     |                |                   |
+-------------------+----------------+-------------------+

---

Regards,

Luis

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 5 Jan 2010 08:03:24 -0800 (PST)

Hi Luis,
 Happy New Year to all!

One point I would like to clarify: the charter clearly states IGMPv3/MLDv2, so we are not chartered to deal with intricacies of dealing with various versions of IGMP and MLD.

Regards,

Behcet

----- Original Message ----
> From: Luis M. Contreras <[email-masked]>
> To: Thomas C. Schmidt <[email-masked]>
> Cc: [email-masked]
> Sent: Mon, January 4, 2010 5:48:35 PM
> Subject: Re: [multimob] [Fwd: New Version Notification for draft-schmidt-multimob-pmipv6-mcast-deployment-03]
> 
> draft-schmidt-multimob-pmipv6-mcast-deployment, I have some comments, thoughts 
> and doubts on it, listed below.
> 
> 1/ on page 4, second paragraph: "... group membership management as signaled by 
> the Multicast Listener Discovery protocol [RFC3810], [RFC2710] requires a 
> dedicated treatment at the network side ..."
> Due to the fact that either MAG or LMA will be equipments of a core network, any 
> modification or tuning of multicast-related protocol parameters will appply not 
> only to mobile part, but also to potential fixed multicast users using multicast 
> capabilities of both of them, if that equipment is shared between mobile and 
> fixed parts of the network. That could be a deployment objective for a network 
> operator, looking for network roll-out sinergies. For that reason, the tuning of 
> such parameters could not be optimal for the mobile case, except if it is 
> established that the multicast functionalities of such boxes are only focused on 
> and applicable to mobile users.
> 
> It could be the case in the network that some MAGs do not have multicast 
> capabilities. Without extending the PMIPv6 protocol, the LMA is not able to know 
> this fact in advance. So, the LMA could configure multicast capabilities and 
> waiting for multicast related messages on a tunnel where the other end, the MAG, 
> is not able to send them because it does not have multicast capabilities. Could 
> be this a security threat?
> 
> 3/ on page 7, first paragraph: " Such mobile node will use IGMPv3 [RFC3376] 
> signaling for multicast ..."
> 4/ on page 8, fourth paragraph: "It therefore needs to implement an instance of 
> the MLD proxy function [RFC4605] for each upstream tunnel interface that has 
> been established with an LMA."
> It could be the case that the tunnel between LMA and MAG is not shared among 
> MNs, but dedicated per MN. In that case a new MLD proxy per upstream tunnel 
> interface  imply an MLD proxy instance per MN, as worst case. Even if the shared 
> tunnel seems to be the most logical way of solution deployment, these 
> scalability issues should be reflected in the draft, with a recommendation or an 
> advise of using shared tunnels for this solution to avoid such scalability 
> problems.
> 
> 5/ on page 8, fifth paragraph: "On the reception of MLD reports from an MN, the 
> MAG MUST identify the corresponding proxy instance from the incoming interface 
> and perform regular MLD proxy operations..."
> Using the same arguments of a past discussion on the mailing list between 
> Hitoshi, Thomas and me about what can be considered as a protocol extension, I 
> think that some aspects of this solution could also fit on such categorization, 
> because from my point of view some of the functions required for this solution 
> can not be implemented based on existing RFCs. IMO, functions such as dynamic 
> set up of an MLD proxy instance per tunnel, binding association between MLD 
> proxy instance and a certain LMA, or MLD proxy instance identification for the 
> General Query message delivery based on the LMA serving an MN during the 
> handover process, are functions not yet documented on existing RFCs. So, this 
> features could be seen also as protocol extension even if no new messages are 
> introduced in this solution.
> 
> 6/ on page 9, first paragraph: "To learn about multicast groups subscribed by a 
> newly attaching MN, the MAG sends a General Query to the MN's link."
> The MNs could use different operating systems with distinc support of group 
> membership protocols. In an IPv6-based MN, the operating system could use either 
> MLDv1 or v2 for subscribing multicast contents. In a similar way, IPv4-based MN 
> could use IGMPv2 or v3. When a MN attaches to a new MAG. this new MAG ignores 
> the group membership protocol in use by the operating system of the MN. For 
> instance, in the IPv6 case, an MLD General Query is sent by the MAG, but if MAG 
> runs MLDv2 and MN runs MLDv1, the query will be ignored. This could drive to 
> inefficiencies and delay on delivering the multicast content to the MN.
> So, two possible solutions could be envisioned: (1) send one query per group 
> membership version; or (2) send just one query of the lower version of the group 
> membership protocol, because backward compatibility is ensured from the higher 
> to the lower version.
> 
> 7/ on page 9, second paragraph: "To prevent erroneous query timeouts at the MAG, 
> MLD parameters SHOULD be carefully adjusted to the mobility regime.  In 
> particular, MLD timers and the Robustness Variable (see section 9 of [RFC3810]) 
> MUST be chosen to be compliant with the time scale of handover operations in the 
> PMIPv6 domain."
> The LMA will terminate the multicast forwarding downstream, but should not 
> terminate immediately the reception of the content (by means of an MLD Done 
> message upstream, if LMA acts as MLD proxy, or PIM prune message signalling 
> upstream, if it acts as mutlicast router) because the MN could attach to another 
> MAG in a short time. This protocol timing needs also to be reviewed to fit the 
> PMIPv6 scenarios.
> 
> 9/ on page 11, last paragraph: "... no new threats arrive from procedures 
> described in this document in excess to [RFC3810], [RFC4605] and [RFC5213] 
> security concerns."
> I think that the value for the number of simultaneous streams at LMA in the case 
> of dedicated multicast LMA is not correct. If I understand well, the topology 
> under consideration is the following: MAG1 to MAG50 are connected to LMA1, LMA2, 
> LMA3 and LMA4 for unicast traffic, using one tunnel from every MAG to every LMA, 
> and also they are connected to LMA-multicast for multicast traffic. Due that the 
> multicast traffic is provided by a single LMA-multicast, each MAGs needs a 
> single MLD proxy instance to manage such multicast traffic, and so, just one 
> tunnel is required between any MAG to the LMA multicast. In this situation, the 
> number of simultaneous streams at LMA-multicast is 50, not 200 as reported in 
> the draft (200 would be the number obtained if we consider 4 MLD proxy instances 
> per MAG, as in the combined unicast/multicast case, but it has no sense when 
> using a dedicated LMA-multicast box) [Maybe Guang or Juan Carlos could confirm 
> this].
> As mentioned in Comment 4, the worst case for the combined unicast/multicast LMA 
> solution proposed by your draft is the case in which a new tunnel is set up per 
> MN, that is, the tunnels between MAG and LMA are not shared among MNs. IMO this 
> would represent the extremal case for this solution. In that case, the numbers 
> for setting two would be:
> Setting 2:
> _______________________________________________
> multimob mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multimob

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Tue, 05 Jan 2010 21:18:43 +0100

Hi Luis and all,

happy & successful new year to all!

  and thanks for reviewing. Please see my comments inline.

Luis M. Contreras wrote:

> That could be a deployment objective for a network operator, looking for 
> network roll-out sinergies. For that reason, the tuning of such 

I don't think we can regard MAGs & LMAs equally as core routers. MAGs 
are access routers, thus at the edges, and both are mobility-related 
entities. Furthermore, at that part of the draft nothing is said about 
MLD tuning - just an explicit treatment is stressed, here.

> capabilities. Without extending the PMIPv6 protocol, the LMA is not able 
> to know this fact in advance. So, the LMA could configure multicast 
> capabilities and waiting for multicast related messages on a tunnel 
> where the other end, the MAG, is not able to send them because it does 
> not have multicast capabilities. Could be this a security threat?
> 

I don't think so: an LMA will only activate multicast forwarding (on a 
particular interface) after it has received MLD reports. If a MAG is not 
capable of multicast, in particular an MLD proxy function, it will not 
issue upstream MLD reports and thus no forwarding states will appear at 
the LMA.

> What about IGMPv2? Is there any reason for not including it?
No, except for the charter. It could as well be MLDv1.

> solution deployment, these scalability issues should be reflected in the 
> draft, with a recommendation or an advise of using shared tunnels for 
> this solution to avoid such scalability problems.
> 
We can add such a remark, but the shared tunnel is the standard picture 
of RFC5213. If tunnels are not shared, the primary scaling issue arises 
from the number of (unicast) tunnels, I believe.

> the functions required for this solution can not be implemented based on 
> existing RFCs. IMO, functions such as dynamic set up of an MLD proxy 
> handover process, are functions not yet documented on existing RFCs. So, 
> this features could be seen also as protocol extension even if no new 
> messages are introduced in this solution.
> 

This was discussed on the list in early December:
Of course, RFC 4605 does not address dynamic instantiation on tunnel 
appearance. But this is just a time-dependent change of configuration 
which could be done by a script or so. We haven't tried it out in a 
practical set up yet, but this is not a change in protocol behavior as 
it only dynamically adapts system parameters.

Since LMAs and MAGs are infrastructure entities (not dynamically 
changing), this could also be configured manually.

> subscribed by a newly attaching MN, the MAG sends a General Query to the 
> MN's link."
> similar way, IPv4-based MN could use IGMPv2 or v3. When a MN attaches to 
> a new MAG. this new MAG ignores the group membership protocol in use by 
> the operating system of the MN. For instance, in the IPv6 case, an MLD 
> General Query is sent by the MAG, but if MAG runs MLDv2 and MN runs 
> MLDv1, the query will be ignored. This could drive to inefficiencies and 
> delay on delivering the multicast content to the MN.
> version of the group membership protocol, because backward compatibility 
> is ensured from the higher to the lower version.
> 

Interesting point, even though it is only loosely related to PMIP. We 
can add a remark on IGMP/MLD compatibility strategies.

> Comment 1 applies also here.

... as does the answer: Personally, I don't see a deployment where MAGs 
are re-used as (home-gate) access routers. But such tuning, i.e., 
increasing robustness and adjusting timers to characteristic wireless 
behavior, are not likely to harm wired networks. They might lead to an 
increased retransmission or so - but this should not harm the (more 
robust) wired links. Am I missing something relevant here?

> message signalling upstream, if it acts as mutlicast router) because the 
> MN could attach to another MAG in a short time. This protocol timing 
> needs also to be reviewed to fit the PMIPv6 scenarios.
> 

Yes, but in general multicast tree management operations are not that 
fast. Pruning usually follows queries on the downlink.

> Comment 2 applies also here.

... and is answered there.

> reported in the draft (200 would be the number obtained if we consider 4 
> MLD proxy instances per MAG, as in the combined unicast/multicast case, 
> but it has no sense when using a dedicated LMA-multicast box) [Maybe 
> Guang or Juan Carlos could confirm this].

This is not talking about Proxy instances, but about real physical 
boxes. 200 streams are needed at the dedicated LMA, because in this 
sample scenario we have 200 MAGs. And multicast data need to reach a MAG 
at least once.

It's actually a simplified extreme.

> case for this solution. In that case, the numbers for setting two would be:
> Setting 2:

As said before: The standard picture for RFC 5213 is to share tunnels 
between MAGs and LMAs (otherwise you had these large numbers of tunnels 
already in the unicast case ...).

If you consider a scenario, where individual tunnels of each MN reach 
the LMA, then there is actually no way to aggregate tunnel states or 
group data within the standard PMIP infrastructure. You either live with 
the scaling issues (both in unicast and multicast), or you build a 
separate multicast infrastructure, e.g., direct routing or dedicated 
multicast tunnels.

Thanks,

Thomas

-- 

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                   Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
° http://www.haw-hamburg.de/inet                   Fon: +49-40-42875-8452 °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-8409 °

---

From: <[email-masked]>
Date: Wed, 6 Jan 2010 10:10:59 +0100

Dear Thomas, Luis, and all,

Two comments from my side to discussed issues:  
- to Luis' comment 1/7 on converged entities for mobile and fixed users: >From an operator point of view it might be advantageous to serve both classes of terminals concurrently (it seems also for me to be an efficiency problem for fixed case only, doing no harm) - perhaps this can be an issue for future work (e.g. to add a flag for mobile subscriptions to select timers etc. based on degree of mobility - this could even distinguish between slow and fast movement and HO frequency to form corresponding tunnels)
 
- to comment 4/5 on MLD proxy per tunnel behaviour: from my understanding also RFC4605 merges subscriptions of MNs to same multicast group and treats them as one (converged) tunnel so I agree that it should be a genereal PMIP unicast scalability issue and on the other hand: the 4605 definition of membership database treatment and change reporting to upstream allows for some dynamic behaviour which would support MN mobility and MAG handover ... 

And a  general remark to the evaluation in the Annex (which is a good idea I like a lot): 
Couldn't such a rough comparison be extended also to include figures for the other solution drafts and perhaps also estimations  on created signalling message traffic (and corrsponding time delay if applicable) to have some metric or criteria for a decision on the future WG draft?

Thanks

Best regards
Dirk 

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Thomas C. Schmidt
Gesendet: Dienstag, 5. Januar 2010 21:19
An: Luis M. Contreras
Cc: [email-masked]
Betreff: Re: [multimob] [Fwd: New VersionNotification for draft-schmidt-multimob-pmipv6-mcast-deployment-03]

Hi Luis and all,

Thanks,

Thomas

--

---

From: "Luis M. Contreras" <[email-masked]>
Date: Thu, 07 Jan 2010 18:31:12 +0100

Hi Thomas,

Thanks for clarification. I continue the discussion in some of the 
points below.

> No, except for the charter. It could as well be MLDv1.
Nevertheless, along the draft, there are reference to MLDv1 (RFC 2710). 
Maybe they could be removed to avoid confussion.

>> instance of the MLD proxy function [RFC4605] for each upstream 
>> tunnel interface that has been established with an LMA."
>> It could be the case that the tunnel between LMA and MAG is not 
>> shared among MNs, but dedicated per MN. In that case a new MLD proxy 
>> per upstream tunnel interface  imply an MLD proxy instance per MN, 
>> as worst case. Even if the shared tunnel seems to be the most 
>> logical way of solution deployment, these scalability issues should 
>> be reflected in the draft, with a recommendation or an advise of 
>> using shared tunnels for this solution to avoid such scalability 
>> problems.
>>
> We can add such a remark, but the shared tunnel is the standard 
> picture of RFC5213. If tunnels are not shared, the primary scaling 
> issue arises from the number of (unicast) tunnels, I believe.
>
I was thinking in the number of simultaneous MLD instances as limiting 
factor, more than in the number of simultaneous tunnels. I guess the 
MLD instances (together with the tunnel, of course) would waste much 
more resources (in terms of CPU and memory) compared to the resources 
wasted by the unicast tunnel alone. In other words, the number of 
supported unicast MNs with their own tunnel would be much higher than 
the number of supported multicast MNs with their own tunnel.

>> 5/ on page 8, fifth paragraph: "On the reception of MLD reports from 
>> an MN, the MAG MUST identify the corresponding proxy instance from 
>> the incoming interface and perform regular MLD proxy operations..."
>> also fit on such categorization, because from my point of view some 
>> of the functions required for this solution can not be implemented 
>> based on existing RFCs. IMO, functions such as dynamic set up of an 
>> MLD proxy instance per tunnel, binding association between MLD proxy 
>> instance and a certain LMA, or MLD proxy instance identification for 
>> the General Query message delivery based on the LMA serving an MN 
>> during the handover process, are functions not yet documented on 
>> existing RFCs. So, this features could be seen also as protocol 
>> extension even if no new messages are introduced in this solution.
>>
>
> practical set up yet, but this is not a change in protocol behavior 
> as it only dynamically adapts system parameters.
>
I must admit that it is not easy for me to recognize the border between 
what is considered a protocol extension and what not. Let me insist 
with a more specific event detailed in your draft, that I think it 
could be a protocol extension according to the arguments of our early 
discussion.
The situation is the following. When a new MN attaches to nMAG, one of 
the MLD instances of the nMAG will send an MLD General Query. In order 
to determine what of the MLD proxy instances has to send the Query, the 
nMAG must know the association (new MN attached <-> LMA serving that MN 
<-> MLD proxy active in that nMAG-LMA tunnel).
Such kind of register, database or binding association is not supported 
by any RFC nowadays. I think this example fits on what was argued as a 
protocol extension then.

>
>> 7/ on page 9, second paragraph: "To prevent erroneous query timeouts 
>> at the MAG, MLD parameters SHOULD be carefully adjusted to the 
>> mobility regime.  In particular, MLD timers and the Robustness 
>> Variable (see section 9 of [RFC3810]) MUST be chosen to be compliant 
>> with the time scale of handover operations in the PMIPv6 domain."
> ... as does the answer: Personally, I don't see a deployment where 
> MAGs are re-used as (home-gate) access routers. But such tuning, 
> i.e., increasing robustness and adjusting timers to characteristic 
> wireless behavior, are not likely to harm wired networks. They might 
> lead to an increased retransmission or so - but this should not harm 
> the (more robust) wired links. Am I missing something relevant here?
>
As Dirk says in a later mail, I think it would be a good idea to 
separate in some way mobile and fixed parametrization. Of course, this 
is for further work.

>> The LMA will terminate the multicast forwarding downstream, but 
>> should not terminate immediately the reception of the content (by 
>> means of an MLD Done message upstream, if LMA acts as MLD proxy, or 
>> PIM prune message signalling upstream, if it acts as mutlicast 
>> router) because the MN could attach to another MAG in a short time. 
>> This protocol timing needs also to be reviewed to fit the PMIPv6 
>> scenarios.
>>
>
Anyway, I think it should be carefully reviewed to ensure that the LMA 
does not leave the multicast tree if acts as multicast router, or the 
LMA does not send and MLD done message if acts as another MLD proxy, as 
a general comment to multicast in PMIP.

>> I think that the value for the number of simultaneous streams at LMA 
>> in the case of dedicated multicast LMA is not correct. If I 
>> understand well, the topology under consideration is the following: 
>> MAG1 to MAG50 are connected to LMA1, LMA2, LMA3 and LMA4 for unicast 
>> traffic, using one tunnel from every MAG to every LMA, and also they 
>> are connected to LMA-multicast for multicast traffic. Due that the 
>> multicast traffic is provided by a single LMA-multicast, each MAGs 
>> needs a single MLD proxy instance to manage such multicast traffic, 
>> and so, just one tunnel is required between any MAG to the LMA 
>> multicast. In this situation, the number of simultaneous streams at 
>> LMA-multicast is 50, not 200 as reported in the draft (200 would be 
>> the number obtained if we consider 4 MLD proxy instances per MAG, as 
>> in the combined unicast/multicast case, but it has no sense when 
>> using a dedicated LMA-multicast box) [Maybe Guang or Juan Carlos 
>> could confirm this].
> sample scenario we have 200 MAGs. And multicast data need to reach a 
> MAG at least once.
>
Sorry, I don't understand well the scenario. If we have 200 MAGs and 4 
LMAs, with 50 MAGs per LMA, then I don't see why 4 redundant streams 
arrive to the MAG in setting 2 for the combined unicast/multicast LMA. 
It should be also 0. For instance, if MAG1 to MAG50 connects to LMA1, 
then LMA1 will send a unique copy of the content to every MAG, so there 
is no case for redundant streams. Maybe it would be usefull to add some 
picture showing the scenario you want to study.

Thanks,

Regards,

Luis

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Thu, 07 Jan 2010 19:02:16 +0100

Hi Luis,

sorry to answer only in brief - please see inline:

> Maybe they could be removed to avoid confussion.

Right, we will make the citings consistent ...

>>> per upstream tunnel interface  imply an MLD proxy instance per MN, as 
>>> worst case. Even if the shared tunnel seems to be the most logical 
>>> way of solution deployment, these scalability issues should be 
>>> reflected in the draft, with a recommendation or an advise of using 
>>> shared tunnels for this solution to avoid such scalability problems.
>>>
> factor, more than in the number of simultaneous tunnels. I guess the MLD 
> instances (together with the tunnel, of course) would waste much more 
> resources (in terms of CPU and memory) compared to the resources wasted 
> by the unicast tunnel alone. In other words, the number of supported 
> unicast MNs with their own tunnel would be much higher than the number 
> of supported multicast MNs with their own tunnel.
> 

The scaling issue comes IMHO with numbers: not every MN will receive 
multicast, but supposedly will use unicast communication. So the number 
of unicast-related tunnels will be much higher than MLD proxy instances.

> what is considered a protocol extension and what not. Let me insist with 
> a more specific event detailed in your draft, that I think it could be a 
> protocol extension according to the arguments of our early discussion.

The issue in your argument is that the order of operation is inversed: 
You don't need an MLD proxy instance for the querying - if the MN 
arrives, the new link will be just MLD-enabled (this is what our test 
report was about btw.).

Once you have the unicast binding (including possible set-up of the 
LMA-MAG tunnel) and an answered MLD query, you set up the proxy instance 
/ add the down-link interface to a specific proxy instance. Those 
operations are simple configurations, you don't need to change software 
for that.

> picture showing the scenario you want to study.

Setting 2 describes that all MNs are joined to the same multicast group. 
It is assumed that due to the MN <-> LMA association, each MAG has 
tunnels to all (4) LMAs. Then each MAG receives mcast data 4 times, one 
from each MAG. Of course, it could be less in some sample scenario, but 
this describes the worst case.

Best wishes,

Thomas

--

---

From: Stig Venaas <[email-masked]>
Date: Mon, 18 Jan 2010 16:36:55 -0800

> sorry to answer only in brief - please see inline:
[...]
>>> changing), this could also be configured manually.

According to RFC 4605 it must be possible to configure the proxy
with an upstream interface and a set of downstream interfaces. We
want to change the set of downstream interfaces dynamically, some
implementations support this. But there may be some that don't too.

Aside from this, I believe we don't require any changes in a proxy
implementation, just that you can run multiple proxy processes with
different configuration.

>> I must admit that it is not easy for me to recognize the border 
>> between what is considered a protocol extension and what not. Let me 
>> insist with a more specific event detailed in your draft, that I think 
>> it could be a protocol extension according to the arguments of our 
>> early discussion.
>> to determine what of the MLD proxy instances has to send the Query, 
>> the nMAG must know the association (new MN attached <-> LMA serving 
>> that MN <-> MLD proxy active in that nMAG-LMA tunnel).
>> Such kind of register, database or binding association is not 
>> supported by any RFC nowadays. I think this example fits on what was 
>> argued as a protocol extension then.
>>

A MAG already keeps track of which MNs are using which LMA, right? So
my thinking is that first you do what is done today to set up the MAG-MN
link and register with the LMA. Once this process is done, we need some
new code in a MAG that determines whether the MN should be provisioned
with multicast, and in that case, find the proxy process that is used
with that LMA and reconfigure it, adding a new downstream interface.

I don't see this as a protocol change. Whatever we do, we need some
additional functionality in MAG and/or LMA for multicast to be provided.

> operations are simple configurations, you don't need to change software 

There is a problem here. You can in theory send an MLD query before the
proxy instance is configured with a new downstream interface. However,
you cannot handle the MLD report until the proxy is reconfigured.

When the proxy gets a new downstream interface, it will have no state
for that interface. Hopefully, the proxy will as soon as it gets a new
interface, send an MLD general query to create the desired state.

Stig

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Tue, 19 Jan 2010 18:26:16 +0100

Hi Stig & Luis,

please see inline:

Stig Venaas wrote:
>>>>> 5/ on page 8, fifth paragraph: "On the reception of MLD reports 
>>>>> from an MN, the MAG MUST identify the corresponding proxy instance 
>>>>> from the incoming interface and perform regular MLD proxy 
>>>>> operations..."
>>>>> protocol extension, I think that some aspects of this solution 
>>>>> could also fit on such categorization, because from my point of 
>>>>> view some of the functions required for this solution can not be 
>>>>> implemented based on existing RFCs. IMO, functions such as dynamic 
>>>>> set up of an MLD proxy instance per tunnel, binding association 
>>>>> between MLD proxy instance and a certain LMA, or MLD proxy instance 
>>>>> identification for the General Query message delivery based on the 
>>>>> LMA serving an MN during the handover process, are functions not 
>>>>> yet documented on existing RFCs. So, this features could be seen 
>>>>> also as protocol extension even if no new messages are introduced 
>>>>> in this solution.
>>>>>
>>>>
>>>> appearance. But this is just a time-dependent change of 
>>>> configuration which could be done by a script or so. We haven't 
>>>> tried it out in a practical set up yet, but this is not a change in 
>>>> protocol behavior as it only dynamically adapts system parameters.
>>>>
>>> insist with a more specific event detailed in your draft, that I 
>>> think it could be a protocol extension according to the arguments of 
>>> our early discussion.
>>> The situation is the following. When a new MN attaches to nMAG, one 
>>> of the MLD instances of the nMAG will send an MLD General Query. In 
>>> order to determine what of the MLD proxy instances has to send the 
>>> Query, the nMAG must know the association (new MN attached <-> LMA 
>>> serving that MN <-> MLD proxy active in that nMAG-LMA tunnel).

Yes, we need the dynamic interface assignment to proxy instances 
triggered by the pure presence of MLD report (this is independent of 
groups/sources, so no multicast semantic is required).

As mentioned earlier, this is something like a little script: exterior 
configuration code, not changing PMIP/MAG or MLD proxy implementations 
itself.

>> LMA-MAG tunnel) and an answered MLD query, you set up the proxy 
>> instance / add the down-link interface to a specific proxy instance. 
>> Those operations are simple configurations, you don't need to change 
>> software for that.
> 

O.K. - right: so we have gained a fruitful insight of this discussion.

What happens is: When the MAG-MN interface comes up, it must be 
preconfigured to be simply MLD-enabled. So it sends a General Query on 
start-up. When the MN sends its first report, the proxy correspondence 
is resolved and the interface is added to the correct proxy instance - 
without forwarding state. Then a second report is required to implement 
the state.

This second report could follow an additional Query of the proxy, but 
could also be received as iterate. This might be another reason (aside 
from wireless link characteristics) to increase the Robustness Variable ...

In any case, it is worth adding the pointer to the draft that dynamic 
interface configuration should stay within the time limit of MLD/IGMP 
retransmissions.

Thanks for the good point!

Cheers,

Thomas
--

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 19 Jan 2010 11:14:44 -0800 (PST)

Hi,

> What happens is: When the MAG-MN interface comes up, it must be preconfigured to 
> be simply MLD-enabled. So it sends a General Query on start-up. When the MN 
> sends its first report, the proxy correspondence is resolved and the interface 
> is added to the correct proxy instance - without forwarding state. Then a second 
> report is required to implement the state.
> 
> This second report could follow an additional Query of the proxy, but could also 
> be received as iterate. This might be another reason (aside from wireless link 
> characteristics) to increase the Robustness Variable ...

For my IGMP/MLD education, what about proxy aggregating the downstream state in its upstream interactions? The above sounds like every MLD report generates a MLD general query.

Regards,

Behcet

---

From: Stig Venaas <[email-masked]>
Date: Tue, 19 Jan 2010 12:11:29 -0800

Thomas C. Schmidt wrote:
>>>>>> between MLD proxy instance and a certain LMA, or MLD proxy 
>>>>>> instance identification for the General Query message delivery 
>>>>>> based on the LMA serving an MN during the handover process, are 
>>>>>> functions not yet documented on existing RFCs. So, this features 
>>>>>> could be seen also as protocol extension even if no new messages 
>>>>>> are introduced in this solution.
>>>>>>
>>>>>
>>>>> Of course, RFC 4605 does not address dynamic instantiation on 
>>>>> tunnel appearance. But this is just a time-dependent change of 

I thought the interface assignment would be done when the MAG has
determined with LMA the MN uses.

> configuration code, not changing PMIP/MAG or MLD proxy implementations 

I agree.
>>
>>> The issue in your argument is that the order of operation is 
>>> inversed: You don't need an MLD proxy instance for the querying - if 
>>> the MN arrives, the new link will be just MLD-enabled (this is what 
>>> our test report was about btw.).
>>>

I can see that. But at least your order is different from what I have
been thinking.

First of all though, I'm not sure at what point the MAG-MN link is up,
is it there even before the MAG has determined which LMA to use? This
is a basic question, I should maybe go back and try to figure that out.

My thinking is that things happen in the following order:

1. MAG-MN link comes up (a new MN has arrived)
(1.5 MLD query sent here?)
2. MAG determines LMA
3. MAG determines if MN should have multicast, if not stop here
4. MAG tells the MLD proxy for the LMA that it needs to add the
    MAG-MN link to its list of downstream interfaces
5. Proxy adds sends (or somehow triggers) an MLD general query
6. MN sends MLD report
7. Proxy process the MLD report, updates state etc...

I think it may vary between implementations whether MLD queries are
sent on an interface that is up but not associated with a proxy.
Similar to how say some routers need PIM configured on an interface
to act as a multicast router and send MLD queries. Although I think
this is more true for IGMP than MLD, since MLD is supposed to be
there even for IPv6 unicast.

That is, I think typically point 1.5 above would happen for MLD, but
there may be implementations that don't. For IGMP it is less likely
to happen.

It also depends who is responsible for sending the MLD queries. If
you think of a UNIX platform, the question is whether it would be
the kernel or the proxy process. In the former case you might have
queries sent as soon as interface comes up. If it is the proxy, then
you would obviously not send queries until the proxy is there.

If it is the kernel, the question is whether queries are sent by
default on all interfaces that are up, or if the proxy needs to
enable it for its downstream interfaces.

Note that in point 5, you may either have the proxy sending the
MLD query, or it might use an API to tell the kernel to send an
MLD report now (and probably restart timers).

I don't think it matters that much whether 1.5 happens or not,
as long as the proxy does point 5.

Of course there may be implementations that don't do 5 either, but
I really expect them to do it. Else the proxy will have to wait
until the next periodic query to build its state. It's critical
that the proxy builds its state ASAP. This is not specific to
our scenario. E.g. when you have a switch with some interfaces
that are up, but not configured for MLD snooping. When you
configure MLD snooping on such an interface, the switch should
receive reports immediately. You might also see RFC 4541,
section 4, Q9. This is regarding new queries sent for topology
changes.

You are right that by tuning MLD, maybe we can make sure that
reports to the query at point 1.5 arrive after 4 above (actually
after the proxy is listening for reports). Are we able to say
for sure how long this takes? I think it's a better solution
that the proxy sends a new query.

I think some of these choices can be left to implementations, but
its good if we document these considerations, so that implementers
are aware of them.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Tue, 19 Jan 2010 14:07:48 -0800

> For my IGMP/MLD education, what about proxy aggregating the downstream state in its upstream interactions? The above sounds like every MLD report generates a MLD general query.

There is a difference between IGMP/MLD snooping and proxying. A proxy
should do aggregation as you say. So when a new report comes from a MN
(either one that just got associated with this MAG, or one that changes
its memberships), the proxy should update its state. It should however
not trigger an IGMP/MLD report upstream unless the aggregate state has
changed. E.g. if another MN previously sent reports for the same group
(or S,G), there is no reason in sending a new report upstream.

Aggregation may not strictly be necessary, but I think we need it for
things to scale with a large number of MNs.

This aggregation is already specified in RFC 4605.

Stig

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Wed, 20 Jan 2010 00:51:46 +0100

Hi Stig,

Stig Venaas wrote:
>>>>>>> from an MN, the MAG MUST identify the corresponding proxy 
>>>>>>> instance from the incoming interface and perform regular MLD 
>>>>>>> proxy operations..."
>>>>>>> implemented based on existing RFCs. IMO, functions such as 
>>>>>>> dynamic set up of an MLD proxy instance per tunnel, binding 
>>>>>>> association between MLD proxy instance and a certain LMA, or MLD 
>>>>>>> proxy instance identification for the General Query message 
>>>>>>> delivery based on the LMA serving an MN during the handover 
>>>>>>> process, are functions not yet documented on existing RFCs. So, 
>>>>>>> this features could be seen also as protocol extension even if no 
>>>>>> tried it out in a practical set up yet, but this is not a change 
>>>>>> in protocol behavior as it only dynamically adapts system parameters.
>>>>>>
>>>>> between what is considered a protocol extension and what not. Let 
>>>>> me insist with a more specific event detailed in your draft, that I 
>>>>> think it could be a protocol extension according to the arguments 
>>>>> of our early discussion.
>>>>> supported by any RFC nowadays. I think this example fits on what 
>>>>> was argued as a protocol extension then.
>>>>>
>>>

Either way, I guess this is a matter of choice: When done immediately 
after unicast binding, multicast will be operationally prepared ASAP on 
the price of possible proxy instances that are never used. If done only 
after the first MLD Report is received, multicast initialization may be 
delayed for the first MN <-> MAG <-> LMA association, but pure unicast 
communication will never activate the proxy instances.

So I wouldn't mind any way.

>> without forwarding state. Then a second report is required to 
>> implement the state.
>>
Yes, it must be up prior to the binding, as normally there is an initial 
RouterSolicitation. The MAG needs to know which MN is behind that link, 
at least.

> 7. Proxy process the MLD report, updates state etc...

This sounds good to me. It might depend on the configuration how quick 
the initial MLD Query/Report. We have seen the Query to wait for IPv6 
address configuration.

> there even for IPv6 unicast.

Yes, but we have seen Queries with and without PIM on the devices under 
test.

> there may be implementations that don't. For IGMP it is less likely

We have seen IGMP correspondingly to MLD. IGMP is usually a bit faster 
as it does not care about unicast address configuration.

> you would obviously not send queries until the proxy is there.
We have tested without a proxy instance running. I would guess that the 
MLD kernel functions already have sent Queries when the proxy comes up 
in normal implementations, i.e., starting the proxy will not interfere 
with the regular MLD until it is running.

> enable it for its downstream interfaces.
This is by default. We have discussed this before and tested. It is 
documented in Appendix A of the document. Tests have been performed for 
a Cisco and Linux - unfortunately, we don't have Avici routers in our 
lab ;)

> as long as the proxy does point 5.

This should probably be tested as well. We'll have a look.

> section 4, Q9. This is regarding new queries sent for topology
I guess so. It seems, that implementations are aware of that.

> that the proxy sends a new query.
Yes, it will be definitely more reliable and a redundant Query will not 
kill the air interface. But it may be worth pointing at that multicast 
services will profit from a quick interface management, which most 
likely does not cause effort as the proxy is already up and running.

> its good if we document these considerations, so that implementers
Sure, we'll do.

Cheers,

Thomas
--

---

From: Stig Venaas <[email-masked]>
Date: Tue, 19 Jan 2010 16:15:29 -0800

Thomas C. Schmidt wrote:
>>>>>>>> Using the same arguments of a past discussion on the mailing 
>>>>>>>> list between Hitoshi, Thomas and me about what can be considered 
>>>>>>>> as a protocol extension, I think that some aspects of this 
>>>>>>>> solution could also fit on such categorization, because from my 
>>>>>>>> point of view some of the functions required for this solution 
>>>>>>>> can not be implemented based on existing RFCs. IMO, functions 
>>>>>>>> such as dynamic set up of an MLD proxy instance per tunnel, 
>>>>>>>> binding association between MLD proxy instance and a certain 
>>>>>>>> LMA, or MLD proxy instance identification for the General Query 
>>>>>>>> message delivery based on the LMA serving an MN during the 
>>>>>>>> handover process, are functions not yet documented on existing 
>>>>>>>> RFCs. So, this features could be seen also as protocol extension 
>>>>>>>> even if no new messages are introduced in this solution.
>>>>>>>>
>>>>>>>
>>>>>> me insist with a more specific event detailed in your draft, that 
>>>>>> I think it could be a protocol extension according to the 
>>>>>> arguments of our early discussion.
>>>>>> The situation is the following. When a new MN attaches to nMAG, 
>>>>>> one of the MLD instances of the nMAG will send an MLD General 
>>>>>> Query. In order to determine what of the MLD proxy instances has 
>>>>>> to send the Query, the nMAG must know the association (new MN 
>>>>>> attached <-> LMA serving that MN <-> MLD proxy active in that 
>>>>>> nMAG-LMA tunnel).

I don't understand what you mean here. Are you somehow talking about a
proxy instance that is not associated with a specific LMA?

I can think of some ways to get the state from the MN before you know
the LMA, and then later provide that info to the correct proxy, but
that would IMO require a larger change to the proxy code.

> communication will never activate the proxy instances.

I believe it would result in a slightly longer delay (longer time before
the MN receives its content), but it may not be significant.

>>> As mentioned earlier, this is something like a little script: 
>>> exterior configuration code, not changing PMIP/MAG or MLD proxy 
>>> implementations itself.
>>
>> I agree.
>>>>
>>>>> inversed: You don't need an MLD proxy instance for the querying - 
>>>>> if the MN arrives, the new link will be just MLD-enabled (this is 
>>>>> what our test report was about btw.).
>>>>>
>>>>> instance / add the down-link interface to a specific proxy 
>>>>> instance. Those operations are simple configurations, you don't 
>>>>> need to change software for that.
>>>>
>>> preconfigured to be simply MLD-enabled. So it sends a General Query 
>>> on start-up. When the MN sends its first report, the proxy 
>>> correspondence is resolved and the interface is added to the correct 
>>> proxy instance - without forwarding state. Then a second report is 
>>> required to implement the state.
>>>
>>> could also be received as iterate. This might be another reason 
>>> (aside from wireless link characteristics) to increase the Robustness 
>>> Variable ...
>>

Stig

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Wed, 20 Jan 2010 10:05:46 +0100

Hi Stig,

Stig Venaas wrote:

>> after unicast binding, multicast will be operationally prepared ASAP 
>> on the price of possible proxy instances that are never used. If done 
>> only 
> 

No, and I just see that I was confused by a previous discussion. I guess 
you're just right: the interface assignment should be done when the MAG 
has resolved the binding of the new MN.

> that would IMO require a larger change to the proxy code.
Yes, but this is a different story. One might do it that way, when 
re-implementing MLD proxy - but it is not needed here.

Cheers,

Thomas

--

---

From: "Luis M. Contreras" <[email-masked]>
Date: Fri, 22 Jan 2010 18:01:17 +0100

Hi Stig,

[...]
> as long as the proxy does point 5.

if step 1.5 does not happen, then the MAG in step 3 can not determine 
that the MN requires multicast service, at least at this stage (no 
protocol extension), because there is no other way to know it. So, the 
Proxy instance should always send the MLD Query as stated on step 5, or 
wait for a periodic MLD status refresh.

As a consequence, the MAG-MN link will be always added to the list of 
downstream interfaces (and it could be removed afterwards if MN has no 
active multicast service).

Am I wrong?

Thanks,

regards,

Luis

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Fri, 22 Jan 2010 23:03:37 +0100

Hi Luis,

> active multicast service).

Sounds about right to me. I know we had the discussion on resources 
consumed by proxies on the MAG, but I suppose (without knowing realistic 
numbers) a downstream interface controlled by a proxy does not make much 
difference when compared to a pure MLD-enabled one (MLD state tables 
need to be allocated either way).

Cheers,

Thomas
--

---

From: Stig Venaas <[email-masked]>
Date: Fri, 22 Jan 2010 14:13:00 -0800

Thomas C. Schmidt wrote:
>> Proxy instance should always send the MLD Query as stated on step 5, 
>> or wait for a periodic MLD status refresh.
>>

I think maybe it should always be added anyway (except if the MAG has
some policy for which MNs should get multicast service, and knows it
should not get it).

The problem is that if you send MLD query to the MN, it will (is
supposed to) always send a report back for some link-local addresses.
This is just how IPv6 unicast should work where the host joins e.g.
the solicited-node-multicast-address or whatever it's called.

If you want to determine if it needs a multicast service, you would need
to check if there are any non-link-local groups in the report, and only
in that case add it to the list of downstream interfaces. But this is a
bit tricky.

Also, it might be that it's only later that the host joins some
non-link-local groups. You would then have to keep monitoring MLD
reports to find out when the interface should be added.

It's much simpler to always add the interface, and have the proxy
examine the MLD reports.

Stig