Subject: [netext] multi-LMA : how to handle

From: Marco Liebsch <[email-masked]>
Date: Fri, 20 Nov 2009 10:44:05 +0100

Folks,

as a follow up of our discussion about localized routing in a
multi-LMA setup, I'd like to initiate a general and clarifying
discussion about signaling paths to set up and maintain a
localized routing path, as current solution proposals cover
different approaches.

We had the discussion about PMIPv6 domains vs provider domains
and came to the conclusion that it's not mandatory for MN and CN
to share the same PMIPv6 domain.

Assume MN connects to MAG1 and LMA1, whereas CN connects
to MAG2 and LMA2. MAG1 shares a PMIP domain with LMA1
and MAG2 shares a PMIP domain with LMA2. We cannot assume
that MAG1 shares a PMIP domain with LMA2.

Now, there are two questions to solve:
(1) Who detects and initiates localized routing, MAG or LMA
(2) How to synchronize distributed states? Will LMA1 contact
LMA2 or will MAG1 contact LMA2

If an existing SA is the only indicator to set up a PMIPv6
domain, then one solution could be to set up an SA dynamically
between MAG1 and LMA2, which needs to be re-done every time
MN1 performs a handover to a different MAG, say MAG1*. This
may be a disadvantage and will blow up PMIPv6 domains, which
are rather administratively configured, in my opinion.

The other alternative is that PMIPv6 domain stractures are not touched
and LMA1 will signal with LMA2 to synchronize states of MN and CN.
Advantage would be that LMAs do not change during a handover and
will keep states on one place.

Any opinions?

marco

---

From: Qin Wu <[email-masked]>
Date: Mon, 23 Nov 2009 14:23:11 +0800

Hi, Marco:
Thank for your raising discussion on Multi-LMA issue.
Please see my comments inline!

Regards!
-Qin
----- Original Message ----- 
From: "Marco Liebsch" <[email-masked]>
To: <[email-masked]>
Sent: Friday, November 20, 2009 5:44 PM
Subject: [netext] multi-LMA : how to handle

> (1) Who detects and initiates localized routing, MAG or LMA

[Qin]: I think Both have its value and are applicable to different scenarios. Whether using MAG initiated or using LMA initiated depends on
who detects localized routing, in other words, if MAG detects local routing is possible, then MAG initiated is more appropriate.
e.g., As described in RFC5213, in the scenario where MN and CN attach to the same MAG, MAG initiated local routing can
be used to negotiate with LMA and enfoce local routing on the MAG.
If LMA is responsible for local routing, then LMA inititated and MAG initiate both can be used.
e.g., in the scenario where MN and CN attach to the different MAGs but connect to the different LMA or the same LMA.

> are rather administratively configured, in my opinion.

[Qin]: It seems to me SA setup each time MN handover to the new MAG is one generic issue we should face for all the Multi-LMA cases.
In other words,When using LMA1 to signal with LMA2 for states synchroizing, it has the same problem. Suppose MN connect to the LMA1, 
each time the MN handover from previous MAG  to the new MAG, the new MAG needs to setup SA with the LMA1 dynamically again.

>From the other aspect, in the Multi-LMA scenario, when MAG1 talks with LMA2, if there is no SA between MAG1 and LMA2, we can ask
LMA2 exchange with AAA server to do authorization and validate whether MAG1 can fetch CN's MAG address from LMA2.

Also since SA is setup between one MAG and one LMA, upon the first MN who is attaching to the MAG triggers this MAG to setup SA with LMA, 
the SA can also be used by the other MN who attach to the same MAG to protect the data traffic between MAG and LMA Therefore the second MN who 
is attaching to the same MAG may not setup SA again. Because all the existing SA can be reused.

Therefore SA setup is not a big issue, the biggest issue is:
1) who discover CN's LMA address?
2) how does he discover CN's LMA address?

One example is , If AAA based CN's LMA discovery can be used, we can ask AAA server push the keying materails which is used to protect the trust relationship between MN's MAG and CN's LMA to the MN's MAG and CN's LMA respectively. In this sense, the trust relationship between MN's MAG and CN's LMA can be easily setup.
 
> will keep states on one place.

[Qin]: if using LMA1 signaling with LMA2 for state synchronizing, how does LMA1 know LMA2 address?

> Any opinions?
> 
> marco
> 
> 
> 
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext

---

From: Marco Liebsch <[email-masked]>
Date: Mon, 23 Nov 2009 10:46:53 +0100

Hi Qin,

please find my comments inline.

> be used to negotiate with LMA and enfoce local routing on the MAG.
Only in single MAG case it may make sense that the MAG detects and 
establishes
a localized route. However, even in such case, the LMA must control/enforce
the setup of the localized route as per RFC5213. So, the LMA
is the point of control and my personal opinion is that this is 
reasonable, as the
LMA maintains states beyond a single MAG. And, dependent on the mechanism
behind HNP assignment (address pools, delegation, ...), the LMA may know if
the setup of a localized route is useful (in case CN is local) or not.

> e.g., in the scenario where MN and CN attach to the different MAGs but connect to the different LMA or the same LMA.
Since the LMA needs to enforce localized routing in all cases, I 
personally see the
LMA as detector. If for some reason the MAG may be able to detect, it should
inform the LMA of the attached MN to enforce localized routing.

> each time the MN handover from previous MAG  to the new MAG, the new MAG needs to setup SA with the LMA1 dynamically again.
there is a big difference between localized routing associations between 
MAGs
and handover between MAGs.
Handover is between globally adjacent ARs/MAGs, hence, I think an LMA
maintains an SA with an MN's MAG and potential handover targets. If you
would establish them each time a handover occurs, this would have impact
to the handover latency. Don't think this is how PMIP is deployed. Now,
localized routing between MN and CN could mean that MN's MAG and CN's
MAG are pretty far apart. Different LMAs could serve different PMIPv6
domains. I don't think it's reasonable to merge these PMIP domains
dynamically by means of establishing an SA between MN's MAG and
CN's LMA. Rather LMAs could take care about the setup of the route
between these MAGs. If both LMAs are in different PMIP domains
but in the same provider network, such signaling is simple.

> LMA2 exchange with AAA server to do authorization and validate whether MAG1 can fetch CN's MAG address from LMA2.
Who is "we" ("...we can ask LMA2...")? It's MAG1, right?

> 2) how does he discover CN's LMA address?
"Who?" should be the LMA, as you need to discovery only once, whereas
if it's the MAG, each handover MAG needs to discover again, unless you
make the localized routing protocol dependent on CTX, which is not
a good approach.
"How?" could be different approaches. Static solutions could be based on
the LMA's knowledge about address/HNP pools for HNP assignment
to attaching MNs. Dynamic solutions could be based on a AAA infrastructure
as you referred to above. I don't think this particular "How?" should be 
addressed
by the localized routing solution.

> [Qin]: if using LMA1 signaling with LMA2 for state synchronizing, how does LMA1 know LMA2 address?
Same as MAG1 may discover LMA2, with many advantages if you do this from 
LMA1.

marco

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Mon, 23 Nov 2009 22:00:09 -0500

Hi Marco, All,

Why do we need to solve this case? (I know we have documented in the PS
ID).

>From what I can tell, there are two nodes in two different PMIPv6
domains attached to two different MAGs and two different LMAs.
What use case will require us to address this scenario? 

We can still address roaming by considering scenarios A11, A12, A21 in
the PS document.
What we need is an indication in the LMA that the visiting node(s) are
allowed to be offered with LR.
We should include that.

Thanks,

-Rajeev

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Marco Liebsch
> Sent: Friday, November 20, 2009 1:44 AM
> To: [email-masked]
> multi-LMA setup, I'd like to initiate a general and 
> clarifying discussion about signaling paths to set up and 
> maintain a localized routing path, as current solution 
> proposals cover different approaches.
> 
> We had the discussion about PMIPv6 domains vs provider 
> domains and came to the conclusion that it's not mandatory 
> for MN and CN to share the same PMIPv6 domain.
> 
> Assume MN connects to MAG1 and LMA1, whereas CN connects to 
> MAG2 and LMA2. MAG1 shares a PMIP domain with LMA1 and MAG2 
> shares a PMIP domain with LMA2. We cannot assume that MAG1 
> shares a PMIP domain with LMA2.
> 
> domain, then one solution could be to set up an SA 
> dynamically between MAG1 and LMA2, which needs to be re-done 
> every time
> The other alternative is that PMIPv6 domain stractures are 
> not touched and LMA1 will signal with LMA2 to synchronize 
> states of MN and CN.
> Advantage would be that LMAs do not change during a handover 
> and will keep states on one place.
> 
> Any opinions?
> 
> marco
> 
> 
>

---

From: Qin Wu <[email-masked]>
Date: Tue, 24 Nov 2009 16:16:35 +0800

Hi, Marco:
Thank for your reply, please see my comments inline.

Regards!
-Qin
----- Original Message ----- 
From: "Marco Liebsch" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, November 23, 2009 5:46 PM
Subject: Re: [netext] multi-LMA : how to handle

> the setup of a localized route is useful (in case CN is local) or not.

[Qin]: Right, single MAG case is more appropirate to apply MAG initiated local routing. Also single MAG case can be divided into two sub cases: i.e.,A11 and A12 described in the PS draft. These two sub cases should be taken care in the solution draft.
On the other hand, I agree LMA control the setup of localized routing, but it seems to me who initiate localized routing does not depend on who control  the setup of the localized route. In the MAG initiate localized routing, MAG can initiate local routing with LMA to see whether localized routing is available.

> LMA as detector. 

[Qin]: Okay.

>If for some reason the MAG may be able to detect, it should

[Qin]: I agee.
 
> and handover between MAGs.

[Qin]: No doubt to this.

> maintains an SA with an MN's MAG and potential handover targets.

[Qin]: How?  You can not predict the direction of MN's movement, i.e., to which MAG the MN will move. Therefore 
you can not expect there is an SA between LMA and handover targets beforehand.

> If you
> to the handover latency. Don't think this is how PMIP is deployed. 

[Qin] As I said in the previous mail, the possible way to fix this issue is 
SA or tunnel setup for the first MN between MAG and LMA can be shared
by the other MNs who are attaching to the same MAG and register to the same LMA as the first MN.
that is to say, the SA or tunnel between MAG and LMA is not per-MN or per-CN and can be reused 
by all the MNs and CNs upon it is setup at the first time.
In this sense, it avoid establishing SA each time a handover occurs.
If this is true, SA between MN's MAG(MAG1) and CN's LMA(LMA2) is not neccessary to be established 
again if SA between MAG1 and LMA2 has already been setup. 

>Now,
> MAG are pretty far apart. 

[Qin] As described in PS draft, We should limit MN's MAG and CN's MAG within the same domain, am I right?

>Different LMAs could serve different PMIPv6
> CN's LMA. 

[Qin]: Same as above.

>Rather LMAs could take care about the setup of the route

[Qin]: Right, the example is MN's MAG1 requests CN's MAG2 address from LMA2, LMA2 should validate the message from MN's MAG1 using AAA mechanism.

> make the localized routing protocol dependent on CTX, which is not

[Qin]: For the handover case, If CTX is used with localized routing protocol, discovery is done once as well.
But CTX is not the only way.
Besides CTX, there is another possible way to deal with handover case for multi-LMA.

Since it is MN's MAG or CN's MAG who is responsible for setup localized routing path, LMA still
needs to inform the MN's MAG to CN's MAG or inform the CN's MAG to MN's MAG.
Therefore when MN handover from MN's previous MAG to the MN's new MAG, it is not MN's LMA but MN's new MAG who is first to know that MN's handover happen, then MN's new MAG can trigger LMA to notify CN's MAG to update MN's MAG address at CN's MAG,
then CN's MAG updates localized routing path with MN's new MAG. 

In this way, discovery is done only once as well.

> by the localized routing solution.

[Qin]: I agree.

---

From: Qin Wu <[email-masked]>
Date: Tue, 24 Nov 2009 16:33:08 +0800

Hi, Rajeev and all:
No doubt that A11,A12 and A21 should be addressed in the solution draft. 
But for A22, One use case in my mind is:
Suppose MN's MAG and CN's MAG are in Japan operator network, and MN and CN share the same LMA in USA operator's network,
I am wondering whether Localized routing protocol can be used to optimize the path between MN and CN to save the traffic from making the unnecessary USA trip?

Regards!
-Qin

---

From: Marco Liebsch <[email-masked]>
Date: Tue, 24 Nov 2009 11:47:42 +0100

Hi Rajeev,

This is not about the PS or about the use case itself, but about the
protocol solution to support the use case. If you have MN connected
to MAG1/LMA1 and CN connected to MAG2/LMA2, the PMIP
components of MN and CN somehow need to communicate with
each other to set up localized routes. If the NetExt protocol solution
for localized routing is supposed to support such use case, we need
to find answers to the questions about detection (look at data packet
and initiate localized routing if appropriate) and the signaling path
(who's talking to whom to set up localized routing states).

marco

---

From: Marco Liebsch <[email-masked]>
Date: Tue, 24 Nov 2009 12:21:51 +0100

Hi Qin,

please see inline for brief comments.

> On the other hand, I agree LMA control the setup of localized routing, but it seems to me who initiate localized routing does not depend on who control  the setup of the localized route. In the MAG…
yes, we can have 3 different ways to do this:
(1) MAG1 detects and requests LMA1 to set up localized routes
(2) MAG1 detects and requests LMA2 to set up localized routes
(3) LMA1 detects and sets up localized routes

> you can not expect there is an SA between LMA and handover targets beforehand.
well, don't confuse SA with forwarding tunnel. The SAs between MAG and a 
particular LMA
should be pre-established when the MN arrives, whereas the forwarding 
tunnel may exist
or may be set up dynamically when the MN arrives.

> by the other MNs who are attaching to the same MAG and register to the same LMA as the first MN.
I understood your point, but I do not agree :-) I do not think that a 
MAG should establish an SA
with any LMA dynamically when the MN arrives, in particular not with an 
LMA which does not
serve the MN but the CN.

> [Qin] As described in PS draft, We should limit MN's MAG and CN's MAG within the same domain, am I right?
Even if they are in one provider domain, distance between MAGs can be 
huge. Multiple LMAs may
be used by the provider to distribute load and to be responsible for a 
smaller region (subset of MAGs).

> then CN's MAG updates localized routing path with MN's new MAG. 
I think the basic assumption for the solutions should be that the MN's 
handover
target MAG does not know more than what PMIPv6 as per RFC5213 requires,
which is the LMA where to send the PBU to and does not cover any localized
routing information. The information and states about localized routing 
could be
re-established (instead of transferred) by a common anchor, which does not
change: The LMA.
draft-oulai even sets up localized routing states on both MAGs without
any signaling between MAGs at all. We proposed something similar in
draft-abeille, which was named 'proxy mode'. Such approach has some
advantages if there is no SA between MAGs.

marco

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Tue, 24 Nov 2009 14:13:27 -0500

Hi Marco,
 
I understand it is not about the PS itself.
 
However, we discussed the case involving multiple LMAs, and ruled it out. 
I don't think we need to address this issue (multiple MAGs, multiple LMAs, multiple PMIP6 domains) for protocol solutions. Unless there is a clear need for this.
 
Thanks,
 
-Rajeev

________________________________

From: Marco Liebsch [mailto:[email-masked]]
Sent: Tue 11/24/2009 2:47 AM
To: Koodli, Rajeev
Cc: [email-masked]
Subject: Re: [netext] multi-LMA : how to handle

Hi Rajeev,

marco

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Tue, 24 Nov 2009 14:17:47 -0500

Hi Qin,
 
the example you quote below has MN and CN belonging to the same PMIP6 domain (and sharing the same LMA). As I mentioned below, if the visited MAG has indication that the roaming user is allowed for LR, the protocol solution applies. 
 
I am saying that multi-LMA, multi-MAG, multi-PMIP6 domain scenario should be out of scope.
 
Regards,
 
-Rajeev

From: Qin Wu [mailto:[email-masked]]
Sent: Tue 11/24/2009 12:33 AM
To: Koodli, Rajeev; [email-masked]
Subject: Re: [netext] multi-LMA : how to handle

Hi, Rajeev and all:

Regards!
-Qin

---

From: Qin Wu <[email-masked]>
Date: Wed, 25 Nov 2009 10:03:12 +0800

Hi, Rajeev:
Sorry for my mistake, the example I quote is the case which include single LMA, multi-MAG.
Let me give you another example as follows:

MN belong to LMA1 in the USA operator A network, CN belong to LMA2 in the USA operator B network, when MN and CN roam to the same Japan 
NTT network, MN and CN attach to the different MAGs in the Japan NTT network.

In this case, MN's MAG and CN's MAG belong to the same operator network and are very close to each other, I am wondering whether Localized routing protocol can be used to optimize the path between MN and CN to save the traffic from making the unnecessary USA trip?

Regards!
-Qin

---

From: Qin Wu <[email-masked]>
Date: Wed, 25 Nov 2009 16:43:39 +0800

Hi, Marco:
please see my comments inline.

Regards!
-Qin
----- Original Message ----- 
From: "Marco Liebsch" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, November 24, 2009 7:21 PM
Subject: Re: [netext] multi-LMA : how to handle

[Qin]: Okay. 
> or may be set up dynamically when the MN arrives.

[Qin]: I agree SA and forwarding tunnel are two different things. But the common aspect of both is
SA and forwarding tunnel for one MN can be reused by the other MN who arrives at the same MAG 
and routes the packet  to the same tunnel end point, i.e., LMA. Right?

> with any LMA dynamically when the MN arrives, in particular not with an 
 
[Qin]: It seem to me it does not matther whether SA is pre-established or dynamically established.
The key point is whether SA can be shared by all the MNs who are using the same path between MAG and LMA.

> smaller region (subset of MAGs).

[Qin]: To me, the physical distance is not big issue. The more important thing is whether communication between MAGs is within the 
same provider domain or acrosss provider domain.

> advantages if there is no SA between MAGs.

[Qin]: Since localized routing protocol can be used between source MAG(i.e., MN's MAG) and LMA,
it also can be used between target MAG and LMA. I don't think it is a big issue.
Also in some case, MN's prefix and CN's prefix should be validated to create for valid routing between MAGs.
therefore LMA can notify both MAG that MN's prefix or CN's prefix is valid each time handover happens.Also LMA can tell target MAG the information about localized routing.
On the other hand, when routing path is established, target MAG need to install localized routing states. This mechanism is quite similar to the routing optimization between MN and CN described in RFC3775 and RFC4866.

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 25 Nov 2009 10:41:50 +0100

Hi Rajeev,

> However, we discussed the case involving multiple LMAs, and ruled it out. 
That's new for me. Who ruled it out? And when?

> I don't think we need to address this issue (multiple MAGs, multiple LMAs, multiple PMIP6 domains) for protocol solutions. Unless there is a clear need for this.
To support only single LMA scenarios is a bad limitation.

marco

---

From: "Mohana Jeyatharan" <[email-masked]>
Date: Wed, 25 Nov 2009 18:28:26 +0800

Hi Qin, Marco and all,

Have been following the thread and I have one clarifying question.
In the multi LMA scenario that is being discussed, is CN.LMA involved
during every handoff event in identifying the CN.MAG address and
informing to Mn's MAG?  

If AAA is used as a common trusted entity in identfying CN.LMA address
and also helping in creating SA between Mn'MAG and CN'LMA, I am just
wondering whether AAA can be used to tell MN's MAG that it owns this
prefix(Mn prefix) and CN's MAG that it own the prefix(CN prefix) and
when bi-directional tunnels are setup between MAG using PBU/PBA such
validation fron AAA can be used to create the routing states at MN's MAG
and CN's MAG.  Bcos in the multi LMA scenario, AAA will perhaps be the
common trusted entity.

Just wondering whether CN.LMA needs to be involved during handoff
process or CTX and such prefix validation from a common trusted entity
(AAA) between LMA1 and LMA2 can be used in setting up the MAG to MAG RO
path.  If LMA is configured as the initiator of MAG to MAG RO, then
MN.MAG and CN.LMA association may be needed but if MAG is the initiator
of RO then perhaps this can be avoided in the handoff case.

Also I have few general opinions on MAG initiated RO or LMA initiated
RO.
Definitely as folks have discussed and identified, LMA is definitely
used in detection of CN.MAG and aid in establishing RO, but MAG can be
initiator of local MAG RO eventhough MN and CN are not attached to the
same MAG.  Perhaps the MAG is informed of CN addresses by MN using some
L2 mechanism and hence it can initiate RO for a bunch of CNs
simultaneously.  Thus LMA need not wait for session to be started
between every MN and each CN to establish the RO.

Thanks.

BR,
Mohana

> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Qin Wu
> Sent: Wednesday, November 25, 2009 4:44 PM
> To: Marco Liebsch
> Cc: [email-masked]
> >>>> [Qin]: I think Both have its value and are applicable to
different
> scenarios. Whether using MAG initiated or using LMA initiated depends
on
> >>>> who detects localized routing, in other words, if MAG detects
local
> routing is possible, then MAG initiated is more appropriate.
> >>>> e.g., As described in RFC5213, in the scenario where MN and CN
attach
> to the same MAG, MAG initiated local routing can
> >>> behind HNP assignment (address pools, delegation, ...), the LMA
may
> know if
> >> [Qin]: Right, single MAG case is more appropirate to apply MAG
> initiated local routing. Also single MAG case can be divided into two
sub
> cases: i.e.,A11 and A12 described in the PS draft. These two sub cases
> should be taken care in the solution draft.
> >>
> >> On the other hand, I agree LMA control the setup of localized
routing,
> but it seems to me who initiate localized routing does not depend on
who
> control  the setup of the localized route. In the MAG initiate
localized
> routing, MAG can initiate local routing with LMA to see whether
localized
> routing is available.
> >>>> If LMA is responsible for local routing, then LMA inititated and
MAG
> initiate both can be used.
> >>>> e.g., in the scenario where MN and CN attach to the different
MAGs
> but connect to the different LMA or the same LMA.
> >>>>
> >>>>
> >>>> [Qin]: It seems to me SA setup each time MN handover to the new
MAG
> is one generic issue we should face for all the Multi-LMA cases.
> >>>> In other words,When using LMA1 to signal with LMA2 for states
> synchroizing, it has the same problem. Suppose MN connect to the LMA1,
> >>>> each time the MN handover from previous MAG  to the new MAG, the
new
> MAG needs to setup SA with the LMA1 dynamically again.
> >>>>
> >>>>
> >> [Qin]: How?  You can not predict the direction of MN's movement,
i.e.,
> to which MAG the MN will move. Therefore
> [Qin]: I agree SA and forwarding tunnel are two different things. But
the
> common aspect of both is
> >> by the other MNs who are attaching to the same MAG and register to
the
> same LMA as the first MN.
> >>
> [Qin]: It seem to me it does not matther whether SA is pre-established
or
> dynamically established.
> The key point is whether SA can be shared by all the MNs who are using
the
> same path between MAG and LMA.
> 
> >> that is to say, the SA or tunnel between MAG and LMA is not per-MN
or
> per-CN and can be reused
> >> If this is true, SA between MN's MAG(MAG1) and CN's LMA(LMA2) is
not
> neccessary to be established
> >> [Qin] As described in PS draft, We should limit MN's MAG and CN's
MAG
> within the same domain, am I right?
> >>
> [Qin]: To me, the physical distance is not big issue. The more
important
> thing is whether communication between MAGs is within the
> >>>> From the other aspect, in the Multi-LMA scenario, when MAG1 talks
> with LMA2, if there is no SA between MAG1 and LMA2, we can ask
> >>>> LMA2 exchange with AAA server to do authorization and validate
> whether MAG1 can fetch CN's MAG address from LMA2.
> >>>>
> >>>>
> >> [Qin]: Right, the example is MN's MAG1 requests CN's MAG2 address
from
> LMA2, LMA2 should validate the message from MN's MAG1 using AAA
mechanism.
> >>
> >>
> >>>> Also since SA is setup between one MAG and one LMA, upon the
first MN
> who is attaching to the MAG triggers this MAG to setup SA with LMA,
> >>>> the SA can also be used by the other MN who attach to the same
MAG to
> protect the data traffic between MAG and LMA Therefore the second MN
who
> >>>> is attaching to the same MAG may not setup SA again. Because all
the
> existing SA can be reused.
> >>>>
> >> [Qin]: For the handover case, If CTX is used with localized routing
> protocol, discovery is done once as well.
> >> Besides CTX, there is another possible way to deal with handover
case
> for multi-LMA.
> >>
> >> Since it is MN's MAG or CN's MAG who is responsible for setup
localized
> routing path, LMA still
> >> needs to inform the MN's MAG to CN's MAG or inform the CN's MAG to
MN's
> MAG.
> >> Therefore when MN handover from MN's previous MAG to the MN's new
MAG,
> it is not MN's LMA but MN's new MAG who is first to know that MN's
> handover happen, then MN's new MAG can trigger LMA to notify CN's MAG
to
> update MN's MAG address at CN's MAG,
> > re-established (instead of transferred) by a common anchor, which
does
> not
> it also can be used between target MAG and LMA. I don't think it is a
big
> issue.
> therefore LMA can notify both MAG that MN's prefix or CN's prefix is
valid
> each time handover happens.Also LMA can tell target MAG the
information
> about localized routing.
> On the other hand, when routing path is established, target MAG need
to
> install localized routing states. This mechanism is quite similar to
the
> routing optimization between MN and CN described in RFC3775 and
RFC4866.
> >>> "How?" could be different approaches. Static solutions could be
based
> on
> >>> as you referred to above. I don't think this particular "How?"
should
> be
> >>>> One example is , If AAA based CN's LMA discovery can be used, we
can
> ask AAA server push the keying materails which is used to protect the
> trust relationship between MN's MAG and CN's LMA to the MN's MAG and
CN's
> LMA respectively. In this sense, the trust relationship between MN's
MAG
> and CN's LMA can be easily setup.
> >>>>
> >>>>
> >>>>
> >>>> [Qin]: if using LMA1 signaling with LMA2 for state synchronizing,
how
> does LMA1 know LMA2 address?
> >>>>
> >>>>
> >>> Same as MAG1 may discover LMA2, with many advantages if you do
this
> from

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 25 Nov 2009 12:08:04 +0100

Hi Mohana,

please see in-line for my answer to your question.

> during every handoff event in identifying the CN.MAG address and
Without pointing to a particular solution but arguing more general, I think
the LMAs should be involved and have mayor control in setting up as
well as in maintaining the localized routing states on the MAG, as they
are the only common nodes (common on a per MN basis) which have the
most up to date location information about the MN and the CN respectively.
This is LMA1 for MN and LMA2 for CN.
> and CN's MAG.  Bcos in the multi LMA scenario, AAA will perhaps be the
I do not think that the AAA should be used as mobility anchor, even though
the AAA might have information about mobility related states. For sure, 
he'll have
information about each MN's assigned LMA. So, I think the AAA *could*
be used to find the MN's and the CN's LMA once during the setup of a
localized routing path. After the setup, LMA1 and LMA2 should be known.
And I do not think that the localized routing solution should be
dependent on the AAA server, hence the solution should work without
any AAA infrastructure at all.

> of RO then perhaps this can be avoided in the handoff case.
both LMAs should be involved as they do not change and they have the
most recent location information. However, as we propose, even though
both LMAs are involved in the signaling, one LMA should have the
control (e.g. LMA2). Then the maintenance during handover cannot run
into a deadlock situation and the solution does not need the AAA server
as common anchor.
> simultaneously. 
I don't think you need L2 here, as a data packet from MN to CN, which
is forwarded by the MN's MAG, carries the CN's IP address.
Or did I misunderstand your proposal?

>  Thus LMA need not wait for session to be started
Ah, maybe now I get your point. You propose to set up a localized
routing path between the MN and a set of potential CNs before
data will be sent, right? I think an important question to answer here
is how long localized routing states will be kept alive? Our current view
(and implementation) sets localized routing states up when the're needed
(when data is sent). They are removed when a session terminates, say
after a timeout in case no further data packets reset the timer. These
states are rather soft-states. If you set them up before there is data,
I am wondering when you delete them again? And how should the
MN decide if a localized route to CN1, CN2, etc makes sense? Their
location is transparent to the MN. What do you think?

marco

>>>>>> be used to negotiate with LMA and enfoce local routing on the
>>>>>>             
> MAG.
>   
>>>>         
>>>>> a localized route. However, even in such case, the LMA must
>>>>>           
>> control/enforce
>>     
>>>>> LMA maintains states beyond a single MAG. And, dependent on the
>>>>>           
>> mechanism
>>     
>>>>> the setup of a localized route is useful (in case CN is local) or
>>>>>           
> not.
>   
>>>>> there is a big difference between localized routing associations
>>>>>           
>> between
>>     
>>>>> MAGs
>>>>> Handover is between globally adjacent ARs/MAGs, hence, I think an
>>>>>           
> LMA
>   
>>>> you can not expect there is an SA between LMA and handover targets
>>>>         
>> beforehand.
>>     
>>> well, don't confuse SA with forwarding tunnel. The SAs between MAG
>>>       
> and a
>   
>>> particular LMA
>>> should be pre-established when the MN arrives, whereas the
>>>       
> forwarding
>   
>>> tunnel may exist
>>>>> would establish them each time a handover occurs, this would have
>>>>>           
>> impact
>>     
>>>> [Qin] As I said in the previous mail, the possible way to fix this
>>>>         
>> issue is
>>     
>>>> SA or tunnel setup for the first MN between MAG and LMA can be
>>>>         
> shared
>   
>>> I understood your point, but I do not agree :-) I do not think that
>>>       
> a
>   
>>> with any LMA dynamically when the MN arrives, in particular not with
>>>       
> an
>   
>>> LMA which does not
>>> serve the MN but the CN.
>>>       
>>>> In this sense, it avoid establishing SA each time a handover
>>>>         
> occurs.
>   
>>>>> localized routing between MN and CN could mean that MN's MAG and
>>>>>           
> CN's
>   
>>> Even if they are in one provider domain, distance between MAGs can
>>>       
> be
>   
>>> huge. Multiple LMAs may
>>> be used by the provider to distribute load and to be responsible for
>>>       
> a
>   
>>>>> "Who?" should be the LMA, as you need to discovery only once,
>>>>>           
> whereas
>   
>>>>> if it's the MAG, each handover MAG needs to discover again, unless
>>>>>           
> you
>   
>>> I think the basic assumption for the solutions should be that the
>>>       
> MN's
>   
>>> handover
>>> target MAG does not know more than what PMIPv6 as per RFC5213
>>>       
> requires,
>   
>>> which is the LMA where to send the PBU to and does not cover any
>>>       
>> localized
>>     
>>> routing information. The information and states about localized
>>>       
> routing
>   
>>> could be
>>> draft-oulai even sets up localized routing states on both MAGs
>>>       
> without
>   
>>>>> to attaching MNs. Dynamic solutions could be based on a AAA
>>>>>           
>> infrastructure
>>     
>>>>>>> The other alternative is that PMIPv6 domain stractures are not
>>>>>>>               
>> touched
>>     
>>>>>>> and LMA1 will signal with LMA2 to synchronize states of MN and
>>>>>>>               
> CN.
>

---

From: Qin Wu <[email-masked]>
Date: Thu, 26 Nov 2009 16:23:02 +0800

Hi, Mohana:
Thank for your feedback, please see my comments below.

Regards!
-Qin
----- Original Message ----- 
From: "Mohana Jeyatharan" <[email-masked]>
To: "Qin Wu" <[email-masked]>; "Marco Liebsch" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, November 25, 2009 6:28 PM
Subject: RE: [netext] multi-LMA : how to handle

Hi Qin, Marco and all,

[Qin]: Good question, in our solution I-D, when MN handover to the new MAG, suppose CN's MAG address keeps unchanged during MN's handover,
CTX can be used between previous MN's MAG and new MN's MAG to inform the CN's MAG address to the MN's MAG. The big advantage is
LMA invlovement can be avoided each time MN's handoff.
That is to say, CN's LMA is only involved when MN's MAG does not know CN's MAG. Upon MN's MAG know CN's MAG and CTX is allowed between
MAGs, MN's new MAG can fetch CN's MAG from MN's previous MAG and update localized routing path between MN's new MAG and CN's MAG without involvement of CN's LMA.

[Qin]: No, AAA server can not keep track of MN or CN's movement as LMA do, each time MN or CN handoff,
MN's MAG address will differ from the previous one  and is updated into MN's LMA. It is the same case with CN's MAG address.
But wherever MN or CN moves, the MN's LMA and CN's LMA will keep unchanged. Therefore MN's LMA and CN's LMA can
may be maintained as a  configured entry in the CN's policy profile located in AAA server.

[Qin]: 
As I said above, if CTX is allowed and CN's MAG keeps unchanged during MN's handover, CN's LMA involvement may be not necessary. 

But if CTX is not available during MN's handover, the MAG may ask the common trusted entity (AAA) between MN's LMA and CN's LMA to inform
MN's LMA and CN's LMA respectively for prefix validation. And then MN's LMA inform MN's MAG that prefix is valid, also CN's LMA informs CN's MAG 
that prefix is valid, is this your idea? 
Anyway I think AAA based mechanism should be out of scope of the solution I-D.

[Qin]: I am not sure L2 mechanism can be used for detection. I think there are other
ways using L3 mechanism. But it should be beyond scope of solution I-D.
Besides this, I share your opinion.

Thanks.

BR,
Mohana

Behalf
different
on
local
attach
MAG.
may
not.
sub
routing,
who
localized
localized
MAG
MAGs
MAG
new
LMA
i.e.,
and a
forwarding
the
shared
the
a
an
or
the
or
occurs.
not
CN's
MAG
be
a
important
from
mechanism.
first MN
MAG to
who
the
whereas
you
case
localized
MN's
MAG,
to
MN's
requires,
routing
does
without
big
valid
information
to
the
RFC4866.
based
should
can
CN's
MAG
CN.
how
this

---

From: "Mohana Jeyatharan" <[email-masked]>
Date: Thu, 26 Nov 2009 17:16:28 +0800

Hi Marco,

Thanks for reply.  Please see some replies in-line.

BR,
Mohana
Behalf
> Of Marco Liebsch
> Sent: Wednesday, November 25, 2009 7:08 PM
> To: Mohana Jeyatharan
> Cc: [email-masked]

[Mohana] I agree that setting up routing states, LMA has important role.
But I am not so convinced about the involvement of LMA in maintaining
routing states (handoff case). Bcos after local MAG RO is set up,
packets don't pass through LMA and local mechanims such CTX can be used
to handle RO.  Ofcourse if CTX is not used for some reason(operator
choice) then perhaps LMA control even during handoff (as you propose)
can be used.  Another point is LMA need not unnecessarily keep state for
local MAG RO. If MN MAG and CN MAG are quite close, then involving LMA
which can even be in another administrative domain can delay the local
MAG path setup especially when you have on going session as in the
handoff case.  Anyway, I am not saying that LMA involvement should not
be there. It all depends.

Another scenario is where MN LMA and CN LMA do not have trust. Then what
mechanism can be used to set up localized routing? I guess currently
such scenario is out of scope of the discussion.  

> any AAA infrastructure at all.

[Mohana] Ok. Since AAA was discussed I was thinking more along this
line.  If LMA1 (MN LMA)and LMA2 (CN LMA) have trust then no need of a
common trusted anchor.  But if they are not then was wondering whether
we need a common trusted anchor to securly establish local MAG RO.
Perhaps we can keep the scenario where there is loose trust between LMAs
out of discussion for now as I mentioned previously.

> > Just wondering whethe r CN.LMA needs to be involved during handoff
> data will be sent, right?

[Mohana] Yes.

 I think an important question to answer here
> states are rather soft-states. 

[Mohana] My thinking was to setup states if the MAG thinks that
communication with certain CNs need to be optimized. Based on
application or the type of service domain in which CN is placed the MAG
may initiate such local rotuing request.  Ofcourse once the session is
complete the local MAG RO can be torn down.  Suppose you are frequently
communicating with such CNs then local MAG RO states can be kept for a
long time.

If you set them up before there is data,
> location is transparent to the MN. 

[Mohana] are you refering to CNs placed in another provider domain with
repect to MN.  In such a case, probably localized routing is not
essential.  MN's MAG does not know anything about where CN is.  It just
wants RO based on some information given to CN.  In such a case LMA
needs to assist.  Anyway as all of us have agreed LMA definitely needs
to play its role in supporting local MAG RO.

Thanks.
What do you think?
> >> SA and forwarding tunnel for one MN can be reused by the other MN
who
> >> arrives at the same MAG
> >> Also in some case, MN's prefix and CN's prefix should be validated
to
> >> create for valid routing between MAGs.
and

---

From: Marco Liebsch <[email-masked]>
Date: Thu, 26 Nov 2009 12:01:42 +0100

Hi Mohana,

please see in-line.

Mohana Jeyatharan wrote:
>>> In the multi LMA scenario that is being discussed, is CN.LMA
>>>       
> involved
>   
>> well as in maintaining the localized routing states on the MAG, as
>>     
> they
>   
>> most up to date location information about the MN and the CN
>>     
> respectively.
>   
I don't think CTX solves all problems, as for example during MN's handover,
CTX may transfer outdated context of CN's location if CN hands over we well.
This may end up in MN's new MAG then contacts CN's previous MAG.
I see the use of CTX as optional, if needed at all. I do not think that
the protocol solution should depend on CTX.

>>> If AAA is used as a common trusted entity in identfying CN.LMA
>>>       
> address
>   
>>> validation fron AAA can be used to create the routing states at MN's
>>>       
> MAG
>   
>>> and CN's MAG.  Bcos in the multi LMA scenario, AAA will perhaps be
>>>       
> the
>   
>>> common trusted entity.
>>>
>>>       
>> I do not think that the AAA should be used as mobility anchor, even
>>     
> though
>   
>> the AAA might have information about mobility related states. For
>>     
> sure,
>   
>> he'll have
>> localized routing path. After the setup, LMA1 and LMA2 should be
>>     
> known.
>   
I thought about the AAA in a different context, which is a common entity
or infrastructure to maintain MN-LMA bindings. This helps LMAs to find
each other. Such function is needed also for two LMAs which share
a trust relationship.

Just as example: LMA1 has only a registration for MN, but needs to find 
CN's LMA.
On request of LMA1, the AAA infrastructure could resolve CN's assigned 
IP address
into CN's LMA, which is LMA2.

>>> process or CTX and such prefix validation from a common trusted
>>>       
> entity
>   
>>> (AAA) between LMA1 and LMA2 can be used in setting up the MAG to MAG
>>>       
> RO
>   
>>> MN.MAG and CN.LMA association may be needed but if MAG is the
>>>       
> initiator
>   
>> into a deadlock situation and the solution does not need the AAA
>>     
> server
>   
>> as common anchor.
>>     
>>> Also I have few general opinions on MAG initiated RO or LMA
>>>       
> initiated
>   
>>> RO.
>>> used in detection of CN.MAG and aid in establishing RO, but MAG can
>>>       
> be
>   
>>> initiator of local MAG RO eventhough MN and CN are not attached to
>>>       
> the
>   
>>> same MAG.  Perhaps the MAG is informed of CN addresses by MN using
>>>       
> some
>   
>> is how long localized routing states will be kept alive? Our current
>>     
> view
>   
>> (and implementation) sets localized routing states up when the're
>>     
> needed
>   
I see. This assumes a lot of intelligence at the MAG, but may be useful.

> essential.
no, I tried to understand your proposal with L2 signaling. My 
understanding of
your proposal was that the MN signals via L2 to the MAG info about CNs
for which the MN would like to have a localized route set up. My comment
was about the MN, which actually does not know anything about the
CNs' location, hence cannot take a decision if localized routing is useful
or even works.

>   MN's MAG does not know anything about where CN is.  It just
Ok.

Thanks and best regards,
marco

>>>>>>>>> and came to the conclusion that it's not mandatory for MN and
>>>>>>>>>                   
> CN
>   
>>>> scenarios. Whether using MAG initiated or using LMA initiated
>>>>         
> depends
>   
>>> on
>>>
>>>       
>>>>>>> Only in single MAG case it may make sense that the MAG detects
>>>>>>>               
> and
>   
>>>>>>> establishes
>>>>>>> the setup of a localized route is useful (in case CN is local)
>>>>>>>               
> or
>   
>>> not.
>>>
>>>       
>>>> initiated local routing. Also single MAG case can be divided into
>>>>         
> two
>   
>>> sub
>>>
>>>       
>>>> cases: i.e.,A11 and A12 described in the PS draft. These two sub
>>>>         
> cases
>   
>>>> but it seems to me who initiate localized routing does not depend
>>>>         
> on
>   
>>> who
>>>
>>>       
>>>>>>>> If LMA is responsible for local routing, then LMA inititated
>>>>>>>>                 
> and
>   
>>> MAG
>>>
>>>       
>>>> synchroizing, it has the same problem. Suppose MN connect to the
>>>>         
> LMA1,
>   
>>>>>>>> each time the MN handover from previous MAG  to the new MAG,
>>>>>>>>                 
> the
>   
>>> new
>>>
>>>       
>>>>>>> Handover is between globally adjacent ARs/MAGs, hence, I think
>>>>>>>               
> an
>   
>>> LMA
>>>
>>>       
>>>>>> you can not expect there is an SA between LMA and handover
>>>>>>             
> targets
>   
>>>> beforehand.
>>>>
>>>>         
>>>> [Qin]: I agree SA and forwarding tunnel are two different things.
>>>>         
> But
>   
>>> the
>>>
>>>       
>>>> common aspect of both is
>>>> and routes the packet  to the same tunnel end point, i.e., LMA.
>>>>         
> Right?
>   
>>>>         
>>>>>>> If you
>>>>>>> would establish them each time a handover occurs, this would
>>>>>>>               
> have
>   
>>>> impact
>>>>
>>>>         
>>>>>>> to the handover latency. Don't think this is how PMIP is
>>>>>>>               
> deployed.
>   
>>>>>>>               
>>>>>> [Qin] As I said in the previous mail, the possible way to fix
>>>>>>             
> this
>   
>>>> issue is
>>>>
>>>>         
>>>>>> by the other MNs who are attaching to the same MAG and register
>>>>>>             
> to
>   
>>> the
>>>
>>>       
>>>>> I understood your point, but I do not agree :-) I do not think
>>>>>           
> that
>   
>>> a
>>>
>>>       
>>>>> with any LMA dynamically when the MN arrives, in particular not
>>>>>           
> with
>   
>>> an
>>>
>>>       
>>>>> LMA which does not
>>>>> serve the MN but the CN.
>>>>>
>>>>>           
>>>> [Qin]: It seem to me it does not matther whether SA is
>>>>         
> pre-established
>   
>>> or
>>>
>>>       
>>>> dynamically established.
>>>> The key point is whether SA can be shared by all the MNs who are
>>>>         
> using
>   
>>> the
>>>
>>>       
>>>>>> that is to say, the SA or tunnel between MAG and LMA is not
>>>>>>             
> per-MN
>   
>>> or
>>>
>>>       
>>>> per-CN and can be reused
>>>>
>>>>         
>>>>> be used by the provider to distribute load and to be responsible
>>>>>           
> for
>   
>>> a
>>>
>>>       
>>>>>>> domains. I don't think it's reasonable to merge these PMIP
>>>>>>>               
> domains
>   
>>>>>>>> From the other aspect, in the Multi-LMA scenario, when MAG1
>>>>>>>>                 
> talks
>   
>>>> protect the data traffic between MAG and LMA Therefore the second
>>>>         
> MN
>   
>>> who
>>>
>>>       
>>>>>>>> is attaching to the same MAG may not setup SA again. Because
>>>>>>>>                 
> all
>   
>>> the
>>>
>>>       
>>>>>>> if it's the MAG, each handover MAG needs to discover again,
>>>>>>>               
> unless
>   
>>> you
>>>
>>>       
>>>>>>> make the localized routing protocol dependent on CTX, which is
>>>>>>>               
> not
>   
>>>>>>> a good approach.
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>> [Qin]: For the handover case, If CTX is used with localized
>>>>>>             
> routing
>   
>>>>>> needs to inform the MN's MAG to CN's MAG or inform the CN's MAG
>>>>>>             
> to
>   
>>> MN's
>>>
>>>       
>>>> MAG.
>>>>
>>>>         
>>>> handover happen, then MN's new MAG can trigger LMA to notify CN's
>>>>         
> MAG
>   
>>> to
>>>
>>>       
>>>>> any signaling between MAGs at all. We proposed something similar
>>>>>           
> in
>   
>>>>> draft-abeille, which was named 'proxy mode'. Such approach has
>>>>>           
> some
>   
>>>> it also can be used between target MAG and LMA. I don't think it is
>>>>         
> a
>   
>>> big
>>>
>>>       
>>>> issue.
>>>> therefore LMA can notify both MAG that MN's prefix or CN's prefix
>>>>         
> is
>   
>>> valid
>>>
>>>       
>>>> On the other hand, when routing path is established, target MAG
>>>>         
> need
>   
>>> to
>>>
>>>       
>>>> install localized routing states. This mechanism is quite similar
>>>>         
> to
>   
>>> the
>>>
>>>       
>>>>>>>> One example is , If AAA based CN's LMA discovery can be used,
>>>>>>>>                 
> we
>   
>>> can
>>>
>>>       
>>>> ask AAA server push the keying materails which is used to protect
>>>>         
> the
>   
>>>> trust relationship between MN's MAG and CN's LMA to the MN's MAG
>>>>         
> and
>   
>>> CN's
>>>
>>>       
>>>> LMA respectively. In this sense, the trust relationship between
>>>>         
> MN's
>   
>>> MAG
>>>
>>>       
>>>>>>>> [Qin]: if using LMA1 signaling with LMA2 for state
>>>>>>>>                 
> synchronizing,
>   
>>> how
>>>
>>>