Re: [netext] multi-LMA : how to handle
"Mohana Jeyatharan" <Mohana.Jeyatharan@sg.panasonic.com> Wed, 25 November 2009 10:29 UTC
Return-Path: <Mohana.Jeyatharan@sg.panasonic.com>
X-Original-To: netext@core3.amsl.com
Delivered-To: netext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48E8928C105 for <netext@core3.amsl.com>; Wed, 25 Nov 2009 02:29:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.821
X-Spam-Level: *
X-Spam-Status: No, score=1.821 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_23=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_62=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86RM6-VqQy0U for <netext@core3.amsl.com>; Wed, 25 Nov 2009 02:29:05 -0800 (PST)
Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 6F7A93A6976 for <netext@ietf.org>; Wed, 25 Nov 2009 02:29:04 -0800 (PST)
Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile11) with ESMTP id nAPASP6S026820; Wed, 25 Nov 2009 19:28:25 +0900 (JST)
Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili07) with ESMTP id nAPASLH03773; Wed, 25 Nov 2009 19:28:22 +0900 (JST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 25 Nov 2009 18:28:26 +0800
Message-ID: <5F09D220B62F79418461A978CA0921BD03B40328@pslexc01.psl.local>
In-Reply-To: <005401ca6dab$629e09c0$420ca40a@china.huawei.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [netext] multi-LMA : how to handle
Thread-Index: Acptq9CRy5ae+xBsT+STRLrhKa88twACpvnQ
References: <4B0664E5.6060901@nw.neclab.eu><018a01ca6c05$6ebb37c0$420ca40a@china.huawei.com><4B0A5A0D.9030401@nw.neclab.eu><02fb01ca6cde$70cccd10$420ca40a@china.huawei.com><4B0BC1CF.1050101@nw.neclab.eu> <005401ca6dab$629e09c0$420ca40a@china.huawei.com>
From: Mohana Jeyatharan <Mohana.Jeyatharan@sg.panasonic.com>
To: Qin Wu <sunseawq@huawei.com>, Marco Liebsch <liebsch@nw.neclab.eu>
Cc: netext@ietf.org
Subject: Re: [netext] multi-LMA : how to handle
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:netext@ietf.org>
List-Help: <mailto:netext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Nov 2009 10:29:07 -0000
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 > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf > Of Qin Wu > Sent: Wednesday, November 25, 2009 4:44 PM > To: Marco Liebsch > Cc: netext@ietf.org > Subject: Re: [netext] multi-LMA : how to handle > > Hi, Marco: > please see my comments inline. > > Regards! > -Qin > ----- Original Message ----- > From: "Marco Liebsch" <liebsch@nw.neclab.eu> > To: "Qin Wu" <sunseawq@huawei.com> > Cc: <netext@ietf.org> > 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" <liebsch@nw.neclab.eu> > >> To: "Qin Wu" <sunseawq@huawei.com> > >> Cc: <netext@ietf.org> > >> 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" <liebsch@nw.neclab.eu> > >>>> To: <netext@ietf.org> > >>>> 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 > >>>>> netext@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/netext > >>>>> > >>>>> > >> _______________________________________________ > >> netext mailing list > >> netext@ietf.org > >> https://www.ietf.org/mailman/listinfo/netext > >> > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext
- [netext] multi-LMA : how to handle Marco Liebsch
- Re: [netext] multi-LMA : how to handle Qin Wu
- Re: [netext] multi-LMA : how to handle Marco Liebsch
- Re: [netext] multi-LMA : how to handle Koodli, Rajeev
- Re: [netext] multi-LMA : how to handle Qin Wu
- Re: [netext] multi-LMA : how to handle Qin Wu
- Re: [netext] multi-LMA : how to handle Marco Liebsch
- Re: [netext] multi-LMA : how to handle Marco Liebsch
- Re: [netext] multi-LMA : how to handle Koodli, Rajeev
- Re: [netext] multi-LMA : how to handle Koodli, Rajeev
- Re: [netext] multi-LMA : how to handle Qin Wu
- Re: [netext] multi-LMA : how to handle Qin Wu
- Re: [netext] multi-LMA : how to handle Marco Liebsch
- Re: [netext] multi-LMA : how to handle Mohana Jeyatharan
- Re: [netext] multi-LMA : how to handle Marco Liebsch
- Re: [netext] multi-LMA : how to handle Qin Wu
- Re: [netext] multi-LMA : how to handle Mohana Jeyatharan
- Re: [netext] multi-LMA : how to handle Marco Liebsch