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

[Marco Liebsch <[e-mail]>]

Hi Mohana,

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

Mohana Jeyatharan wrote:
> 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?  
>   
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.
> 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.
>   
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.

> 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.
>   
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.
> 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. 
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
> between every MN and each CN to establish the RO.
>   
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



>
> Thanks.
>
> BR,
> Mohana
>
>
>   
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On
>>     
> Behalf
>   
>> Of Qin Wu
>> Sent: Wednesday, November 25, 2009 4:44 PM
>> To: Marco Liebsch
>> Cc: [e-mail]
>> Subject: Re: [netext] multi-LMA : how to handle
>>
>> Hi, Marco:
>> please see my comments inline.
>>
>> Regards!
>> -Qin
>> ----- Original Message -----
>> From: "Marco Liebsch" <[e-mail]>
>> To: "Qin Wu" <[e-mail]>
>> Cc: <[e-mail]>
>> Sent: Tuesday, November 24, 2009 7:21 PM
>> Subject: Re: [netext] multi-LMA : how to handle
>>
>>
>>     
>>> Hi Qin,
>>>
>>> please see inline for brief comments.
>>>
>>> Qin Wu wrote:
>>>       
>>>> Hi, Marco:
>>>> Thank for your reply, please see my comments inline.
>>>>
>>>> Regards!
>>>> -Qin
>>>> ----- Original Message -----
>>>> From: "Marco Liebsch" <[e-mail]>
>>>> To: "Qin Wu" <[e-mail]>
>>>> Cc: <[e-mail]>
>>>> Sent: Monday, November 23, 2009 5:46 PM
>>>> Subject: Re: [netext] multi-LMA : how to handle
>>>>
>>>>
>>>>
>>>>         
>>>>> Hi Qin,
>>>>>
>>>>> please find my comments inline.
>>>>>
>>>>> Qin Wu wrote:
>>>>>
>>>>>           
>>>>>> Hi, Marco:
>>>>>> Thank for your raising discussion on Multi-LMA issue.
>>>>>> Please see my comments inline!
>>>>>>
>>>>>> Regards!
>>>>>> -Qin
>>>>>> ----- Original Message -----
>>>>>> From: "Marco Liebsch" <[e-mail]>
>>>>>> To: <[e-mail]>
>>>>>> Sent: Friday, November 20, 2009 5:44 PM
>>>>>> Subject: [netext] multi-LMA : how to handle
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> 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
>>>>>>>
>>>>>>>               
>>>>         
>>>>>> [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.
>   
>>>>         
>>>>> 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.
>   
>>>> [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.
>>     
>>> 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
>>>       
>> [Qin]: Okay.
>>     
>>>>         
>>>>>> 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.
>>     
>>>>>>             
>>>>> Since the LMA needs to enforce localized routing in all cases, I
>>>>> personally see the
>>>>> LMA as detector.
>>>>>
>>>>>           
>>>> [Qin]: Okay.
>>>>
>>>>
>>>>         
>>>>> If for some reason the MAG may be able to detect, it should
>>>>> inform the LMA of the attached MN to enforce localized routing.
>>>>>
>>>>>           
>>>> [Qin]: I agee.
>>>>
>>>>
>>>>         
>>>>>>> (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.
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>> [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.
>>     
>>>>>>             
>>>>> there is a big difference between localized routing associations
>>>>>           
>> between
>>     
>>>>> MAGs
>>>>> and handover between MAGs.
>>>>>
>>>>>           
>>>> [Qin]: No doubt to this.
>>>>
>>>>
>>>>         
>>>>> Handover is between globally adjacent ARs/MAGs, hence, I think an
>>>>>           
> LMA
>   
>>>>> 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.
>>     
>>> 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.
>>>       
>> [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?
>>
>>     
>>>>> 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
>>     
>>>> 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.
>>     
>>> 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]: 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
>>     
>>>> 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,
>>>>> localized routing between MN and CN could mean that MN's MAG and
>>>>>           
> CN's
>   
>>>>> 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?
>>     
>>> 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).
>>>       
>> [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.
>>
>>     
>>>>> 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.
>>>>>
>>>>>           
>>>> [Qin]: Same as above.
>>>>
>>>>
>>>>         
>>>>> 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.
>>>>>
>>>>>
>>>>>
>>>>>           
>>>>>> 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.
>>     
>>>>>>             
>>>>> Who is "we" ("...we can ask LMA2...")? It's MAG1, right?
>>>>>
>>>>>           
>>>> [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.
>>     
>>>>>> 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?
>>>>>>
>>>>>>
>>>>>>             
>>>>> "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.
>>>>>
>>>>>           
>>>> [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.
>>>>
>>>>         
>>> 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.
>>>       
>> [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.
>   
>>> marco
>>>
>>>
>>>       
>>>> In this way, discovery is done only once as well.
>>>>
>>>>
>>>>         
>>>>> "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]: I agree.
>>>>
>>>>
>>>>         
>>>>>> 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.
>>     
>>>>>>
>>>>>>             
>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>> [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
>>>>>
>>>>>
>>>>>           
>>>>>>             
>>>>>>> Any opinions?
>>>>>>>
>>>>>>> marco
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> netext mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/netext
>>>>>>>
>>>>>>>
>>>>>>>               
>>>> _______________________________________________
>>>> netext mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/netext
>>>>
>>>>         
>> _______________________________________________
>> netext mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netext
>>