Re: [netext] PMIP6 and roaming

"Mohana Jeyatharan" <Mohana.Jeyatharan@sg.panasonic.com> Wed, 19 August 2009 01:58 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 178683A685B for <netext@core3.amsl.com>; Tue, 18 Aug 2009 18:58:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.31
X-Spam-Level: **
X-Spam-Status: No, score=2.31 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_42=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 C5SsrjOq6kxb for <netext@core3.amsl.com>; Tue, 18 Aug 2009 18:58:30 -0700 (PDT)
Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id A685D3A67B2 for <netext@ietf.org>; Tue, 18 Aug 2009 18:58:30 -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 n7J1wBXV011778; Wed, 19 Aug 2009 10:58:11 +0900 (JST)
Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili02) with ESMTP id n7J1w2T17649; Wed, 19 Aug 2009 10:58:03 +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 09:54:48 +0800
Message-ID: <5F09D220B62F79418461A978CA0921BD037FA451@pslexc01.psl.local>
In-Reply-To: <4A8AA0FC.10406@nw.neclab.eu>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [netext] PMIP6 and roaming
Thread-Index: AcogDNT7Ds28H3dYQuqSZdK6skzwsAAXjCCA
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
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 01:58:32 -0000

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