Subject: [multimob] Comments on draft-zuniga-multimob-smspmip-00

From: "Luis M. Contreras" <[email-masked]>
Date: Wed, 28 Oct 2009 10:56:41 +0100

Hi all,

I have some comments on draft-zuniga-multimob-smspmip-00 that I would 
like to share with you. These comments are:

Section 4 presents the architecture of the dedicated LMA multicast. I 
have two questions on this:
- Both LMAs (unicast and multicast) keep the same information in their 
respective binding caches? How can be guaranteed the coherence of the 
information contained in both binding caches?
- Due that the MAG executes two binding processes, it is possible that 
it could receive two distinct link-local addresses (one for each LMA) 
for the same point-to-point link with MN. Could be this a problem for 
the MN or the MAG when managing traffic in the point-to-point link?

Figure 5 does not include the description of a MN receiving 
simultaneously unicast and multicast service. It seems that the 
delivery by the MN of an MLD report is the trigger to launch the 
registration (PBU/PBA) with LMA multicast. Some questions arise to me 
in this point:
- In case of any MN does not have an active subscription to a multicast 
content then the multicast tunnel will not be set up. Is it ok?
- If the trigger is the delivery of an MLD Report, in case a MN just 
connect to LMA multicast (as MN3 case in figure 4) but no active 
suscription is required by the MN at that moment, what is the status of 
such MN in the network? It would not be registered at any LMA 
multicast. Would it be, let say, in a "ghost" status?

In section 4.3, figure 6, the MN resignals the multicast membership 
sending an MLD report. In my opinion this means that the MN is aware of 
the mobility process, so it is in conflict with the PMIPv6 aim.

In section 5.2 you introduce the handover triggers as mechanisms to 
minimise the service disruption as the MN moves. You extend this 
possibility to both unicast and multicast service. The handover trigger 
establish in advance the tunnel between the LMA and the MAG. I have 
some questions here:
- For the unicast case, if the tunnel between the LMA and the nMAG is 
simultaneously established with that between pMAG and LMA, what is the 
routing decission in LMA?
- Could be seen the establishment of the second tunnel between nMAG and 
LMA as a modification of current PMIPv6 protocol? According to RFC5213 
the trigger for sending PBU/PBA messages in nMAG is the MN attachment 
event. You propose to establish the tuinnel before the attachment event.
- In figure 8 the HO trigger is forwarded by the LMA, but, how does the 
LMA know the nMAG to forward the HO trigger? At that time the MN is not 
yet attached to nMAG, so the LMA is not aware of the nMAG, except if 
the nMAG is identified in the HO trigger message. But if so, what is 
the sense of sending it to the LMA and not directly to nMAG?
- Just after figure 8 you mention that either the LMA or the MAG can 
initiate the establishment of the multicast tunnel in advance, but as 
stated in RFC5213 it is always the MAG which initiates the siganalling 
with the PBU/PBA sequence. Could be seen the establishment of the 
tunnel triggered by the LMA as a modification of current PMIPv6 
protocol?

Thanks for any further clarification,

best regards,

Luis

---

From: "Lu, Guang" <[email-masked]>
Date: Fri, 30 Oct 2009 17:22:03 -0400

Hi Luis, 

Thank you for providing comments to our draft. Please see our replies
below. 

Best regards,
Guang & Juan Carlos

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Luis M. Contreras
> Sent: Wednesday, October 28, 2009 5:57 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [multimob] Comments on draft-zuniga-multimob-smspmip-00
> 
> Hi all,
> 
[Guang-JC] Both unicast and multicast LMAs serve independent sets of MNs
so they can have different binding caches. On the other hand, if an MN
has both the unicast LMA and multicast LMA in its policy profile, the
MAG will do the Binding Update to unicast LMA and multicast LMA
independently.  

> the MN or the MAG when managing traffic in the point-to-point link?
[Guang-JC] We don't think there are problems. There are multiple ways to
have it worked out. First, the MAG and MN can have p2p link for the
unicast data, and p2mp link for multicast data. Then it is ok for these
two links have different link local addresses. Second, a fixed
link-local address across all the access links in a Proxy MIPv6 domain
can be used per RFC 5213. Third, in case there is a link-local address
collision, the MAG can report back to LMA.   

> content then the multicast tunnel will not be set up. Is it ok?
[Guang-JC] Please see replies to the next question since they are
related.

> multicast. Would it be, let say, in a "ghost" status?
[Guang-JC] The MLD procedures are on top of PMIP procedures, i.e., the
MLD report triggers the multicast traffic in the tunnel, but not the
establishment of the PMIP tunnel. The MAG decides when to send the PBU.
So the status of a MN in a network depends on if it's registered by MAG
with the PMIP domain. In the scenario of Figure 4, as long as MAG
registers the MN with the multicast LMA, the MN is not "ghost". This
falls into the procedures defined in RFC 5213. We can add texts to
clarify the above in the next version of the draft.

> the mobility process, so it is in conflict with the PMIPv6 aim.
[Guang-JC] This is also related to the discussions above. MLD report
enables the multicast service. It is on top of PMIP procedures. The MN
is not aware of the mobility process. The MN can send MLD report by
replying an MLD Query, regardless of its mobility status. We can add
texts to clarify it in the next version of the drafts.

> routing decission in LMA?
[Guang-JC] The LMA will have to temporarily send the traffic to both
tunnels, until the tunnel with the p-MAG is torn down.

> event. You propose to establish the tuinnel before the attachment
[Guang-JC] In our view, the trigger of PBU is an implementation issue,
rather than the PMIPv6 protocol itself. For example, in section 6.9.1.1
of RFC 5213, under bullet 1, it states "if it (MAG) determines that the
network-based mobility management service needs to be offered to the
mobile node, it MUST send a Proxy Binding Update message to the local
mobility anchor".

> the sense of sending it to the LMA and not directly to nMAG?
[Guang-JC] The MN might have discovered the nMAG and included it in the
HO trigger information; or if it is a network commanded HO, the nMAG can
be known as HO target in advance. There are such discussions regarding
fast HO for MIP and PMIP in other groups. In this draft, we didn't
discuss it explicitly since we thought it is out of the scope of this
draft.  
We illustrated a scenario that LMA forwards the HO trigger to nMAG. This
is for the cases when there are no direct communication between the
p-MAG and n-MAG.

> tunnel triggered by the LMA as a modification of current PMIPv6
[Guang-JC] No. The intention is not to modify PMIPv6. The explanation of
Figure 8 is above the figure. As you can see, in order not to change the
sequence of PMIPv6 that it is always MAG initiates the PBU, the HO
trigger is passed from LMA to n-MAG. 
The text you mentioned is talking about another scenario, when a network
node is aware of HO triggers (by comparison to the scenarios that MN is
aware of HO triggers).The procedures are pretty much the same as what's
shown in Figure 7 and 8, except that the HO trigger exchanges will be
between network nodes only. 
We agree with you that the wording is a bit confusing and we'll update
it in the next version.

> _______________________________________________
> multimob mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multimob

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Fri, 30 Oct 2009 22:36:44 +0100

Hi Guang & Luis,

sorry to interfere this discussion ... but please see inline:

> MAG will do the Binding Update to unicast LMA and multicast LMA
[Thomas] There is no need for a binding cache here, as - according to 
the draft - there is only a single MLD proxy instance, thus a single 
uplink and therefore only a single multicast LMA. All MAGs throughout 
the PMIP domain MUST share the uplink for multicast with this particular 
LMA. The LMA will thus forward according to (proxy-initiated) forwarding 
states at its tunnel interfaces that are independent of individual MNs.

Cheers,

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: "Luis M. Contreras" <[email-masked]>
Date: Sat, 31 Oct 2009 13:18:52 +0100

Hi Thomas,

thanks for interfering because it always enrich the discussion process.

My answer below:

> the PMIP domain MUST share the uplink for multicast with this 
> particular LMA. The LMA will thus forward according to 
> (proxy-initiated) forwarding states at its tunnel interfaces that are 
> independent of individual MNs.
>
[Luis] According to RFC5213, section 3, the actions taken by the LMA 
once it receives tha PBU message from the MAG are: "Upon accepting this 
Proxy Binding Update message, the local mobility anchor sends a Proxy 
Binding Acknowledgement message including the mobile node's home 
network prefix(es). It also creates the Binding Cache entry and sets up 
its endpoint of the bi-directional tunnel to the mobile access 
gateway." So, if the way of registering in the multicast-dedicated LMA 
is the standard PBU/PBA procedure, a binding cache should be created 
and maintained for the MN there. If not, we are altering the protocol 
specified in RFC5213. Maybe this is an extreme interpretation by myself.

Furthermore something could be said regarding the reference in RFC5213 
to the mobile node's home network prefix(es). I think that if the 
procedure is not the same for LMA multicast than for LMA unicast we are 
then defining a bit different signalling procedure .

Rergards,

Luis

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Sat, 31 Oct 2009 14:25:02 +0100

Hi Luis,

O.K. - you caught me by being too fast ;)

The issue nevertheless is only the name "LMA" I guess ... see below:

Luis M. Contreras wrote:

> Binding Acknowledgement message including the mobile node's home network 
> prefix(es). It also creates the Binding Cache entry and sets up its 
> endpoint of the bi-directional tunnel to the mobile access gateway." So, 
> if the way of registering in the multicast-dedicated LMA is the standard 
> PBU/PBA procedure, a binding cache should be created and maintained for 
> the MN there. If not, we are altering the protocol specified in RFC5213. 
> Maybe this is an extreme interpretation by myself.
> 

[Thomas] I agree, you are perfectly right, as long as we call this 
multicast thing "LMA". If we just call it a multicast designated router, 
then no binding procedures with the MN ("A receiver") are required. In 
fact, an MLD proxy is supposed to aggregate states ... and a multicast 
router is supposed to maintain only 'anonymous' forwarding states at its 
downstream interfaces (towards the MAGs). That actually would make 
things much easier and reduces protocol operations to what is really needed.

> then defining a bit different signalling procedure .

[Thomas] The home network prefix(es) and all other *unicast*-related 
states of the MN's profile should be maintained by the (untouched) 
unicast entities: there will be an LMA operating unicast mobility as 
described in RFC5213 ... in this proposal, multicast comes as an 
"additional overlay", unseen by the 'standard LMAs', I believe.

Am I understanding things correctly?

Best regards,

Thomas
--