Re: [netext] PMIP6 and roaming

"Mohana Jeyatharan" <Mohana.Jeyatharan@sg.panasonic.com> Wed, 19 August 2009 03:42 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 3A5BF3A682E for <netext@core3.amsl.com>; Tue, 18 Aug 2009 20:42:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.61
X-Spam-Level: **
X-Spam-Status: No, score=2.61 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_42=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, J_CHICKENPOX_74=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 OrZZWSWiVcjN for <netext@core3.amsl.com>; Tue, 18 Aug 2009 20:42:16 -0700 (PDT)
Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 9C95F3A67F3 for <netext@ietf.org>; Tue, 18 Aug 2009 20:42:16 -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-maile14) with ESMTP id n7J3d0VX005101; Wed, 19 Aug 2009 12:39:00 +0900 (JST)
Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili06) with ESMTP id n7J3cwt10260; Wed, 19 Aug 2009 12:38:58 +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: Wed, 19 Aug 2009 11:35:45 +0800
Message-ID: <5F09D220B62F79418461A978CA0921BD037FA4D8@pslexc01.psl.local>
In-Reply-To: <00ff01ca2079$f2289d00$260ca40a@china.huawei.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [netext] PMIP6 and roaming
Thread-Index: AcogeYipYUGg9svnTn2tDxFPQUxWwwAAnH1A
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: Wed, 19 Aug 2009 03:42:18 -0000

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