Re: [netext] PMIP6 and roaming

"Mohana Jeyatharan" <Mohana.Jeyatharan@sg.panasonic.com> Thu, 20 August 2009 06:09 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 22BCD3A6AA4 for <netext@core3.amsl.com>; Wed, 19 Aug 2009 23:09:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.66
X-Spam-Level: ***
X-Spam-Status: No, score=3.66 tagged_above=-999 required=5 tests=[AWL=-1.050, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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]
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 zQtWdD65D6gJ for <netext@core3.amsl.com>; Wed, 19 Aug 2009 23:09:34 -0700 (PDT)
Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 9BAAB3A6C17 for <netext@ietf.org>; Wed, 19 Aug 2009 23:09:11 -0700 (PDT)
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 n7K69Ajw003700; Thu, 20 Aug 2009 15:09:10 +0900 (JST)
Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili01) with ESMTP id n7K698W19243; Thu, 20 Aug 2009 15:09:08 +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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 20 Aug 2009 14:05:55 +0800
Message-ID: <5F09D220B62F79418461A978CA0921BD037FA741@pslexc01.psl.local>
In-Reply-To: <011001ca2148$8c8356a0$260ca40a@china.huawei.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [netext] PMIP6 and roaming
Thread-Index: AcohSDFICyIg3PySRIyyXnCfauu9bQAEBqFw
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
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: Thu, 20 Aug 2009 06:09:36 -0000

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. 

> 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).

> 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