Re: [netext] PMIP6 and roaming

Qin Wu <sunseawq@huawei.com> Fri, 21 August 2009 09:55 UTC

Return-Path: <sunseawq@huawei.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 0CA493A6AEF for <netext@core3.amsl.com>; Fri, 21 Aug 2009 02:55:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.544
X-Spam-Level: ***
X-Spam-Status: No, score=3.544 tagged_above=-999 required=5 tests=[AWL=-2.514, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_32=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_46=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, J_CHICKENPOX_74=0.6, J_CHICKENPOX_92=0.6, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1]
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 08kxjy8Ec9ex for <netext@core3.amsl.com>; Fri, 21 Aug 2009 02:55:05 -0700 (PDT)
Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id A16233A692A for <netext@ietf.org>; Fri, 21 Aug 2009 02:55:04 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOQ00HIU0SA2A@szxga03-in.huawei.com> for netext@ietf.org; Fri, 21 Aug 2009 17:52:58 +0800 (CST)
Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOQ00HZ10S986@szxga03-in.huawei.com> for netext@ietf.org; Fri, 21 Aug 2009 17:52:57 +0800 (CST)
Received: from w53375 ([10.164.12.38]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KOQ004RK0S917@szxml04-in.huawei.com> for netext@ietf.org; Fri, 21 Aug 2009 17:52:57 +0800 (CST)
Date: Fri, 21 Aug 2009 17:52:57 +0800
From: Qin Wu <sunseawq@huawei.com>
To: Mohana Jeyatharan <Mohana.Jeyatharan@sg.panasonic.com>, Marco Liebsch <marco.liebsch@nw.neclab.eu>
Message-id: <02a901ca2245$2962a960$260ca40a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: base64
X-Priority: 3
X-MSMail-priority: Normal
References: <5F09D220B62F79418461A978CA0921BD037FA741@pslexc01.psl.local>
Cc: netext@ietf.org
Subject: Re: [netext] PMIP6 and roaming
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: Fri, 21 Aug 2009 09:55:07 -0000

Hi, Mohana:
There is still no consensus on what are real operating sceanrios that localized routing can be applied to. But definitely this issue was raised at IETF 75 meeting, which is related to the scope of localized routing. The discussion on this issue  is
(a) narrow/restrict scope of localized routing and match the scope of PS draft with the scope of solution
(b) the scope of PS draft can be larger than the scope of solution. 
So maybe we need one compromized way to resolve this. Just as your suggestion, the scenarios can be solved from simple one to complex one, as regarding the complex one, some additional explaination text can be used for scope restriction. 
w.r.t. complicated scenario you metioned, I think it can be simplied without interworking between LMAs if MN and CN share the same LMA in the
VPLMN or HPLMN.

Regards!
-Qin
----- Original Message ----- 
From: "Mohana Jeyatharan" <Mohana.Jeyatharan@sg.panasonic.com>
To: "Qin Wu" <sunseawq@huawei.com>; "Marco Liebsch" <marco.liebsch@nw.neclab.eu>
Cc: <netext@ietf.org>
Sent: Thursday, August 20, 2009 2:05 PM
Subject: RE: [netext] PMIP6 and roaming


Hi Qin,

Well I am not sure whether there is consensus in the group to capture the different operating scenarios of localized MAG routing in the PS draft. But, I think such understanding is essential bcos we need to apply these solutions in real deployments. Thus such clarifications are essential. For simple scenarios or basic scenarios we can solve without information passing between LMAs. But for more complicated scenarios we may need LMA interworking as part of solution to achieve localized routing or some other solution without explicit interworking between LMAs(implit).

Localized routing is RO between MN and CN placed in the same PMIPv6 domain. But MN and CN home domain can be anything.. 

Please see below for some replies...

BR,
Mohana

> -----Original Message-----
> From: Qin Wu [mailto:sunseawq@huawei.com]
> Sent: Thursday, August 20, 2009 11:45 AM
> To: Mohana Jeyatharan; Marco Liebsch
> Cc: netext@ietf.org
> Subject: Re: [netext] PMIP6 and roaming
> 
> Hi, Mohana:
> Thank for your reply. I think 3GPP case you mentioned is a good example to
> help us understand what PMIP domain really is.
> From 3GPP deployment perspective, I would agree HPLMN or VPLMN are taken
> as an example of PMIP domain.
> In this sense, it seems that  all the mobility entity(i.e., MN's LMA, MN's
> MAG, CN's LMA, CN' MAG) are located in the same VPLMN.
> I agree it is a practical scenario to which we can apply localized
> routing . However localized routing can also applied to the scenario where
> two MAGs
> in communciation are located in the VPLMN while MN's LMA and CN's MN are
> located in the same or different HPLMNs, am I right?

[Mohana] MN and CN can belong to same HPLMN and currently located in same VPLMN/HPLMN can be solved by localized routing solutions we currently have. The problematic case is where MN and CN are located in a VPLMN and connected to different MAGs and their HPLMNS are different(MN's home domain is HPLMN1 and CN's home domain is HPLMN2). This is the case you have mentioned above. This is not so simple because we do not have LMA interwroking. The other problematic case is, CN in home domain, and MN in CN's home domain (both MN and CN connected to different LMAs due to scenario) and MN's LMA is in its(MN's)  home domain.  What I mean by problematic case is, we need to see whether the solutions we currently have can be applied in such complex scenarios. 

[Qin]: Suppose MN and CN under the different MAG and belong to the same LMA, the solution we have can be applied easily.
         Suppose MN and CN under the differnt MAG and belong to the different LMA, it is a little hard to come up a concrete solution. Some folks suggest to allow 
         MN's MAG communicate with CN's LMA and CN's MAG talk to the MN's LMA in the IETF75 meeting, maybe it is possible way.

> So the open issue we have here is
> Shall we restrict all the mobility entities including MN's MAG, MN's LMA,
> CN's MAG, CN's LMA in the same VPLMN or HPLMN?
[Mohana] Lets call this Basic Scenario


> We just ask MN's MAG and CN's MAG to be located in the same VPLMN and
> don't care about where MN's LMA and CN's LMA are.
> If So, I am interested to know WG consensus on this.
[Mohana] I hope we get consensus on this and at least capture some of these scenarios somewhere. I think we may need to know the interoperability state between LMAs(Unless we have a solution that surpasses this).

[Qin] See above.



> Regards
> -Qin
> ----- Original Message -----
> From: "Mohana Jeyatharan" <Mohana.Jeyatharan@sg.panasonic.com>
> To: "Qin Wu" <sunseawq@huawei.com>; "Marco Liebsch"
> <marco.liebsch@nw.neclab.eu>
> Cc: <netext@ietf.org>
> Sent: Wednesday, August 19, 2009 11:35 AM
> Subject: RE: [netext] PMIP6 and roaming
> 
> 
> Hi Qin,
> 
> I agree that there is no unqiue way to define PMIP domain and
> administrative domain. But, I guess we can give it some assumptions. If
> LMAs in an administrative domain know each other state, we can call it
> same adminsitrative domain/PMIP domain.
> 
> However, in 3GPP home routed case, the MN may receive home services via
> home routed mechanism but, it is placed in another administrative domain.
> For example the LMAs in the different domains may not know each other. I
> think if every network entitiy in PMIP domain knows other network entties
> and can easily create security associations or allowed to create secuity
> associations(not worrying about roaming agreement), we can easily
> classifiy as a single PMIP domain. Again this is my own judgment. Thus the
> home routed case may not fall into single administrative domain.
> 
> 
> >in many cases, one PMIP domain can cover multiple adminstrative
> > domains. However how to define one administrative domain? In your
> > understanding, one administrative domain can be examplified as one
> subnet
> > or a logical division of one access network in 3GPP scenario? am I
> right?
> > Is it  what we understand for the definition of adminitrative domain?
>  Well in 3GPP case, I agree, even within one HPLMN(one administartive
> domain of MN) multiple operators can handle different access networks.
> Here I would not really look at the granularity of access network to
> define the PMIP/adminsitrative domain, but will look at HPLMN in general.
> But, now we are breaking the MAG to MAG RO scenario into the access types
> tied to the MAG and whether there will be agreement in establishing
> tunnels between such MAGs. I think if LMA is involved in establishing MAG
> to MAG RO, it may know whether such tunneling is allowed.
> 
> So I think it is better to initially say HPLMN is like one adminsitrative
> or PMIP domain. Then later narrow or break HMPLN into further sub domains
> and look at the feasibility of MAG to MAG RO. I think it would be good to
> capture this scenario (inter 3GPP sub divisions) also in the PS draft.
> 
> BR,
> Mohana
> > -----Original Message-----
> > From: Qin Wu [mailto:sunseawq@huawei.com]
> > Sent: Wednesday, August 19, 2009 11:06 AM
> > To: Mohana Jeyatharan; Marco Liebsch
> > Cc: netext@ietf.org
> > Subject: Re: [netext] PMIP6 and roaming
> >
> > Hi, Mohana and all:
> > As you mentioned, PMIP domain and administrative domain coincides, I
> agree.
> > e.g.,in many cases, one PMIP domain can cover multiple adminstrative
> > domains. However how to define one administrative domain? In your
> > understanding, one administrative domain can be examplified as one
> subnet
> > or a logical division of one access network in 3GPP scenario? am I
> right?
> > Is it  what we understand for the definition of adminitrative domain?
> > From my understanding, the term of "administrative domain" is more
> generic
> > term and very confusing, e.g, I can say one AAA domain is a
> administrative
> > domain too or adminstrative domain can be examplified as *a geographic
> > mobility domain*. So if we consider to use this term in the PS draft, we
> > should be very careful what it exact means.
> >
> > Regards!
> > -Qin
> > ----- Original Message -----
> > From: "Mohana Jeyatharan" <Mohana.Jeyatharan@sg.panasonic.com>
> > To: "Marco Liebsch" <marco.liebsch@nw.neclab.eu>; "Qin Wu"
> > <sunseawq@huawei.com>
> > Cc: <netext@ietf.org>
> > Sent: Wednesday, August 19, 2009 9:54 AM
> > Subject: RE: [netext] PMIP6 and roaming
> >
> >
> > Hi all,
> >
> > I just followed the thread, and tried to look into the scenarios we have
> > in the RO PS draft. We have classified the four scenarios in PS draft
> for
> > MAG localized routing.
> >
> > (1)MN and CN under same MAG and both MN and CN belong to same LMA. Here
> MN
> > and CN need to be placed in the same admnistrative domain(canbe their
> home
> > domain or be a foreign domain(3GPP home routed)) and they need to belong
> > to same home domain.
> > (2) Mn and CN under same MAG but different LMAs(Mn belong to LMA1 and CN
> > belong to LMA2). Here, MN and CN need to be placed in same
> administrative
> > domain but may belong to different administrative(home) domain.
> > (3) MN and CN under different MAGs but same LMA. Here for MAG to MAG RO
> to
> > work, both MN and CN must be placed in the same administrative
> domain(home
> > domain or foreign domain(3GPP home routed)) and they must belong to same
> > home domain
> > (4) MN and CN under different MAG and different LMA(LMA1 and LMA2). Here
> > MN and CN must be placed in same adminsitrative domain(home or foreign
> > domain) and LMAs should also be from the same adminsitrative(home)
> domain.
> >
> > So, I think that MAG to MAG RO can work when MN and CN are placed in
> same
> > adminsitartive domains as Marco pointed out. However, they may belong to
> > different domains(home domains may be different). Again as Marco pointed
> > out it all depend on the assumptions we make, such as whether LMAs can
> > interact and so on. Also coming to adminsitrative domain and PMIP domain,
> > I think PMIP domain and administrative domain coincides. Yes, in 3GPP
> you
> > can see your HNP in another adminsitartive domain. But the Mn is aware
> > that it is another adminisrative domain although it sees the HNP from
> home
> > domain.
> >
> > So, I think we can keep the MAG to MAG RO for cases where MN and CN are
> > placed in the same adminsitrative domain.
> >
> > Thanks.
> >
> > BR,
> > Mohana
> >
> > > -----Original Message-----
> > > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On
> Behalf
> > > Of Marco Liebsch
> > > Sent: Tuesday, August 18, 2009 8:39 PM
> > > To: Qin Wu
> > > Cc: netext@ietf.org
> > > Subject: Re: [netext] PMIP6 and roaming
> > >
> > > hi Qin,
> > >
> > > Qin Wu schrieb:
> > > > Hi, Marco:
> > > >  I agree the Localized routing mechanism can be applicable to the
> > > scenario
> > > >  where two MAGs in communication are within the same
> *administrative*
> > > > domain.However there are still confusion between administrative
> domain
> > > > and PMIP domain. Because PMIP domain can be taken as one
> > administrative
> > > >  domain, however one administrative domain may be not PMIP domain
> but
> > > > MIP domain. So what's the scope of administrative domain and PMIP
> > > domain?
> > > > it is necessary to be clarified, am I right?
> > > >
> > > Yes, but I am not sure this will bring us further. As difference to
> the
> > > PMIPv6 specification,
> > > we handle scenarios between two communicating MNs, which may get
> served
> > > by components
> > > from different administrative domains. Sure, a PMIPv6 domain can cover
> > > multiple admin domains.
> > > Hence, I think for the protocol specification it's sufficient to
> assume
> > > that, to work, there must
> > > be a trust relationship between components exchanging signaling. So
> for
> > > the protocol specification
> > > I think it's sufficient to mandate a security association between
> these
> > > components to authenticate
> > > messages.
> > >
> > > marco
> > >
> > >
> > >
> > >
> > >
> > >
> > > > Regards!
> > > > -Qin
> > > > ----- Original Message -----
> > > > From: "Marco Liebsch" <marco.liebsch@nw.neclab.eu>
> > > > To: "Alper Yegin" <alper.yegin@yegin.org>
> > > > Cc: <netext@ietf.org>
> > > > Sent: Tuesday, August 04, 2009 4:26 PM
> > > > Subject: Re: [netext] PMIP6 and roaming
> > > >
> > > >
> > > > Hi Alper, Desire, all
> > > >
> > > > if we assume that PMIPv6 operates between the LMA in the US and the
> > MAG
> > > > in Sweden, well, then a security association is implicit. Hence,
> there
> > > > is some level
> > > > of trust.For the protocol solution in the IETF, this should be the
> > main
> > > > requirement.
> > > > Where these components are finally located is deployment specific.
> > > >
> > > > Same for localized routing: When a MAG can create a binding at the
> LMA,
> > > > I don't
> > > > see a problem why the LMA cannot create a state at the MAG to
> perform
> > > > localized
> > > > routing. SAme as above: As long as there is an SA between the two
> > > > components.
> > > >
> > > > From the discussion we had in Stockholm, I think for deployment
> > > > perspective it's more important to have both MAGs (mobile 1 and
> mobile
> > > 2) in the same
> > > > *administrative* domain (to distiguish from a PMIP domain), as
> inter-
> > MAG
> > > operation between
> > > > administrative domains comprises the knows issues.
> > > >
> > > > For the protocol specification: Well, it does not matter.. as long
> as
> > > MAGs share a security association and can set up a
> > > > forwarding tunnel.
> > > >
> > > > marco
> > > >
> > > >
> > > > Alper Yegin schrieb:
> > > >
> > > >> Hi Desire,
> > > >>
> > > >> RFC 5213:
> > > >>
> > > >>    Proxy Mobile IPv6 Domain (PMIPv6-Domain)
> > > >>
> > > >>       Proxy Mobile IPv6 domain refers to the network where the
> > mobility
> > > >>       management of a mobile node is handled using the Proxy Mobile
> > > IPv6
> > > >>       protocol as defined in this specification.  The Proxy Mobile
> > IPv6
> > > >>       domain includes local mobility anchors and mobile access
> > gateways
> > > >>       between which security associations can be set up and
> > > >>       authorization for sending Proxy Binding Updates on behalf of
> > the
> > > >>       mobile nodes can be ensured.
> > > >>
> > > >>
> > > >> I remember this was specifically discussed and we had come up with
> a
> > > text
> > > >> that refers to "local mobility anchors and mobile access gateways
> > > between
> > > >> which security associations can be set up" as the limiting factor
> > that
> > > sets
> > > >> the boundary. And security associations can be setup between MAGs
> and
> > > LMAs
> > > >> belonging to separate operators when there is a roaming agreement.
> > > WiMAX
> > > >> architecture already does that.
> > > >>
> > > >> Alper
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>> -----Original Message-----
> > > >>> From: Desire Oulai [mailto:desire.oulai@ericsson.com]
> > > >>> Sent: Thursday, July 30, 2009 4:13 PM
> > > >>> To: Alper Yegin; netext@ietf.org
> > > >>> Subject: RE : [netext] PMIP6 and roaming
> > > >>>
> > > >>> Hi Alper,
> > > >>>
> > > >>>   See inline!
> > > >>>
> > > >>> Desire
> > > >>>
> > > >>> ________________________________
> > > >>>
> > > >>> De: netext-bounces@ietf.org de la part de Alper Yegin
> > > >>> Date: jeu. 2009-07-30 08:02
> > > >>> À: netext@ietf.org
> > > >>> Objet : [netext] PMIP6 and roaming
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>> Continuing the discussion on the ML......
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>> Consider mobile1 and mobile2 subscribed to data service in USA.
> > > >>>
> > > >>> They are in Sweden, accessing Internet by "roaming" to a Swedish
> > > >>> operator network.
> > > >>>
> > > >>>
> > > >>>
> > > >>> Does PMIP6 not support this case where MAG is in Swedish operator
> > > >>> network, and LMA in USA operator's network? I think the answer is
> > yes.
> > > >>>
> > > >>> [Desire]:   I think PMIP6 as defined in RFC5213 does not support
> > this
> > > >>> scenario as the MAG are not in the same PMIP domain. However, SDOs
> > > like
> > > >>> 3GPP supports home tunnelling.
> > > >>>
> > > >>>
> > > >>>
> > > >>> Wouldn't we want to optimize the path between mobile1 and mobile2
> to
> > > >>> save the traffic from making the unnecessary USA trip? I think the
> > > >>> answer is yes again.
> > > >>>
> > > >>> [Desire]: I agree that it is an interesting optimization. But we
> > need
> > > >>> first to clarify the relation between the MAG in sweden and the
> LMA
> > in
> > > >>> USA. So we need to specify PMIP6 roaming before talking about
> > > Localized
> > > >>> routing in PMIP6 roaming.
> > > >>>
> > > >>>
> > > >>>
> > > >>> Comments?
> > > >>>
> > > >>>
> > > >>>
> > > >>> Alper
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >> _______________________________________________
> > > >> 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