From Xiangsong.Cui@huawei.com Sat Aug 1 19:09:01 2009 Return-Path: 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 50D9B3A67E6 for ; Sat, 1 Aug 2009 19:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.294 X-Spam-Level: ** X-Spam-Status: No, score=2.294 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, 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 H--W3JlYJK0i for ; Sat, 1 Aug 2009 19:09:00 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id DEF803A66B4 for ; Sat, 1 Aug 2009 19:08:59 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNQ00KTX8MRBD@szxga01-in.huawei.com> for netext@ietf.org; Sun, 02 Aug 2009 10:08:51 +0800 (CST) Received: from huawei.com ([172.17.1.31]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNQ00JVJ8MRUA@szxga01-in.huawei.com> for netext@ietf.org; Sun, 02 Aug 2009 10:08:51 +0800 (CST) Received: from [172.24.1.6] (Forwarded-For: [123.113.127.24]) by szxmc03-in.huawei.com (mshttpd); Sun, 02 Aug 2009 10:08:51 +0800 Date: Sun, 02 Aug 2009 10:08:51 +0800 From: cuixiangsong 00111037 In-reply-to: To: jouni korhonen Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: multipart/mixed; boundary="Boundary_(ID_4jkCajO+Jv9On9y2I5Hhzg)" Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal References: <018b01ca10fc$396761c0$40106f0a@china.huawei.com> <00e501ca1194$f20d4b70$40106f0a@china.huawei.com> <63E93F6E-5066-4DF9-B634-ECAED67E322F@gmail.com> <017b01ca11c5$bd5defc0$40106f0a@china.huawei.com> Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2009 02:09:01 -0000 This is a multi-part message in MIME format. --Boundary_(ID_4jkCajO+Jv9On9y2I5Hhzg) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Content-disposition: inline Hi jouni=2C Sorry for the late response=2E I=27m glad to try this approach=2E I have this idea base on the statment from = =22draft-ietf-netlmm-grekey-option-09=2Etxt=22=2C (I will call it grekey-draft in this context) The draft says=2C in section 1=3A =22 The negotiated downlink and uplink GRE keys can be used for marking the downlink and uplink traffic for a specific mobility session=2E=22 This is the key=3A we can use the GRE keys to marking the traffic=2E I think this is equal to say we can identify the flow use GRE keys and we of course may take the connections as the traffic flows=2E So I wish we can re-use the GRE key with only a little overloading=2E Now let=27s consider how can we use GRE key to achieve this requirement=2E= I assume the MAG and the LMA both support GRE key option and connection feature=2E Firstly=2C when MAG sends PBU message to LMA=2C the MAG creats a down link GRE key and maps the down link GRE key to the connection = originated from MN=2E The MAG includes the GRE key option in the PBU as specified in grekey-draft=2C and also includes a Service Selection Mobility Option as speified in RFC5149=2E Secondly=2C when the LMA receives the PBU message from the MAG=2C = the LMA deals the message and the options as specified in existing documents=2E After the LMA creats BCE and a uplink GRE key=2C the LMA caches the MN-id=2C Service Selection=2C downlink GRE key and uplink GRE key in the BCE and also associates both the downlink GRE key and the uplink GRE key with the PDN connection=2E The LMA responds PBA message to the MAG=2C with the uplink GRE key option included=2E Thirdly=2C when the MAG receives the PBA from the LMA=2C the MAG caches the uplink GRE key and associates both the downlink GRE key and uplink GRE key with the connection to MN=2E The MN also knows well the MN id and the Service Selection=2E By now=2C the registration has been finished and both the LMA and the MAG have cached a mapping=2C between GRE key pair(i=2Ee=2E downlink GRE key and uplink GRE key) and the connection (i=2Ee=2E the conncetion from multiple PDN connections to a same APN)=2E In the Data Packets Processing procedure=2C section 7=2E3=2E1 and 7=2E4=2E= 1 from grekey-draft show the rule and additionally=2C section 3=2E1 from grekey-draft says=3A =22 once the GRE keys have been exchanged between the mobile access gateway and the local mobility anchor as per this specification=2C the mobile access gateway will use the uplink GRE key= that is assigned by the local mobility anchor in the GRE header of the uplink payload packet=2E Similarly=2C the local mobility anchor w= ill use the downlink GRE key as negotiated with the mobile access gateway in the GRE header of the downlink payload packet=2E=22 That means=2C both the LMA and the MAG can use the GRE keys included in the GRE header to identify the data packet=2C or identify the traffic flo= w=2E So=2C the connection is iedntified by the combination of =22MN id + GRE k= ey + Service Selection(i=2Ee=2E APN)=22=2E In fact=2C the connection is frac= tionized=2C the direction from LMA to MAG is identified by =22MN id + downlink GRE ke= y + APN=22 while the direction from MAG to LMA is identified by =22MN id + = uplink GRE key + APN=22=2E Each connection may be identified exactly=2E As to the handover=2C grekey-draft says=2C in section 3=2E3=2E2=2C =22 In this case=2C the new mobile access gateway may either pick a new downlink GRE key or use the downlink GRE key that was used by the previous mobile access gateway for the same binding=2E= For the new mobile access gateway to know the downlink GRE key used by the previous mobile access gateway=2C it may require transfer of context from the previous mobile access gateway to the new mobile access gateway during a handoff=2E Such mechanisms are out-of-scope for this specification=2E=22 This is for the downlink GRE key=2C and for the uplink GRE key=2C the grekey draft says=3A =22 If the local mobility anchor successfully processes a handoff- triggered Binding Lifetime Extension Proxy Binding Update message which contains a GRE key option with a downlink GRE key included=2C th= e local mobility anchor MUST return the same uplink GRE key that was exchanged with the previous mobile access gateway for the same mobility session in the GRE key option in a successful Proxy Binding Acknowledgement=2E=22 Above all=2C I think we can use the GRE key option to achieve the = requirement of =22multiple PDN connections to the same APN=22=2E Is it right or usable=3F Regards Xiangsong =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ----- =D4=AD=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A jouni korhonen =3Cjouni=2Enospam=40gmail=2Ecom=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=CE=E5=2C =C6=DF=D4=C2 31=C8=D5=2C 2009 =CF=C2= =CE=E79=3A39 =D6=F7=CC=E2=3A Re=3A =5Bnetext=5D Comments on I-D=3A draft-wolfner-netex= t-pmip6-connid-00 =CA=D5=BC=FE=C8=CB=3A Xiangsong Cui =3CXiangsong=2ECui=40huawei=2Ecom=3E =B3=AD=CB=CD=3A netext=40ietf=2Eorg=2C Basavaraj=2EPatil=40nokia=2Ecom =3E = =3E = =3E Lets first resolve whether the GRE keys are usable in the first = =3E place=2E = =3E Then we can return to the rest of the discussion=2E Some more stuff = =3E inline=2E =3E = =3E On Jul 31=2C 2009=2C at 1=3A00 PM=2C Xiangsong Cui wrote=3A =3E = =3E =3E Hi Jouni=2C =3E =3E Please see inline=2E =3E =3E =3E =3E Regards/Xiangsong =3E =3E =3E =3E =3E =3E ----- Original Message ----- From=3A =22jouni korhonen=22 = =3E =3Cjouni=2Enospam=40gmail=2Ecom = =3E =3E =3E =3E =3E To=3A =22Xiangsong Cui=22 =3CXiangsong=2ECui=40huawei=2Ecom=3E =3E =3E Cc=3A =3Cnetext=40ietf=2Eorg=3E=3B =3CBasavaraj=2EPatil=40nokia=2E= com=3E =3E =3E Sent=3A Friday=2C July 31=2C 2009 5=3A16 PM =3E =3E Subject=3A Re=3A =5Bnetext=5D Comments on I-D=3A draft-wolfner-ne= text- =3E pmip6- = =3E =3E connid-00 =3E =3E =3E =3E =3E =3E=3E Hi=2C =3E =3E=3E On Jul 31=2C 2009=2C at 7=3A11 AM=2C Xiangsong Cui wrote=3A =3E =3E=3E=3E Hi Jouni=2C =3E =3E=3E=3E =3E =3E=3E=3E Thank you for your response=2E =3E =3E=3E=3E =3E =3E=3E=3E=3E There are few reasons=2E First=2C which GRE key to use=3F= Uplink or = =3E = =3E =3E=3E=3E=3E downlink=3F =3E =3E=3E=3E I think Uplink and downlink may be used to identify the con= nection =3E =3E=3E Uh=2E=2E so you would use combination of both keys simultaneou= sly=3F =3E =3E =3E =3E Yes=2C I think GRE Key is designed for this manner=2E =3E = =3E I am a bit confused=2E Do you mean using 64-bit identifier made of = =3E both = =3E uplink =26 downlink GRE keys=3F =3E = =3E Anyway=2C downlink GRE keys are no good in general as they may = =3E change = =3E during handovers=2E If there is context transfer between MAGs it = =3E still = =3E does not solve the downlink key issue=2E One would need to start = =3E coordinating downlink key space between MAGs=2C which is a new = =3E requirement=2E =3E = =3E The Uplink GRE key would be an usable connection Id=2C assuming MAGs = =3E can = =3E do a context transfer=2C the exception mentioned in Section 3=2E3=2E2= of = =3E = =3E draft-ietf-netlmm-grekey-option does not happen and that GRE is = =3E used = =3E in the first place=2E However=2C the GRE key option in a PBU contains= = =3E only = =3E the downlink key=2E This means=2C you need something beyond draft-iet= f- =3E = =3E netlmm-grekey-option to send the uplink GRE key in the PBU (if the = =3E = =3E uplink GRE key were used as the connection Id)=2E =3E = =3E =5Bsnap=5D =3E = =3E =3E=3E=3E=3E =3E =3E=3E=3E=3E Second=2C the use of GRE keys and GRE tunneling is optio= nal in = =3E = =3E =3E=3E=3E=3E PMIP6=2E Well=2C so is Service Selection too but I woul= d avoid = =3E =3E=3E=3E=3E building additional dependencies between different docu= ments = =3E if = =3E =3E=3E=3E=3E just possible=2E =3E =3E=3E=3E Yes=2C GRE Key is an optional option=2E I think an optional= option = =3E is = =3E =3E=3E=3E used =3E =3E=3E=3E for a optional feature is reasonable =3E =3E=3E The less the better=2E I=2Ee=2E if I can choose between two op= tional = =3E = =3E =3E=3E features versus three optional features=2C I would go for two=2E= =3E =3E=3E=3E =3E =3E=3E=3E=3E =3E =3E=3E=3E=3E Third=2C overloading the function of the GRE key option = does = =3E not = =3E =3E=3E=3E=3E sound a good idea in general=2C even if it were possible= =2E =3E =3E=3E=3E If it works well=2C why not take it as the solution=3F =3E =3E=3E Overloading existing semantics is always a bad practice=2E =3E =3E Yes=2C I agree it is a trouble=2E =3E =3E But if the overloading is in the acceptable scope=2C IMO=2C we ne= ed = =3E =3E balance the impact of overloading and introducing a new expansio= n=2E =3E =3E It is the motivation behind my original question=2E =3E = =3E You would still need a document that describes how the GRE keys = =3E are = =3E used to extend the BCE lookup=2C how they are used with RFC5149=2C an= d = =3E how = =3E to indicate to the LMA that the GRE keys are used in this special = =3E overloaded way etc=2E If you go down this road=2C what is the benefit= = =3E of = =3E it over defining a new option specifically made for connection = =3E identifier purpose=3F At the end=2C the connection identifier content= = =3E can = =3E be anything that is a stable identifier within the system where = =3E this = =3E extension is being used=2E=2E be that a GRE key or not=2E =3E = =3E Cheers=2C =3E Jouni =3E = =3E = =3E =3E =3E =3E=3E I=27ll skip the rest as I don=27t see how they relate to this = =3E discussion=2E=3E=3E Cheers=2C =3E =3E=3E Jouni =3E =3E =5Bsnip=5D =3E =3E =3E = =3E = =3E =3E =3E = =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =3E netext mailing list =3E netext=40ietf=2Eorg =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/netext =3E --Boundary_(ID_4jkCajO+Jv9On9y2I5Hhzg) Content-type: text/x-vcard; name=c00111037.vcf; charset=gb2312 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=c00111037.vcf Content-description: Card for cuixiangsong 00111037 begin:vcard n:Cui;Xiangsong fn:Xiangsong Cui version:2.1 email;internet:Xiangsong.Cui@huawei.com end:vcard --Boundary_(ID_4jkCajO+Jv9On9y2I5Hhzg)-- From yokota@kddilabs.jp Sun Aug 2 18:36:36 2009 Return-Path: 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 7489C3A6D26 for ; Sun, 2 Aug 2009 18:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 GQx7fssWxgz6 for ; Sun, 2 Aug 2009 18:36:35 -0700 (PDT) Received: from mandala.kddilabs.jp (unknown [IPv6:2001:200:601:12:230:48ff:fe22:3a84]) by core3.amsl.com (Postfix) with ESMTP id 1FF503A6D30 for ; Sun, 2 Aug 2009 18:36:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id ECDD3EC868; Mon, 3 Aug 2009 10:36:31 +0900 (JST) Received: from ultra.mip.kddilabs.jp (ultra.mip.kddilabs.jp [2001:200:601:402::145]) by mandala.kddilabs.jp (Postfix) with ESMTP id 360A2EC860; Mon, 3 Aug 2009 10:36:31 +0900 (JST) Received: from [IPv6:::1] (unknown [IPv6:2001:200:601:400:1867:5f90:39b4:5517]) by ultra.mip.kddilabs.jp (Postfix) with ESMTP id 9A2CB1BA74; Mon, 3 Aug 2009 10:32:23 +0900 (JST) Message-ID: <4A763F17.1060303@kddilabs.jp> Date: Mon, 03 Aug 2009 10:36:23 +0900 From: Hidetoshi Yokota User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Koodli, Rajeev" References: <01C58952-A8B2-460D-BE11-E9F01541AF71@gmail.com> <4D35478224365146822AE9E3AD4A266609382A43@exchtewks3.starentnetworks.com> <4A733014.8050705@kddilabs.jp> <4D35478224365146822AE9E3AD4A266609382A47@exchtewks3.starentnetworks.com> In-Reply-To: <4D35478224365146822AE9E3AD4A266609382A47@exchtewks3.starentnetworks.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new Cc: netext@ietf.org Subject: Re: [netext] Clarifications regarding the runtime LMA assignment 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 01:36:36 -0000 Hi Rajeev, Koodli, Rajeev wrote: > > Hello Yokota-san. > > > >> We don't necessarily have to make 2) as a special case. It's just one >> way of realization and can be treated equally. > > > Well, redirecting MAG is to a different LMA and establishing BCE at the redirected LMA are two different things. I agree that 1) and 2) are separate things, but handling 1) and 2) at the same time doesn't have to be considered as special. > We need to solve the first part for sure, and we can consider allowing the second once we understand the picture clearly. I agree with that order of resolution since 2) won't happen without 1). Regards, -- Hidetoshi > Regards, > > -Rajeev > > > Regards, > -- > Hidetoshi > >> Regards, >> >> -Rajeev >> >> >> ________________________________ >> >> From: netext-bounces@ietf.org on behalf of jouni korhonen >> Sent: Thu 7/30/2009 9:45 AM >> To: netext@ietf.org >> Subject: [netext] Clarifications regarding the runtime LMA assignment >> >> >> >> Hi all, >> >> To follow up and clarify the questions from Rajeev, here is something >> that hopefully makes things clearer. The "proxied" case can be >> represented as below. The assumption is that the rfLMA and the r2LMA >> can exchange information between each other, and that the MAG has SAs >> with both rfLMA and the r2LMA. We do not define how and what goes >> between the rfLMA and the r2LMA. That is internal to the "LMA system", >> whatever that "LMA system" constitutes of (that would imply a single >> vendor within a "LMA system" but I guess it would reflect the reality >> anyway). We need to state in the draft, though, that a MAG can be sure >> the r2LMA has a binding setup when it receives a PBA with both >> redirection information and a successful result code. There is both >> vendor and operator interest in this approach, so I consider it >> important. >> >> MAG rfLMA r2LMA >> | | | >> |--PBU-->|- - - - | (redirection takes place, >> |<--PBA--| - - - -| PBA contains rfLMA & r2LMA >> | | | information) >> | | | >> |<=====data======>| >> | | | >> |-------PBU------>| (lifetime extension, >> |<------PBA-------| de-registration, etc >> | | | >> >> I don't mind nuking the "direct" solution in the draft. Actually I >> would be happy to do that ;) If folks are fine with options, we could >> add a variation of the "proxied" case, where another roundtrip of PBU/ >> PBA is needed between a MAG and a r2LMA before data can flow. This >> would, of course, be runtime negotiated. >> >> >> Cheers, >> Jouni >> _______________________________________________ >> 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 > > > From jouni.nospam@gmail.com Mon Aug 3 00:00:26 2009 Return-Path: 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 472053A6D53 for ; Mon, 3 Aug 2009 00:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.412 X-Spam-Level: X-Spam-Status: No, score=-0.412 tagged_above=-999 required=5 tests=[AWL=-1.998, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=1.396] 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 anx7D7S7IFZH for ; Mon, 3 Aug 2009 00:00:25 -0700 (PDT) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 889E53A6CA8 for ; Mon, 3 Aug 2009 00:00:24 -0700 (PDT) Received: by ewy10 with SMTP id 10so2801849ewy.37 for ; Mon, 03 Aug 2009 00:00:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=bHFFP0n0fkxV35KS55p66zzxv5V3gwJIrPixXVnsYS0=; b=kKFAXjMP3WzDh//GQWU3btVvXXMf3G0sfc1UgH0hU6+Iw4JI+u4fUaBDwOQquG+B9H DGfK1Er0WABkxVkZy+RLdKQ5qg4Fy7EC2+IT5J2mUyUPJPcreKAAwpCjUDT5SKAhICF8 BBq/zaxjBUcvywDIc22RkVgw+5OyaBk+HOxso= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=qu1bTbJQNp3QOUA3yUWKYCvejElI3d/E2KNxsoj+Jb+cbhxT3O2SRxsCEZAvAKYLQ1 JlxHNRI8+IEN7IIGBLQ2uUqLErjvmrL6Wlh3v22fJpPmNPwh+eoEVTV7DK3s8dqjJQPA jdyqvI44k69zEQUf/cXaOwiwEbwIZOPgttH40= Received: by 10.210.69.13 with SMTP id r13mr4512988eba.66.1249282824212; Mon, 03 Aug 2009 00:00:24 -0700 (PDT) Received: from a88-112-143-19.elisa-laajakaista.fi (a88-112-143-19.elisa-laajakaista.fi [88.112.143.19]) by mx.google.com with ESMTPS id 5sm10484810eyf.18.2009.08.03.00.00.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 03 Aug 2009 00:00:23 -0700 (PDT) Message-Id: <439F112A-84B0-4ADF-B643-097A1B647BC8@gmail.com> From: jouni korhonen To: cuixiangsong 00111037 In-Reply-To: Content-Type: text/plain; charset=GB2312; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 3 Aug 2009 10:00:21 +0300 References: <018b01ca10fc$396761c0$40106f0a@china.huawei.com> <00e501ca1194$f20d4b70$40106f0a@china.huawei.com> <63E93F6E-5066-4DF9-B634-ECAED67E322F@gmail.com> <017b01ca11c5$bd5defc0$40106f0a@china.huawei.com> X-Mailer: Apple Mail (2.935.3) Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 07:00:26 -0000 Hi Xiangsong, On Aug 2, 2009, at 5:08 AM, cuixiangsong 00111037 wrote: [snip] > > Now let's consider how can we use GRE key to achieve this requirement. I already said that uplink key could be an usable connection id as a =20 *value*, if other conditions match. > > I assume the MAG and the LMA both support GRE key option and > connection feature. Point one, we don't want to mandate GRE keys.. even if those in =20 practice would be there. =46rom draft-wolfner-* point of view, GRE keys =20= are/can be "lower layer" information. However, specifically saying the =20= connection id is *the* GRE key, is not what we want. There is =20 absolutely no need to bind this draft to grekey-draft. > > Firstly, when MAG sends PBU message to LMA, the MAG creats a down > link GRE key and maps the down link GRE key to the connection > originated from MN. The MAG includes the GRE key option in the PBU > as specified in grekey-draft, and also includes a Service Selection > Mobility Option as speified in RFC5149. As said, a PBU can only have the downlink key as per grekey-draft and =20= downlink key as-is is not enough. > > Secondly, when the LMA receives the PBU message from the MAG, > the LMA deals the message and the options as specified in existing > documents. After the LMA creats BCE and a uplink GRE key, the LMA > caches the MN-id, Service Selection, downlink GRE key and uplink > GRE key in the BCE and also associates both the downlink GRE key > and the uplink GRE key with the PDN connection. The LMA responds > PBA message to the MAG, with the uplink GRE key option included. As said, for signaling uplink GRE key in a PBU you would need =20 something beyond grekey-draft. > > Thirdly, when the MAG receives the PBA from the LMA, the MAG caches > the uplink GRE key and associates both the downlink GRE key and > uplink GRE key with the connection to MN. The MN also knows well > the MN id and the Service Selection. See above. [snip] > That means, both the LMA and the MAG can use the GRE keys included in > the GRE header to identify the data packet, or identify the traffic =20= > flow. > > So, the connection is iedntified by the combination of "MN id + GRE =20= > key > + Service Selection(i.e. APN)". In fact, the connection is =20 > fractionized, > the direction from LMA to MAG is identified by "MN id + downlink GRE =20= > key > + APN" while the direction from MAG to LMA is identified by "MN id + > uplink GRE key + APN". Each connection may be identified exactly. > > > As to the handover, grekey-draft says, in section 3.3.2, > " In this case, the new mobile access gateway may > either pick a new downlink GRE key or use the downlink GRE key that > was used by the previous mobile access gateway for the same binding. > For the new mobile access gateway to know the downlink GRE key used > by the previous mobile access gateway, it may require transfer of > context from the previous mobile access gateway to the new mobile > access gateway during a handoff. Such mechanisms are out-of-scope > for this specification." > > This is for the downlink GRE key, and for the uplink GRE key, the > grekey draft says: > > " If the local mobility anchor successfully processes a handoff- > triggered Binding Lifetime Extension Proxy Binding Update message > which contains a GRE key option with a downlink GRE key included, =20= > the > local mobility anchor MUST return the same uplink GRE key that was > exchanged with the previous mobile access gateway for the same > mobility session in the GRE key option in a successful Proxy Binding > Acknowledgement." > > > Above all, I think we can use the GRE key option to achieve the > requirement of "multiple PDN connections to the same APN". > > Is it right or usable? I think you are still missing the point here. You would still need a =20 new option in a PBU, and document the behavior in the LMA and the MAG, =20= even if the GRE uplink key were used as the connection id value. This =20= is what draft-wolfner is aiming to.. Cheers, Jouni > > > Regards > > Xiangsong > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > ----- =D4=AD=D3=CA=BC=FE ----- > =B7=A2=BC=FE=C8=CB: jouni korhonen > =C8=D5=C6=DA: =D0=C7=C6=DA=CE=E5, =C6=DF=D4=C2 31=C8=D5, 2009 =CF=C2=CE=E7= 9:39 > =D6=F7=CC=E2: Re: [netext] Comments on I-D: = draft-wolfner-netext-pmip6-=20 > connid-00 > =CA=D5=BC=FE=C8=CB: Xiangsong Cui > =B3=AD=CB=CD: netext@ietf.org, Basavaraj.Patil@nokia.com > >> >> >> Lets first resolve whether the GRE keys are usable in the first >> place. >> Then we can return to the rest of the discussion. Some more stuff >> inline. >> >> On Jul 31, 2009, at 1:00 PM, Xiangsong Cui wrote: >> >>> Hi Jouni, >>> Please see inline. >>> >>> Regards/Xiangsong >>> >>> >>> ----- Original Message ----- From: "jouni korhonen" >> >>> >>> To: "Xiangsong Cui" >>> Cc: ; >>> Sent: Friday, July 31, 2009 5:16 PM >>> Subject: Re: [netext] Comments on I-D: draft-wolfner-netext- >> pmip6- >>> connid-00 >>> >>> >>>> Hi, >>>> On Jul 31, 2009, at 7:11 AM, Xiangsong Cui wrote: >>>>> Hi Jouni, >>>>> >>>>> Thank you for your response. >>>>> >>>>>> There are few reasons. First, which GRE key to use? Uplink or >> >>>>>> downlink? >>>>> I think Uplink and downlink may be used to identify the connection >>>> Uh.. so you would use combination of both keys simultaneously? >>> >>> Yes, I think GRE Key is designed for this manner. >> >> I am a bit confused. Do you mean using 64-bit identifier made of >> both >> uplink & downlink GRE keys? >> >> Anyway, downlink GRE keys are no good in general as they may >> change >> during handovers. If there is context transfer between MAGs it >> still >> does not solve the downlink key issue. One would need to start >> coordinating downlink key space between MAGs, which is a new >> requirement. >> >> The Uplink GRE key would be an usable connection Id, assuming MAGs >> can >> do a context transfer, the exception mentioned in Section 3.3.2 of >> >> draft-ietf-netlmm-grekey-option does not happen and that GRE is >> used >> in the first place. However, the GRE key option in a PBU contains >> only >> the downlink key. This means, you need something beyond draft-ietf- >> >> netlmm-grekey-option to send the uplink GRE key in the PBU (if the >> >> uplink GRE key were used as the connection Id). >> >> [snap] >> >>>>>> >>>>>> Second, the use of GRE keys and GRE tunneling is optional in >> >>>>>> PMIP6. Well, so is Service Selection too but I would avoid >>>>>> building additional dependencies between different documents >> if >>>>>> just possible. >>>>> Yes, GRE Key is an optional option. I think an optional option >> is >>>>> used >>>>> for a optional feature is reasonable >>>> The less the better. I.e. if I can choose between two optional >> >>>> features versus three optional features, I would go for two. >>>>> >>>>>> >>>>>> Third, overloading the function of the GRE key option does >> not >>>>>> sound a good idea in general, even if it were possible. >>>>> If it works well, why not take it as the solution? >>>> Overloading existing semantics is always a bad practice. >>> Yes, I agree it is a trouble. >>> But if the overloading is in the acceptable scope, IMO, we need >>> balance the impact of overloading and introducing a new expansion. >>> It is the motivation behind my original question. >> >> You would still need a document that describes how the GRE keys >> are >> used to extend the BCE lookup, how they are used with RFC5149, and >> how >> to indicate to the LMA that the GRE keys are used in this special >> overloaded way etc. If you go down this road, what is the benefit >> of >> it over defining a new option specifically made for connection >> identifier purpose? At the end, the connection identifier content >> can >> be anything that is a stable identifier within the system where >> this >> extension is being used.. be that a GRE key or not. >> >> Cheers, >> Jouni >> >> >>> >>>> I'll skip the rest as I don't see how they relate to this >> discussion.>> Cheers, >>>> Jouni >>> [snip] >>> >> >> >>> >> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> > From Xiangsong.Cui@huawei.com Mon Aug 3 00:41:14 2009 Return-Path: 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 791873A6D73 for ; Mon, 3 Aug 2009 00:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.311 X-Spam-Level: * X-Spam-Status: No, score=1.311 tagged_above=-999 required=5 tests=[AWL=-2.472, BAYES_05=-1.11, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, 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 yVy616wdMxvi for ; Mon, 3 Aug 2009 00:41:10 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 9D4453A6D5E for ; Mon, 3 Aug 2009 00:41:07 -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 <0KNS00MA0IKHYQ@szxga03-in.huawei.com> for netext@ietf.org; Mon, 03 Aug 2009 15:38:42 +0800 (CST) Received: from c00111037 ([10.111.16.64]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KNS00LVNIKHT2@szxga03-in.huawei.com> for netext@ietf.org; Mon, 03 Aug 2009 15:38:41 +0800 (CST) Date: Mon, 03 Aug 2009 15:38:46 +0800 From: Xiangsong Cui To: jouni korhonen Message-id: <010b01ca140d$6f25a970$40106f0a@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; format=flowed; charset=gb2312; reply-type=response Content-transfer-encoding: 8BIT X-Priority: 3 X-MSMail-priority: Normal References: <018b01ca10fc$396761c0$40106f0a@china.huawei.com> <00e501ca1194$f20d4b70$40106f0a@china.huawei.com> <63E93F6E-5066-4DF9-B634-ECAED67E322F@gmail.com> <017b01ca11c5$bd5defc0$40106f0a@china.huawei.com> <439F112A-84B0-4ADF-B643-097A1B647BC8@gmail.com> Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 07:41:14 -0000 Hi Jouni, > As said, a PBU can only have the downlink key as per grekey-draft and > downlink key as-is is not enough. [...snip...] > As said, for signaling uplink GRE key in a PBU you would need something > beyond grekey-draft. Why do you exclude PBA message? The MAG and the LMA can learn both the downlink key and the uplink key by PBU/PBA exchange. > I think you are still missing the point here. You would still need a new > option in a PBU, and document the behavior in the LMA and the MAG, even > if the GRE uplink key were used as the connection id value. This is what > draft-wolfner is aiming to.. I don't think so. As I said in the previous mail, GRE key option can already meet the protocol requirement, we don't need any more option for this feature. As to the behavior in the MAG and the LMA, it is mainly about the mapping management, I don't think it is in the protocol scope. I also think you would agree me on this point, because in the draft "draft-wolfner-netext-pmip6-connid-00.txt", it says: " How the MAG maps connections originated from the MN to connection identifiers is out of scope of this specification." Regards Xiangsong ----- Original Message ----- From: "jouni korhonen" To: "cuixiangsong 00111037" Cc: ; Sent: Monday, August 03, 2009 3:00 PM Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00 Hi Xiangsong, On Aug 2, 2009, at 5:08 AM, cuixiangsong 00111037 wrote: [snip] > > Now let's consider how can we use GRE key to achieve this requirement. I already said that uplink key could be an usable connection id as a *value*, if other conditions match. > > I assume the MAG and the LMA both support GRE key option and > connection feature. Point one, we don't want to mandate GRE keys.. even if those in practice would be there. From draft-wolfner-* point of view, GRE keys are/can be "lower layer" information. However, specifically saying the connection id is *the* GRE key, is not what we want. There is absolutely no need to bind this draft to grekey-draft. > > Firstly, when MAG sends PBU message to LMA, the MAG creats a down > link GRE key and maps the down link GRE key to the connection > originated from MN. The MAG includes the GRE key option in the PBU > as specified in grekey-draft, and also includes a Service Selection > Mobility Option as speified in RFC5149. As said, a PBU can only have the downlink key as per grekey-draft and downlink key as-is is not enough. > > Secondly, when the LMA receives the PBU message from the MAG, > the LMA deals the message and the options as specified in existing > documents. After the LMA creats BCE and a uplink GRE key, the LMA > caches the MN-id, Service Selection, downlink GRE key and uplink > GRE key in the BCE and also associates both the downlink GRE key > and the uplink GRE key with the PDN connection. The LMA responds > PBA message to the MAG, with the uplink GRE key option included. As said, for signaling uplink GRE key in a PBU you would need something beyond grekey-draft. > > Thirdly, when the MAG receives the PBA from the LMA, the MAG caches > the uplink GRE key and associates both the downlink GRE key and > uplink GRE key with the connection to MN. The MN also knows well > the MN id and the Service Selection. See above. [snip] > That means, both the LMA and the MAG can use the GRE keys included in > the GRE header to identify the data packet, or identify the traffic flow. > > So, the connection is iedntified by the combination of "MN id + GRE key > + Service Selection(i.e. APN)". In fact, the connection is fractionized, > the direction from LMA to MAG is identified by "MN id + downlink GRE key > + APN" while the direction from MAG to LMA is identified by "MN id + > uplink GRE key + APN". Each connection may be identified exactly. > > > As to the handover, grekey-draft says, in section 3.3.2, > " In this case, the new mobile access gateway may > either pick a new downlink GRE key or use the downlink GRE key that > was used by the previous mobile access gateway for the same binding. > For the new mobile access gateway to know the downlink GRE key used > by the previous mobile access gateway, it may require transfer of > context from the previous mobile access gateway to the new mobile > access gateway during a handoff. Such mechanisms are out-of-scope > for this specification." > > This is for the downlink GRE key, and for the uplink GRE key, the > grekey draft says: > > " If the local mobility anchor successfully processes a handoff- > triggered Binding Lifetime Extension Proxy Binding Update message > which contains a GRE key option with a downlink GRE key included, the > local mobility anchor MUST return the same uplink GRE key that was > exchanged with the previous mobile access gateway for the same > mobility session in the GRE key option in a successful Proxy Binding > Acknowledgement." > > > Above all, I think we can use the GRE key option to achieve the > requirement of "multiple PDN connections to the same APN". > > Is it right or usable? I think you are still missing the point here. You would still need a new option in a PBU, and document the behavior in the LMA and the MAG, even if the GRE uplink key were used as the connection id value. This is what draft-wolfner is aiming to.. Cheers, Jouni > > > Regards > > Xiangsong > > =============================================================== > ----- Ô­Óʼþ ----- > ·¢¼þÈË: jouni korhonen > ÈÕÆÚ: ÐÇÆÚÎå, ÆßÔ 31ÈÕ, 2009 ÏÂÎç9:39 > Ö÷Ìâ: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6- connid-00 > ÊÕ¼þÈË: Xiangsong Cui > ³­ËÍ: netext@ietf.org, Basavaraj.Patil@nokia.com > >> >> >> Lets first resolve whether the GRE keys are usable in the first >> place. >> Then we can return to the rest of the discussion. Some more stuff >> inline. >> >> On Jul 31, 2009, at 1:00 PM, Xiangsong Cui wrote: >> >>> Hi Jouni, >>> Please see inline. >>> >>> Regards/Xiangsong >>> >>> >>> ----- Original Message ----- From: "jouni korhonen" >> >>> >>> To: "Xiangsong Cui" >>> Cc: ; >>> Sent: Friday, July 31, 2009 5:16 PM >>> Subject: Re: [netext] Comments on I-D: draft-wolfner-netext- >> pmip6- >>> connid-00 >>> >>> >>>> Hi, >>>> On Jul 31, 2009, at 7:11 AM, Xiangsong Cui wrote: >>>>> Hi Jouni, >>>>> >>>>> Thank you for your response. >>>>> >>>>>> There are few reasons. First, which GRE key to use? Uplink or >> >>>>>> downlink? >>>>> I think Uplink and downlink may be used to identify the connection >>>> Uh.. so you would use combination of both keys simultaneously? >>> >>> Yes, I think GRE Key is designed for this manner. >> >> I am a bit confused. Do you mean using 64-bit identifier made of >> both >> uplink & downlink GRE keys? >> >> Anyway, downlink GRE keys are no good in general as they may >> change >> during handovers. If there is context transfer between MAGs it >> still >> does not solve the downlink key issue. One would need to start >> coordinating downlink key space between MAGs, which is a new >> requirement. >> >> The Uplink GRE key would be an usable connection Id, assuming MAGs >> can >> do a context transfer, the exception mentioned in Section 3.3.2 of >> >> draft-ietf-netlmm-grekey-option does not happen and that GRE is >> used >> in the first place. However, the GRE key option in a PBU contains >> only >> the downlink key. This means, you need something beyond draft-ietf- >> >> netlmm-grekey-option to send the uplink GRE key in the PBU (if the >> >> uplink GRE key were used as the connection Id). >> >> [snap] >> >>>>>> >>>>>> Second, the use of GRE keys and GRE tunneling is optional in >> >>>>>> PMIP6. Well, so is Service Selection too but I would avoid >>>>>> building additional dependencies between different documents >> if >>>>>> just possible. >>>>> Yes, GRE Key is an optional option. I think an optional option >> is >>>>> used >>>>> for a optional feature is reasonable >>>> The less the better. I.e. if I can choose between two optional >> >>>> features versus three optional features, I would go for two. >>>>> >>>>>> >>>>>> Third, overloading the function of the GRE key option does >> not >>>>>> sound a good idea in general, even if it were possible. >>>>> If it works well, why not take it as the solution? >>>> Overloading existing semantics is always a bad practice. >>> Yes, I agree it is a trouble. >>> But if the overloading is in the acceptable scope, IMO, we need >>> balance the impact of overloading and introducing a new expansion. >>> It is the motivation behind my original question. >> >> You would still need a document that describes how the GRE keys >> are >> used to extend the BCE lookup, how they are used with RFC5149, and >> how >> to indicate to the LMA that the GRE keys are used in this special >> overloaded way etc. If you go down this road, what is the benefit >> of >> it over defining a new option specifically made for connection >> identifier purpose? At the end, the connection identifier content >> can >> be anything that is a stable identifier within the system where >> this >> extension is being used.. be that a GRE key or not. >> >> Cheers, >> Jouni >> >> >>> >>>> I'll skip the rest as I don't see how they relate to this >> discussion.>> Cheers, >>>> Jouni >>> [snip] >>> >> >> >>> >> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> > From jouni.nospam@gmail.com Mon Aug 3 01:47:42 2009 Return-Path: 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 239F93A6C50 for ; Mon, 3 Aug 2009 01:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.825 X-Spam-Level: X-Spam-Status: No, score=-0.825 tagged_above=-999 required=5 tests=[AWL=-1.015, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45] 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 95vmad5wrJaW for ; Mon, 3 Aug 2009 01:47:40 -0700 (PDT) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id 326B63A67B0 for ; Mon, 3 Aug 2009 01:47:39 -0700 (PDT) Received: by bwz19 with SMTP id 19so2301899bwz.37 for ; Mon, 03 Aug 2009 01:47:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :x-priority:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; bh=2q5SKhP5vlfRkH1OUr7X+TWItLWOj15cuG+BF0IS/aM=; b=QsU+CLQOCQ8f7nFxXoeaVdKoh4hZ1sH/jIJOtwi0tFE5cWcw1UuLJay7wjCPZ7CNr7 DNTcrjAMdfO7+T7P2zJPfiJottnBLtoLX8y+Yui/KMjYfZCE+y5UsrSK3fz+Qe58KP1i JEuufhJHPCV1UMghBSy9i64bskYJ4h++Xvm/Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:x-priority:references:message-id :content-type:content-transfer-encoding:mime-version:date:cc :x-mailer; b=XWNV5ffUDzrQGUXI6SM6jcOjngLmjAjoI6a6AlVaHHBCqvkH1F794TevactYZ3EGjU 90gcsJvx/cMULGWmA6KFrhLvuh6BUuCLXGmAl88FiYxjnTrqHnOjzTyuxzqhjBdIaO0c //XgKu5q8emiBaQUyFHXxIA+1Jigj/VlJSUCE= Received: by 10.103.221.14 with SMTP id y14mr2187122muq.57.1249289259499; Mon, 03 Aug 2009 01:47:39 -0700 (PDT) Received: from a88-112-143-19.elisa-laajakaista.fi (a88-112-143-19.elisa-laajakaista.fi [88.112.143.19]) by mx.google.com with ESMTPS id y2sm36442237mug.42.2009.08.03.01.47.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 03 Aug 2009 01:47:39 -0700 (PDT) From: jouni korhonen To: Xiangsong Cui In-Reply-To: <010b01ca140d$6f25a970$40106f0a@china.huawei.com> X-Priority: 3 References: <018b01ca10fc$396761c0$40106f0a@china.huawei.com> <00e501ca1194$f20d4b70$40106f0a@china.huawei.com> <63E93F6E-5066-4DF9-B634-ECAED67E322F@gmail.com> <017b01ca11c5$bd5defc0$40106f0a@china.huawei.com> <439F112A-84B0-4ADF-B643-097A1B647BC8@gmail.com> <010b01ca140d$6f25a970$40106f0a@china.huawei.com> Message-Id: <2796F141-85B7-433E-A088-BE0E478F49EF@gmail.com> Content-Type: text/plain; charset=GB2312; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 3 Aug 2009 11:47:37 +0300 X-Mailer: Apple Mail (2.935.3) Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 08:47:42 -0000 On Aug 3, 2009, at 10:38 AM, Xiangsong Cui wrote: > Hi Jouni, > >> As said, a PBU can only have the downlink key as per grekey-draft =20 >> and downlink key as-is is not enough. > [...snip...] >> As said, for signaling uplink GRE key in a PBU you would need =20 >> something beyond grekey-draft. > > Why do you exclude PBA message? In grekey-draft scope because, the LMA needs to know the connection id =20= already when receiving the PBU. The MAG needs to include a connection =20= id in the PBU. Downlink key is not really good for this purpose. > The MAG and the LMA can learn both the downlink key and the uplink key > by PBU/PBA exchange. > > > >> I think you are still missing the point here. You would still need =20= >> a new option in a PBU, and document the behavior in the LMA and =20 >> the MAG, even if the GRE uplink key were used as the connection id =20= >> value. This is what draft-wolfner is aiming to.. > > I don't think so. > > As I said in the previous mail, GRE key option can already meet the > protocol requirement, we don't need any more option for this feature. > > As to the behavior in the MAG and the LMA, it is mainly about the > mapping management, I don't think it is in the protocol scope. You impact BCE lookup. That is one main reason why to bring this stuff =20= to IETF in the first place. If it were completely protocol agnostic, =20 we would have kept it inside 3GPP. > I also think you would agree me on this point, because in the draft > "draft-wolfner-netext-pmip6-connid-00.txt", it says: > > " How the MAG maps connections originated from the > MN to connection identifiers is out of scope of this specification." And? I don't see the point as I wrote that text in the draft ;) I =20 should probably clarify that the quoted text means mapping of e.g. =20 some radio level "bearer" to some identity value used as connection id. Jouni > > > Regards > > Xiangsong > > > ----- Original Message ----- From: "jouni korhonen" = > > To: "cuixiangsong 00111037" > Cc: ; > Sent: Monday, August 03, 2009 3:00 PM > Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-=20 > connid-00 > > > > Hi Xiangsong, > > On Aug 2, 2009, at 5:08 AM, cuixiangsong 00111037 wrote: > > [snip] > >> >> Now let's consider how can we use GRE key to achieve this =20 >> requirement. > > I already said that uplink key could be an usable connection id as a > *value*, if other conditions match. > >> >> I assume the MAG and the LMA both support GRE key option and >> connection feature. > > Point one, we don't want to mandate GRE keys.. even if those in > practice would be there. =46rom draft-wolfner-* point of view, GRE = keys > are/can be "lower layer" information. However, specifically saying the > connection id is *the* GRE key, is not what we want. There is > absolutely no need to bind this draft to grekey-draft. > >> >> Firstly, when MAG sends PBU message to LMA, the MAG creats a down >> link GRE key and maps the down link GRE key to the connection >> originated from MN. The MAG includes the GRE key option in the PBU >> as specified in grekey-draft, and also includes a Service Selection >> Mobility Option as speified in RFC5149. > > As said, a PBU can only have the downlink key as per grekey-draft and > downlink key as-is is not enough. > >> >> Secondly, when the LMA receives the PBU message from the MAG, >> the LMA deals the message and the options as specified in existing >> documents. After the LMA creats BCE and a uplink GRE key, the LMA >> caches the MN-id, Service Selection, downlink GRE key and uplink >> GRE key in the BCE and also associates both the downlink GRE key >> and the uplink GRE key with the PDN connection. The LMA responds >> PBA message to the MAG, with the uplink GRE key option included. > > As said, for signaling uplink GRE key in a PBU you would need > something beyond grekey-draft. > > >> >> Thirdly, when the MAG receives the PBA from the LMA, the MAG caches >> the uplink GRE key and associates both the downlink GRE key and >> uplink GRE key with the connection to MN. The MN also knows well >> the MN id and the Service Selection. > > See above. > > [snip] > > >> That means, both the LMA and the MAG can use the GRE keys included in >> the GRE header to identify the data packet, or identify the =20 >> traffic flow. >> >> So, the connection is iedntified by the combination of "MN id + =20 >> GRE key >> + Service Selection(i.e. APN)". In fact, the connection is =20 >> fractionized, >> the direction from LMA to MAG is identified by "MN id + downlink =20 >> GRE key >> + APN" while the direction from MAG to LMA is identified by "MN id + >> uplink GRE key + APN". Each connection may be identified exactly. >> >> >> As to the handover, grekey-draft says, in section 3.3.2, >> " In this case, the new mobile access gateway may >> either pick a new downlink GRE key or use the downlink GRE key that >> was used by the previous mobile access gateway for the same binding. >> For the new mobile access gateway to know the downlink GRE key used >> by the previous mobile access gateway, it may require transfer of >> context from the previous mobile access gateway to the new mobile >> access gateway during a handoff. Such mechanisms are out-of-scope >> for this specification." >> >> This is for the downlink GRE key, and for the uplink GRE key, the >> grekey draft says: >> >> " If the local mobility anchor successfully processes a handoff- >> triggered Binding Lifetime Extension Proxy Binding Update message >> which contains a GRE key option with a downlink GRE key included, =20= >> the >> local mobility anchor MUST return the same uplink GRE key that was >> exchanged with the previous mobile access gateway for the same >> mobility session in the GRE key option in a successful Proxy Binding >> Acknowledgement." >> >> >> Above all, I think we can use the GRE key option to achieve the >> requirement of "multiple PDN connections to the same APN". >> >> Is it right or usable? > > I think you are still missing the point here. You would still need a > new option in a PBU, and document the behavior in the LMA and the MAG, > even if the GRE uplink key were used as the connection id value. This > is what draft-wolfner is aiming to.. > > Cheers, > Jouni > > > >> >> >> Regards >> >> Xiangsong >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> ----- =D4=AD=D3=CA=BC=FE ----- >> =B7=A2=BC=FE=C8=CB: jouni korhonen >> =C8=D5=C6=DA: =D0=C7=C6=DA=CE=E5, =C6=DF=D4=C2 31=C8=D5, 2009 = =CF=C2=CE=E79:39 >> =D6=F7=CC=E2: Re: [netext] Comments on I-D: = draft-wolfner-netext-pmip6- =20 >> connid-00 >> =CA=D5=BC=FE=C8=CB: Xiangsong Cui >> =B3=AD=CB=CD: netext@ietf.org, Basavaraj.Patil@nokia.com >> >>> >>> >>> Lets first resolve whether the GRE keys are usable in the first >>> place. >>> Then we can return to the rest of the discussion. Some more stuff >>> inline. >>> >>> On Jul 31, 2009, at 1:00 PM, Xiangsong Cui wrote: >>> >>>> Hi Jouni, >>>> Please see inline. >>>> >>>> Regards/Xiangsong >>>> >>>> >>>> ----- Original Message ----- From: "jouni korhonen" >>> >>>> >>>> To: "Xiangsong Cui" >>>> Cc: ; >>>> Sent: Friday, July 31, 2009 5:16 PM >>>> Subject: Re: [netext] Comments on I-D: draft-wolfner-netext- >>> pmip6- >>>> connid-00 >>>> >>>> >>>>> Hi, >>>>> On Jul 31, 2009, at 7:11 AM, Xiangsong Cui wrote: >>>>>> Hi Jouni, >>>>>> >>>>>> Thank you for your response. >>>>>> >>>>>>> There are few reasons. First, which GRE key to use? Uplink or >>> >>>>>>> downlink? >>>>>> I think Uplink and downlink may be used to identify the =20 >>>>>> connection >>>>> Uh.. so you would use combination of both keys simultaneously? >>>> >>>> Yes, I think GRE Key is designed for this manner. >>> >>> I am a bit confused. Do you mean using 64-bit identifier made of >>> both >>> uplink & downlink GRE keys? >>> >>> Anyway, downlink GRE keys are no good in general as they may >>> change >>> during handovers. If there is context transfer between MAGs it >>> still >>> does not solve the downlink key issue. One would need to start >>> coordinating downlink key space between MAGs, which is a new >>> requirement. >>> >>> The Uplink GRE key would be an usable connection Id, assuming MAGs >>> can >>> do a context transfer, the exception mentioned in Section 3.3.2 of >>> >>> draft-ietf-netlmm-grekey-option does not happen and that GRE is >>> used >>> in the first place. However, the GRE key option in a PBU contains >>> only >>> the downlink key. This means, you need something beyond draft-ietf- >>> >>> netlmm-grekey-option to send the uplink GRE key in the PBU (if the >>> >>> uplink GRE key were used as the connection Id). >>> >>> [snap] >>> >>>>>>> >>>>>>> Second, the use of GRE keys and GRE tunneling is optional in >>> >>>>>>> PMIP6. Well, so is Service Selection too but I would avoid >>>>>>> building additional dependencies between different documents >>> if >>>>>>> just possible. >>>>>> Yes, GRE Key is an optional option. I think an optional option >>> is >>>>>> used >>>>>> for a optional feature is reasonable >>>>> The less the better. I.e. if I can choose between two optional >>> >>>>> features versus three optional features, I would go for two. >>>>>> >>>>>>> >>>>>>> Third, overloading the function of the GRE key option does >>> not >>>>>>> sound a good idea in general, even if it were possible. >>>>>> If it works well, why not take it as the solution? >>>>> Overloading existing semantics is always a bad practice. >>>> Yes, I agree it is a trouble. >>>> But if the overloading is in the acceptable scope, IMO, we need >>>> balance the impact of overloading and introducing a new expansion. >>>> It is the motivation behind my original question. >>> >>> You would still need a document that describes how the GRE keys >>> are >>> used to extend the BCE lookup, how they are used with RFC5149, and >>> how >>> to indicate to the LMA that the GRE keys are used in this special >>> overloaded way etc. If you go down this road, what is the benefit >>> of >>> it over defining a new option specifically made for connection >>> identifier purpose? At the end, the connection identifier content >>> can >>> be anything that is a stable identifier within the system where >>> this >>> extension is being used.. be that a GRE key or not. >>> >>> Cheers, >>> Jouni >>> >>> >>>> >>>>> I'll skip the rest as I don't see how they relate to this >>> discussion.>> Cheers, >>>>> Jouni >>>> [snip] >>>> >>> >>> >>>> >>> >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >>> >> > From Xiangsong.Cui@huawei.com Mon Aug 3 02:55:15 2009 Return-Path: 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 5F7AD3A6D59 for ; Mon, 3 Aug 2009 02:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.704 X-Spam-Level: X-Spam-Status: No, score=0.704 tagged_above=-999 required=5 tests=[AWL=-1.590, BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, 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 qOdLZ591xTob for ; Mon, 3 Aug 2009 02:55:14 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id AB3C428C106 for ; Mon, 3 Aug 2009 02:55:13 -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 <0KNS00MGXOVTYQ@szxga03-in.huawei.com> for netext@ietf.org; Mon, 03 Aug 2009 17:55:05 +0800 (CST) Received: from c00111037 ([10.111.16.64]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KNS004ZXOVS6J@szxga03-in.huawei.com> for netext@ietf.org; Mon, 03 Aug 2009 17:55:05 +0800 (CST) Date: Mon, 03 Aug 2009 17:55:05 +0800 From: Xiangsong Cui To: jouni korhonen Message-id: <013f01ca1420$7a30d4d0$40106f0a@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; format=flowed; charset=gb2312; reply-type=response Content-transfer-encoding: 8BIT X-Priority: 3 X-MSMail-priority: Normal References: <018b01ca10fc$396761c0$40106f0a@china.huawei.com> <00e501ca1194$f20d4b70$40106f0a@china.huawei.com> <63E93F6E-5066-4DF9-B634-ECAED67E322F@gmail.com> <017b01ca11c5$bd5defc0$40106f0a@china.huawei.com> <439F112A-84B0-4ADF-B643-097A1B647BC8@gmail.com> <010b01ca140d$6f25a970$40106f0a@china.huawei.com> <2796F141-85B7-433E-A088-BE0E478F49EF@gmail.com> Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 09:55:15 -0000 Hi jouni, Please see inline. Regards/Xiangsong ----- Original Message ----- From: "jouni korhonen" To: "Xiangsong Cui" Cc: ; Sent: Monday, August 03, 2009 4:47 PM Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00 On Aug 3, 2009, at 10:38 AM, Xiangsong Cui wrote: > Hi Jouni, > >> As said, a PBU can only have the downlink key as per grekey-draft and >> downlink key as-is is not enough. > [...snip...] >> As said, for signaling uplink GRE key in a PBU you would need something >> beyond grekey-draft. > > Why do you exclude PBA message? In grekey-draft scope because, the LMA needs to know the connection id already when receiving the PBU. The MAG needs to include a connection id in the PBU. Downlink key is not really good for this purpose. [Xiangsong] Where do you get the requirement of "know the connection id already when receiving the PBU"? Is it base on your solution? In my understanding, the requirement should be "can identify the connection among multiple PDN connections" and GRE key option can meet the requirement well. > The MAG and the LMA can learn both the downlink key and the uplink key > by PBU/PBA exchange. > > > >> I think you are still missing the point here. You would still need a >> new option in a PBU, and document the behavior in the LMA and the MAG, >> even if the GRE uplink key were used as the connection id value. This >> is what draft-wolfner is aiming to.. > > I don't think so. > > As I said in the previous mail, GRE key option can already meet the > protocol requirement, we don't need any more option for this feature. > > As to the behavior in the MAG and the LMA, it is mainly about the > mapping management, I don't think it is in the protocol scope. You impact BCE lookup. That is one main reason why to bring this stuff to IETF in the first place. If it were completely protocol agnostic, we would have kept it inside 3GPP. [Xiangsong] Comparing to simple PMIP, the GRE key option do impact BCE lookup, but if the LMA support GRE key option, all work well, what is the trouble? Your connection id option do also impact BCE lookup, they are same essentially. > I also think you would agree me on this point, because in the draft > "draft-wolfner-netext-pmip6-connid-00.txt", it says: > > " How the MAG maps connections originated from the > MN to connection identifiers is out of scope of this specification." And? I don't see the point as I wrote that text in the draft ;) I should probably clarify that the quoted text means mapping of e.g. some radio level "bearer" to some identity value used as connection id. [Xiangsong] This more and more like a game. In general, do you mean when we have already had a RFC, which says "GRE keys can be used for marking the downlink and uplink traffic ", we additionally need another document, which says "define a new option to be used for identifying conncetion" ? Xiangsong Jouni > > > Regards > > Xiangsong > > > ----- Original Message ----- From: "jouni korhonen" > > > To: "cuixiangsong 00111037" > Cc: ; > Sent: Monday, August 03, 2009 3:00 PM > Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6- > connid-00 > > > > Hi Xiangsong, > > On Aug 2, 2009, at 5:08 AM, cuixiangsong 00111037 wrote: > > [snip] > >> >> Now let's consider how can we use GRE key to achieve this requirement. > > I already said that uplink key could be an usable connection id as a > *value*, if other conditions match. > >> >> I assume the MAG and the LMA both support GRE key option and >> connection feature. > > Point one, we don't want to mandate GRE keys.. even if those in > practice would be there. From draft-wolfner-* point of view, GRE keys > are/can be "lower layer" information. However, specifically saying the > connection id is *the* GRE key, is not what we want. There is > absolutely no need to bind this draft to grekey-draft. > >> >> Firstly, when MAG sends PBU message to LMA, the MAG creats a down >> link GRE key and maps the down link GRE key to the connection >> originated from MN. The MAG includes the GRE key option in the PBU >> as specified in grekey-draft, and also includes a Service Selection >> Mobility Option as speified in RFC5149. > > As said, a PBU can only have the downlink key as per grekey-draft and > downlink key as-is is not enough. > >> >> Secondly, when the LMA receives the PBU message from the MAG, >> the LMA deals the message and the options as specified in existing >> documents. After the LMA creats BCE and a uplink GRE key, the LMA >> caches the MN-id, Service Selection, downlink GRE key and uplink >> GRE key in the BCE and also associates both the downlink GRE key >> and the uplink GRE key with the PDN connection. The LMA responds >> PBA message to the MAG, with the uplink GRE key option included. > > As said, for signaling uplink GRE key in a PBU you would need > something beyond grekey-draft. > > >> >> Thirdly, when the MAG receives the PBA from the LMA, the MAG caches >> the uplink GRE key and associates both the downlink GRE key and >> uplink GRE key with the connection to MN. The MN also knows well >> the MN id and the Service Selection. > > See above. > > [snip] > > >> That means, both the LMA and the MAG can use the GRE keys included in >> the GRE header to identify the data packet, or identify the traffic >> flow. >> >> So, the connection is iedntified by the combination of "MN id + GRE key >> + Service Selection(i.e. APN)". In fact, the connection is >> fractionized, >> the direction from LMA to MAG is identified by "MN id + downlink GRE >> key >> + APN" while the direction from MAG to LMA is identified by "MN id + >> uplink GRE key + APN". Each connection may be identified exactly. >> >> >> As to the handover, grekey-draft says, in section 3.3.2, >> " In this case, the new mobile access gateway may >> either pick a new downlink GRE key or use the downlink GRE key that >> was used by the previous mobile access gateway for the same binding. >> For the new mobile access gateway to know the downlink GRE key used >> by the previous mobile access gateway, it may require transfer of >> context from the previous mobile access gateway to the new mobile >> access gateway during a handoff. Such mechanisms are out-of-scope >> for this specification." >> >> This is for the downlink GRE key, and for the uplink GRE key, the >> grekey draft says: >> >> " If the local mobility anchor successfully processes a handoff- >> triggered Binding Lifetime Extension Proxy Binding Update message >> which contains a GRE key option with a downlink GRE key included, the >> local mobility anchor MUST return the same uplink GRE key that was >> exchanged with the previous mobile access gateway for the same >> mobility session in the GRE key option in a successful Proxy Binding >> Acknowledgement." >> >> >> Above all, I think we can use the GRE key option to achieve the >> requirement of "multiple PDN connections to the same APN". >> >> Is it right or usable? > > I think you are still missing the point here. You would still need a > new option in a PBU, and document the behavior in the LMA and the MAG, > even if the GRE uplink key were used as the connection id value. This > is what draft-wolfner is aiming to.. > > Cheers, > Jouni > > > >> >> >> Regards >> >> Xiangsong >> >> =============================================================== >> ----- Ô­Óʼþ ----- >> ·¢¼þÈË: jouni korhonen >> ÈÕÆÚ: ÐÇÆÚÎå, ÆßÔ 31ÈÕ, 2009 ÏÂÎç9:39 >> Ö÷Ìâ: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6- >> connid-00 >> ÊÕ¼þÈË: Xiangsong Cui >> ³­ËÍ: netext@ietf.org, Basavaraj.Patil@nokia.com >> >>> >>> >>> Lets first resolve whether the GRE keys are usable in the first >>> place. >>> Then we can return to the rest of the discussion. Some more stuff >>> inline. >>> >>> On Jul 31, 2009, at 1:00 PM, Xiangsong Cui wrote: >>> >>>> Hi Jouni, >>>> Please see inline. >>>> >>>> Regards/Xiangsong >>>> >>>> >>>> ----- Original Message ----- From: "jouni korhonen" >>> >>>> >>>> To: "Xiangsong Cui" >>>> Cc: ; >>>> Sent: Friday, July 31, 2009 5:16 PM >>>> Subject: Re: [netext] Comments on I-D: draft-wolfner-netext- >>> pmip6- >>>> connid-00 >>>> >>>> >>>>> Hi, >>>>> On Jul 31, 2009, at 7:11 AM, Xiangsong Cui wrote: >>>>>> Hi Jouni, >>>>>> >>>>>> Thank you for your response. >>>>>> >>>>>>> There are few reasons. First, which GRE key to use? Uplink or >>> >>>>>>> downlink? >>>>>> I think Uplink and downlink may be used to identify the connection >>>>> Uh.. so you would use combination of both keys simultaneously? >>>> >>>> Yes, I think GRE Key is designed for this manner. >>> >>> I am a bit confused. Do you mean using 64-bit identifier made of >>> both >>> uplink & downlink GRE keys? >>> >>> Anyway, downlink GRE keys are no good in general as they may >>> change >>> during handovers. If there is context transfer between MAGs it >>> still >>> does not solve the downlink key issue. One would need to start >>> coordinating downlink key space between MAGs, which is a new >>> requirement. >>> >>> The Uplink GRE key would be an usable connection Id, assuming MAGs >>> can >>> do a context transfer, the exception mentioned in Section 3.3.2 of >>> >>> draft-ietf-netlmm-grekey-option does not happen and that GRE is >>> used >>> in the first place. However, the GRE key option in a PBU contains >>> only >>> the downlink key. This means, you need something beyond draft-ietf- >>> >>> netlmm-grekey-option to send the uplink GRE key in the PBU (if the >>> >>> uplink GRE key were used as the connection Id). >>> >>> [snap] >>> >>>>>>> >>>>>>> Second, the use of GRE keys and GRE tunneling is optional in >>> >>>>>>> PMIP6. Well, so is Service Selection too but I would avoid >>>>>>> building additional dependencies between different documents >>> if >>>>>>> just possible. >>>>>> Yes, GRE Key is an optional option. I think an optional option >>> is >>>>>> used >>>>>> for a optional feature is reasonable >>>>> The less the better. I.e. if I can choose between two optional >>> >>>>> features versus three optional features, I would go for two. >>>>>> >>>>>>> >>>>>>> Third, overloading the function of the GRE key option does >>> not >>>>>>> sound a good idea in general, even if it were possible. >>>>>> If it works well, why not take it as the solution? >>>>> Overloading existing semantics is always a bad practice. >>>> Yes, I agree it is a trouble. >>>> But if the overloading is in the acceptable scope, IMO, we need >>>> balance the impact of overloading and introducing a new expansion. >>>> It is the motivation behind my original question. >>> >>> You would still need a document that describes how the GRE keys >>> are >>> used to extend the BCE lookup, how they are used with RFC5149, and >>> how >>> to indicate to the LMA that the GRE keys are used in this special >>> overloaded way etc. If you go down this road, what is the benefit >>> of >>> it over defining a new option specifically made for connection >>> identifier purpose? At the end, the connection identifier content >>> can >>> be anything that is a stable identifier within the system where >>> this >>> extension is being used.. be that a GRE key or not. >>> >>> Cheers, >>> Jouni >>> >>> >>>> >>>>> I'll skip the rest as I don't see how they relate to this >>> discussion.>> Cheers, >>>>> Jouni >>>> [snip] >>>> >>> >>> >>>> >>> >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >>> >> > From sunseawq@huawei.com Mon Aug 3 03:14:06 2009 Return-Path: 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 70CC528C157 for ; Mon, 3 Aug 2009 03:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.858 X-Spam-Level: * X-Spam-Status: No, score=1.858 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_22=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 Qh1VeSvuXGDK for ; Mon, 3 Aug 2009 03:14:05 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 9EF5028C154 for ; Mon, 3 Aug 2009 03:13:48 -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 <0KNS006GXPPI1Z@szxga03-in.huawei.com> for netext@ietf.org; Mon, 03 Aug 2009 18:12:55 +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 <0KNS004O7PPI6J@szxga03-in.huawei.com> for netext@ietf.org; Mon, 03 Aug 2009 18:12:54 +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 <0KNS000FAPPH79@szxml04-in.huawei.com> for netext@ietf.org; Mon, 03 Aug 2009 18:12:54 +0800 (CST) Date: Mon, 03 Aug 2009 18:12:55 +0800 From: Qin Wu To: Alper Yegin , 'Desire Oulai' , netext@ietf.org Message-id: <01fa01ca1422$f81b1b10$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: <060f01ca110d$903ca120$b0b5e360$%yegin@yegin.org> <063901ca111a$01ce9c60$056bd520$%yegin@yegin.org> Cc: basavaraj.Patil@nokia.com 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 10:14:06 -0000 SGksIGZvbGtzOg0KDQpJdCBzZWVtcyB0byBtZSB0aGVyZSBhcmUgc29tZSBjb25mdXNpb24gb3Ig bWlzdW5kZXJzdGFuZGluZ3Mgd2l0aCB0aGUgc2NvcGUgb2Ygb25lIFBNSVA2IGRvbWFpbi4NClRo ZSBjb25mdXNpb24gY29tZXMgZnJvbSBob3cgdG8gdW5kZXJzdGFuZCBlbmFibGluZyBsb2NhbGl6 ZWQgcm91dGluZyB3aXRoaW4gb25lIFBNSVA2IGRvbWFpbg0KYW5kIGhvdyB0byBkaXN0aW5ndWlz aCBQTUlQNiBkb21haW4gZnJvbSBhZG1pbmlzdHJhdGlvbiBkb21haW4gb3duZWQgYnkgb25lIG9w ZXJhdG9yLg0KSW4gb3JkZXIgdG8gcHJvY2VlZCB0aGlzIGRpc2N1c3Npb24sIEkgd291bGQgbGlr ZSB0byBnaXZlIHNldmVyYWwgdXNlIGNhc2VzIHdoZXJlIHdlIGFzc3VtZSBNTiBhbmQgQ04gYXR0 YWNoZXMgdG8gdGhlIGRpZmZlcmVudCBNQUdzKGkuZS4sIE1BRzEgYW5kIE1BRzIpIGFuZCBhbmNo b3JlZCB0byB0aGUgZGlmZmVyZW50IExNQShpLmUuLExNQTEgYW5kIExNQTIpLg0KDQpVc2UgY2Fz ZSBBOiAgDQpTdXBwb3NlIE1BRzEsIE1BRzIgYW5kIExNQTEsTE1BMiBiZWxvbmcgdGhlIHNhbWUg b3BlcmF0b3IgQSB3aXRoaW4gb25lIGFkbWluaXN0cmF0aW9uIGRvbWFpbi4NCg0KVXNlIGNhc2Ug QjogIA0KU3VwcG9zZSBNQUcxIE1BRzIgYW5kIExNQTEgYmVsb25nIHRvIHRoZSBvcGVyYXRvciBB IHdpdGhpbiB0aGUgc2FtZSBhZG1pbmlzdHJhdGlvbmRvbWFpbiB3aGlsZSB0aGUgTE1BMiBibG9u Z3MgdG8gYW5vdGhlciBhZG1pbmlzdHJhdGlvbmRvbWFpbiBvd25lZCBieSB0aGUgb3BlcmF0b3Ig Qw0KDQpVc2UgY2FzZSBDOiANClN1cHBvc2UgTUFHMSxNQUcyIGJlbG9uZyB0byB0aGUgb3BlYXRv ciBBIHdpdGhpbiB0aGUgc2FtZSBhZG1pbmlzdHJhdGlvbiBkb21haW4sIExNQTEgYmVsb25ncyB0 byBhbm90aGVyIGFkbWluaXN0cmF0aW9uZG9tYWluIG93bmVkIGJ5IHRoZSBvcGVyYXRvciBCLCBM TUEyIGJlbG9uZyB0byBhbm90aGVyIGFkbWluaXN0cmF0aW9uIGRvbWFpbiBvd25lZCBieSB0aGUg b3BlcmF0b3IgQy4NCg0KVXNlIGNhc2UgRDogDQpTdXBwb3NlIE1BRzEsIExNQTEsIExNQTIgYmVs b25nIHRvIHRoZSBvcGVyYXRvciBBIHdpdGhpbiB0aGUgc2FtZSBhZG1pbnN0cmF0aW9uIGRvbWFp biB3aGlsZSB0aGUgTUFHMiBiZWxvbmcgdG8gYW5vdGhlciBhZG1pbmlzdHJhdGlvbmRvbWFpbiBv d25lZCBieSB0aGUgb3BlcmF0b3IgQg0KDQpVc2UgY2FzZSBFOiANClN1cHBvc2UgTUFHMSwgTE1B MSBiZWxvbmcgdG8gb25lIGFkbWluaXN0cmF0aW9uZG9tYWluIG93bmVkIGJ5IG9wZXJhdG9yIEEg d2hpbGUgdGhlIExNQTIgYW5kIE1BRzIgYmVsb25nIHRvIGFub3RoZXIgYWRtaW5pc3RyYXRpb25k b21haW4gb3duZWQgYnkgdGhlIG9wZXJhdG9yIEINCg0KSW4gYWxsIHRoZSB1c2UgY2FzZXMgbWVu dGlvbmVkIGFib3ZlLCBJIHdvbmRlciB3aGljaCB1c2UgY2FzZSBzaG91bGQgYmUgdGFrZW4gYXMg TG9jYWxpemVkIHJvdXRpbmcgY2FzZSB3aXRoaW4gb25lIFBNSVA2IGRvbWFpbj8gSW4gbXkgdW5k ZXJzdGFuZGluZywgdGhlIFVzZSBjYXNlIEEsQixDIGNhbiBiZSBjb25zaWRlcmVkIGluIHRoZSBz Y29wZSBvZiBsb2NhbGl6ZWQgcm91dGluZyB3aXRoaW4gUE1JUDYgZG9tYWluLiBBbnkgb3Bpbmlv biBhYm91dCB0aGlzPw0KDQpBcyByZWdhcmRpbmcgdGhlIHVuZGVyc3RhbmRpbmcgdGhlIHJvYW1p bmcsIHJvYW1pbmcgYmV0d2VlbiBvcGVyYXRvcnMgaXMgcXVpdGUgZGlmZmVyZW50IGZyb20gcm9h bWluZyBiZXR3ZWVuIGRpZmZlcmVudCBQTUlQNiBkb21haW5zLiBJbiB0aGUgc2NvcGUgb2YgbG9j YWxpemVkIHJvdXRpbmcsICBJIHRoaW5rIHdlIGNhbiBjb25zaWRlciB3aGV0aGVyIHJvYW1pbmcg YmV0d2VlbiBvcGVyYXRvcnMgc2hvdWxkIGJlIHN1cHBvcnRlZCBpbiB0aGUgc2NvcGUgb2YgbG9j YWxpemVkIHJvdXRpbmcsIE15IGFuc3dlciBpcyB5ZXMsIGl0IGNvdWxkIGJlLg0KZS5nLiwgaW4g c29tZSBzY2VuYXJpbywNCnN1cHBvc2UgdGhlIG1vYmlsZSBzdXBwb3J0cyByb2FtaW5nIGJldHdl ZW4gZGlmZmVyZW50IG9wZXJhdG9ycywgTU4gYW5kIENOIG9yIG9ubHkgTU4gbWF5IG1vdmUgdG8g dGhlIG9uZSBQTUlQNiBkb21haW4sIGluIHRoaXMgcG1pcDYgZG9tYWluLCBNTixDTiBhbmQgTU4n cyBNQUcgLCBDTidzIE1BRyBhcmUgbG9jYXRlZCBpbiB0aGUgc2FtZSBkb21haW4sIGhvd2V2ZXIg TU4ncyBMTUEgb3IgQ04ncyBMTUEgaXMgbm90IGluIHRoaXMgZG9tYWluLCBJbiB0aGlzIGNhc2Us IGlmIGxvY2FsaXplZCByb3V0aW5nIGJldHdlZW4NCk1OJ3MgTUFHIGFuZCBDTidzIE1BRyBpcyBh bGxvd2VkLCBpdCBjYW4gZ3JlYXRseSBzYXZlIHRyYWZmaWMgYXMgQWxwZXIncyBzYWlkIGluIHRo ZSBwcmV2aW91cyBtYWlsLg0KDQpBbnkgb3BpbmlvbiBhbmQgY29tbWVudHM/DQoNClJlZ2FyZHMh DQotUWluDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkFscGVyIFllZ2lu IiA8YWxwZXIueWVnaW5AeWVnaW4ub3JnPg0KVG86ICInRGVzaXJlIE91bGFpJyIgPGRlc2lyZS5v dWxhaUBlcmljc3Nvbi5jb20+OyA8bmV0ZXh0QGlldGYub3JnPg0KU2VudDogVGh1cnNkYXksIEp1 bHkgMzAsIDIwMDkgOTozMSBQTQ0KU3ViamVjdDogUmU6IFtuZXRleHRdIFBNSVA2IGFuZCByb2Ft aW5nDQoNCg0KSGkgRGVzaXJlLA0KDQpSRkMgNTIxMzoNCg0KICAgUHJveHkgTW9iaWxlIElQdjYg RG9tYWluIChQTUlQdjYtRG9tYWluKQ0KDQogICAgICBQcm94eSBNb2JpbGUgSVB2NiBkb21haW4g cmVmZXJzIHRvIHRoZSBuZXR3b3JrIHdoZXJlIHRoZSBtb2JpbGl0eQ0KICAgICAgbWFuYWdlbWVu dCBvZiBhIG1vYmlsZSBub2RlIGlzIGhhbmRsZWQgdXNpbmcgdGhlIFByb3h5IE1vYmlsZSBJUHY2 DQogICAgICBwcm90b2NvbCBhcyBkZWZpbmVkIGluIHRoaXMgc3BlY2lmaWNhdGlvbi4gIFRoZSBQ cm94eSBNb2JpbGUgSVB2Ng0KICAgICAgZG9tYWluIGluY2x1ZGVzIGxvY2FsIG1vYmlsaXR5IGFu Y2hvcnMgYW5kIG1vYmlsZSBhY2Nlc3MgZ2F0ZXdheXMNCiAgICAgIGJldHdlZW4gd2hpY2ggc2Vj dXJpdHkgYXNzb2NpYXRpb25zIGNhbiBiZSBzZXQgdXAgYW5kDQogICAgICBhdXRob3JpemF0aW9u IGZvciBzZW5kaW5nIFByb3h5IEJpbmRpbmcgVXBkYXRlcyBvbiBiZWhhbGYgb2YgdGhlDQogICAg ICBtb2JpbGUgbm9kZXMgY2FuIGJlIGVuc3VyZWQuDQoNCg0KSSByZW1lbWJlciB0aGlzIHdhcyBz cGVjaWZpY2FsbHkgZGlzY3Vzc2VkIGFuZCB3ZSBoYWQgY29tZSB1cCB3aXRoIGEgdGV4dA0KdGhh dCByZWZlcnMgdG8gImxvY2FsIG1vYmlsaXR5IGFuY2hvcnMgYW5kIG1vYmlsZSBhY2Nlc3MgZ2F0 ZXdheXMgYmV0d2Vlbg0Kd2hpY2ggc2VjdXJpdHkgYXNzb2NpYXRpb25zIGNhbiBiZSBzZXQgdXAi IGFzIHRoZSBsaW1pdGluZyBmYWN0b3IgdGhhdCBzZXRzDQp0aGUgYm91bmRhcnkuIEFuZCBzZWN1 cml0eSBhc3NvY2lhdGlvbnMgY2FuIGJlIHNldHVwIGJldHdlZW4gTUFHcyBhbmQgTE1Bcw0KYmVs b25naW5nIHRvIHNlcGFyYXRlIG9wZXJhdG9ycyB3aGVuIHRoZXJlIGlzIGEgcm9hbWluZyBhZ3Jl ZW1lbnQuIFdpTUFYDQphcmNoaXRlY3R1cmUgYWxyZWFkeSBkb2VzIHRoYXQuDQoNCkFscGVyDQoN Cg0KDQoNCg0KDQoNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IERl c2lyZSBPdWxhaSBbbWFpbHRvOmRlc2lyZS5vdWxhaUBlcmljc3Nvbi5jb21dDQo+IFNlbnQ6IFRo dXJzZGF5LCBKdWx5IDMwLCAyMDA5IDQ6MTMgUE0NCj4gVG86IEFscGVyIFllZ2luOyBuZXRleHRA aWV0Zi5vcmcNCj4gU3ViamVjdDogUkUgOiBbbmV0ZXh0XSBQTUlQNiBhbmQgcm9hbWluZw0KPiAN Cj4gSGkgQWxwZXIsDQo+IA0KPiAgIFNlZSBpbmxpbmUhDQo+IA0KPiBEZXNpcmUNCj4gDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IA0KPiBEZTogbmV0ZXh0LWJvdW5jZXNA aWV0Zi5vcmcgZGUgbGEgcGFydCBkZSBBbHBlciBZZWdpbg0KPiBEYXRlOiBqZXUuIDIwMDktMDct MzAgMDg6MDINCj4gwDogbmV0ZXh0QGlldGYub3JnDQo+IE9iamV0IDogW25ldGV4dF0gUE1JUDYg YW5kIHJvYW1pbmcNCj4gDQo+IA0KPiANCj4gDQo+IA0KPiBDb250aW51aW5nIHRoZSBkaXNjdXNz aW9uIG9uIHRoZSBNTC4uLi4uLg0KPiANCj4gDQo+IA0KPiANCj4gDQo+IENvbnNpZGVyIG1vYmls ZTEgYW5kIG1vYmlsZTIgc3Vic2NyaWJlZCB0byBkYXRhIHNlcnZpY2UgaW4gVVNBLg0KPiANCj4g VGhleSBhcmUgaW4gU3dlZGVuLCBhY2Nlc3NpbmcgSW50ZXJuZXQgYnkgInJvYW1pbmciIHRvIGEg U3dlZGlzaA0KPiBvcGVyYXRvciBuZXR3b3JrLg0KPiANCj4gDQo+IA0KPiBEb2VzIFBNSVA2IG5v dCBzdXBwb3J0IHRoaXMgY2FzZSB3aGVyZSBNQUcgaXMgaW4gU3dlZGlzaCBvcGVyYXRvcg0KPiBu ZXR3b3JrLCBhbmQgTE1BIGluIFVTQSBvcGVyYXRvcidzIG5ldHdvcms/IEkgdGhpbmsgdGhlIGFu c3dlciBpcyB5ZXMuDQo+IA0KPiBbRGVzaXJlXTogICBJIHRoaW5rIFBNSVA2IGFzIGRlZmluZWQg aW4gUkZDNTIxMyBkb2VzIG5vdCBzdXBwb3J0IHRoaXMNCj4gc2NlbmFyaW8gYXMgdGhlIE1BRyBh cmUgbm90IGluIHRoZSBzYW1lIFBNSVAgZG9tYWluLiBIb3dldmVyLCBTRE9zIGxpa2UNCj4gM0dQ UCBzdXBwb3J0cyBob21lIHR1bm5lbGxpbmcuDQo+IA0KPiANCj4gDQo+IFdvdWxkbid0IHdlIHdh bnQgdG8gb3B0aW1pemUgdGhlIHBhdGggYmV0d2VlbiBtb2JpbGUxIGFuZCBtb2JpbGUyIHRvDQo+ IHNhdmUgdGhlIHRyYWZmaWMgZnJvbSBtYWtpbmcgdGhlIHVubmVjZXNzYXJ5IFVTQSB0cmlwPyBJ IHRoaW5rIHRoZQ0KPiBhbnN3ZXIgaXMgeWVzIGFnYWluLg0KPiANCj4gW0Rlc2lyZV06IEkgYWdy ZWUgdGhhdCBpdCBpcyBhbiBpbnRlcmVzdGluZyBvcHRpbWl6YXRpb24uIEJ1dCB3ZSBuZWVkDQo+ IGZpcnN0IHRvIGNsYXJpZnkgdGhlIHJlbGF0aW9uIGJldHdlZW4gdGhlIE1BRyBpbiBzd2VkZW4g YW5kIHRoZSBMTUEgaW4NCj4gVVNBLiBTbyB3ZSBuZWVkIHRvIHNwZWNpZnkgUE1JUDYgcm9hbWlu ZyBiZWZvcmUgdGFsa2luZyBhYm91dCBMb2NhbGl6ZWQNCj4gcm91dGluZyBpbiBQTUlQNiByb2Ft aW5nLg0KPiANCj4gDQo+IA0KPiBDb21tZW50cz8NCj4gDQo+IA0KPiANCj4gQWxwZXINCj4gDQo+ IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRleHQgbWFp bGluZyBsaXN0DQpuZXRleHRAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbmV0ZXh0 From desire.oulai@ericsson.com Mon Aug 3 06:36:08 2009 Return-Path: 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 5A3EF28C18B for ; Mon, 3 Aug 2009 06:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 PxFqJw8EOIuT for ; Mon, 3 Aug 2009 06:36:07 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 659C63A6A32 for ; Mon, 3 Aug 2009 06:36:07 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n73Da63N003112; Mon, 3 Aug 2009 08:36:08 -0500 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 08:36:08 -0500 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: Mon, 3 Aug 2009 09:36:07 -0400 Message-ID: In-Reply-To: <063901ca111a$01ce9c60$056bd520$@yegin@yegin.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] PMIP6 and roaming Thread-Index: AcoRDY3vYI+oJ9LbQhuRXYYW4CQ2tgACGU1JAADpwjAAyWURUA== References: <060f01ca110d$903ca120$b0b5e360$@yegin@yegin.org> <063901ca111a$01ce9c60$056bd520$@yegin@yegin.org> From: "Desire Oulai" To: "Alper Yegin" , X-OriginalArrivalTime: 03 Aug 2009 13:36:08.0146 (UTC) FILETIME=[5B57DB20:01CA143F] 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 13:36:08 -0000 Hi Alper, Thanks for the pointer. In this case, the scenario you mentionned seems = valid to me and should be considered. Regards=20 > -----Original Message----- > From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 > Sent: July 30, 2009 9:31 AM > To: Desire Oulai; netext@ietf.org > Subject: RE: [netext] PMIP6 and roaming >=20 > Hi Desire, >=20 > RFC 5213: >=20 > Proxy Mobile IPv6 Domain (PMIPv6-Domain) >=20 > Proxy Mobile IPv6 domain refers to the network where=20 > the mobility > management of a mobile node is handled using the Proxy=20 > Mobile IPv6 > protocol as defined in this specification. The Proxy=20 > Mobile IPv6 > domain includes local mobility anchors and mobile=20 > 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. >=20 >=20 > I remember this was specifically discussed and we had come up=20 > with a text that refers to "local mobility anchors and mobile=20 > access gateways between which security associations can be=20 > set up" as the limiting factor that sets the boundary. And=20 > security associations can be setup between MAGs and LMAs=20 > belonging to separate operators when there is a roaming=20 > agreement. WiMAX architecture already does that. >=20 > Alper >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > > -----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=A0: [netext] PMIP6 and roaming > >=20 > > Hi Alper, > >=20 > > See inline! > >=20 > > Desire > >=20 > > ________________________________ > >=20 > > De: netext-bounces@ietf.org de la part de Alper Yegin > > Date: jeu. 2009-07-30 08:02 > > =C0: netext@ietf.org > > Objet : [netext] PMIP6 and roaming > >=20 > >=20 > >=20 > >=20 > >=20 > > Continuing the discussion on the ML...... > >=20 > >=20 > >=20 > >=20 > >=20 > > Consider mobile1 and mobile2 subscribed to data service in USA. > >=20 > > They are in Sweden, accessing Internet by "roaming" to a Swedish=20 > > operator network. > >=20 > >=20 > >=20 > > Does PMIP6 not support this case where MAG is in Swedish operator=20 > > network, and LMA in USA operator's network? I think the=20 > answer is yes. > >=20 > > [Desire]: I think PMIP6 as defined in RFC5213 does not=20 > support this > > scenario as the MAG are not in the same PMIP domain. However, SDOs=20 > > like 3GPP supports home tunnelling. > >=20 > >=20 > >=20 > > Wouldn't we want to optimize the path between mobile1 and=20 > mobile2 to=20 > > save the traffic from making the unnecessary USA trip? I think the=20 > > answer is yes again. > >=20 > > [Desire]: I agree that it is an interesting optimization.=20 > But we need=20 > > first to clarify the relation between the MAG in sweden and=20 > the LMA in=20 > > USA. So we need to specify PMIP6 roaming before talking about=20 > > Localized routing in PMIP6 roaming. > >=20 > >=20 > >=20 > > Comments? > >=20 > >=20 > >=20 > > Alper > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 >=20 >=20 >=20 From Marco.Liebsch@nw.neclab.eu Tue Aug 4 01:27:09 2009 Return-Path: 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 0701E3A6BD1 for ; Tue, 4 Aug 2009 01:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 IV+RCoxBc+uf for ; Tue, 4 Aug 2009 01:27:08 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id C619728C2E5 for ; Tue, 4 Aug 2009 01:27:07 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id EFF3F2C0012C8; Tue, 4 Aug 2009 10:27:07 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+IDLwfd2WPp; Tue, 4 Aug 2009 10:27:07 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id C54D02C0002FE; Tue, 4 Aug 2009 10:26:52 +0200 (CEST) Received: from [127.0.0.1] ([10.1.2.187]) by VENUS.office with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Aug 2009 10:26:53 +0200 Message-ID: <4A77F0CC.4090204@nw.neclab.eu> Date: Tue, 04 Aug 2009 10:26:52 +0200 From: Marco Liebsch User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Alper Yegin References: <060f01ca110d$903ca120$b0b5e360$@yegin@yegin.org> <063901ca111a$01ce9c60$056bd520$@yegin@yegin.org> In-Reply-To: <063901ca111a$01ce9c60$056bd520$@yegin@yegin.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 04 Aug 2009 08:26:53.0092 (UTC) FILETIME=[52150E40:01CA14DD] 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 08:27:09 -0000 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 > From Telemaco.Melia@alcatel-lucent.com Tue Aug 4 01:44:36 2009 Return-Path: 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 E18563A6F97 for ; Tue, 4 Aug 2009 01:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.684 X-Spam-Level: X-Spam-Status: No, score=-5.684 tagged_above=-999 required=5 tests=[AWL=0.565, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] 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 qD6tWYjkLrVK for ; Tue, 4 Aug 2009 01:44:36 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 7F0E028C2F0 for ; Tue, 4 Aug 2009 01:43:59 -0700 (PDT) Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.dc-m.alcatel-lucent.com [155.132.6.75]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n748i0cq031534; Tue, 4 Aug 2009 10:44:00 +0200 Received: from FRVELSMBS14.ad2.ad.alcatel.com ([155.132.6.37]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Aug 2009 10:43:59 +0200 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: Tue, 4 Aug 2009 10:43:59 +0200 Message-ID: <853DD750D9C3724FBF2DF7164FCF641C034AD1BD@FRVELSMBS14.ad2.ad.alcatel.com> In-Reply-To: <4A77F0CC.4090204@nw.neclab.eu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] PMIP6 and roaming Thread-Index: AcoU3WEX9EQss/W3TJeA9aSUFjYnogAAhD9Q References: <060f01ca110d$903ca120$b0b5e360$@yegin@yegin.org> <063901ca111a$01ce9c60$056bd520$@yegin@yegin.org> <4A77F0CC.4090204@nw.neclab.eu> From: "MELIA TELEMACO" To: "Marco Liebsch" , "Alper Yegin" X-OriginalArrivalTime: 04 Aug 2009 08:43:59.0972 (UTC) FILETIME=[B6268240:01CA14DF] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 08:44:37 -0000 I agree on this. telemaco From the discussion we had in Stockholm, I think for deployment=20 perspective it's more important to have both MAGs (mobile 1 and mobile 2) in the same=20 *administrative* domain (to distiguish from a PMIP domain), as inter-MAG operation between=20 administrative domains comprises the knows issues. For the protocol specification:=20 Well, it does not matter.. as long as MAGs share a security association and can set up a=20 forwarding tunnel. [tele] I agree on this. telemaco 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 > > > > > > > > > > =20 >> -----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 >> =C0: 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 >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> =20 > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > =20 _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext From sunseawq@huawei.com Tue Aug 18 05:17:04 2009 Return-Path: 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 99C253A6B92 for ; Tue, 18 Aug 2009 05:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.768 X-Spam-Level: X-Spam-Status: No, score=0.768 tagged_above=-999 required=5 tests=[AWL=-0.490, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 RwmzERdpXcdT for ; Tue, 18 Aug 2009 05:17:03 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 40EFA3A6A43 for ; Tue, 18 Aug 2009 05:17:03 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOK00KTUNE22V@szxga04-in.huawei.com> for netext@ietf.org; Tue, 18 Aug 2009 20:15:38 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOK004A7NE2AJ@szxga04-in.huawei.com> for netext@ietf.org; Tue, 18 Aug 2009 20:15:38 +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 <0KOK00KXYNE1L1@szxml04-in.huawei.com> for netext@ietf.org; Tue, 18 Aug 2009 20:15:38 +0800 (CST) Date: Tue, 18 Aug 2009 20:15:37 +0800 From: Qin Wu To: Marco Liebsch , Alper Yegin Message-id: <037501ca1ffd$98a1d4d0$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: <060f01ca110d$903ca120$b0b5e360$%yegin@yegin.org> <063901ca111a$01ce9c60$056bd520$%yegin@yegin.org> <4A77F0CC.4090204@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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 12:17:04 -0000 SGksIE1hcmNvOg0KIEkgYWdyZWUgdGhlIExvY2FsaXplZCByb3V0aW5nIG1lY2hhbmlzbSBjYW4g YmUgYXBwbGljYWJsZSB0byB0aGUgc2NlbmFyaW8NCiB3aGVyZSB0d28gTUFHcyBpbiBjb21tdW5p Y2F0aW9uIGFyZSB3aXRoaW4gdGhlIHNhbWUgKmFkbWluaXN0cmF0aXZlKiANCmRvbWFpbi5Ib3dl dmVyIHRoZXJlIGFyZSBzdGlsbCBjb25mdXNpb24gYmV0d2VlbiBhZG1pbmlzdHJhdGl2ZSBkb21h aW4gDQphbmQgUE1JUCBkb21haW4uIEJlY2F1c2UgUE1JUCBkb21haW4gY2FuIGJlIHRha2VuIGFz IG9uZSBhZG1pbmlzdHJhdGl2ZQ0KIGRvbWFpbiwgaG93ZXZlciBvbmUgYWRtaW5pc3RyYXRpdmUg ZG9tYWluIG1heSBiZSBub3QgUE1JUCBkb21haW4gYnV0IA0KTUlQIGRvbWFpbi4gU28gd2hhdCdz IHRoZSBzY29wZSBvZiBhZG1pbmlzdHJhdGl2ZSBkb21haW4gYW5kIFBNSVAgZG9tYWluPyANCml0 IGlzIG5lY2Vzc2FyeSB0byBiZSBjbGFyaWZpZWQsIGFtIEkgcmlnaHQ/DQoNClJlZ2FyZHMhDQot UWluDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIk1hcmNvIExpZWJzY2gi IDxtYXJjby5saWVic2NoQG53Lm5lY2xhYi5ldT4NClRvOiAiQWxwZXIgWWVnaW4iIDxhbHBlci55 ZWdpbkB5ZWdpbi5vcmc+DQpDYzogPG5ldGV4dEBpZXRmLm9yZz4NClNlbnQ6IFR1ZXNkYXksIEF1 Z3VzdCAwNCwgMjAwOSA0OjI2IFBNDQpTdWJqZWN0OiBSZTogW25ldGV4dF0gUE1JUDYgYW5kIHJv YW1pbmcNCg0KDQpIaSBBbHBlciwgRGVzaXJlLCBhbGwNCg0KaWYgd2UgYXNzdW1lIHRoYXQgUE1J UHY2IG9wZXJhdGVzIGJldHdlZW4gdGhlIExNQSBpbiB0aGUgVVMgYW5kIHRoZSBNQUcNCmluIFN3 ZWRlbiwgd2VsbCwgdGhlbiBhIHNlY3VyaXR5IGFzc29jaWF0aW9uIGlzIGltcGxpY2l0LiBIZW5j ZSwgdGhlcmUgDQppcyBzb21lIGxldmVsDQpvZiB0cnVzdC5Gb3IgdGhlIHByb3RvY29sIHNvbHV0 aW9uIGluIHRoZSBJRVRGLCB0aGlzIHNob3VsZCBiZSB0aGUgbWFpbiANCnJlcXVpcmVtZW50Lg0K V2hlcmUgdGhlc2UgY29tcG9uZW50cyBhcmUgZmluYWxseSBsb2NhdGVkIGlzIGRlcGxveW1lbnQg c3BlY2lmaWMuDQoNClNhbWUgZm9yIGxvY2FsaXplZCByb3V0aW5nOiBXaGVuIGEgTUFHIGNhbiBj cmVhdGUgYSBiaW5kaW5nIGF0IHRoZSBMTUEsIA0KSSBkb24ndA0Kc2VlIGEgcHJvYmxlbSB3aHkg dGhlIExNQSBjYW5ub3QgY3JlYXRlIGEgc3RhdGUgYXQgdGhlIE1BRyB0byBwZXJmb3JtIA0KbG9j YWxpemVkDQpyb3V0aW5nLiBTQW1lIGFzIGFib3ZlOiBBcyBsb25nIGFzIHRoZXJlIGlzIGFuIFNB IGJldHdlZW4gdGhlIHR3byANCmNvbXBvbmVudHMuDQoNCkZyb20gdGhlIGRpc2N1c3Npb24gd2Ug aGFkIGluIFN0b2NraG9sbSwgSSB0aGluayBmb3IgZGVwbG95bWVudCANCnBlcnNwZWN0aXZlIGl0 J3MgbW9yZSBpbXBvcnRhbnQgdG8gaGF2ZSBib3RoIE1BR3MgKG1vYmlsZSAxIGFuZCBtb2JpbGUg MikgaW4gdGhlIHNhbWUgDQoqYWRtaW5pc3RyYXRpdmUqIGRvbWFpbiAodG8gZGlzdGlndWlzaCBm cm9tIGEgUE1JUCBkb21haW4pLCBhcyBpbnRlci1NQUcgb3BlcmF0aW9uIGJldHdlZW4gDQphZG1p bmlzdHJhdGl2ZSBkb21haW5zIGNvbXByaXNlcyB0aGUga25vd3MgaXNzdWVzLiANCg0KRm9yIHRo ZSBwcm90b2NvbCBzcGVjaWZpY2F0aW9uOiBXZWxsLCBpdCBkb2VzIG5vdCBtYXR0ZXIuLiBhcyBs b25nIGFzIE1BR3Mgc2hhcmUgYSBzZWN1cml0eSBhc3NvY2lhdGlvbiBhbmQgY2FuIHNldCB1cCBh IA0KZm9yd2FyZGluZyB0dW5uZWwuDQoNCm1hcmNvDQoNCg0KQWxwZXIgWWVnaW4gc2NocmllYjoN Cj4gSGkgRGVzaXJlLA0KPg0KPiBSRkMgNTIxMzoNCj4NCj4gICAgUHJveHkgTW9iaWxlIElQdjYg RG9tYWluIChQTUlQdjYtRG9tYWluKQ0KPg0KPiAgICAgICBQcm94eSBNb2JpbGUgSVB2NiBkb21h aW4gcmVmZXJzIHRvIHRoZSBuZXR3b3JrIHdoZXJlIHRoZSBtb2JpbGl0eQ0KPiAgICAgICBtYW5h Z2VtZW50IG9mIGEgbW9iaWxlIG5vZGUgaXMgaGFuZGxlZCB1c2luZyB0aGUgUHJveHkgTW9iaWxl IElQdjYNCj4gICAgICAgcHJvdG9jb2wgYXMgZGVmaW5lZCBpbiB0aGlzIHNwZWNpZmljYXRpb24u ICBUaGUgUHJveHkgTW9iaWxlIElQdjYNCj4gICAgICAgZG9tYWluIGluY2x1ZGVzIGxvY2FsIG1v YmlsaXR5IGFuY2hvcnMgYW5kIG1vYmlsZSBhY2Nlc3MgZ2F0ZXdheXMNCj4gICAgICAgYmV0d2Vl biB3aGljaCBzZWN1cml0eSBhc3NvY2lhdGlvbnMgY2FuIGJlIHNldCB1cCBhbmQNCj4gICAgICAg YXV0aG9yaXphdGlvbiBmb3Igc2VuZGluZyBQcm94eSBCaW5kaW5nIFVwZGF0ZXMgb24gYmVoYWxm IG9mIHRoZQ0KPiAgICAgICBtb2JpbGUgbm9kZXMgY2FuIGJlIGVuc3VyZWQuDQo+DQo+DQo+IEkg cmVtZW1iZXIgdGhpcyB3YXMgc3BlY2lmaWNhbGx5IGRpc2N1c3NlZCBhbmQgd2UgaGFkIGNvbWUg dXAgd2l0aCBhIHRleHQNCj4gdGhhdCByZWZlcnMgdG8gImxvY2FsIG1vYmlsaXR5IGFuY2hvcnMg YW5kIG1vYmlsZSBhY2Nlc3MgZ2F0ZXdheXMgYmV0d2Vlbg0KPiB3aGljaCBzZWN1cml0eSBhc3Nv Y2lhdGlvbnMgY2FuIGJlIHNldCB1cCIgYXMgdGhlIGxpbWl0aW5nIGZhY3RvciB0aGF0IHNldHMN Cj4gdGhlIGJvdW5kYXJ5LiBBbmQgc2VjdXJpdHkgYXNzb2NpYXRpb25zIGNhbiBiZSBzZXR1cCBi ZXR3ZWVuIE1BR3MgYW5kIExNQXMNCj4gYmVsb25naW5nIHRvIHNlcGFyYXRlIG9wZXJhdG9ycyB3 aGVuIHRoZXJlIGlzIGEgcm9hbWluZyBhZ3JlZW1lbnQuIFdpTUFYDQo+IGFyY2hpdGVjdHVyZSBh bHJlYWR5IGRvZXMgdGhhdC4NCj4NCj4gQWxwZXINCj4NCj4NCj4NCj4NCj4NCj4NCj4NCj4NCj4N Cj4gICANCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBEZXNpcmUgT3Vs YWkgW21haWx0bzpkZXNpcmUub3VsYWlAZXJpY3Nzb24uY29tXQ0KPj4gU2VudDogVGh1cnNkYXks IEp1bHkgMzAsIDIwMDkgNDoxMyBQTQ0KPj4gVG86IEFscGVyIFllZ2luOyBuZXRleHRAaWV0Zi5v cmcNCj4+IFN1YmplY3Q6IFJFIDogW25ldGV4dF0gUE1JUDYgYW5kIHJvYW1pbmcNCj4+DQo+PiBI aSBBbHBlciwNCj4+DQo+PiAgIFNlZSBpbmxpbmUhDQo+Pg0KPj4gRGVzaXJlDQo+Pg0KPj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+DQo+PiBEZTogbmV0ZXh0LWJvdW5jZXNA aWV0Zi5vcmcgZGUgbGEgcGFydCBkZSBBbHBlciBZZWdpbg0KPj4gRGF0ZTogamV1LiAyMDA5LTA3 LTMwIDA4OjAyDQo+PiDAOiBuZXRleHRAaWV0Zi5vcmcNCj4+IE9iamV0IDogW25ldGV4dF0gUE1J UDYgYW5kIHJvYW1pbmcNCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4gQ29udGludWluZyB0aGUgZGlz Y3Vzc2lvbiBvbiB0aGUgTUwuLi4uLi4NCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4gQ29uc2lkZXIg bW9iaWxlMSBhbmQgbW9iaWxlMiBzdWJzY3JpYmVkIHRvIGRhdGEgc2VydmljZSBpbiBVU0EuDQo+ Pg0KPj4gVGhleSBhcmUgaW4gU3dlZGVuLCBhY2Nlc3NpbmcgSW50ZXJuZXQgYnkgInJvYW1pbmci IHRvIGEgU3dlZGlzaA0KPj4gb3BlcmF0b3IgbmV0d29yay4NCj4+DQo+Pg0KPj4NCj4+IERvZXMg UE1JUDYgbm90IHN1cHBvcnQgdGhpcyBjYXNlIHdoZXJlIE1BRyBpcyBpbiBTd2VkaXNoIG9wZXJh dG9yDQo+PiBuZXR3b3JrLCBhbmQgTE1BIGluIFVTQSBvcGVyYXRvcidzIG5ldHdvcms/IEkgdGhp bmsgdGhlIGFuc3dlciBpcyB5ZXMuDQo+Pg0KPj4gW0Rlc2lyZV06ICAgSSB0aGluayBQTUlQNiBh cyBkZWZpbmVkIGluIFJGQzUyMTMgZG9lcyBub3Qgc3VwcG9ydCB0aGlzDQo+PiBzY2VuYXJpbyBh cyB0aGUgTUFHIGFyZSBub3QgaW4gdGhlIHNhbWUgUE1JUCBkb21haW4uIEhvd2V2ZXIsIFNET3Mg bGlrZQ0KPj4gM0dQUCBzdXBwb3J0cyBob21lIHR1bm5lbGxpbmcuDQo+Pg0KPj4NCj4+DQo+PiBX b3VsZG4ndCB3ZSB3YW50IHRvIG9wdGltaXplIHRoZSBwYXRoIGJldHdlZW4gbW9iaWxlMSBhbmQg bW9iaWxlMiB0bw0KPj4gc2F2ZSB0aGUgdHJhZmZpYyBmcm9tIG1ha2luZyB0aGUgdW5uZWNlc3Nh cnkgVVNBIHRyaXA/IEkgdGhpbmsgdGhlDQo+PiBhbnN3ZXIgaXMgeWVzIGFnYWluLg0KPj4NCj4+ IFtEZXNpcmVdOiBJIGFncmVlIHRoYXQgaXQgaXMgYW4gaW50ZXJlc3Rpbmcgb3B0aW1pemF0aW9u LiBCdXQgd2UgbmVlZA0KPj4gZmlyc3QgdG8gY2xhcmlmeSB0aGUgcmVsYXRpb24gYmV0d2VlbiB0 aGUgTUFHIGluIHN3ZWRlbiBhbmQgdGhlIExNQSBpbg0KPj4gVVNBLiBTbyB3ZSBuZWVkIHRvIHNw ZWNpZnkgUE1JUDYgcm9hbWluZyBiZWZvcmUgdGFsa2luZyBhYm91dCBMb2NhbGl6ZWQNCj4+IHJv dXRpbmcgaW4gUE1JUDYgcm9hbWluZy4NCj4+DQo+Pg0KPj4NCj4+IENvbW1lbnRzPw0KPj4NCj4+ DQo+Pg0KPj4gQWxwZXINCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+ Pg0KPj4NCj4+DQo+Pg0KPj4gICAgIA0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBuZXRleHQgbWFpbGluZyBsaXN0DQo+IG5ldGV4dEBp ZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGV4dA0K PiAgIA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpuZXRleHQgbWFpbGluZyBsaXN0DQpuZXRleHRAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbmV0ZXh0 From Marco.Liebsch@nw.neclab.eu Tue Aug 18 07:07:41 2009 Return-Path: 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 87F7D3A69F1 for ; Tue, 18 Aug 2009 07:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] 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 g60FBJBXNyxm for ; Tue, 18 Aug 2009 07:07:40 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 32D0F3A689D for ; Tue, 18 Aug 2009 07:07:40 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id DB6842C0002FC; Tue, 18 Aug 2009 14:39:39 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVW2+HHxiSw0; Tue, 18 Aug 2009 14:39:39 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id B1F0F2C0002FE; Tue, 18 Aug 2009 14:39:24 +0200 (CEST) Received: from [127.0.0.1] ([10.1.2.187]) by VENUS.office with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 14:39:24 +0200 Message-ID: <4A8AA0FC.10406@nw.neclab.eu> Date: Tue, 18 Aug 2009 14:39:24 +0200 From: Marco Liebsch User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Qin Wu References: <060f01ca110d$903ca120$b0b5e360$%yegin@yegin.org> <063901ca111a$01ce9c60$056bd520$%yegin@yegin.org> <4A77F0CC.4090204@nw.neclab.eu> <037501ca1ffd$98a1d4d0$260ca40a@china.huawei.com> In-Reply-To: <037501ca1ffd$98a1d4d0$260ca40a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 18 Aug 2009 12:39:24.0796 (UTC) FILETIME=[EAFC1BC0:01CA2000] 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 14:07:41 -0000 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" > To: "Alper Yegin" > Cc: > 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 From Mohana.Jeyatharan@sg.panasonic.com Tue Aug 18 18:58:32 2009 Return-Path: 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 ; 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 ; 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 ; 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" To: "Marco Liebsch" , "Qin Wu" 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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.=20 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 >=20 > hi Qin, >=20 > 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. >=20 > marco >=20 >=20 >=20 >=20 >=20 >=20 > > Regards! > > -Qin > > ----- Original Message ----- > > From: "Marco Liebsch" > > To: "Alper Yegin" > > Cc: > > 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 > >>> =C0: 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 >=20 >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From sunseawq@huawei.com Tue Aug 18 19:03:06 2009 Return-Path: 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 8F1A83A69AE for ; Tue, 18 Aug 2009 19:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.603 X-Spam-Level: X-Spam-Status: No, score=0.603 tagged_above=-999 required=5 tests=[AWL=-0.655, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 g-9wujuGV4R9 for ; Tue, 18 Aug 2009 19:03:05 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 31B2D3A685B for ; Tue, 18 Aug 2009 19:03:05 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOL008DQPOX01@szxga01-in.huawei.com> for netext@ietf.org; Wed, 19 Aug 2009 10:02:57 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOL000UBPOXXM@szxga01-in.huawei.com> for netext@ietf.org; Wed, 19 Aug 2009 10:02:57 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KOL001MQPOW4O@szxml06-in.huawei.com> for netext@ietf.org; Wed, 19 Aug 2009 10:02:56 +0800 (CST) Date: Wed, 19 Aug 2009 10:02:55 +0800 From: Qin Wu To: Marco Liebsch Message-id: <005d01ca2071$2b8c78e0$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: <060f01ca110d$903ca120$b0b5e360$%yegin@yegin.org> <063901ca111a$01ce9c60$056bd520$%yegin@yegin.org> <4A77F0CC.4090204@nw.neclab.eu> <037501ca1ffd$98a1d4d0$260ca40a@china.huawei.com> <4A8AA0FC.10406@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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 02:03:06 -0000 SGksIE1hcmNvOg0KU3VwcG9zZSBQTUlQdjYgb3BlcmF0ZXMgYmV0d2VlbiB0aGUgTE1BIGluIHRo ZSBVUyANCmFuZCB0aGUgTUFHICBpbiBTd2VkZW4gYXMgeW91IG1lbnRpb25lZCwgd2hhdCdzIHRo ZSBwcmVyZXF1aXNpdCANCmNvbmRpdGlvbiB0byBlbmFibGluZyBzZXR1cCBzZWN1cml0eSBhc3Nv Y2lhdGlvbj8gSXMgaXQgcm9hbWluZyBzdXBwb3J0DQogb3Igc29tZXRoaW5nIGVsc2U/DQoNCkFs c28gaW4gdGhpcyBzY2VuYXJpbywgSSBhbSBkaWZmaWN1bHQgdG8gdGVsbCBob3cgbWFueSBwbXA2 IGRvbWFpbnMgdGhlcmUgaXM/IA0KV2UgY2FuIHNheSBpbiBVUywgdGhlcmUgaXMgb25lIFBNSVB2 NiBkb21haW4gdGhhdCBvd25zIExNQSwNCndoaWxlIGluIFN3ZWRlbiwgdGhlcmUgaXMgYW5vdGhl ciBQTUlQdjYgZG9tYWluIHRoYXQgb3ducyBNQUcsIA0KaG93ZXZlciBpZiB3ZSBhc3N1bWUgdGhl cmUgaXMgYSByb2FtaW5nIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSANClBNSVB2NiBkb21haW4g aW4gVVMgYW5kIGFub3RoZXIgUE1JUHY2IGRvbWFpbiBpbiBTd2VkZW4sDQogaXQgc2VlbXMgdGhl c2UgdHdvIFBNSVB2NiBkb21haW5zIGNhbiBiZSBjb21iaW5lZCBpbnRvIG9uZSANClBNSVB2NiBk b21haW4uIEluIHRoaXMgd2F5LCBpdCBzZWVtcyBlYWNoIFBNSVB2NiBkb21haW5zDQogY2FuIGJl IHRha2VuIGFzIG9uZSBQTUlQNiBkb21haW4gaWYgdGhlcmUgaXMgdHJ1c3QgcmVsYXRpb25zaGlw IA0KYmV0d2VlbiB0aGVtPyBhbSBJIHJpZ2h0Pw0KDQpTbyBJIGFtIHdvbmRlcmluZyBob3cgdG8g dW5kZXJzdGFuZCAibG9jYWwiIG9yICJsb2NhbGl6ZWQiDQogaW4gdGhlIGxvY2FsaXplZCByb3V0 aW5nIHRvcGljPyBXaGV0aGVyIHRoZSBQTUlQdjYgZG9tYWluIA0KY2FuIGJlIHJlc3RyaWN0ZWQg aW50byBvbmUgbG9jYWwgUE1JUHY2IGRvbWFpbj8gDQoNClJlZ2FyZHMhDQotUWluDQotLS0tLSBP cmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIk1hcmNvIExpZWJzY2giIDxtYXJjby5saWVi c2NoQG53Lm5lY2xhYi5ldT4NClRvOiAiUWluIFd1IiA8c3Vuc2Vhd3FAaHVhd2VpLmNvbT4NCkNj OiAiQWxwZXIgWWVnaW4iIDxhbHBlci55ZWdpbkB5ZWdpbi5vcmc+OyA8bmV0ZXh0QGlldGYub3Jn Pg0KU2VudDogVHVlc2RheSwgQXVndXN0IDE4LCAyMDA5IDg6MzkgUE0NClN1YmplY3Q6IFJlOiBb bmV0ZXh0XSBQTUlQNiBhbmQgcm9hbWluZw0KDQoNCj4gaGkgUWluLA0KPiANCj4gUWluIFd1IHNj aHJpZWI6DQo+PiBIaSwgTWFyY286DQo+PiAgSSBhZ3JlZSB0aGUgTG9jYWxpemVkIHJvdXRpbmcg bWVjaGFuaXNtIGNhbiBiZSBhcHBsaWNhYmxlIHRvIHRoZSBzY2VuYXJpbw0KPj4gIHdoZXJlIHR3 byBNQUdzIGluIGNvbW11bmljYXRpb24gYXJlIHdpdGhpbiB0aGUgc2FtZSAqYWRtaW5pc3RyYXRp dmUqIA0KPj4gZG9tYWluLkhvd2V2ZXIgdGhlcmUgYXJlIHN0aWxsIGNvbmZ1c2lvbiBiZXR3ZWVu IGFkbWluaXN0cmF0aXZlIGRvbWFpbiANCj4+IGFuZCBQTUlQIGRvbWFpbi4gQmVjYXVzZSBQTUlQ IGRvbWFpbiBjYW4gYmUgdGFrZW4gYXMgb25lIGFkbWluaXN0cmF0aXZlDQo+PiAgZG9tYWluLCBo b3dldmVyIG9uZSBhZG1pbmlzdHJhdGl2ZSBkb21haW4gbWF5IGJlIG5vdCBQTUlQIGRvbWFpbiBi dXQgDQo+PiBNSVAgZG9tYWluLiBTbyB3aGF0J3MgdGhlIHNjb3BlIG9mIGFkbWluaXN0cmF0aXZl IGRvbWFpbiBhbmQgUE1JUCBkb21haW4/IA0KPj4gaXQgaXMgbmVjZXNzYXJ5IHRvIGJlIGNsYXJp ZmllZCwgYW0gSSByaWdodD8NCj4+ICAgDQo+IFllcywgYnV0IEkgYW0gbm90IHN1cmUgdGhpcyB3 aWxsIGJyaW5nIHVzIGZ1cnRoZXIuIEFzIGRpZmZlcmVuY2UgdG8gdGhlIA0KPiBQTUlQdjYgc3Bl Y2lmaWNhdGlvbiwNCj4gd2UgaGFuZGxlIHNjZW5hcmlvcyBiZXR3ZWVuIHR3byBjb21tdW5pY2F0 aW5nIE1Ocywgd2hpY2ggbWF5IGdldCBzZXJ2ZWQgDQo+IGJ5IGNvbXBvbmVudHMNCj4gZnJvbSBk aWZmZXJlbnQgYWRtaW5pc3RyYXRpdmUgZG9tYWlucy4gU3VyZSwgYSBQTUlQdjYgZG9tYWluIGNh biBjb3ZlciANCj4gbXVsdGlwbGUgYWRtaW4gZG9tYWlucy4NCj4gSGVuY2UsIEkgdGhpbmsgZm9y IHRoZSBwcm90b2NvbCBzcGVjaWZpY2F0aW9uIGl0J3Mgc3VmZmljaWVudCB0byBhc3N1bWUgDQo+ IHRoYXQsIHRvIHdvcmssIHRoZXJlIG11c3QNCj4gYmUgYSB0cnVzdCByZWxhdGlvbnNoaXAgYmV0 d2VlbiBjb21wb25lbnRzIGV4Y2hhbmdpbmcgc2lnbmFsaW5nLiBTbyBmb3IgDQo+IHRoZSBwcm90 b2NvbCBzcGVjaWZpY2F0aW9uDQo+IEkgdGhpbmsgaXQncyBzdWZmaWNpZW50IHRvIG1hbmRhdGUg YSBzZWN1cml0eSBhc3NvY2lhdGlvbiBiZXR3ZWVuIHRoZXNlIA0KPiBjb21wb25lbnRzIHRvIGF1 dGhlbnRpY2F0ZQ0KPiBtZXNzYWdlcy4NCj4gDQo+IG1hcmNvDQo+IA0KPiANCj4gDQo+IA0KPiAN Cj4gDQo+PiBSZWdhcmRzIQ0KPj4gLVFpbg0KPj4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0t LSANCj4+IEZyb206ICJNYXJjbyBMaWVic2NoIiA8bWFyY28ubGllYnNjaEBudy5uZWNsYWIuZXU+ DQo+PiBUbzogIkFscGVyIFllZ2luIiA8YWxwZXIueWVnaW5AeWVnaW4ub3JnPg0KPj4gQ2M6IDxu ZXRleHRAaWV0Zi5vcmc+DQo+PiBTZW50OiBUdWVzZGF5LCBBdWd1c3QgMDQsIDIwMDkgNDoyNiBQ TQ0KPj4gU3ViamVjdDogUmU6IFtuZXRleHRdIFBNSVA2IGFuZCByb2FtaW5nDQo+Pg0KPj4NCj4+ IEhpIEFscGVyLCBEZXNpcmUsIGFsbA0KPj4NCj4+IGlmIHdlIGFzc3VtZSB0aGF0IFBNSVB2NiBv cGVyYXRlcyBiZXR3ZWVuIHRoZSBMTUEgaW4gdGhlIFVTIGFuZCB0aGUgTUFHDQo+PiBpbiBTd2Vk ZW4sIHdlbGwsIHRoZW4gYSBzZWN1cml0eSBhc3NvY2lhdGlvbiBpcyBpbXBsaWNpdC4gSGVuY2Us IHRoZXJlIA0KPj4gaXMgc29tZSBsZXZlbA0KPj4gb2YgdHJ1c3QuRm9yIHRoZSBwcm90b2NvbCBz b2x1dGlvbiBpbiB0aGUgSUVURiwgdGhpcyBzaG91bGQgYmUgdGhlIG1haW4gDQo+PiByZXF1aXJl bWVudC4NCj4+IFdoZXJlIHRoZXNlIGNvbXBvbmVudHMgYXJlIGZpbmFsbHkgbG9jYXRlZCBpcyBk ZXBsb3ltZW50IHNwZWNpZmljLg0KPj4NCj4+IFNhbWUgZm9yIGxvY2FsaXplZCByb3V0aW5nOiBX aGVuIGEgTUFHIGNhbiBjcmVhdGUgYSBiaW5kaW5nIGF0IHRoZSBMTUEsIA0KPj4gSSBkb24ndA0K Pj4gc2VlIGEgcHJvYmxlbSB3aHkgdGhlIExNQSBjYW5ub3QgY3JlYXRlIGEgc3RhdGUgYXQgdGhl IE1BRyB0byBwZXJmb3JtIA0KPj4gbG9jYWxpemVkDQo+PiByb3V0aW5nLiBTQW1lIGFzIGFib3Zl OiBBcyBsb25nIGFzIHRoZXJlIGlzIGFuIFNBIGJldHdlZW4gdGhlIHR3byANCj4+IGNvbXBvbmVu dHMuDQo+Pg0KPj4gRnJvbSB0aGUgZGlzY3Vzc2lvbiB3ZSBoYWQgaW4gU3RvY2tob2xtLCBJIHRo aW5rIGZvciBkZXBsb3ltZW50IA0KPj4gcGVyc3BlY3RpdmUgaXQncyBtb3JlIGltcG9ydGFudCB0 byBoYXZlIGJvdGggTUFHcyAobW9iaWxlIDEgYW5kIG1vYmlsZSAyKSBpbiB0aGUgc2FtZSANCj4+ ICphZG1pbmlzdHJhdGl2ZSogZG9tYWluICh0byBkaXN0aWd1aXNoIGZyb20gYSBQTUlQIGRvbWFp biksIGFzIGludGVyLU1BRyBvcGVyYXRpb24gYmV0d2VlbiANCj4+IGFkbWluaXN0cmF0aXZlIGRv bWFpbnMgY29tcHJpc2VzIHRoZSBrbm93cyBpc3N1ZXMuIA0KPj4NCj4+IEZvciB0aGUgcHJvdG9j b2wgc3BlY2lmaWNhdGlvbjogV2VsbCwgaXQgZG9lcyBub3QgbWF0dGVyLi4gYXMgbG9uZyBhcyBN QUdzIHNoYXJlIGEgc2VjdXJpdHkgYXNzb2NpYXRpb24gYW5kIGNhbiBzZXQgdXAgYSANCj4+IGZv cndhcmRpbmcgdHVubmVsLg0KPj4NCj4+IG1hcmNvDQo+Pg0KPj4NCj4+IEFscGVyIFllZ2luIHNj aHJpZWI6DQo+PiAgIA0KPj4+IEhpIERlc2lyZSwNCj4+Pg0KPj4+IFJGQyA1MjEzOg0KPj4+DQo+ Pj4gICAgUHJveHkgTW9iaWxlIElQdjYgRG9tYWluIChQTUlQdjYtRG9tYWluKQ0KPj4+DQo+Pj4g ICAgICAgUHJveHkgTW9iaWxlIElQdjYgZG9tYWluIHJlZmVycyB0byB0aGUgbmV0d29yayB3aGVy ZSB0aGUgbW9iaWxpdHkNCj4+PiAgICAgICBtYW5hZ2VtZW50IG9mIGEgbW9iaWxlIG5vZGUgaXMg aGFuZGxlZCB1c2luZyB0aGUgUHJveHkgTW9iaWxlIElQdjYNCj4+PiAgICAgICBwcm90b2NvbCBh cyBkZWZpbmVkIGluIHRoaXMgc3BlY2lmaWNhdGlvbi4gIFRoZSBQcm94eSBNb2JpbGUgSVB2Ng0K Pj4+ICAgICAgIGRvbWFpbiBpbmNsdWRlcyBsb2NhbCBtb2JpbGl0eSBhbmNob3JzIGFuZCBtb2Jp bGUgYWNjZXNzIGdhdGV3YXlzDQo+Pj4gICAgICAgYmV0d2VlbiB3aGljaCBzZWN1cml0eSBhc3Nv Y2lhdGlvbnMgY2FuIGJlIHNldCB1cCBhbmQNCj4+PiAgICAgICBhdXRob3JpemF0aW9uIGZvciBz ZW5kaW5nIFByb3h5IEJpbmRpbmcgVXBkYXRlcyBvbiBiZWhhbGYgb2YgdGhlDQo+Pj4gICAgICAg bW9iaWxlIG5vZGVzIGNhbiBiZSBlbnN1cmVkLg0KPj4+DQo+Pj4NCj4+PiBJIHJlbWVtYmVyIHRo aXMgd2FzIHNwZWNpZmljYWxseSBkaXNjdXNzZWQgYW5kIHdlIGhhZCBjb21lIHVwIHdpdGggYSB0 ZXh0DQo+Pj4gdGhhdCByZWZlcnMgdG8gImxvY2FsIG1vYmlsaXR5IGFuY2hvcnMgYW5kIG1vYmls ZSBhY2Nlc3MgZ2F0ZXdheXMgYmV0d2Vlbg0KPj4+IHdoaWNoIHNlY3VyaXR5IGFzc29jaWF0aW9u cyBjYW4gYmUgc2V0IHVwIiBhcyB0aGUgbGltaXRpbmcgZmFjdG9yIHRoYXQgc2V0cw0KPj4+IHRo ZSBib3VuZGFyeS4gQW5kIHNlY3VyaXR5IGFzc29jaWF0aW9ucyBjYW4gYmUgc2V0dXAgYmV0d2Vl biBNQUdzIGFuZCBMTUFzDQo+Pj4gYmVsb25naW5nIHRvIHNlcGFyYXRlIG9wZXJhdG9ycyB3aGVu IHRoZXJlIGlzIGEgcm9hbWluZyBhZ3JlZW1lbnQuIFdpTUFYDQo+Pj4gYXJjaGl0ZWN0dXJlIGFs cmVhZHkgZG9lcyB0aGF0Lg0KPj4+DQo+Pj4gQWxwZXINCj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+ DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+PiAgIA0KPj4+ICAgICANCj4+Pj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4+Pj4gRnJvbTogRGVzaXJlIE91bGFpIFttYWlsdG86ZGVzaXJlLm91 bGFpQGVyaWNzc29uLmNvbV0NCj4+Pj4gU2VudDogVGh1cnNkYXksIEp1bHkgMzAsIDIwMDkgNDox MyBQTQ0KPj4+PiBUbzogQWxwZXIgWWVnaW47IG5ldGV4dEBpZXRmLm9yZw0KPj4+PiBTdWJqZWN0 OiBSRSA6IFtuZXRleHRdIFBNSVA2IGFuZCByb2FtaW5nDQo+Pj4+DQo+Pj4+IEhpIEFscGVyLA0K Pj4+Pg0KPj4+PiAgIFNlZSBpbmxpbmUhDQo+Pj4+DQo+Pj4+IERlc2lyZQ0KPj4+Pg0KPj4+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pg0KPj4+PiBEZTogbmV0ZXh0LWJv dW5jZXNAaWV0Zi5vcmcgZGUgbGEgcGFydCBkZSBBbHBlciBZZWdpbg0KPj4+PiBEYXRlOiBqZXUu IDIwMDktMDctMzAgMDg6MDINCj4+Pj4gwDogbmV0ZXh0QGlldGYub3JnDQo+Pj4+IE9iamV0IDog W25ldGV4dF0gUE1JUDYgYW5kIHJvYW1pbmcNCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4N Cj4+Pj4gQ29udGludWluZyB0aGUgZGlzY3Vzc2lvbiBvbiB0aGUgTUwuLi4uLi4NCj4+Pj4NCj4+ Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4gQ29uc2lkZXIgbW9iaWxlMSBhbmQgbW9iaWxlMiBz dWJzY3JpYmVkIHRvIGRhdGEgc2VydmljZSBpbiBVU0EuDQo+Pj4+DQo+Pj4+IFRoZXkgYXJlIGlu IFN3ZWRlbiwgYWNjZXNzaW5nIEludGVybmV0IGJ5ICJyb2FtaW5nIiB0byBhIFN3ZWRpc2gNCj4+ Pj4gb3BlcmF0b3IgbmV0d29yay4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4gRG9lcyBQTUlQNiBu b3Qgc3VwcG9ydCB0aGlzIGNhc2Ugd2hlcmUgTUFHIGlzIGluIFN3ZWRpc2ggb3BlcmF0b3INCj4+ Pj4gbmV0d29yaywgYW5kIExNQSBpbiBVU0Egb3BlcmF0b3IncyBuZXR3b3JrPyBJIHRoaW5rIHRo ZSBhbnN3ZXIgaXMgeWVzLg0KPj4+Pg0KPj4+PiBbRGVzaXJlXTogICBJIHRoaW5rIFBNSVA2IGFz IGRlZmluZWQgaW4gUkZDNTIxMyBkb2VzIG5vdCBzdXBwb3J0IHRoaXMNCj4+Pj4gc2NlbmFyaW8g YXMgdGhlIE1BRyBhcmUgbm90IGluIHRoZSBzYW1lIFBNSVAgZG9tYWluLiBIb3dldmVyLCBTRE9z IGxpa2UNCj4+Pj4gM0dQUCBzdXBwb3J0cyBob21lIHR1bm5lbGxpbmcuDQo+Pj4+DQo+Pj4+DQo+ Pj4+DQo+Pj4+IFdvdWxkbid0IHdlIHdhbnQgdG8gb3B0aW1pemUgdGhlIHBhdGggYmV0d2VlbiBt b2JpbGUxIGFuZCBtb2JpbGUyIHRvDQo+Pj4+IHNhdmUgdGhlIHRyYWZmaWMgZnJvbSBtYWtpbmcg dGhlIHVubmVjZXNzYXJ5IFVTQSB0cmlwPyBJIHRoaW5rIHRoZQ0KPj4+PiBhbnN3ZXIgaXMgeWVz IGFnYWluLg0KPj4+Pg0KPj4+PiBbRGVzaXJlXTogSSBhZ3JlZSB0aGF0IGl0IGlzIGFuIGludGVy ZXN0aW5nIG9wdGltaXphdGlvbi4gQnV0IHdlIG5lZWQNCj4+Pj4gZmlyc3QgdG8gY2xhcmlmeSB0 aGUgcmVsYXRpb24gYmV0d2VlbiB0aGUgTUFHIGluIHN3ZWRlbiBhbmQgdGhlIExNQSBpbg0KPj4+ PiBVU0EuIFNvIHdlIG5lZWQgdG8gc3BlY2lmeSBQTUlQNiByb2FtaW5nIGJlZm9yZSB0YWxraW5n IGFib3V0IExvY2FsaXplZA0KPj4+PiByb3V0aW5nIGluIFBNSVA2IHJvYW1pbmcuDQo+Pj4+DQo+ Pj4+DQo+Pj4+DQo+Pj4+IENvbW1lbnRzPw0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiBBbHBlcg0K Pj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+ Pg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiAgICAgDQo+Pj4+ICAgICAgIA0KPj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gbmV0ZXh0 IG1haWxpbmcgbGlzdA0KPj4+IG5ldGV4dEBpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbmV0ZXh0DQo+Pj4gICANCj4+PiAgICAgDQo+Pg0KPj4NCj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBuZXRl eHQgbWFpbGluZyBsaXN0DQo+PiBuZXRleHRAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbmV0ZXh0DQo+IA0KPg== From sunseawq@huawei.com Tue Aug 18 20:10:01 2009 Return-Path: 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 7C78E3A680E for ; Tue, 18 Aug 2009 20:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.885 X-Spam-Level: * X-Spam-Status: No, score=1.885 tagged_above=-999 required=5 tests=[AWL=-1.773, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_42=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, J_CHICKENPOX_74=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 vDx2w83ubJWE for ; Tue, 18 Aug 2009 20:10:00 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id CF8933A680C for ; Tue, 18 Aug 2009 20:09:59 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOL008FISLM01@szxga01-in.huawei.com> for netext@ietf.org; Wed, 19 Aug 2009 11:05:46 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOL00LXASLMGK@szxga01-in.huawei.com> for netext@ietf.org; Wed, 19 Aug 2009 11:05:46 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KOL00EIUSLL67@szxml06-in.huawei.com> for netext@ietf.org; Wed, 19 Aug 2009 11:05:46 +0800 (CST) Date: Wed, 19 Aug 2009 11:05:45 +0800 From: Qin Wu To: Mohana Jeyatharan , Marco Liebsch Message-id: <00ff01ca2079$f2289d00$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: <5F09D220B62F79418461A978CA0921BD037FA451@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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 03:10:01 -0000 SGksIE1vaGFuYSBhbmQgYWxsOg0KQXMgeW91IG1lbnRpb25lZCwgUE1JUCBkb21haW4gYW5kIGFk bWluaXN0cmF0aXZlIGRvbWFpbiBjb2luY2lkZXMsIEkgYWdyZWUuIGUuZy4saW4gbWFueSBjYXNl cywgb25lIFBNSVAgZG9tYWluIGNhbiBjb3ZlciBtdWx0aXBsZSBhZG1pbnN0cmF0aXZlIGRvbWFp bnMuIEhvd2V2ZXIgaG93IHRvIGRlZmluZSBvbmUgYWRtaW5pc3RyYXRpdmUgZG9tYWluPyBJbiB5 b3VyIHVuZGVyc3RhbmRpbmcsIG9uZSBhZG1pbmlzdHJhdGl2ZSBkb21haW4gY2FuIGJlIGV4YW1w bGlmaWVkIGFzIG9uZSBzdWJuZXQgb3IgYSBsb2dpY2FsIGRpdmlzaW9uIG9mIG9uZSBhY2Nlc3Mg bmV0d29yayBpbiAzR1BQIHNjZW5hcmlvPyBhbSBJIHJpZ2h0PyBJcyBpdCAgd2hhdCB3ZSB1bmRl cnN0YW5kIGZvciB0aGUgZGVmaW5pdGlvbiBvZiBhZG1pbml0cmF0aXZlIGRvbWFpbj8NCkZyb20g bXkgdW5kZXJzdGFuZGluZywgdGhlIHRlcm0gb2YgImFkbWluaXN0cmF0aXZlIGRvbWFpbiIgaXMg bW9yZSBnZW5lcmljIHRlcm0gYW5kIHZlcnkgY29uZnVzaW5nLCBlLmcsIEkgY2FuIHNheSBvbmUg QUFBIGRvbWFpbiBpcyBhIGFkbWluaXN0cmF0aXZlIGRvbWFpbiB0b28gb3IgYWRtaW5zdHJhdGl2 ZSBkb21haW4gY2FuIGJlIGV4YW1wbGlmaWVkIGFzICphIGdlb2dyYXBoaWMgbW9iaWxpdHkgZG9t YWluKi4gU28gaWYgd2UgY29uc2lkZXIgdG8gdXNlIHRoaXMgdGVybSBpbiB0aGUgUFMgZHJhZnQs IHdlIHNob3VsZCBiZSB2ZXJ5IGNhcmVmdWwgd2hhdCBpdCBleGFjdCBtZWFucy4NCg0KUmVnYXJk cyENCi1RaW4NCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiTW9oYW5hIEpl eWF0aGFyYW4iIDxNb2hhbmEuSmV5YXRoYXJhbkBzZy5wYW5hc29uaWMuY29tPg0KVG86ICJNYXJj byBMaWVic2NoIiA8bWFyY28ubGllYnNjaEBudy5uZWNsYWIuZXU+OyAiUWluIFd1IiA8c3Vuc2Vh d3FAaHVhd2VpLmNvbT4NCkNjOiA8bmV0ZXh0QGlldGYub3JnPg0KU2VudDogV2VkbmVzZGF5LCBB dWd1c3QgMTksIDIwMDkgOTo1NCBBTQ0KU3ViamVjdDogUkU6IFtuZXRleHRdIFBNSVA2IGFuZCBy b2FtaW5nDQoNCg0KSGkgYWxsLA0KDQpJIGp1c3QgZm9sbG93ZWQgdGhlIHRocmVhZCwgYW5kIHRy aWVkIHRvIGxvb2sgaW50byB0aGUgc2NlbmFyaW9zIHdlIGhhdmUgaW4gdGhlIFJPIFBTIGRyYWZ0 LiBXZSBoYXZlIGNsYXNzaWZpZWQgdGhlIGZvdXIgc2NlbmFyaW9zIGluIFBTIGRyYWZ0IGZvciBN QUcgbG9jYWxpemVkIHJvdXRpbmcuDQoNCigxKU1OIGFuZCBDTiB1bmRlciBzYW1lIE1BRyBhbmQg Ym90aCBNTiBhbmQgQ04gYmVsb25nIHRvIHNhbWUgTE1BLiBIZXJlIE1OIGFuZCBDTiBuZWVkIHRv IGJlIHBsYWNlZCBpbiB0aGUgc2FtZSBhZG1uaXN0cmF0aXZlIGRvbWFpbihjYW5iZSB0aGVpciBo b21lIGRvbWFpbiBvciBiZSBhIGZvcmVpZ24gZG9tYWluKDNHUFAgaG9tZSByb3V0ZWQpKSBhbmQg dGhleSBuZWVkIHRvIGJlbG9uZyB0byBzYW1lIGhvbWUgZG9tYWluLg0KKDIpIE1uIGFuZCBDTiB1 bmRlciBzYW1lIE1BRyBidXQgZGlmZmVyZW50IExNQXMoTW4gYmVsb25nIHRvIExNQTEgYW5kIENO IGJlbG9uZyB0byBMTUEyKS4gSGVyZSwgTU4gYW5kIENOIG5lZWQgdG8gYmUgcGxhY2VkIGluIHNh bWUgYWRtaW5pc3RyYXRpdmUgZG9tYWluIGJ1dCBtYXkgYmVsb25nIHRvIGRpZmZlcmVudCBhZG1p bmlzdHJhdGl2ZShob21lKSBkb21haW4uDQooMykgTU4gYW5kIENOIHVuZGVyIGRpZmZlcmVudCBN QUdzIGJ1dCBzYW1lIExNQS4gSGVyZSBmb3IgTUFHIHRvIE1BRyBSTyB0byB3b3JrLCBib3RoIE1O IGFuZCBDTiBtdXN0IGJlIHBsYWNlZCBpbiB0aGUgc2FtZSBhZG1pbmlzdHJhdGl2ZSBkb21haW4o aG9tZSBkb21haW4gb3IgZm9yZWlnbiBkb21haW4oM0dQUCBob21lIHJvdXRlZCkpIGFuZCB0aGV5 IG11c3QgYmVsb25nIHRvIHNhbWUgaG9tZSBkb21haW4NCig0KSBNTiBhbmQgQ04gdW5kZXIgZGlm ZmVyZW50IE1BRyBhbmQgZGlmZmVyZW50IExNQShMTUExIGFuZCBMTUEyKS4gSGVyZSBNTiBhbmQg Q04gbXVzdCBiZSBwbGFjZWQgaW4gc2FtZSBhZG1pbnNpdHJhdGl2ZSBkb21haW4oaG9tZSBvciBm b3JlaWduIGRvbWFpbikgYW5kIExNQXMgc2hvdWxkIGFsc28gYmUgZnJvbSB0aGUgc2FtZSBhZG1p bnNpdHJhdGl2ZShob21lKSBkb21haW4uDQoNClNvLCBJIHRoaW5rIHRoYXQgTUFHIHRvIE1BRyBS TyBjYW4gd29yayB3aGVuIE1OIGFuZCBDTiBhcmUgcGxhY2VkIGluIHNhbWUgYWRtaW5zaXRhcnRp dmUgZG9tYWlucyBhcyBNYXJjbyBwb2ludGVkIG91dC4gSG93ZXZlciwgdGhleSBtYXkgYmVsb25n IHRvIGRpZmZlcmVudCBkb21haW5zKGhvbWUgZG9tYWlucyBtYXkgYmUgZGlmZmVyZW50KS4gQWdh aW4gYXMgTWFyY28gcG9pbnRlZCBvdXQgaXQgYWxsIGRlcGVuZCBvbiB0aGUgYXNzdW1wdGlvbnMg d2UgbWFrZSwgc3VjaCBhcyB3aGV0aGVyIExNQXMgY2FuIGludGVyYWN0IGFuZCBzbyBvbi4gQWxz byBjb21pbmcgdG8gYWRtaW5zaXRyYXRpdmUgZG9tYWluIGFuZCBQTUlQIGRvbWFpbiwgSSB0aGlu ayBQTUlQIGRvbWFpbiBhbmQgYWRtaW5pc3RyYXRpdmUgZG9tYWluIGNvaW5jaWRlcy4gWWVzLCBp biAzR1BQIHlvdSBjYW4gc2VlIHlvdXIgSE5QIGluIGFub3RoZXIgYWRtaW5zaXRhcnRpdmUgZG9t YWluLiBCdXQgdGhlIE1uIGlzIGF3YXJlIHRoYXQgaXQgaXMgYW5vdGhlciBhZG1pbmlzcmF0aXZl IGRvbWFpbiBhbHRob3VnaCBpdCBzZWVzIHRoZSBITlAgZnJvbSBob21lIGRvbWFpbi4gDQoNClNv LCBJIHRoaW5rIHdlIGNhbiBrZWVwIHRoZSBNQUcgdG8gTUFHIFJPIGZvciBjYXNlcyB3aGVyZSBN TiBhbmQgQ04gYXJlIHBsYWNlZCBpbiB0aGUgc2FtZSBhZG1pbnNpdHJhdGl2ZSBkb21haW4uDQoN ClRoYW5rcy4NCg0KQlIsDQpNb2hhbmENCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiBGcm9tOiBuZXRleHQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm5ldGV4dC1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYNCj4gT2YgTWFyY28gTGllYnNjaA0KPiBTZW50OiBUdWVzZGF5LCBB dWd1c3QgMTgsIDIwMDkgODozOSBQTQ0KPiBUbzogUWluIFd1DQo+IENjOiBuZXRleHRAaWV0Zi5v cmcNCj4gU3ViamVjdDogUmU6IFtuZXRleHRdIFBNSVA2IGFuZCByb2FtaW5nDQo+IA0KPiBoaSBR aW4sDQo+IA0KPiBRaW4gV3Ugc2NocmllYjoNCj4gPiBIaSwgTWFyY286DQo+ID4gIEkgYWdyZWUg dGhlIExvY2FsaXplZCByb3V0aW5nIG1lY2hhbmlzbSBjYW4gYmUgYXBwbGljYWJsZSB0byB0aGUN Cj4gc2NlbmFyaW8NCj4gPiAgd2hlcmUgdHdvIE1BR3MgaW4gY29tbXVuaWNhdGlvbiBhcmUgd2l0 aGluIHRoZSBzYW1lICphZG1pbmlzdHJhdGl2ZSoNCj4gPiBkb21haW4uSG93ZXZlciB0aGVyZSBh cmUgc3RpbGwgY29uZnVzaW9uIGJldHdlZW4gYWRtaW5pc3RyYXRpdmUgZG9tYWluDQo+ID4gYW5k IFBNSVAgZG9tYWluLiBCZWNhdXNlIFBNSVAgZG9tYWluIGNhbiBiZSB0YWtlbiBhcyBvbmUgYWRt aW5pc3RyYXRpdmUNCj4gPiAgZG9tYWluLCBob3dldmVyIG9uZSBhZG1pbmlzdHJhdGl2ZSBkb21h aW4gbWF5IGJlIG5vdCBQTUlQIGRvbWFpbiBidXQNCj4gPiBNSVAgZG9tYWluLiBTbyB3aGF0J3Mg dGhlIHNjb3BlIG9mIGFkbWluaXN0cmF0aXZlIGRvbWFpbiBhbmQgUE1JUA0KPiBkb21haW4/DQo+ ID4gaXQgaXMgbmVjZXNzYXJ5IHRvIGJlIGNsYXJpZmllZCwgYW0gSSByaWdodD8NCj4gPg0KPiBZ ZXMsIGJ1dCBJIGFtIG5vdCBzdXJlIHRoaXMgd2lsbCBicmluZyB1cyBmdXJ0aGVyLiBBcyBkaWZm ZXJlbmNlIHRvIHRoZQ0KPiBQTUlQdjYgc3BlY2lmaWNhdGlvbiwNCj4gd2UgaGFuZGxlIHNjZW5h cmlvcyBiZXR3ZWVuIHR3byBjb21tdW5pY2F0aW5nIE1Ocywgd2hpY2ggbWF5IGdldCBzZXJ2ZWQN Cj4gYnkgY29tcG9uZW50cw0KPiBmcm9tIGRpZmZlcmVudCBhZG1pbmlzdHJhdGl2ZSBkb21haW5z LiBTdXJlLCBhIFBNSVB2NiBkb21haW4gY2FuIGNvdmVyDQo+IG11bHRpcGxlIGFkbWluIGRvbWFp bnMuDQo+IEhlbmNlLCBJIHRoaW5rIGZvciB0aGUgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbiBpdCdz IHN1ZmZpY2llbnQgdG8gYXNzdW1lDQo+IHRoYXQsIHRvIHdvcmssIHRoZXJlIG11c3QNCj4gYmUg YSB0cnVzdCByZWxhdGlvbnNoaXAgYmV0d2VlbiBjb21wb25lbnRzIGV4Y2hhbmdpbmcgc2lnbmFs aW5nLiBTbyBmb3INCj4gdGhlIHByb3RvY29sIHNwZWNpZmljYXRpb24NCj4gSSB0aGluayBpdCdz IHN1ZmZpY2llbnQgdG8gbWFuZGF0ZSBhIHNlY3VyaXR5IGFzc29jaWF0aW9uIGJldHdlZW4gdGhl c2UNCj4gY29tcG9uZW50cyB0byBhdXRoZW50aWNhdGUNCj4gbWVzc2FnZXMuDQo+IA0KPiBtYXJj bw0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiA+IFJlZ2FyZHMhDQo+ID4gLVFpbg0KPiA+IC0t LS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4gPiBGcm9tOiAiTWFyY28gTGllYnNjaCIgPG1h cmNvLmxpZWJzY2hAbncubmVjbGFiLmV1Pg0KPiA+IFRvOiAiQWxwZXIgWWVnaW4iIDxhbHBlci55 ZWdpbkB5ZWdpbi5vcmc+DQo+ID4gQ2M6IDxuZXRleHRAaWV0Zi5vcmc+DQo+ID4gU2VudDogVHVl c2RheSwgQXVndXN0IDA0LCAyMDA5IDQ6MjYgUE0NCj4gPiBTdWJqZWN0OiBSZTogW25ldGV4dF0g UE1JUDYgYW5kIHJvYW1pbmcNCj4gPg0KPiA+DQo+ID4gSGkgQWxwZXIsIERlc2lyZSwgYWxsDQo+ ID4NCj4gPiBpZiB3ZSBhc3N1bWUgdGhhdCBQTUlQdjYgb3BlcmF0ZXMgYmV0d2VlbiB0aGUgTE1B IGluIHRoZSBVUyBhbmQgdGhlIE1BRw0KPiA+IGluIFN3ZWRlbiwgd2VsbCwgdGhlbiBhIHNlY3Vy aXR5IGFzc29jaWF0aW9uIGlzIGltcGxpY2l0LiBIZW5jZSwgdGhlcmUNCj4gPiBpcyBzb21lIGxl dmVsDQo+ID4gb2YgdHJ1c3QuRm9yIHRoZSBwcm90b2NvbCBzb2x1dGlvbiBpbiB0aGUgSUVURiwg dGhpcyBzaG91bGQgYmUgdGhlIG1haW4NCj4gPiByZXF1aXJlbWVudC4NCj4gPiBXaGVyZSB0aGVz ZSBjb21wb25lbnRzIGFyZSBmaW5hbGx5IGxvY2F0ZWQgaXMgZGVwbG95bWVudCBzcGVjaWZpYy4N Cj4gPg0KPiA+IFNhbWUgZm9yIGxvY2FsaXplZCByb3V0aW5nOiBXaGVuIGEgTUFHIGNhbiBjcmVh dGUgYSBiaW5kaW5nIGF0IHRoZSBMTUEsDQo+ID4gSSBkb24ndA0KPiA+IHNlZSBhIHByb2JsZW0g d2h5IHRoZSBMTUEgY2Fubm90IGNyZWF0ZSBhIHN0YXRlIGF0IHRoZSBNQUcgdG8gcGVyZm9ybQ0K PiA+IGxvY2FsaXplZA0KPiA+IHJvdXRpbmcuIFNBbWUgYXMgYWJvdmU6IEFzIGxvbmcgYXMgdGhl cmUgaXMgYW4gU0EgYmV0d2VlbiB0aGUgdHdvDQo+ID4gY29tcG9uZW50cy4NCj4gPg0KPiA+IEZy b20gdGhlIGRpc2N1c3Npb24gd2UgaGFkIGluIFN0b2NraG9sbSwgSSB0aGluayBmb3IgZGVwbG95 bWVudA0KPiA+IHBlcnNwZWN0aXZlIGl0J3MgbW9yZSBpbXBvcnRhbnQgdG8gaGF2ZSBib3RoIE1B R3MgKG1vYmlsZSAxIGFuZCBtb2JpbGUNCj4gMikgaW4gdGhlIHNhbWUNCj4gPiAqYWRtaW5pc3Ry YXRpdmUqIGRvbWFpbiAodG8gZGlzdGlndWlzaCBmcm9tIGEgUE1JUCBkb21haW4pLCBhcyBpbnRl ci1NQUcNCj4gb3BlcmF0aW9uIGJldHdlZW4NCj4gPiBhZG1pbmlzdHJhdGl2ZSBkb21haW5zIGNv bXByaXNlcyB0aGUga25vd3MgaXNzdWVzLg0KPiA+DQo+ID4gRm9yIHRoZSBwcm90b2NvbCBzcGVj aWZpY2F0aW9uOiBXZWxsLCBpdCBkb2VzIG5vdCBtYXR0ZXIuLiBhcyBsb25nIGFzDQo+IE1BR3Mg c2hhcmUgYSBzZWN1cml0eSBhc3NvY2lhdGlvbiBhbmQgY2FuIHNldCB1cCBhDQo+ID4gZm9yd2Fy ZGluZyB0dW5uZWwuDQo+ID4NCj4gPiBtYXJjbw0KPiA+DQo+ID4NCj4gPiBBbHBlciBZZWdpbiBz Y2hyaWViOg0KPiA+DQo+ID4+IEhpIERlc2lyZSwNCj4gPj4NCj4gPj4gUkZDIDUyMTM6DQo+ID4+ DQo+ID4+ICAgIFByb3h5IE1vYmlsZSBJUHY2IERvbWFpbiAoUE1JUHY2LURvbWFpbikNCj4gPj4N Cj4gPj4gICAgICAgUHJveHkgTW9iaWxlIElQdjYgZG9tYWluIHJlZmVycyB0byB0aGUgbmV0d29y ayB3aGVyZSB0aGUgbW9iaWxpdHkNCj4gPj4gICAgICAgbWFuYWdlbWVudCBvZiBhIG1vYmlsZSBu b2RlIGlzIGhhbmRsZWQgdXNpbmcgdGhlIFByb3h5IE1vYmlsZQ0KPiBJUHY2DQo+ID4+ICAgICAg IHByb3RvY29sIGFzIGRlZmluZWQgaW4gdGhpcyBzcGVjaWZpY2F0aW9uLiAgVGhlIFByb3h5IE1v YmlsZSBJUHY2DQo+ID4+ICAgICAgIGRvbWFpbiBpbmNsdWRlcyBsb2NhbCBtb2JpbGl0eSBhbmNo b3JzIGFuZCBtb2JpbGUgYWNjZXNzIGdhdGV3YXlzDQo+ID4+ICAgICAgIGJldHdlZW4gd2hpY2gg c2VjdXJpdHkgYXNzb2NpYXRpb25zIGNhbiBiZSBzZXQgdXAgYW5kDQo+ID4+ICAgICAgIGF1dGhv cml6YXRpb24gZm9yIHNlbmRpbmcgUHJveHkgQmluZGluZyBVcGRhdGVzIG9uIGJlaGFsZiBvZiB0 aGUNCj4gPj4gICAgICAgbW9iaWxlIG5vZGVzIGNhbiBiZSBlbnN1cmVkLg0KPiA+Pg0KPiA+Pg0K PiA+PiBJIHJlbWVtYmVyIHRoaXMgd2FzIHNwZWNpZmljYWxseSBkaXNjdXNzZWQgYW5kIHdlIGhh ZCBjb21lIHVwIHdpdGggYQ0KPiB0ZXh0DQo+ID4+IHRoYXQgcmVmZXJzIHRvICJsb2NhbCBtb2Jp bGl0eSBhbmNob3JzIGFuZCBtb2JpbGUgYWNjZXNzIGdhdGV3YXlzDQo+IGJldHdlZW4NCj4gPj4g d2hpY2ggc2VjdXJpdHkgYXNzb2NpYXRpb25zIGNhbiBiZSBzZXQgdXAiIGFzIHRoZSBsaW1pdGlu ZyBmYWN0b3IgdGhhdA0KPiBzZXRzDQo+ID4+IHRoZSBib3VuZGFyeS4gQW5kIHNlY3VyaXR5IGFz c29jaWF0aW9ucyBjYW4gYmUgc2V0dXAgYmV0d2VlbiBNQUdzIGFuZA0KPiBMTUFzDQo+ID4+IGJl bG9uZ2luZyB0byBzZXBhcmF0ZSBvcGVyYXRvcnMgd2hlbiB0aGVyZSBpcyBhIHJvYW1pbmcgYWdy ZWVtZW50Lg0KPiBXaU1BWA0KPiA+PiBhcmNoaXRlY3R1cmUgYWxyZWFkeSBkb2VzIHRoYXQuDQo+ ID4+DQo+ID4+IEFscGVyDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+ DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiA+Pj4gRnJvbTogRGVzaXJlIE91bGFpIFttYWlsdG86ZGVzaXJlLm91bGFpQGVyaWNzc29u LmNvbV0NCj4gPj4+IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDMwLCAyMDA5IDQ6MTMgUE0NCj4gPj4+ IFRvOiBBbHBlciBZZWdpbjsgbmV0ZXh0QGlldGYub3JnDQo+ID4+PiBTdWJqZWN0OiBSRSA6IFtu ZXRleHRdIFBNSVA2IGFuZCByb2FtaW5nDQo+ID4+Pg0KPiA+Pj4gSGkgQWxwZXIsDQo+ID4+Pg0K PiA+Pj4gICBTZWUgaW5saW5lIQ0KPiA+Pj4NCj4gPj4+IERlc2lyZQ0KPiA+Pj4NCj4gPj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+Pg0KPiA+Pj4gRGU6IG5ldGV4dC1i b3VuY2VzQGlldGYub3JnIGRlIGxhIHBhcnQgZGUgQWxwZXIgWWVnaW4NCj4gPj4+IERhdGU6IGpl dS4gMjAwOS0wNy0zMCAwODowMg0KPiA+Pj4gwDogbmV0ZXh0QGlldGYub3JnDQo+ID4+PiBPYmpl dCA6IFtuZXRleHRdIFBNSVA2IGFuZCByb2FtaW5nDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+ Pg0KPiA+Pj4NCj4gPj4+IENvbnRpbnVpbmcgdGhlIGRpc2N1c3Npb24gb24gdGhlIE1MLi4uLi4u DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IENvbnNpZGVyIG1vYmls ZTEgYW5kIG1vYmlsZTIgc3Vic2NyaWJlZCB0byBkYXRhIHNlcnZpY2UgaW4gVVNBLg0KPiA+Pj4N Cj4gPj4+IFRoZXkgYXJlIGluIFN3ZWRlbiwgYWNjZXNzaW5nIEludGVybmV0IGJ5ICJyb2FtaW5n IiB0byBhIFN3ZWRpc2gNCj4gPj4+IG9wZXJhdG9yIG5ldHdvcmsuDQo+ID4+Pg0KPiA+Pj4NCj4g Pj4+DQo+ID4+PiBEb2VzIFBNSVA2IG5vdCBzdXBwb3J0IHRoaXMgY2FzZSB3aGVyZSBNQUcgaXMg aW4gU3dlZGlzaCBvcGVyYXRvcg0KPiA+Pj4gbmV0d29yaywgYW5kIExNQSBpbiBVU0Egb3BlcmF0 b3IncyBuZXR3b3JrPyBJIHRoaW5rIHRoZSBhbnN3ZXIgaXMgeWVzLg0KPiA+Pj4NCj4gPj4+IFtE ZXNpcmVdOiAgIEkgdGhpbmsgUE1JUDYgYXMgZGVmaW5lZCBpbiBSRkM1MjEzIGRvZXMgbm90IHN1 cHBvcnQgdGhpcw0KPiA+Pj4gc2NlbmFyaW8gYXMgdGhlIE1BRyBhcmUgbm90IGluIHRoZSBzYW1l IFBNSVAgZG9tYWluLiBIb3dldmVyLCBTRE9zDQo+IGxpa2UNCj4gPj4+IDNHUFAgc3VwcG9ydHMg aG9tZSB0dW5uZWxsaW5nLg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gV291bGRuJ3Qgd2Ug d2FudCB0byBvcHRpbWl6ZSB0aGUgcGF0aCBiZXR3ZWVuIG1vYmlsZTEgYW5kIG1vYmlsZTIgdG8N Cj4gPj4+IHNhdmUgdGhlIHRyYWZmaWMgZnJvbSBtYWtpbmcgdGhlIHVubmVjZXNzYXJ5IFVTQSB0 cmlwPyBJIHRoaW5rIHRoZQ0KPiA+Pj4gYW5zd2VyIGlzIHllcyBhZ2Fpbi4NCj4gPj4+DQo+ID4+ PiBbRGVzaXJlXTogSSBhZ3JlZSB0aGF0IGl0IGlzIGFuIGludGVyZXN0aW5nIG9wdGltaXphdGlv bi4gQnV0IHdlIG5lZWQNCj4gPj4+IGZpcnN0IHRvIGNsYXJpZnkgdGhlIHJlbGF0aW9uIGJldHdl ZW4gdGhlIE1BRyBpbiBzd2VkZW4gYW5kIHRoZSBMTUEgaW4NCj4gPj4+IFVTQS4gU28gd2UgbmVl ZCB0byBzcGVjaWZ5IFBNSVA2IHJvYW1pbmcgYmVmb3JlIHRhbGtpbmcgYWJvdXQNCj4gTG9jYWxp emVkDQo+ID4+PiByb3V0aW5nIGluIFBNSVA2IHJvYW1pbmcuDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+ DQo+ID4+PiBDb21tZW50cz8NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IEFscGVyDQo+ID4+ Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+ DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiBuZXRl eHQgbWFpbGluZyBsaXN0DQo+ID4+IG5ldGV4dEBpZXRmLm9yZw0KPiA+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGV4dA0KPiA+Pg0KPiA+Pg0KPiA+DQo+ID4NCj4g PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IG5l dGV4dCBtYWlsaW5nIGxpc3QNCj4gPiBuZXRleHRAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGV4dA0KPiANCj4gDQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG5ldGV4dCBtYWlsaW5nIGxpc3QN Cj4gbmV0ZXh0QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbmV0ZXh0 From Mohana.Jeyatharan@sg.panasonic.com Tue Aug 18 20:42:18 2009 Return-Path: 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 ; 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 ; 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 ; 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" To: "Qin Wu" , "Marco Liebsch" 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 >=20 > 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. >=20 > Regards! > -Qin > ----- Original Message ----- > From: "Mohana Jeyatharan" > To: "Marco Liebsch" ; "Qin Wu" > > Cc: > Sent: Wednesday, August 19, 2009 9:54 AM > Subject: RE: [netext] PMIP6 and roaming >=20 >=20 > Hi all, >=20 > 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. >=20 > (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. >=20 > 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. >=20 > So, I think we can keep the MAG to MAG RO for cases where MN and CN = are > placed in the same adminsitrative domain. >=20 > Thanks. >=20 > BR, > Mohana >=20 > > -----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" > > > To: "Alper Yegin" > > > Cc: > > > 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 > > >>> =C0: 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 From sunseawq@huawei.com Wed Aug 19 20:45:01 2009 Return-Path: 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 A5C2928C115 for ; Wed, 19 Aug 2009 20:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.127 X-Spam-Level: *** X-Spam-Status: No, score=3.127 tagged_above=-999 required=5 tests=[AWL=-2.620, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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, 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 V9tTIu1Oe2bX for ; Wed, 19 Aug 2009 20:45:00 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id F3A893A6BBF for ; Wed, 19 Aug 2009 20:44:47 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KON006USP2IQ2@szxga02-in.huawei.com> for netext@ietf.org; Thu, 20 Aug 2009 11:44:42 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KON005TJP2I62@szxga02-in.huawei.com> for netext@ietf.org; Thu, 20 Aug 2009 11:44:42 +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 <0KON0034JP2HHV@szxml04-in.huawei.com> for netext@ietf.org; Thu, 20 Aug 2009 11:44:42 +0800 (CST) Date: Thu, 20 Aug 2009 11:44:40 +0800 From: Qin Wu To: Mohana Jeyatharan , Marco Liebsch Message-id: <011001ca2148$8c8356a0$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: <5F09D220B62F79418461A978CA0921BD037FA4D8@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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 03:45:01 -0000 SGksIE1vaGFuYToNClRoYW5rIGZvciB5b3VyIHJlcGx5LiBJIHRoaW5rIDNHUFAgY2FzZSB5b3Ug bWVudGlvbmVkIGlzIGEgZ29vZCBleGFtcGxlIHRvIGhlbHAgdXMgdW5kZXJzdGFuZCB3aGF0IFBN SVAgZG9tYWluIHJlYWxseSBpcy4NCkZyb20gM0dQUCBkZXBsb3ltZW50IHBlcnNwZWN0aXZlLCBJ IHdvdWxkIGFncmVlIEhQTE1OIG9yIFZQTE1OIGFyZSB0YWtlbiBhcyBhbiBleGFtcGxlIG9mIFBN SVAgZG9tYWluLg0KSW4gdGhpcyBzZW5zZSwgaXQgc2VlbXMgdGhhdCAgYWxsIHRoZSBtb2JpbGl0 eSBlbnRpdHkoaS5lLiwgTU4ncyBMTUEsIE1OJ3MgTUFHLCBDTidzIExNQSwgQ04nIE1BRykgYXJl IGxvY2F0ZWQgaW4gdGhlIHNhbWUgVlBMTU4uDQpJIGFncmVlIGl0IGlzIGEgcHJhY3RpY2FsIHNj ZW5hcmlvIHRvIHdoaWNoIHdlIGNhbiBhcHBseSBsb2NhbGl6ZWQgcm91dGluZyAuIEhvd2V2ZXIg bG9jYWxpemVkIHJvdXRpbmcgY2FuIGFsc28gYXBwbGllZCB0byB0aGUgc2NlbmFyaW8gd2hlcmUg dHdvIE1BR3MNCmluIGNvbW11bmNpYXRpb24gYXJlIGxvY2F0ZWQgaW4gdGhlIFZQTE1OIHdoaWxl IE1OJ3MgTE1BIGFuZCBDTidzIE1OIGFyZSBsb2NhdGVkIGluIHRoZSBzYW1lIG9yIGRpZmZlcmVu dCBIUExNTnMsIGFtIEkgcmlnaHQ/DQoNClNvIHRoZSBvcGVuIGlzc3VlIHdlIGhhdmUgaGVyZSBp cw0KU2hhbGwgd2UgcmVzdHJpY3QgYWxsIHRoZSBtb2JpbGl0eSBlbnRpdGllcyBpbmNsdWRpbmcg TU4ncyBNQUcsIE1OJ3MgTE1BLCBDTidzIE1BRywgQ04ncyBMTUEgaW4gdGhlIHNhbWUgVlBMTU4g b3IgSFBMTU4/IA0Kb3INCldlIGp1c3QgYXNrIE1OJ3MgTUFHIGFuZCBDTidzIE1BRyB0byBiZSBs b2NhdGVkIGluIHRoZSBzYW1lIFZQTE1OIGFuZCBkb24ndCBjYXJlIGFib3V0IHdoZXJlIE1OJ3Mg TE1BIGFuZCBDTidzIExNQSBhcmUuDQpJZiBTbywgSSBhbSBpbnRlcmVzdGVkIHRvIGtub3cgV0cg Y29uc2Vuc3VzIG9uIHRoaXMuDQoNClJlZ2FyZHMNCi1RaW4NCi0tLS0tIE9yaWdpbmFsIE1lc3Nh Z2UgLS0tLS0gDQpGcm9tOiAiTW9oYW5hIEpleWF0aGFyYW4iIDxNb2hhbmEuSmV5YXRoYXJhbkBz Zy5wYW5hc29uaWMuY29tPg0KVG86ICJRaW4gV3UiIDxzdW5zZWF3cUBodWF3ZWkuY29tPjsgIk1h cmNvIExpZWJzY2giIDxtYXJjby5saWVic2NoQG53Lm5lY2xhYi5ldT4NCkNjOiA8bmV0ZXh0QGll dGYub3JnPg0KU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMTksIDIwMDkgMTE6MzUgQU0NClN1Ympl Y3Q6IFJFOiBbbmV0ZXh0XSBQTUlQNiBhbmQgcm9hbWluZw0KDQoNCkhpIFFpbiwNCg0KSSBhZ3Jl ZSB0aGF0IHRoZXJlIGlzIG5vIHVucWl1ZSB3YXkgdG8gZGVmaW5lIFBNSVAgZG9tYWluIGFuZCBh ZG1pbmlzdHJhdGl2ZSBkb21haW4uIEJ1dCwgSSBndWVzcyB3ZSBjYW4gZ2l2ZSBpdCBzb21lIGFz c3VtcHRpb25zLiBJZiBMTUFzIGluIGFuIGFkbWluaXN0cmF0aXZlIGRvbWFpbiBrbm93IGVhY2gg b3RoZXIgc3RhdGUsIHdlIGNhbiBjYWxsIGl0IHNhbWUgYWRtaW5zaXRyYXRpdmUgZG9tYWluL1BN SVAgZG9tYWluLg0KDQpIb3dldmVyLCBpbiAzR1BQIGhvbWUgcm91dGVkIGNhc2UsIHRoZSBNTiBt YXkgcmVjZWl2ZSBob21lIHNlcnZpY2VzIHZpYSBob21lIHJvdXRlZCBtZWNoYW5pc20gYnV0LCBp dCBpcyBwbGFjZWQgaW4gYW5vdGhlciBhZG1pbmlzdHJhdGl2ZSBkb21haW4uIEZvciBleGFtcGxl IHRoZSBMTUFzIGluIHRoZSBkaWZmZXJlbnQgZG9tYWlucyBtYXkgbm90IGtub3cgZWFjaCBvdGhl ci4gSSB0aGluayBpZiBldmVyeSBuZXR3b3JrIGVudGl0aXkgaW4gUE1JUCBkb21haW4ga25vd3Mg b3RoZXIgbmV0d29yayBlbnR0aWVzIGFuZCBjYW4gZWFzaWx5IGNyZWF0ZSBzZWN1cml0eSBhc3Nv Y2lhdGlvbnMgb3IgYWxsb3dlZCB0byBjcmVhdGUgc2VjdWl0eSBhc3NvY2lhdGlvbnMobm90IHdv cnJ5aW5nIGFib3V0IHJvYW1pbmcgYWdyZWVtZW50KSwgd2UgY2FuIGVhc2lseSBjbGFzc2lmaXkg YXMgYSBzaW5nbGUgUE1JUCBkb21haW4uIEFnYWluIHRoaXMgaXMgbXkgb3duIGp1ZGdtZW50LiBU aHVzIHRoZSBob21lIHJvdXRlZCBjYXNlIG1heSBub3QgZmFsbCBpbnRvIHNpbmdsZSBhZG1pbmlz dHJhdGl2ZSBkb21haW4uDQoNCg0KPmluIG1hbnkgY2FzZXMsIG9uZSBQTUlQIGRvbWFpbiBjYW4g Y292ZXIgbXVsdGlwbGUgYWRtaW5zdHJhdGl2ZQ0KPiBkb21haW5zLiBIb3dldmVyIGhvdyB0byBk ZWZpbmUgb25lIGFkbWluaXN0cmF0aXZlIGRvbWFpbj8gSW4geW91cg0KPiB1bmRlcnN0YW5kaW5n LCBvbmUgYWRtaW5pc3RyYXRpdmUgZG9tYWluIGNhbiBiZSBleGFtcGxpZmllZCBhcyBvbmUgc3Vi bmV0DQo+IG9yIGEgbG9naWNhbCBkaXZpc2lvbiBvZiBvbmUgYWNjZXNzIG5ldHdvcmsgaW4gM0dQ UCBzY2VuYXJpbz8gYW0gSSByaWdodD8NCj4gSXMgaXQgIHdoYXQgd2UgdW5kZXJzdGFuZCBmb3Ig dGhlIGRlZmluaXRpb24gb2YgYWRtaW5pdHJhdGl2ZSBkb21haW4/DQogV2VsbCBpbiAzR1BQIGNh c2UsIEkgYWdyZWUsIGV2ZW4gd2l0aGluIG9uZSBIUExNTihvbmUgYWRtaW5pc3RhcnRpdmUgZG9t YWluIG9mIE1OKSBtdWx0aXBsZSBvcGVyYXRvcnMgY2FuIGhhbmRsZSBkaWZmZXJlbnQgYWNjZXNz IG5ldHdvcmtzLiBIZXJlIEkgd291bGQgbm90IHJlYWxseSBsb29rIGF0IHRoZSBncmFudWxhcml0 eSBvZiBhY2Nlc3MgbmV0d29yayB0byBkZWZpbmUgdGhlIFBNSVAvYWRtaW5zaXRyYXRpdmUgZG9t YWluLCBidXQgd2lsbCBsb29rIGF0IEhQTE1OIGluIGdlbmVyYWwuIEJ1dCwgbm93IHdlIGFyZSBi cmVha2luZyB0aGUgTUFHIHRvIE1BRyBSTyBzY2VuYXJpbyBpbnRvIHRoZSBhY2Nlc3MgdHlwZXMg dGllZCB0byB0aGUgTUFHIGFuZCB3aGV0aGVyIHRoZXJlIHdpbGwgYmUgYWdyZWVtZW50IGluIGVz dGFibGlzaGluZyB0dW5uZWxzIGJldHdlZW4gc3VjaCBNQUdzLiBJIHRoaW5rIGlmIExNQSBpcyBp bnZvbHZlZCBpbiBlc3RhYmxpc2hpbmcgTUFHIHRvIE1BRyBSTywgaXQgbWF5IGtub3cgd2hldGhl ciBzdWNoIHR1bm5lbGluZyBpcyBhbGxvd2VkLg0KDQpTbyBJIHRoaW5rIGl0IGlzIGJldHRlciB0 byBpbml0aWFsbHkgc2F5IEhQTE1OIGlzIGxpa2Ugb25lIGFkbWluc2l0cmF0aXZlIG9yIFBNSVAg ZG9tYWluLiBUaGVuIGxhdGVyIG5hcnJvdyBvciBicmVhayBITVBMTiBpbnRvIGZ1cnRoZXIgc3Vi IGRvbWFpbnMgYW5kIGxvb2sgYXQgdGhlIGZlYXNpYmlsaXR5IG9mIE1BRyB0byBNQUcgUk8uIEkg dGhpbmsgaXQgd291bGQgYmUgZ29vZCB0byBjYXB0dXJlIHRoaXMgc2NlbmFyaW8gKGludGVyIDNH UFAgc3ViIGRpdmlzaW9ucykgYWxzbyBpbiB0aGUgUFMgZHJhZnQuDQoNCkJSLA0KTW9oYW5hDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFFpbiBXdSBbbWFpbHRvOnN1bnNl YXdxQGh1YXdlaS5jb21dDQo+IFNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDE5LCAyMDA5IDExOjA2 IEFNDQo+IFRvOiBNb2hhbmEgSmV5YXRoYXJhbjsgTWFyY28gTGllYnNjaA0KPiBDYzogbmV0ZXh0 QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbbmV0ZXh0XSBQTUlQNiBhbmQgcm9hbWluZw0KPiAN Cj4gSGksIE1vaGFuYSBhbmQgYWxsOg0KPiBBcyB5b3UgbWVudGlvbmVkLCBQTUlQIGRvbWFpbiBh bmQgYWRtaW5pc3RyYXRpdmUgZG9tYWluIGNvaW5jaWRlcywgSSBhZ3JlZS4NCj4gZS5nLixpbiBt YW55IGNhc2VzLCBvbmUgUE1JUCBkb21haW4gY2FuIGNvdmVyIG11bHRpcGxlIGFkbWluc3RyYXRp dmUNCj4gZG9tYWlucy4gSG93ZXZlciBob3cgdG8gZGVmaW5lIG9uZSBhZG1pbmlzdHJhdGl2ZSBk b21haW4/IEluIHlvdXINCj4gdW5kZXJzdGFuZGluZywgb25lIGFkbWluaXN0cmF0aXZlIGRvbWFp biBjYW4gYmUgZXhhbXBsaWZpZWQgYXMgb25lIHN1Ym5ldA0KPiBvciBhIGxvZ2ljYWwgZGl2aXNp b24gb2Ygb25lIGFjY2VzcyBuZXR3b3JrIGluIDNHUFAgc2NlbmFyaW8/IGFtIEkgcmlnaHQ/DQo+ IElzIGl0ICB3aGF0IHdlIHVuZGVyc3RhbmQgZm9yIHRoZSBkZWZpbml0aW9uIG9mIGFkbWluaXRy YXRpdmUgZG9tYWluPw0KPiBGcm9tIG15IHVuZGVyc3RhbmRpbmcsIHRoZSB0ZXJtIG9mICJhZG1p bmlzdHJhdGl2ZSBkb21haW4iIGlzIG1vcmUgZ2VuZXJpYw0KPiB0ZXJtIGFuZCB2ZXJ5IGNvbmZ1 c2luZywgZS5nLCBJIGNhbiBzYXkgb25lIEFBQSBkb21haW4gaXMgYSBhZG1pbmlzdHJhdGl2ZQ0K PiBkb21haW4gdG9vIG9yIGFkbWluc3RyYXRpdmUgZG9tYWluIGNhbiBiZSBleGFtcGxpZmllZCBh cyAqYSBnZW9ncmFwaGljDQo+IG1vYmlsaXR5IGRvbWFpbiouIFNvIGlmIHdlIGNvbnNpZGVyIHRv IHVzZSB0aGlzIHRlcm0gaW4gdGhlIFBTIGRyYWZ0LCB3ZQ0KPiBzaG91bGQgYmUgdmVyeSBjYXJl ZnVsIHdoYXQgaXQgZXhhY3QgbWVhbnMuDQo+IA0KPiBSZWdhcmRzIQ0KPiAtUWluDQo+IC0tLS0t IE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4gRnJvbTogIk1vaGFuYSBKZXlhdGhhcmFuIiA8TW9o YW5hLkpleWF0aGFyYW5Ac2cucGFuYXNvbmljLmNvbT4NCj4gVG86ICJNYXJjbyBMaWVic2NoIiA8 bWFyY28ubGllYnNjaEBudy5uZWNsYWIuZXU+OyAiUWluIFd1Ig0KPiA8c3Vuc2Vhd3FAaHVhd2Vp LmNvbT4NCj4gQ2M6IDxuZXRleHRAaWV0Zi5vcmc+DQo+IFNlbnQ6IFdlZG5lc2RheSwgQXVndXN0 IDE5LCAyMDA5IDk6NTQgQU0NCj4gU3ViamVjdDogUkU6IFtuZXRleHRdIFBNSVA2IGFuZCByb2Ft aW5nDQo+IA0KPiANCj4gSGkgYWxsLA0KPiANCj4gSSBqdXN0IGZvbGxvd2VkIHRoZSB0aHJlYWQs IGFuZCB0cmllZCB0byBsb29rIGludG8gdGhlIHNjZW5hcmlvcyB3ZSBoYXZlDQo+IGluIHRoZSBS TyBQUyBkcmFmdC4gV2UgaGF2ZSBjbGFzc2lmaWVkIHRoZSBmb3VyIHNjZW5hcmlvcyBpbiBQUyBk cmFmdCBmb3INCj4gTUFHIGxvY2FsaXplZCByb3V0aW5nLg0KPiANCj4gKDEpTU4gYW5kIENOIHVu ZGVyIHNhbWUgTUFHIGFuZCBib3RoIE1OIGFuZCBDTiBiZWxvbmcgdG8gc2FtZSBMTUEuIEhlcmUg TU4NCj4gYW5kIENOIG5lZWQgdG8gYmUgcGxhY2VkIGluIHRoZSBzYW1lIGFkbW5pc3RyYXRpdmUg ZG9tYWluKGNhbmJlIHRoZWlyIGhvbWUNCj4gZG9tYWluIG9yIGJlIGEgZm9yZWlnbiBkb21haW4o M0dQUCBob21lIHJvdXRlZCkpIGFuZCB0aGV5IG5lZWQgdG8gYmVsb25nDQo+IHRvIHNhbWUgaG9t ZSBkb21haW4uDQo+ICgyKSBNbiBhbmQgQ04gdW5kZXIgc2FtZSBNQUcgYnV0IGRpZmZlcmVudCBM TUFzKE1uIGJlbG9uZyB0byBMTUExIGFuZCBDTg0KPiBiZWxvbmcgdG8gTE1BMikuIEhlcmUsIE1O IGFuZCBDTiBuZWVkIHRvIGJlIHBsYWNlZCBpbiBzYW1lIGFkbWluaXN0cmF0aXZlDQo+IGRvbWFp biBidXQgbWF5IGJlbG9uZyB0byBkaWZmZXJlbnQgYWRtaW5pc3RyYXRpdmUoaG9tZSkgZG9tYWlu Lg0KPiAoMykgTU4gYW5kIENOIHVuZGVyIGRpZmZlcmVudCBNQUdzIGJ1dCBzYW1lIExNQS4gSGVy ZSBmb3IgTUFHIHRvIE1BRyBSTyB0bw0KPiB3b3JrLCBib3RoIE1OIGFuZCBDTiBtdXN0IGJlIHBs YWNlZCBpbiB0aGUgc2FtZSBhZG1pbmlzdHJhdGl2ZSBkb21haW4oaG9tZQ0KPiBkb21haW4gb3Ig Zm9yZWlnbiBkb21haW4oM0dQUCBob21lIHJvdXRlZCkpIGFuZCB0aGV5IG11c3QgYmVsb25nIHRv IHNhbWUNCj4gaG9tZSBkb21haW4NCj4gKDQpIE1OIGFuZCBDTiB1bmRlciBkaWZmZXJlbnQgTUFH IGFuZCBkaWZmZXJlbnQgTE1BKExNQTEgYW5kIExNQTIpLiBIZXJlDQo+IE1OIGFuZCBDTiBtdXN0 IGJlIHBsYWNlZCBpbiBzYW1lIGFkbWluc2l0cmF0aXZlIGRvbWFpbihob21lIG9yIGZvcmVpZ24N Cj4gZG9tYWluKSBhbmQgTE1BcyBzaG91bGQgYWxzbyBiZSBmcm9tIHRoZSBzYW1lIGFkbWluc2l0 cmF0aXZlKGhvbWUpIGRvbWFpbi4NCj4gDQo+IFNvLCBJIHRoaW5rIHRoYXQgTUFHIHRvIE1BRyBS TyBjYW4gd29yayB3aGVuIE1OIGFuZCBDTiBhcmUgcGxhY2VkIGluIHNhbWUNCj4gYWRtaW5zaXRh cnRpdmUgZG9tYWlucyBhcyBNYXJjbyBwb2ludGVkIG91dC4gSG93ZXZlciwgdGhleSBtYXkgYmVs b25nIHRvDQo+IGRpZmZlcmVudCBkb21haW5zKGhvbWUgZG9tYWlucyBtYXkgYmUgZGlmZmVyZW50 KS4gQWdhaW4gYXMgTWFyY28gcG9pbnRlZA0KPiBvdXQgaXQgYWxsIGRlcGVuZCBvbiB0aGUgYXNz dW1wdGlvbnMgd2UgbWFrZSwgc3VjaCBhcyB3aGV0aGVyIExNQXMgY2FuDQo+IGludGVyYWN0IGFu ZCBzbyBvbi4gQWxzbyBjb21pbmcgdG8gYWRtaW5zaXRyYXRpdmUgZG9tYWluIGFuZCBQTUlQIGRv bWFpbiwNCj4gSSB0aGluayBQTUlQIGRvbWFpbiBhbmQgYWRtaW5pc3RyYXRpdmUgZG9tYWluIGNv aW5jaWRlcy4gWWVzLCBpbiAzR1BQIHlvdQ0KPiBjYW4gc2VlIHlvdXIgSE5QIGluIGFub3RoZXIg YWRtaW5zaXRhcnRpdmUgZG9tYWluLiBCdXQgdGhlIE1uIGlzIGF3YXJlDQo+IHRoYXQgaXQgaXMg YW5vdGhlciBhZG1pbmlzcmF0aXZlIGRvbWFpbiBhbHRob3VnaCBpdCBzZWVzIHRoZSBITlAgZnJv bSBob21lDQo+IGRvbWFpbi4NCj4gDQo+IFNvLCBJIHRoaW5rIHdlIGNhbiBrZWVwIHRoZSBNQUcg dG8gTUFHIFJPIGZvciBjYXNlcyB3aGVyZSBNTiBhbmQgQ04gYXJlDQo+IHBsYWNlZCBpbiB0aGUg c2FtZSBhZG1pbnNpdHJhdGl2ZSBkb21haW4uDQo+IA0KPiBUaGFua3MuDQo+IA0KPiBCUiwNCj4g TW9oYW5hDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogbmV0 ZXh0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpuZXRleHQtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmDQo+ID4gT2YgTWFyY28gTGllYnNjaA0KPiA+IFNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAx OCwgMjAwOSA4OjM5IFBNDQo+ID4gVG86IFFpbiBXdQ0KPiA+IENjOiBuZXRleHRAaWV0Zi5vcmcN Cj4gPiBTdWJqZWN0OiBSZTogW25ldGV4dF0gUE1JUDYgYW5kIHJvYW1pbmcNCj4gPg0KPiA+IGhp IFFpbiwNCj4gPg0KPiA+IFFpbiBXdSBzY2hyaWViOg0KPiA+ID4gSGksIE1hcmNvOg0KPiA+ID4g IEkgYWdyZWUgdGhlIExvY2FsaXplZCByb3V0aW5nIG1lY2hhbmlzbSBjYW4gYmUgYXBwbGljYWJs ZSB0byB0aGUNCj4gPiBzY2VuYXJpbw0KPiA+ID4gIHdoZXJlIHR3byBNQUdzIGluIGNvbW11bmlj YXRpb24gYXJlIHdpdGhpbiB0aGUgc2FtZSAqYWRtaW5pc3RyYXRpdmUqDQo+ID4gPiBkb21haW4u SG93ZXZlciB0aGVyZSBhcmUgc3RpbGwgY29uZnVzaW9uIGJldHdlZW4gYWRtaW5pc3RyYXRpdmUg ZG9tYWluDQo+ID4gPiBhbmQgUE1JUCBkb21haW4uIEJlY2F1c2UgUE1JUCBkb21haW4gY2FuIGJl IHRha2VuIGFzIG9uZQ0KPiBhZG1pbmlzdHJhdGl2ZQ0KPiA+ID4gIGRvbWFpbiwgaG93ZXZlciBv bmUgYWRtaW5pc3RyYXRpdmUgZG9tYWluIG1heSBiZSBub3QgUE1JUCBkb21haW4gYnV0DQo+ID4g PiBNSVAgZG9tYWluLiBTbyB3aGF0J3MgdGhlIHNjb3BlIG9mIGFkbWluaXN0cmF0aXZlIGRvbWFp biBhbmQgUE1JUA0KPiA+IGRvbWFpbj8NCj4gPiA+IGl0IGlzIG5lY2Vzc2FyeSB0byBiZSBjbGFy aWZpZWQsIGFtIEkgcmlnaHQ/DQo+ID4gPg0KPiA+IFllcywgYnV0IEkgYW0gbm90IHN1cmUgdGhp cyB3aWxsIGJyaW5nIHVzIGZ1cnRoZXIuIEFzIGRpZmZlcmVuY2UgdG8gdGhlDQo+ID4gUE1JUHY2 IHNwZWNpZmljYXRpb24sDQo+ID4gd2UgaGFuZGxlIHNjZW5hcmlvcyBiZXR3ZWVuIHR3byBjb21t dW5pY2F0aW5nIE1Ocywgd2hpY2ggbWF5IGdldCBzZXJ2ZWQNCj4gPiBieSBjb21wb25lbnRzDQo+ ID4gZnJvbSBkaWZmZXJlbnQgYWRtaW5pc3RyYXRpdmUgZG9tYWlucy4gU3VyZSwgYSBQTUlQdjYg ZG9tYWluIGNhbiBjb3Zlcg0KPiA+IG11bHRpcGxlIGFkbWluIGRvbWFpbnMuDQo+ID4gSGVuY2Us IEkgdGhpbmsgZm9yIHRoZSBwcm90b2NvbCBzcGVjaWZpY2F0aW9uIGl0J3Mgc3VmZmljaWVudCB0 byBhc3N1bWUNCj4gPiB0aGF0LCB0byB3b3JrLCB0aGVyZSBtdXN0DQo+ID4gYmUgYSB0cnVzdCBy ZWxhdGlvbnNoaXAgYmV0d2VlbiBjb21wb25lbnRzIGV4Y2hhbmdpbmcgc2lnbmFsaW5nLiBTbyBm b3INCj4gPiB0aGUgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbg0KPiA+IEkgdGhpbmsgaXQncyBzdWZm aWNpZW50IHRvIG1hbmRhdGUgYSBzZWN1cml0eSBhc3NvY2lhdGlvbiBiZXR3ZWVuIHRoZXNlDQo+ ID4gY29tcG9uZW50cyB0byBhdXRoZW50aWNhdGUNCj4gPiBtZXNzYWdlcy4NCj4gPg0KPiA+IG1h cmNvDQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4gPiBSZWdhcmRzIQ0KPiA+ID4g LVFpbg0KPiA+ID4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPiA+ID4gRnJvbTogIk1h cmNvIExpZWJzY2giIDxtYXJjby5saWVic2NoQG53Lm5lY2xhYi5ldT4NCj4gPiA+IFRvOiAiQWxw ZXIgWWVnaW4iIDxhbHBlci55ZWdpbkB5ZWdpbi5vcmc+DQo+ID4gPiBDYzogPG5ldGV4dEBpZXRm Lm9yZz4NCj4gPiA+IFNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAwNCwgMjAwOSA0OjI2IFBNDQo+ID4g PiBTdWJqZWN0OiBSZTogW25ldGV4dF0gUE1JUDYgYW5kIHJvYW1pbmcNCj4gPiA+DQo+ID4gPg0K PiA+ID4gSGkgQWxwZXIsIERlc2lyZSwgYWxsDQo+ID4gPg0KPiA+ID4gaWYgd2UgYXNzdW1lIHRo YXQgUE1JUHY2IG9wZXJhdGVzIGJldHdlZW4gdGhlIExNQSBpbiB0aGUgVVMgYW5kIHRoZQ0KPiBN QUcNCj4gPiA+IGluIFN3ZWRlbiwgd2VsbCwgdGhlbiBhIHNlY3VyaXR5IGFzc29jaWF0aW9uIGlz IGltcGxpY2l0LiBIZW5jZSwgdGhlcmUNCj4gPiA+IGlzIHNvbWUgbGV2ZWwNCj4gPiA+IG9mIHRy dXN0LkZvciB0aGUgcHJvdG9jb2wgc29sdXRpb24gaW4gdGhlIElFVEYsIHRoaXMgc2hvdWxkIGJl IHRoZQ0KPiBtYWluDQo+ID4gPiByZXF1aXJlbWVudC4NCj4gPiA+IFdoZXJlIHRoZXNlIGNvbXBv bmVudHMgYXJlIGZpbmFsbHkgbG9jYXRlZCBpcyBkZXBsb3ltZW50IHNwZWNpZmljLg0KPiA+ID4N Cj4gPiA+IFNhbWUgZm9yIGxvY2FsaXplZCByb3V0aW5nOiBXaGVuIGEgTUFHIGNhbiBjcmVhdGUg YSBiaW5kaW5nIGF0IHRoZSBMTUEsDQo+ID4gPiBJIGRvbid0DQo+ID4gPiBzZWUgYSBwcm9ibGVt IHdoeSB0aGUgTE1BIGNhbm5vdCBjcmVhdGUgYSBzdGF0ZSBhdCB0aGUgTUFHIHRvIHBlcmZvcm0N Cj4gPiA+IGxvY2FsaXplZA0KPiA+ID4gcm91dGluZy4gU0FtZSBhcyBhYm92ZTogQXMgbG9uZyBh cyB0aGVyZSBpcyBhbiBTQSBiZXR3ZWVuIHRoZSB0d28NCj4gPiA+IGNvbXBvbmVudHMuDQo+ID4g Pg0KPiA+ID4gRnJvbSB0aGUgZGlzY3Vzc2lvbiB3ZSBoYWQgaW4gU3RvY2tob2xtLCBJIHRoaW5r IGZvciBkZXBsb3ltZW50DQo+ID4gPiBwZXJzcGVjdGl2ZSBpdCdzIG1vcmUgaW1wb3J0YW50IHRv IGhhdmUgYm90aCBNQUdzIChtb2JpbGUgMSBhbmQgbW9iaWxlDQo+ID4gMikgaW4gdGhlIHNhbWUN Cj4gPiA+ICphZG1pbmlzdHJhdGl2ZSogZG9tYWluICh0byBkaXN0aWd1aXNoIGZyb20gYSBQTUlQ IGRvbWFpbiksIGFzIGludGVyLQ0KPiBNQUcNCj4gPiBvcGVyYXRpb24gYmV0d2Vlbg0KPiA+ID4g YWRtaW5pc3RyYXRpdmUgZG9tYWlucyBjb21wcmlzZXMgdGhlIGtub3dzIGlzc3Vlcy4NCj4gPiA+ DQo+ID4gPiBGb3IgdGhlIHByb3RvY29sIHNwZWNpZmljYXRpb246IFdlbGwsIGl0IGRvZXMgbm90 IG1hdHRlci4uIGFzIGxvbmcgYXMNCj4gPiBNQUdzIHNoYXJlIGEgc2VjdXJpdHkgYXNzb2NpYXRp b24gYW5kIGNhbiBzZXQgdXAgYQ0KPiA+ID4gZm9yd2FyZGluZyB0dW5uZWwuDQo+ID4gPg0KPiA+ ID4gbWFyY28NCj4gPiA+DQo+ID4gPg0KPiA+ID4gQWxwZXIgWWVnaW4gc2NocmllYjoNCj4gPiA+ DQo+ID4gPj4gSGkgRGVzaXJlLA0KPiA+ID4+DQo+ID4gPj4gUkZDIDUyMTM6DQo+ID4gPj4NCj4g PiA+PiAgICBQcm94eSBNb2JpbGUgSVB2NiBEb21haW4gKFBNSVB2Ni1Eb21haW4pDQo+ID4gPj4N Cj4gPiA+PiAgICAgICBQcm94eSBNb2JpbGUgSVB2NiBkb21haW4gcmVmZXJzIHRvIHRoZSBuZXR3 b3JrIHdoZXJlIHRoZQ0KPiBtb2JpbGl0eQ0KPiA+ID4+ICAgICAgIG1hbmFnZW1lbnQgb2YgYSBt b2JpbGUgbm9kZSBpcyBoYW5kbGVkIHVzaW5nIHRoZSBQcm94eSBNb2JpbGUNCj4gPiBJUHY2DQo+ ID4gPj4gICAgICAgcHJvdG9jb2wgYXMgZGVmaW5lZCBpbiB0aGlzIHNwZWNpZmljYXRpb24uICBU aGUgUHJveHkgTW9iaWxlDQo+IElQdjYNCj4gPiA+PiAgICAgICBkb21haW4gaW5jbHVkZXMgbG9j YWwgbW9iaWxpdHkgYW5jaG9ycyBhbmQgbW9iaWxlIGFjY2Vzcw0KPiBnYXRld2F5cw0KPiA+ID4+ ICAgICAgIGJldHdlZW4gd2hpY2ggc2VjdXJpdHkgYXNzb2NpYXRpb25zIGNhbiBiZSBzZXQgdXAg YW5kDQo+ID4gPj4gICAgICAgYXV0aG9yaXphdGlvbiBmb3Igc2VuZGluZyBQcm94eSBCaW5kaW5n IFVwZGF0ZXMgb24gYmVoYWxmIG9mDQo+IHRoZQ0KPiA+ID4+ICAgICAgIG1vYmlsZSBub2RlcyBj YW4gYmUgZW5zdXJlZC4NCj4gPiA+Pg0KPiA+ID4+DQo+ID4gPj4gSSByZW1lbWJlciB0aGlzIHdh cyBzcGVjaWZpY2FsbHkgZGlzY3Vzc2VkIGFuZCB3ZSBoYWQgY29tZSB1cCB3aXRoIGENCj4gPiB0 ZXh0DQo+ID4gPj4gdGhhdCByZWZlcnMgdG8gImxvY2FsIG1vYmlsaXR5IGFuY2hvcnMgYW5kIG1v YmlsZSBhY2Nlc3MgZ2F0ZXdheXMNCj4gPiBiZXR3ZWVuDQo+ID4gPj4gd2hpY2ggc2VjdXJpdHkg YXNzb2NpYXRpb25zIGNhbiBiZSBzZXQgdXAiIGFzIHRoZSBsaW1pdGluZyBmYWN0b3INCj4gdGhh dA0KPiA+IHNldHMNCj4gPiA+PiB0aGUgYm91bmRhcnkuIEFuZCBzZWN1cml0eSBhc3NvY2lhdGlv bnMgY2FuIGJlIHNldHVwIGJldHdlZW4gTUFHcyBhbmQNCj4gPiBMTUFzDQo+ID4gPj4gYmVsb25n aW5nIHRvIHNlcGFyYXRlIG9wZXJhdG9ycyB3aGVuIHRoZXJlIGlzIGEgcm9hbWluZyBhZ3JlZW1l bnQuDQo+ID4gV2lNQVgNCj4gPiA+PiBhcmNoaXRlY3R1cmUgYWxyZWFkeSBkb2VzIHRoYXQuDQo+ ID4gPj4NCj4gPiA+PiBBbHBlcg0KPiA+ID4+DQo+ID4gPj4NCj4gPiA+Pg0KPiA+ID4+DQo+ID4g Pj4NCj4gPiA+Pg0KPiA+ID4+DQo+ID4gPj4NCj4gPiA+Pg0KPiA+ID4+DQo+ID4gPj4NCj4gPiA+ Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+Pj4gRnJvbTogRGVzaXJlIE91bGFp IFttYWlsdG86ZGVzaXJlLm91bGFpQGVyaWNzc29uLmNvbV0NCj4gPiA+Pj4gU2VudDogVGh1cnNk YXksIEp1bHkgMzAsIDIwMDkgNDoxMyBQTQ0KPiA+ID4+PiBUbzogQWxwZXIgWWVnaW47IG5ldGV4 dEBpZXRmLm9yZw0KPiA+ID4+PiBTdWJqZWN0OiBSRSA6IFtuZXRleHRdIFBNSVA2IGFuZCByb2Ft aW5nDQo+ID4gPj4+DQo+ID4gPj4+IEhpIEFscGVyLA0KPiA+ID4+Pg0KPiA+ID4+PiAgIFNlZSBp bmxpbmUhDQo+ID4gPj4+DQo+ID4gPj4+IERlc2lyZQ0KPiA+ID4+Pg0KPiA+ID4+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4+Pg0KPiA+ID4+PiBEZTogbmV0ZXh0LWJv dW5jZXNAaWV0Zi5vcmcgZGUgbGEgcGFydCBkZSBBbHBlciBZZWdpbg0KPiA+ID4+PiBEYXRlOiBq ZXUuIDIwMDktMDctMzAgMDg6MDINCj4gPiA+Pj4gwDogbmV0ZXh0QGlldGYub3JnDQo+ID4gPj4+ IE9iamV0IDogW25ldGV4dF0gUE1JUDYgYW5kIHJvYW1pbmcNCj4gPiA+Pj4NCj4gPiA+Pj4NCj4g PiA+Pj4NCj4gPiA+Pj4NCj4gPiA+Pj4NCj4gPiA+Pj4gQ29udGludWluZyB0aGUgZGlzY3Vzc2lv biBvbiB0aGUgTUwuLi4uLi4NCj4gPiA+Pj4NCj4gPiA+Pj4NCj4gPiA+Pj4NCj4gPiA+Pj4NCj4g PiA+Pj4NCj4gPiA+Pj4gQ29uc2lkZXIgbW9iaWxlMSBhbmQgbW9iaWxlMiBzdWJzY3JpYmVkIHRv IGRhdGEgc2VydmljZSBpbiBVU0EuDQo+ID4gPj4+DQo+ID4gPj4+IFRoZXkgYXJlIGluIFN3ZWRl biwgYWNjZXNzaW5nIEludGVybmV0IGJ5ICJyb2FtaW5nIiB0byBhIFN3ZWRpc2gNCj4gPiA+Pj4g b3BlcmF0b3IgbmV0d29yay4NCj4gPiA+Pj4NCj4gPiA+Pj4NCj4gPiA+Pj4NCj4gPiA+Pj4gRG9l cyBQTUlQNiBub3Qgc3VwcG9ydCB0aGlzIGNhc2Ugd2hlcmUgTUFHIGlzIGluIFN3ZWRpc2ggb3Bl cmF0b3INCj4gPiA+Pj4gbmV0d29yaywgYW5kIExNQSBpbiBVU0Egb3BlcmF0b3IncyBuZXR3b3Jr PyBJIHRoaW5rIHRoZSBhbnN3ZXIgaXMNCj4geWVzLg0KPiA+ID4+Pg0KPiA+ID4+PiBbRGVzaXJl XTogICBJIHRoaW5rIFBNSVA2IGFzIGRlZmluZWQgaW4gUkZDNTIxMyBkb2VzIG5vdCBzdXBwb3J0 DQo+IHRoaXMNCj4gPiA+Pj4gc2NlbmFyaW8gYXMgdGhlIE1BRyBhcmUgbm90IGluIHRoZSBzYW1l IFBNSVAgZG9tYWluLiBIb3dldmVyLCBTRE9zDQo+ID4gbGlrZQ0KPiA+ID4+PiAzR1BQIHN1cHBv cnRzIGhvbWUgdHVubmVsbGluZy4NCj4gPiA+Pj4NCj4gPiA+Pj4NCj4gPiA+Pj4NCj4gPiA+Pj4g V291bGRuJ3Qgd2Ugd2FudCB0byBvcHRpbWl6ZSB0aGUgcGF0aCBiZXR3ZWVuIG1vYmlsZTEgYW5k IG1vYmlsZTIgdG8NCj4gPiA+Pj4gc2F2ZSB0aGUgdHJhZmZpYyBmcm9tIG1ha2luZyB0aGUgdW5u ZWNlc3NhcnkgVVNBIHRyaXA/IEkgdGhpbmsgdGhlDQo+ID4gPj4+IGFuc3dlciBpcyB5ZXMgYWdh aW4uDQo+ID4gPj4+DQo+ID4gPj4+IFtEZXNpcmVdOiBJIGFncmVlIHRoYXQgaXQgaXMgYW4gaW50 ZXJlc3Rpbmcgb3B0aW1pemF0aW9uLiBCdXQgd2UNCj4gbmVlZA0KPiA+ID4+PiBmaXJzdCB0byBj bGFyaWZ5IHRoZSByZWxhdGlvbiBiZXR3ZWVuIHRoZSBNQUcgaW4gc3dlZGVuIGFuZCB0aGUgTE1B DQo+IGluDQo+ID4gPj4+IFVTQS4gU28gd2UgbmVlZCB0byBzcGVjaWZ5IFBNSVA2IHJvYW1pbmcg YmVmb3JlIHRhbGtpbmcgYWJvdXQNCj4gPiBMb2NhbGl6ZWQNCj4gPiA+Pj4gcm91dGluZyBpbiBQ TUlQNiByb2FtaW5nLg0KPiA+ID4+Pg0KPiA+ID4+Pg0KPiA+ID4+Pg0KPiA+ID4+PiBDb21tZW50 cz8NCj4gPiA+Pj4NCj4gPiA+Pj4NCj4gPiA+Pj4NCj4gPiA+Pj4gQWxwZXINCj4gPiA+Pj4NCj4g PiA+Pj4NCj4gPiA+Pj4NCj4gPiA+Pj4NCj4gPiA+Pj4NCj4gPiA+Pj4NCj4gPiA+Pj4NCj4gPiA+ Pj4NCj4gPiA+Pj4NCj4gPiA+Pj4NCj4gPiA+Pj4NCj4gPiA+Pj4NCj4gPiA+Pj4NCj4gPiA+Pj4N Cj4gPiA+Pj4NCj4gPiA+Pj4NCj4gPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+ID4+IG5ldGV4dCBtYWlsaW5nIGxpc3QNCj4gPiA+PiBuZXRl eHRAaWV0Zi5vcmcNCj4gPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L25ldGV4dA0KPiA+ID4+DQo+ID4gPj4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+IG5ldGV4dCBtYWlsaW5n IGxpc3QNCj4gPiA+IG5ldGV4dEBpZXRmLm9yZw0KPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9uZXRleHQNCj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBuZXRleHQgbWFpbGluZyBsaXN0DQo+ ID4gbmV0ZXh0QGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9uZXRleHQ= From Mohana.Jeyatharan@sg.panasonic.com Wed Aug 19 23:09:36 2009 Return-Path: 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 ; 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 ; 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 ; 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" To: "Qin Wu" , "Marco Liebsch" 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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..=20 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 >=20 > 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.=20 > 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" > To: "Qin Wu" ; "Marco Liebsch" > > Cc: > Sent: Wednesday, August 19, 2009 11:35 AM > Subject: RE: [netext] PMIP6 and roaming >=20 >=20 > Hi Qin, >=20 > 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. >=20 > 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. >=20 >=20 > >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. >=20 > 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. >=20 > 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" > > To: "Marco Liebsch" ; "Qin Wu" > > > > Cc: > > 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" > > > > To: "Alper Yegin" > > > > Cc: > > > > 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 > > > >>> =C0: 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 From Marco.Liebsch@nw.neclab.eu Thu Aug 20 05:38:37 2009 Return-Path: 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 5A1833A6EC4 for ; Thu, 20 Aug 2009 05:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 4qjbNHHy9hCd for ; Thu, 20 Aug 2009 05:38:36 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id A610A3A6E9E for ; Thu, 20 Aug 2009 05:38:35 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id E94022C0004E6; Thu, 20 Aug 2009 14:38:40 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QgHXFWkfNSQW; Thu, 20 Aug 2009 14:38:40 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id B7A602C0012C4; Thu, 20 Aug 2009 14:38:25 +0200 (CEST) Received: from [10.1.2.86] ([10.1.2.86]) by VENUS.office with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Aug 2009 14:38:25 +0200 Message-ID: <4A8D43C2.4020302@nw.neclab.eu> Date: Thu, 20 Aug 2009 14:38:26 +0200 From: Marco Liebsch User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Qin Wu References: <060f01ca110d$903ca120$b0b5e360$%yegin@yegin.org> <063901ca111a$01ce9c60$056bd520$%yegin@yegin.org> <4A77F0CC.4090204@nw.neclab.eu> <037501ca1ffd$98a1d4d0$260ca40a@china.huawei.com> <4A8AA0FC.10406@nw.neclab.eu> <005d01ca2071$2b8c78e0$260ca40a@china.huawei.com> In-Reply-To: <005d01ca2071$2b8c78e0$260ca40a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 20 Aug 2009 12:38:25.0814 (UTC) FILETIME=[1CA7AB60:01CA2193] 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 12:38:37 -0000 Hi Qin, Qin Wu wrote: > Hi, Marco: > Suppose PMIPv6 operates between the LMA in the US > and the MAG in Sweden as you mentioned, what's the prerequisit > condition to enabling setup security association? Is it roaming support > or something else? > I think it's part of a roaming agreement. But if there is PMIPv6 protocol operation between MAG in Sweden and LMA in the US, the security association is implicit. > Also in this scenario, I am difficult to tell how many pmp6 domains there is? > We can say in US, there is one PMIPv6 domain that owns LMA, > while in Sweden, there is another PMIPv6 domain that owns MAG, > however if we assume there is a roaming relationship between the > PMIPv6 domain in US and another PMIPv6 domain in Sweden, > it seems these two PMIPv6 domains can be combined into one > PMIPv6 domain. In this way, it seems each PMIPv6 domains > can be taken as one PMIP6 domain if there is trust relationship > between them? am I right? > I think the term PMIP domain has been so far used from a single MN's perspective. As long as the MN can remain anchored at its LMA and can keep its HNP/IP address, it moves within the same PMIP domain. W.r.t. your example above, I'd say it's one PMIP domain when a single LMA performs PMIP with both MNs' MAG, even if MAGs are in a different admin domain. In case of multi-LMA scenario, hmm, I'd say that it's the same PMIP domain if both LMAs have a trust relationship. > So I am wondering how to understand "local" or "localized" > in the localized routing topic? Whether the PMIPv6 domain > can be restricted into one local PMIPv6 domain? > For localized routing, we could apply the same logic and could say that both MAGs (from MN1 and MN2) must have a trust relationship. That at least satisfies our functional and non-functional requirements. But in such case it could happen, that MAG1 is in Sweden whereas MAG2 is in the US, where we possibly will not benefit from setting up an MAG-to-MAG tunnel. So, I don' think this is to be resolved with limitation of localized routing to a PMIP or Admin domain, but it's deployment. Actually it's up to the operators whether or not to set up a direct forwarding tunnel between MAG1 and MAG2. That's why I say that for the protocol specification it may be sufficient to mandate the trust relationship between relevant components. Everything else is deployment. marco > Regards! > -Qin > ----- Original Message ----- > From: "Marco Liebsch" > To: "Qin Wu" > Cc: "Alper Yegin" ; > Sent: Tuesday, August 18, 2009 8:39 PM > 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" >>> To: "Alper Yegin" >>> Cc: >>> 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 >>> > > From david.cypher@nist.gov Thu Aug 20 06:16:24 2009 Return-Path: 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 C291B3A6BBA for ; Thu, 20 Aug 2009 06:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 U93V+nqdizYp for ; Thu, 20 Aug 2009 06:16:23 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 15A543A68E9 for ; Thu, 20 Aug 2009 06:16:22 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (wsxghub2.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n7KDFVvk004263; Thu, 20 Aug 2009 09:15:31 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([2002:8106:1213::8106:1213]) with mapi; Thu, 20 Aug 2009 09:15:31 -0400 From: "Cypher, David E." To: Marco Liebsch , Qin Wu Date: Thu, 20 Aug 2009 09:15:31 -0400 Thread-Topic: [netext] PMIP6 and roaming Thread-Index: Acohkz1lUc31KN9PThKYUGWd9+N4CAAA1zQg Message-ID: References: <060f01ca110d$903ca120$b0b5e360$%yegin@yegin.org> <063901ca111a$01ce9c60$056bd520$%yegin@yegin.org> <4A77F0CC.4090204@nw.neclab.eu> <037501ca1ffd$98a1d4d0$260ca40a@china.huawei.com> <4A8AA0FC.10406@nw.neclab.eu> <005d01ca2071$2b8c78e0$260ca40a@china.huawei.com> <4A8D43C2.4020302@nw.neclab.eu> In-Reply-To: <4A8D43C2.4020302@nw.neclab.eu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cypher@nist.gov 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 13:16:24 -0000 > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf > Of Marco Liebsch > Sent: Thursday, August 20, 2009 8:38 AM > To: Qin Wu > Cc: netext@ietf.org > Subject: Re: [netext] PMIP6 and roaming >=20 > Hi Qin, >=20 > Qin Wu wrote: > > Hi, Marco: > > Suppose PMIPv6 operates between the LMA in the US > > and the MAG in Sweden as you mentioned, what's the prerequisit > > condition to enabling setup security association? Is it roaming support > > or something else? > > > I think it's part of a roaming agreement. But if there is PMIPv6 protocol > operation between MAG in Sweden and LMA in the US, the security > association is implicit. >=20 > > Also in this scenario, I am difficult to tell how many pmp6 domains > there is? > > We can say in US, there is one PMIPv6 domain that owns LMA, > > while in Sweden, there is another PMIPv6 domain that owns MAG, > > however if we assume there is a roaming relationship between the > > PMIPv6 domain in US and another PMIPv6 domain in Sweden, > > it seems these two PMIPv6 domains can be combined into one > > PMIPv6 domain. In this way, it seems each PMIPv6 domains > > can be taken as one PMIP6 domain if there is trust relationship > > between them? am I right? > > > I think the term PMIP domain has been so far used from a single MN's > perspective. > As long as the MN can remain anchored at its LMA and can keep its HNP/IP > address, > it moves within the same PMIP domain. This is the only way to view a PMIP domain based entirely on its definition= . Thank you for presenting this so concisely. Perhaps we can reconsidered the draft proposals covering the interactions b= etween PMIP domains when the MN and the CN have different LMA's. David Cypher =20 > W.r.t. your example above, I'd say it's one PMIP domain when a single LMA > performs PMIP with both MNs' MAG, even if MAGs are in a different admin > domain. > In case of multi-LMA scenario, hmm, I'd say that it's the same PMIP domai= n > if both LMAs have a trust relationship. >=20 > > So I am wondering how to understand "local" or "localized" > > in the localized routing topic? Whether the PMIPv6 domain > > can be restricted into one local PMIPv6 domain? > > > For localized routing, we could apply the same logic and could say that > both MAGs > (from MN1 and MN2) must have a trust relationship. That at least > satisfies our > functional and non-functional requirements. But in such case it could > happen, that > MAG1 is in Sweden whereas MAG2 is in the US, where we possibly will not > benefit > from setting up an MAG-to-MAG tunnel. So, I don' think this is to be > resolved > with limitation of localized routing to a PMIP or Admin domain, but it's > deployment. > Actually it's up to the operators whether or not to set up a direct > forwarding tunnel > between MAG1 and MAG2. That's why I say that for the protocol > specification it may be > sufficient to mandate the trust relationship between relevant > components. Everything else > is deployment. >=20 > marco >=20 > > Regards! > > -Qin > > ----- Original Message ----- > > From: "Marco Liebsch" > > To: "Qin Wu" > > Cc: "Alper Yegin" ; > > Sent: Tuesday, August 18, 2009 8:39 PM > > 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 domai= n > >>> 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 th= e > >> PMIPv6 specification, > >> we handle scenarios between two communicating MNs, which may get serve= d > >> 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 assum= e > >> that, to work, there must > >> be a trust relationship between components exchanging signaling. So fo= r > >> the protocol specification > >> I think it's sufficient to mandate a security association between thes= e > >> components to authenticate > >> messages. > >> > >> marco > >> > >> > >> > >> > >> > >> > >> > >>> Regards! > >>> -Qin > >>> ----- Original Message ----- > >>> From: "Marco Liebsch" > >>> To: "Alper Yegin" > >>> Cc: > >>> 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, ther= e > >>> 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 LM= A, > >>> 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 mobil= e > 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 an= d > 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 > >>>>> =C0: 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 t= o > >>>>> 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 > >>> > > > >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From sunseawq@huawei.com Fri Aug 21 02:55:07 2009 Return-Path: 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 ; 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 ; 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 ; 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 To: Mohana Jeyatharan , Marco Liebsch 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 09:55:07 -0000 SGksIE1vaGFuYToNClRoZXJlIGlzIHN0aWxsIG5vIGNvbnNlbnN1cyBvbiB3aGF0IGFyZSByZWFs IG9wZXJhdGluZyBzY2VhbnJpb3MgdGhhdCBsb2NhbGl6ZWQgcm91dGluZyBjYW4gYmUgYXBwbGll ZCB0by4gQnV0IGRlZmluaXRlbHkgdGhpcyBpc3N1ZSB3YXMgcmFpc2VkIGF0IElFVEYgNzUgbWVl dGluZywgd2hpY2ggaXMgcmVsYXRlZCB0byB0aGUgc2NvcGUgb2YgbG9jYWxpemVkIHJvdXRpbmcu IFRoZSBkaXNjdXNzaW9uIG9uIHRoaXMgaXNzdWUgIGlzDQooYSkgbmFycm93L3Jlc3RyaWN0IHNj b3BlIG9mIGxvY2FsaXplZCByb3V0aW5nIGFuZCBtYXRjaCB0aGUgc2NvcGUgb2YgUFMgZHJhZnQg d2l0aCB0aGUgc2NvcGUgb2Ygc29sdXRpb24NCihiKSB0aGUgc2NvcGUgb2YgUFMgZHJhZnQgY2Fu IGJlIGxhcmdlciB0aGFuIHRoZSBzY29wZSBvZiBzb2x1dGlvbi4gDQpTbyBtYXliZSB3ZSBuZWVk IG9uZSBjb21wcm9taXplZCB3YXkgdG8gcmVzb2x2ZSB0aGlzLiBKdXN0IGFzIHlvdXIgc3VnZ2Vz dGlvbiwgdGhlIHNjZW5hcmlvcyBjYW4gYmUgc29sdmVkIGZyb20gc2ltcGxlIG9uZSB0byBjb21w bGV4IG9uZSwgYXMgcmVnYXJkaW5nIHRoZSBjb21wbGV4IG9uZSwgc29tZSBhZGRpdGlvbmFsIGV4 cGxhaW5hdGlvbiB0ZXh0IGNhbiBiZSB1c2VkIGZvciBzY29wZSByZXN0cmljdGlvbi4gDQp3LnIu dC4gY29tcGxpY2F0ZWQgc2NlbmFyaW8geW91IG1ldGlvbmVkLCBJIHRoaW5rIGl0IGNhbiBiZSBz aW1wbGllZCB3aXRob3V0IGludGVyd29ya2luZyBiZXR3ZWVuIExNQXMgaWYgTU4gYW5kIENOIHNo YXJlIHRoZSBzYW1lIExNQSBpbiB0aGUNClZQTE1OIG9yIEhQTE1OLg0KDQpSZWdhcmRzIQ0KLVFp bg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJNb2hhbmEgSmV5YXRoYXJh biIgPE1vaGFuYS5KZXlhdGhhcmFuQHNnLnBhbmFzb25pYy5jb20+DQpUbzogIlFpbiBXdSIgPHN1 bnNlYXdxQGh1YXdlaS5jb20+OyAiTWFyY28gTGllYnNjaCIgPG1hcmNvLmxpZWJzY2hAbncubmVj bGFiLmV1Pg0KQ2M6IDxuZXRleHRAaWV0Zi5vcmc+DQpTZW50OiBUaHVyc2RheSwgQXVndXN0IDIw LCAyMDA5IDI6MDUgUE0NClN1YmplY3Q6IFJFOiBbbmV0ZXh0XSBQTUlQNiBhbmQgcm9hbWluZw0K DQoNCkhpIFFpbiwNCg0KV2VsbCBJIGFtIG5vdCBzdXJlIHdoZXRoZXIgdGhlcmUgaXMgY29uc2Vu c3VzIGluIHRoZSBncm91cCB0byBjYXB0dXJlIHRoZSBkaWZmZXJlbnQgb3BlcmF0aW5nIHNjZW5h cmlvcyBvZiBsb2NhbGl6ZWQgTUFHIHJvdXRpbmcgaW4gdGhlIFBTIGRyYWZ0LiBCdXQsIEkgdGhp bmsgc3VjaCB1bmRlcnN0YW5kaW5nIGlzIGVzc2VudGlhbCBiY29zIHdlIG5lZWQgdG8gYXBwbHkg dGhlc2Ugc29sdXRpb25zIGluIHJlYWwgZGVwbG95bWVudHMuIFRodXMgc3VjaCBjbGFyaWZpY2F0 aW9ucyBhcmUgZXNzZW50aWFsLiBGb3Igc2ltcGxlIHNjZW5hcmlvcyBvciBiYXNpYyBzY2VuYXJp b3Mgd2UgY2FuIHNvbHZlIHdpdGhvdXQgaW5mb3JtYXRpb24gcGFzc2luZyBiZXR3ZWVuIExNQXMu IEJ1dCBmb3IgbW9yZSBjb21wbGljYXRlZCBzY2VuYXJpb3Mgd2UgbWF5IG5lZWQgTE1BIGludGVy d29ya2luZyBhcyBwYXJ0IG9mIHNvbHV0aW9uIHRvIGFjaGlldmUgbG9jYWxpemVkIHJvdXRpbmcg b3Igc29tZSBvdGhlciBzb2x1dGlvbiB3aXRob3V0IGV4cGxpY2l0IGludGVyd29ya2luZyBiZXR3 ZWVuIExNQXMoaW1wbGl0KS4NCg0KTG9jYWxpemVkIHJvdXRpbmcgaXMgUk8gYmV0d2VlbiBNTiBh bmQgQ04gcGxhY2VkIGluIHRoZSBzYW1lIFBNSVB2NiBkb21haW4uIEJ1dCBNTiBhbmQgQ04gaG9t ZSBkb21haW4gY2FuIGJlIGFueXRoaW5nLi4gDQoNClBsZWFzZSBzZWUgYmVsb3cgZm9yIHNvbWUg cmVwbGllcy4uLg0KDQpCUiwNCk1vaGFuYQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IFFpbiBXdSBbbWFpbHRvOnN1bnNlYXdxQGh1YXdlaS5jb21dDQo+IFNlbnQ6IFRo dXJzZGF5LCBBdWd1c3QgMjAsIDIwMDkgMTE6NDUgQU0NCj4gVG86IE1vaGFuYSBKZXlhdGhhcmFu OyBNYXJjbyBMaWVic2NoDQo+IENjOiBuZXRleHRAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtu ZXRleHRdIFBNSVA2IGFuZCByb2FtaW5nDQo+IA0KPiBIaSwgTW9oYW5hOg0KPiBUaGFuayBmb3Ig eW91ciByZXBseS4gSSB0aGluayAzR1BQIGNhc2UgeW91IG1lbnRpb25lZCBpcyBhIGdvb2QgZXhh bXBsZSB0bw0KPiBoZWxwIHVzIHVuZGVyc3RhbmQgd2hhdCBQTUlQIGRvbWFpbiByZWFsbHkgaXMu DQo+IEZyb20gM0dQUCBkZXBsb3ltZW50IHBlcnNwZWN0aXZlLCBJIHdvdWxkIGFncmVlIEhQTE1O IG9yIFZQTE1OIGFyZSB0YWtlbg0KPiBhcyBhbiBleGFtcGxlIG9mIFBNSVAgZG9tYWluLg0KPiBJ biB0aGlzIHNlbnNlLCBpdCBzZWVtcyB0aGF0ICBhbGwgdGhlIG1vYmlsaXR5IGVudGl0eShpLmUu LCBNTidzIExNQSwgTU4ncw0KPiBNQUcsIENOJ3MgTE1BLCBDTicgTUFHKSBhcmUgbG9jYXRlZCBp biB0aGUgc2FtZSBWUExNTi4NCj4gSSBhZ3JlZSBpdCBpcyBhIHByYWN0aWNhbCBzY2VuYXJpbyB0 byB3aGljaCB3ZSBjYW4gYXBwbHkgbG9jYWxpemVkDQo+IHJvdXRpbmcgLiBIb3dldmVyIGxvY2Fs aXplZCByb3V0aW5nIGNhbiBhbHNvIGFwcGxpZWQgdG8gdGhlIHNjZW5hcmlvIHdoZXJlDQo+IHR3 byBNQUdzDQo+IGluIGNvbW11bmNpYXRpb24gYXJlIGxvY2F0ZWQgaW4gdGhlIFZQTE1OIHdoaWxl IE1OJ3MgTE1BIGFuZCBDTidzIE1OIGFyZQ0KPiBsb2NhdGVkIGluIHRoZSBzYW1lIG9yIGRpZmZl cmVudCBIUExNTnMsIGFtIEkgcmlnaHQ/DQoNCltNb2hhbmFdIE1OIGFuZCBDTiBjYW4gYmVsb25n IHRvIHNhbWUgSFBMTU4gYW5kIGN1cnJlbnRseSBsb2NhdGVkIGluIHNhbWUgVlBMTU4vSFBMTU4g Y2FuIGJlIHNvbHZlZCBieSBsb2NhbGl6ZWQgcm91dGluZyBzb2x1dGlvbnMgd2UgY3VycmVudGx5 IGhhdmUuIFRoZSBwcm9ibGVtYXRpYyBjYXNlIGlzIHdoZXJlIE1OIGFuZCBDTiBhcmUgbG9jYXRl ZCBpbiBhIFZQTE1OIGFuZCBjb25uZWN0ZWQgdG8gZGlmZmVyZW50IE1BR3MgYW5kIHRoZWlyIEhQ TE1OUyBhcmUgZGlmZmVyZW50KE1OJ3MgaG9tZSBkb21haW4gaXMgSFBMTU4xIGFuZCBDTidzIGhv bWUgZG9tYWluIGlzIEhQTE1OMikuIFRoaXMgaXMgdGhlIGNhc2UgeW91IGhhdmUgbWVudGlvbmVk IGFib3ZlLiBUaGlzIGlzIG5vdCBzbyBzaW1wbGUgYmVjYXVzZSB3ZSBkbyBub3QgaGF2ZSBMTUEg aW50ZXJ3cm9raW5nLiBUaGUgb3RoZXIgcHJvYmxlbWF0aWMgY2FzZSBpcywgQ04gaW4gaG9tZSBk b21haW4sIGFuZCBNTiBpbiBDTidzIGhvbWUgZG9tYWluIChib3RoIE1OIGFuZCBDTiBjb25uZWN0 ZWQgdG8gZGlmZmVyZW50IExNQXMgZHVlIHRvIHNjZW5hcmlvKSBhbmQgTU4ncyBMTUEgaXMgaW4g aXRzKE1OJ3MpICBob21lIGRvbWFpbi4gIFdoYXQgSSBtZWFuIGJ5IHByb2JsZW1hdGljIGNhc2Ug aXMsIHdlIG5lZWQgdG8gc2VlIHdoZXRoZXIgdGhlIHNvbHV0aW9ucyB3ZSBjdXJyZW50bHkgaGF2 ZSBjYW4gYmUgYXBwbGllZCBpbiBzdWNoIGNvbXBsZXggc2NlbmFyaW9zLiANCg0KW1Fpbl06IFN1 cHBvc2UgTU4gYW5kIENOIHVuZGVyIHRoZSBkaWZmZXJlbnQgTUFHIGFuZCBiZWxvbmcgdG8gdGhl IHNhbWUgTE1BLCB0aGUgc29sdXRpb24gd2UgaGF2ZSBjYW4gYmUgYXBwbGllZCBlYXNpbHkuDQog ICAgICAgICBTdXBwb3NlIE1OIGFuZCBDTiB1bmRlciB0aGUgZGlmZmVybnQgTUFHIGFuZCBiZWxv bmcgdG8gdGhlIGRpZmZlcmVudCBMTUEsIGl0IGlzIGEgbGl0dGxlIGhhcmQgdG8gY29tZSB1cCBh IGNvbmNyZXRlIHNvbHV0aW9uLiBTb21lIGZvbGtzIHN1Z2dlc3QgdG8gYWxsb3cgDQogICAgICAg ICBNTidzIE1BRyBjb21tdW5pY2F0ZSB3aXRoIENOJ3MgTE1BIGFuZCBDTidzIE1BRyB0YWxrIHRv IHRoZSBNTidzIExNQSBpbiB0aGUgSUVURjc1IG1lZXRpbmcsIG1heWJlIGl0IGlzIHBvc3NpYmxl IHdheS4NCg0KPiBTbyB0aGUgb3BlbiBpc3N1ZSB3ZSBoYXZlIGhlcmUgaXMNCj4gU2hhbGwgd2Ug cmVzdHJpY3QgYWxsIHRoZSBtb2JpbGl0eSBlbnRpdGllcyBpbmNsdWRpbmcgTU4ncyBNQUcsIE1O J3MgTE1BLA0KPiBDTidzIE1BRywgQ04ncyBMTUEgaW4gdGhlIHNhbWUgVlBMTU4gb3IgSFBMTU4/ DQpbTW9oYW5hXSBMZXRzIGNhbGwgdGhpcyBCYXNpYyBTY2VuYXJpbw0KDQoNCj4gV2UganVzdCBh c2sgTU4ncyBNQUcgYW5kIENOJ3MgTUFHIHRvIGJlIGxvY2F0ZWQgaW4gdGhlIHNhbWUgVlBMTU4g YW5kDQo+IGRvbid0IGNhcmUgYWJvdXQgd2hlcmUgTU4ncyBMTUEgYW5kIENOJ3MgTE1BIGFyZS4N Cj4gSWYgU28sIEkgYW0gaW50ZXJlc3RlZCB0byBrbm93IFdHIGNvbnNlbnN1cyBvbiB0aGlzLg0K W01vaGFuYV0gSSBob3BlIHdlIGdldCBjb25zZW5zdXMgb24gdGhpcyBhbmQgYXQgbGVhc3QgY2Fw dHVyZSBzb21lIG9mIHRoZXNlIHNjZW5hcmlvcyBzb21ld2hlcmUuIEkgdGhpbmsgd2UgbWF5IG5l ZWQgdG8ga25vdyB0aGUgaW50ZXJvcGVyYWJpbGl0eSBzdGF0ZSBiZXR3ZWVuIExNQXMoVW5sZXNz IHdlIGhhdmUgYSBzb2x1dGlvbiB0aGF0IHN1cnBhc3NlcyB0aGlzKS4NCg0KW1Fpbl0gU2VlIGFi b3ZlLg0KDQoNCg0KPiBSZWdhcmRzDQo+IC1RaW4NCj4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAt LS0tLQ0KPiBGcm9tOiAiTW9oYW5hIEpleWF0aGFyYW4iIDxNb2hhbmEuSmV5YXRoYXJhbkBzZy5w YW5hc29uaWMuY29tPg0KPiBUbzogIlFpbiBXdSIgPHN1bnNlYXdxQGh1YXdlaS5jb20+OyAiTWFy Y28gTGllYnNjaCINCj4gPG1hcmNvLmxpZWJzY2hAbncubmVjbGFiLmV1Pg0KPiBDYzogPG5ldGV4 dEBpZXRmLm9yZz4NCj4gU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMTksIDIwMDkgMTE6MzUgQU0N Cj4gU3ViamVjdDogUkU6IFtuZXRleHRdIFBNSVA2IGFuZCByb2FtaW5nDQo+IA0KPiANCj4gSGkg UWluLA0KPiANCj4gSSBhZ3JlZSB0aGF0IHRoZXJlIGlzIG5vIHVucWl1ZSB3YXkgdG8gZGVmaW5l IFBNSVAgZG9tYWluIGFuZA0KPiBhZG1pbmlzdHJhdGl2ZSBkb21haW4uIEJ1dCwgSSBndWVzcyB3 ZSBjYW4gZ2l2ZSBpdCBzb21lIGFzc3VtcHRpb25zLiBJZg0KPiBMTUFzIGluIGFuIGFkbWluaXN0 cmF0aXZlIGRvbWFpbiBrbm93IGVhY2ggb3RoZXIgc3RhdGUsIHdlIGNhbiBjYWxsIGl0DQo+IHNh bWUgYWRtaW5zaXRyYXRpdmUgZG9tYWluL1BNSVAgZG9tYWluLg0KPiANCj4gSG93ZXZlciwgaW4g M0dQUCBob21lIHJvdXRlZCBjYXNlLCB0aGUgTU4gbWF5IHJlY2VpdmUgaG9tZSBzZXJ2aWNlcyB2 aWENCj4gaG9tZSByb3V0ZWQgbWVjaGFuaXNtIGJ1dCwgaXQgaXMgcGxhY2VkIGluIGFub3RoZXIg YWRtaW5pc3RyYXRpdmUgZG9tYWluLg0KPiBGb3IgZXhhbXBsZSB0aGUgTE1BcyBpbiB0aGUgZGlm ZmVyZW50IGRvbWFpbnMgbWF5IG5vdCBrbm93IGVhY2ggb3RoZXIuIEkNCj4gdGhpbmsgaWYgZXZl cnkgbmV0d29yayBlbnRpdGl5IGluIFBNSVAgZG9tYWluIGtub3dzIG90aGVyIG5ldHdvcmsgZW50 dGllcw0KPiBhbmQgY2FuIGVhc2lseSBjcmVhdGUgc2VjdXJpdHkgYXNzb2NpYXRpb25zIG9yIGFs bG93ZWQgdG8gY3JlYXRlIHNlY3VpdHkNCj4gYXNzb2NpYXRpb25zKG5vdCB3b3JyeWluZyBhYm91 dCByb2FtaW5nIGFncmVlbWVudCksIHdlIGNhbiBlYXNpbHkNCj4gY2xhc3NpZml5IGFzIGEgc2lu Z2xlIFBNSVAgZG9tYWluLiBBZ2FpbiB0aGlzIGlzIG15IG93biBqdWRnbWVudC4gVGh1cyB0aGUN Cj4gaG9tZSByb3V0ZWQgY2FzZSBtYXkgbm90IGZhbGwgaW50byBzaW5nbGUgYWRtaW5pc3RyYXRp dmUgZG9tYWluLg0KPiANCj4gDQo+ID5pbiBtYW55IGNhc2VzLCBvbmUgUE1JUCBkb21haW4gY2Fu IGNvdmVyIG11bHRpcGxlIGFkbWluc3RyYXRpdmUNCj4gPiBkb21haW5zLiBIb3dldmVyIGhvdyB0 byBkZWZpbmUgb25lIGFkbWluaXN0cmF0aXZlIGRvbWFpbj8gSW4geW91cg0KPiA+IHVuZGVyc3Rh bmRpbmcsIG9uZSBhZG1pbmlzdHJhdGl2ZSBkb21haW4gY2FuIGJlIGV4YW1wbGlmaWVkIGFzIG9u ZQ0KPiBzdWJuZXQNCj4gPiBvciBhIGxvZ2ljYWwgZGl2aXNpb24gb2Ygb25lIGFjY2VzcyBuZXR3 b3JrIGluIDNHUFAgc2NlbmFyaW8/IGFtIEkNCj4gcmlnaHQ/DQo+ID4gSXMgaXQgIHdoYXQgd2Ug dW5kZXJzdGFuZCBmb3IgdGhlIGRlZmluaXRpb24gb2YgYWRtaW5pdHJhdGl2ZSBkb21haW4/DQo+ ICBXZWxsIGluIDNHUFAgY2FzZSwgSSBhZ3JlZSwgZXZlbiB3aXRoaW4gb25lIEhQTE1OKG9uZSBh ZG1pbmlzdGFydGl2ZQ0KPiBkb21haW4gb2YgTU4pIG11bHRpcGxlIG9wZXJhdG9ycyBjYW4gaGFu ZGxlIGRpZmZlcmVudCBhY2Nlc3MgbmV0d29ya3MuDQo+IEhlcmUgSSB3b3VsZCBub3QgcmVhbGx5 IGxvb2sgYXQgdGhlIGdyYW51bGFyaXR5IG9mIGFjY2VzcyBuZXR3b3JrIHRvDQo+IGRlZmluZSB0 aGUgUE1JUC9hZG1pbnNpdHJhdGl2ZSBkb21haW4sIGJ1dCB3aWxsIGxvb2sgYXQgSFBMTU4gaW4g Z2VuZXJhbC4NCj4gQnV0LCBub3cgd2UgYXJlIGJyZWFraW5nIHRoZSBNQUcgdG8gTUFHIFJPIHNj ZW5hcmlvIGludG8gdGhlIGFjY2VzcyB0eXBlcw0KPiB0aWVkIHRvIHRoZSBNQUcgYW5kIHdoZXRo ZXIgdGhlcmUgd2lsbCBiZSBhZ3JlZW1lbnQgaW4gZXN0YWJsaXNoaW5nDQo+IHR1bm5lbHMgYmV0 d2VlbiBzdWNoIE1BR3MuIEkgdGhpbmsgaWYgTE1BIGlzIGludm9sdmVkIGluIGVzdGFibGlzaGlu ZyBNQUcNCj4gdG8gTUFHIFJPLCBpdCBtYXkga25vdyB3aGV0aGVyIHN1Y2ggdHVubmVsaW5nIGlz IGFsbG93ZWQuDQo+IA0KPiBTbyBJIHRoaW5rIGl0IGlzIGJldHRlciB0byBpbml0aWFsbHkgc2F5 IEhQTE1OIGlzIGxpa2Ugb25lIGFkbWluc2l0cmF0aXZlDQo+IG9yIFBNSVAgZG9tYWluLiBUaGVu IGxhdGVyIG5hcnJvdyBvciBicmVhayBITVBMTiBpbnRvIGZ1cnRoZXIgc3ViIGRvbWFpbnMNCj4g YW5kIGxvb2sgYXQgdGhlIGZlYXNpYmlsaXR5IG9mIE1BRyB0byBNQUcgUk8uIEkgdGhpbmsgaXQg d291bGQgYmUgZ29vZCB0bw0KPiBjYXB0dXJlIHRoaXMgc2NlbmFyaW8gKGludGVyIDNHUFAgc3Vi IGRpdmlzaW9ucykgYWxzbyBpbiB0aGUgUFMgZHJhZnQuDQo+IA0KPiBCUiwNCj4gTW9oYW5hDQo+ ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBRaW4gV3UgW21haWx0bzpz dW5zZWF3cUBodWF3ZWkuY29tXQ0KPiA+IFNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDE5LCAyMDA5 IDExOjA2IEFNDQo+ID4gVG86IE1vaGFuYSBKZXlhdGhhcmFuOyBNYXJjbyBMaWVic2NoDQo+ID4g Q2M6IG5ldGV4dEBpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJlOiBbbmV0ZXh0XSBQTUlQNiBhbmQg cm9hbWluZw0KPiA+DQo+ID4gSGksIE1vaGFuYSBhbmQgYWxsOg0KPiA+IEFzIHlvdSBtZW50aW9u ZWQsIFBNSVAgZG9tYWluIGFuZCBhZG1pbmlzdHJhdGl2ZSBkb21haW4gY29pbmNpZGVzLCBJDQo+ IGFncmVlLg0KPiA+IGUuZy4saW4gbWFueSBjYXNlcywgb25lIFBNSVAgZG9tYWluIGNhbiBjb3Zl ciBtdWx0aXBsZSBhZG1pbnN0cmF0aXZlDQo+ID4gZG9tYWlucy4gSG93ZXZlciBob3cgdG8gZGVm aW5lIG9uZSBhZG1pbmlzdHJhdGl2ZSBkb21haW4/IEluIHlvdXINCj4gPiB1bmRlcnN0YW5kaW5n LCBvbmUgYWRtaW5pc3RyYXRpdmUgZG9tYWluIGNhbiBiZSBleGFtcGxpZmllZCBhcyBvbmUNCj4g c3VibmV0DQo+ID4gb3IgYSBsb2dpY2FsIGRpdmlzaW9uIG9mIG9uZSBhY2Nlc3MgbmV0d29yayBp biAzR1BQIHNjZW5hcmlvPyBhbSBJDQo+IHJpZ2h0Pw0KPiA+IElzIGl0ICB3aGF0IHdlIHVuZGVy c3RhbmQgZm9yIHRoZSBkZWZpbml0aW9uIG9mIGFkbWluaXRyYXRpdmUgZG9tYWluPw0KPiA+IEZy b20gbXkgdW5kZXJzdGFuZGluZywgdGhlIHRlcm0gb2YgImFkbWluaXN0cmF0aXZlIGRvbWFpbiIg aXMgbW9yZQ0KPiBnZW5lcmljDQo+ID4gdGVybSBhbmQgdmVyeSBjb25mdXNpbmcsIGUuZywgSSBj YW4gc2F5IG9uZSBBQUEgZG9tYWluIGlzIGENCj4gYWRtaW5pc3RyYXRpdmUNCj4gPiBkb21haW4g dG9vIG9yIGFkbWluc3RyYXRpdmUgZG9tYWluIGNhbiBiZSBleGFtcGxpZmllZCBhcyAqYSBnZW9n cmFwaGljDQo+ID4gbW9iaWxpdHkgZG9tYWluKi4gU28gaWYgd2UgY29uc2lkZXIgdG8gdXNlIHRo aXMgdGVybSBpbiB0aGUgUFMgZHJhZnQsIHdlDQo+ID4gc2hvdWxkIGJlIHZlcnkgY2FyZWZ1bCB3 aGF0IGl0IGV4YWN0IG1lYW5zLg0KPiA+DQo+ID4gUmVnYXJkcyENCj4gPiAtUWluDQo+ID4gLS0t LS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPiA+IEZyb206ICJNb2hhbmEgSmV5YXRoYXJhbiIg PE1vaGFuYS5KZXlhdGhhcmFuQHNnLnBhbmFzb25pYy5jb20+DQo+ID4gVG86ICJNYXJjbyBMaWVi c2NoIiA8bWFyY28ubGllYnNjaEBudy5uZWNsYWIuZXU+OyAiUWluIFd1Ig0KPiA+IDxzdW5zZWF3 cUBodWF3ZWkuY29tPg0KPiA+IENjOiA8bmV0ZXh0QGlldGYub3JnPg0KPiA+IFNlbnQ6IFdlZG5l c2RheSwgQXVndXN0IDE5LCAyMDA5IDk6NTQgQU0NCj4gPiBTdWJqZWN0OiBSRTogW25ldGV4dF0g UE1JUDYgYW5kIHJvYW1pbmcNCj4gPg0KPiA+DQo+ID4gSGkgYWxsLA0KPiA+DQo+ID4gSSBqdXN0 IGZvbGxvd2VkIHRoZSB0aHJlYWQsIGFuZCB0cmllZCB0byBsb29rIGludG8gdGhlIHNjZW5hcmlv cyB3ZSBoYXZlDQo+ID4gaW4gdGhlIFJPIFBTIGRyYWZ0LiBXZSBoYXZlIGNsYXNzaWZpZWQgdGhl IGZvdXIgc2NlbmFyaW9zIGluIFBTIGRyYWZ0DQo+IGZvcg0KPiA+IE1BRyBsb2NhbGl6ZWQgcm91 dGluZy4NCj4gPg0KPiA+ICgxKU1OIGFuZCBDTiB1bmRlciBzYW1lIE1BRyBhbmQgYm90aCBNTiBh bmQgQ04gYmVsb25nIHRvIHNhbWUgTE1BLiBIZXJlDQo+IE1ODQo+ID4gYW5kIENOIG5lZWQgdG8g YmUgcGxhY2VkIGluIHRoZSBzYW1lIGFkbW5pc3RyYXRpdmUgZG9tYWluKGNhbmJlIHRoZWlyDQo+ IGhvbWUNCj4gPiBkb21haW4gb3IgYmUgYSBmb3JlaWduIGRvbWFpbigzR1BQIGhvbWUgcm91dGVk KSkgYW5kIHRoZXkgbmVlZCB0byBiZWxvbmcNCj4gPiB0byBzYW1lIGhvbWUgZG9tYWluLg0KPiA+ ICgyKSBNbiBhbmQgQ04gdW5kZXIgc2FtZSBNQUcgYnV0IGRpZmZlcmVudCBMTUFzKE1uIGJlbG9u ZyB0byBMTUExIGFuZCBDTg0KPiA+IGJlbG9uZyB0byBMTUEyKS4gSGVyZSwgTU4gYW5kIENOIG5l ZWQgdG8gYmUgcGxhY2VkIGluIHNhbWUNCj4gYWRtaW5pc3RyYXRpdmUNCj4gPiBkb21haW4gYnV0 IG1heSBiZWxvbmcgdG8gZGlmZmVyZW50IGFkbWluaXN0cmF0aXZlKGhvbWUpIGRvbWFpbi4NCj4g PiAoMykgTU4gYW5kIENOIHVuZGVyIGRpZmZlcmVudCBNQUdzIGJ1dCBzYW1lIExNQS4gSGVyZSBm b3IgTUFHIHRvIE1BRyBSTw0KPiB0bw0KPiA+IHdvcmssIGJvdGggTU4gYW5kIENOIG11c3QgYmUg cGxhY2VkIGluIHRoZSBzYW1lIGFkbWluaXN0cmF0aXZlDQo+IGRvbWFpbihob21lDQo+ID4gZG9t YWluIG9yIGZvcmVpZ24gZG9tYWluKDNHUFAgaG9tZSByb3V0ZWQpKSBhbmQgdGhleSBtdXN0IGJl bG9uZyB0byBzYW1lDQo+ID4gaG9tZSBkb21haW4NCj4gPiAoNCkgTU4gYW5kIENOIHVuZGVyIGRp ZmZlcmVudCBNQUcgYW5kIGRpZmZlcmVudCBMTUEoTE1BMSBhbmQgTE1BMikuIEhlcmUNCj4gPiBN TiBhbmQgQ04gbXVzdCBiZSBwbGFjZWQgaW4gc2FtZSBhZG1pbnNpdHJhdGl2ZSBkb21haW4oaG9t ZSBvciBmb3JlaWduDQo+ID4gZG9tYWluKSBhbmQgTE1BcyBzaG91bGQgYWxzbyBiZSBmcm9tIHRo ZSBzYW1lIGFkbWluc2l0cmF0aXZlKGhvbWUpDQo+IGRvbWFpbi4NCj4gPg0KPiA+IFNvLCBJIHRo aW5rIHRoYXQgTUFHIHRvIE1BRyBSTyBjYW4gd29yayB3aGVuIE1OIGFuZCBDTiBhcmUgcGxhY2Vk IGluDQo+IHNhbWUNCj4gPiBhZG1pbnNpdGFydGl2ZSBkb21haW5zIGFzIE1hcmNvIHBvaW50ZWQg b3V0LiBIb3dldmVyLCB0aGV5IG1heSBiZWxvbmcgdG8NCj4gPiBkaWZmZXJlbnQgZG9tYWlucyho b21lIGRvbWFpbnMgbWF5IGJlIGRpZmZlcmVudCkuIEFnYWluIGFzIE1hcmNvIHBvaW50ZWQNCj4g PiBvdXQgaXQgYWxsIGRlcGVuZCBvbiB0aGUgYXNzdW1wdGlvbnMgd2UgbWFrZSwgc3VjaCBhcyB3 aGV0aGVyIExNQXMgY2FuDQo+ID4gaW50ZXJhY3QgYW5kIHNvIG9uLiBBbHNvIGNvbWluZyB0byBh ZG1pbnNpdHJhdGl2ZSBkb21haW4gYW5kIFBNSVAgZG9tYWluLA0KPiA+IEkgdGhpbmsgUE1JUCBk b21haW4gYW5kIGFkbWluaXN0cmF0aXZlIGRvbWFpbiBjb2luY2lkZXMuIFllcywgaW4gM0dQUA0K PiB5b3UNCj4gPiBjYW4gc2VlIHlvdXIgSE5QIGluIGFub3RoZXIgYWRtaW5zaXRhcnRpdmUgZG9t YWluLiBCdXQgdGhlIE1uIGlzIGF3YXJlDQo+ID4gdGhhdCBpdCBpcyBhbm90aGVyIGFkbWluaXNy YXRpdmUgZG9tYWluIGFsdGhvdWdoIGl0IHNlZXMgdGhlIEhOUCBmcm9tDQo+IGhvbWUNCj4gPiBk b21haW4uDQo+ID4NCj4gPiBTbywgSSB0aGluayB3ZSBjYW4ga2VlcCB0aGUgTUFHIHRvIE1BRyBS TyBmb3IgY2FzZXMgd2hlcmUgTU4gYW5kIENOIGFyZQ0KPiA+IHBsYWNlZCBpbiB0aGUgc2FtZSBh ZG1pbnNpdHJhdGl2ZSBkb21haW4uDQo+ID4NCj4gPiBUaGFua3MuDQo+ID4NCj4gPiBCUiwNCj4g PiBNb2hhbmENCj4gPg0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZy b206IG5ldGV4dC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bmV0ZXh0LWJvdW5jZXNAaWV0Zi5v cmddIE9uDQo+IEJlaGFsZg0KPiA+ID4gT2YgTWFyY28gTGllYnNjaA0KPiA+ID4gU2VudDogVHVl c2RheSwgQXVndXN0IDE4LCAyMDA5IDg6MzkgUE0NCj4gPiA+IFRvOiBRaW4gV3UNCj4gPiA+IENj OiBuZXRleHRAaWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IFJlOiBbbmV0ZXh0XSBQTUlQNiBhbmQg cm9hbWluZw0KPiA+ID4NCj4gPiA+IGhpIFFpbiwNCj4gPiA+DQo+ID4gPiBRaW4gV3Ugc2Nocmll YjoNCj4gPiA+ID4gSGksIE1hcmNvOg0KPiA+ID4gPiAgSSBhZ3JlZSB0aGUgTG9jYWxpemVkIHJv dXRpbmcgbWVjaGFuaXNtIGNhbiBiZSBhcHBsaWNhYmxlIHRvIHRoZQ0KPiA+ID4gc2NlbmFyaW8N Cj4gPiA+ID4gIHdoZXJlIHR3byBNQUdzIGluIGNvbW11bmljYXRpb24gYXJlIHdpdGhpbiB0aGUg c2FtZQ0KPiAqYWRtaW5pc3RyYXRpdmUqDQo+ID4gPiA+IGRvbWFpbi5Ib3dldmVyIHRoZXJlIGFy ZSBzdGlsbCBjb25mdXNpb24gYmV0d2VlbiBhZG1pbmlzdHJhdGl2ZQ0KPiBkb21haW4NCj4gPiA+ ID4gYW5kIFBNSVAgZG9tYWluLiBCZWNhdXNlIFBNSVAgZG9tYWluIGNhbiBiZSB0YWtlbiBhcyBv bmUNCj4gPiBhZG1pbmlzdHJhdGl2ZQ0KPiA+ID4gPiAgZG9tYWluLCBob3dldmVyIG9uZSBhZG1p bmlzdHJhdGl2ZSBkb21haW4gbWF5IGJlIG5vdCBQTUlQIGRvbWFpbg0KPiBidXQNCj4gPiA+ID4g TUlQIGRvbWFpbi4gU28gd2hhdCdzIHRoZSBzY29wZSBvZiBhZG1pbmlzdHJhdGl2ZSBkb21haW4g YW5kIFBNSVANCj4gPiA+IGRvbWFpbj8NCj4gPiA+ID4gaXQgaXMgbmVjZXNzYXJ5IHRvIGJlIGNs YXJpZmllZCwgYW0gSSByaWdodD8NCj4gPiA+ID4NCj4gPiA+IFllcywgYnV0IEkgYW0gbm90IHN1 cmUgdGhpcyB3aWxsIGJyaW5nIHVzIGZ1cnRoZXIuIEFzIGRpZmZlcmVuY2UgdG8NCj4gdGhlDQo+ ID4gPiBQTUlQdjYgc3BlY2lmaWNhdGlvbiwNCj4gPiA+IHdlIGhhbmRsZSBzY2VuYXJpb3MgYmV0 d2VlbiB0d28gY29tbXVuaWNhdGluZyBNTnMsIHdoaWNoIG1heSBnZXQNCj4gc2VydmVkDQo+ID4g PiBieSBjb21wb25lbnRzDQo+ID4gPiBmcm9tIGRpZmZlcmVudCBhZG1pbmlzdHJhdGl2ZSBkb21h aW5zLiBTdXJlLCBhIFBNSVB2NiBkb21haW4gY2FuIGNvdmVyDQo+ID4gPiBtdWx0aXBsZSBhZG1p biBkb21haW5zLg0KPiA+ID4gSGVuY2UsIEkgdGhpbmsgZm9yIHRoZSBwcm90b2NvbCBzcGVjaWZp Y2F0aW9uIGl0J3Mgc3VmZmljaWVudCB0bw0KPiBhc3N1bWUNCj4gPiA+IHRoYXQsIHRvIHdvcmss IHRoZXJlIG11c3QNCj4gPiA+IGJlIGEgdHJ1c3QgcmVsYXRpb25zaGlwIGJldHdlZW4gY29tcG9u ZW50cyBleGNoYW5naW5nIHNpZ25hbGluZy4gU28NCj4gZm9yDQo+ID4gPiB0aGUgcHJvdG9jb2wg c3BlY2lmaWNhdGlvbg0KPiA+ID4gSSB0aGluayBpdCdzIHN1ZmZpY2llbnQgdG8gbWFuZGF0ZSBh IHNlY3VyaXR5IGFzc29jaWF0aW9uIGJldHdlZW4NCj4gdGhlc2UNCj4gPiA+IGNvbXBvbmVudHMg dG8gYXV0aGVudGljYXRlDQo+ID4gPiBtZXNzYWdlcy4NCj4gPiA+DQo+ID4gPiBtYXJjbw0KPiA+ ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gPiBSZWdhcmRzIQ0K PiA+ID4gPiAtUWluDQo+ID4gPiA+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4gPiA+ ID4gRnJvbTogIk1hcmNvIExpZWJzY2giIDxtYXJjby5saWVic2NoQG53Lm5lY2xhYi5ldT4NCj4g PiA+ID4gVG86ICJBbHBlciBZZWdpbiIgPGFscGVyLnllZ2luQHllZ2luLm9yZz4NCj4gPiA+ID4g Q2M6IDxuZXRleHRAaWV0Zi5vcmc+DQo+ID4gPiA+IFNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAwNCwg MjAwOSA0OjI2IFBNDQo+ID4gPiA+IFN1YmplY3Q6IFJlOiBbbmV0ZXh0XSBQTUlQNiBhbmQgcm9h bWluZw0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBIaSBBbHBlciwgRGVzaXJlLCBhbGwNCj4g PiA+ID4NCj4gPiA+ID4gaWYgd2UgYXNzdW1lIHRoYXQgUE1JUHY2IG9wZXJhdGVzIGJldHdlZW4g dGhlIExNQSBpbiB0aGUgVVMgYW5kIHRoZQ0KPiA+IE1BRw0KPiA+ID4gPiBpbiBTd2VkZW4sIHdl bGwsIHRoZW4gYSBzZWN1cml0eSBhc3NvY2lhdGlvbiBpcyBpbXBsaWNpdC4gSGVuY2UsDQo+IHRo ZXJlDQo+ID4gPiA+IGlzIHNvbWUgbGV2ZWwNCj4gPiA+ID4gb2YgdHJ1c3QuRm9yIHRoZSBwcm90 b2NvbCBzb2x1dGlvbiBpbiB0aGUgSUVURiwgdGhpcyBzaG91bGQgYmUgdGhlDQo+ID4gbWFpbg0K PiA+ID4gPiByZXF1aXJlbWVudC4NCj4gPiA+ID4gV2hlcmUgdGhlc2UgY29tcG9uZW50cyBhcmUg ZmluYWxseSBsb2NhdGVkIGlzIGRlcGxveW1lbnQgc3BlY2lmaWMuDQo+ID4gPiA+DQo+ID4gPiA+ IFNhbWUgZm9yIGxvY2FsaXplZCByb3V0aW5nOiBXaGVuIGEgTUFHIGNhbiBjcmVhdGUgYSBiaW5k aW5nIGF0IHRoZQ0KPiBMTUEsDQo+ID4gPiA+IEkgZG9uJ3QNCj4gPiA+ID4gc2VlIGEgcHJvYmxl bSB3aHkgdGhlIExNQSBjYW5ub3QgY3JlYXRlIGEgc3RhdGUgYXQgdGhlIE1BRyB0bw0KPiBwZXJm b3JtDQo+ID4gPiA+IGxvY2FsaXplZA0KPiA+ID4gPiByb3V0aW5nLiBTQW1lIGFzIGFib3ZlOiBB cyBsb25nIGFzIHRoZXJlIGlzIGFuIFNBIGJldHdlZW4gdGhlIHR3bw0KPiA+ID4gPiBjb21wb25l bnRzLg0KPiA+ID4gPg0KPiA+ID4gPiBGcm9tIHRoZSBkaXNjdXNzaW9uIHdlIGhhZCBpbiBTdG9j a2hvbG0sIEkgdGhpbmsgZm9yIGRlcGxveW1lbnQNCj4gPiA+ID4gcGVyc3BlY3RpdmUgaXQncyBt b3JlIGltcG9ydGFudCB0byBoYXZlIGJvdGggTUFHcyAobW9iaWxlIDEgYW5kDQo+IG1vYmlsZQ0K PiA+ID4gMikgaW4gdGhlIHNhbWUNCj4gPiA+ID4gKmFkbWluaXN0cmF0aXZlKiBkb21haW4gKHRv IGRpc3RpZ3Vpc2ggZnJvbSBhIFBNSVAgZG9tYWluKSwgYXMNCj4gaW50ZXItDQo+ID4gTUFHDQo+ ID4gPiBvcGVyYXRpb24gYmV0d2Vlbg0KPiA+ID4gPiBhZG1pbmlzdHJhdGl2ZSBkb21haW5zIGNv bXByaXNlcyB0aGUga25vd3MgaXNzdWVzLg0KPiA+ID4gPg0KPiA+ID4gPiBGb3IgdGhlIHByb3Rv Y29sIHNwZWNpZmljYXRpb246IFdlbGwsIGl0IGRvZXMgbm90IG1hdHRlci4uIGFzIGxvbmcNCj4g YXMNCj4gPiA+IE1BR3Mgc2hhcmUgYSBzZWN1cml0eSBhc3NvY2lhdGlvbiBhbmQgY2FuIHNldCB1 cCBhDQo+ID4gPiA+IGZvcndhcmRpbmcgdHVubmVsLg0KPiA+ID4gPg0KPiA+ID4gPiBtYXJjbw0K PiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBBbHBlciBZZWdpbiBzY2hyaWViOg0KPiA+ID4gPg0K PiA+ID4gPj4gSGkgRGVzaXJlLA0KPiA+ID4gPj4NCj4gPiA+ID4+IFJGQyA1MjEzOg0KPiA+ID4g Pj4NCj4gPiA+ID4+ICAgIFByb3h5IE1vYmlsZSBJUHY2IERvbWFpbiAoUE1JUHY2LURvbWFpbikN Cj4gPiA+ID4+DQo+ID4gPiA+PiAgICAgICBQcm94eSBNb2JpbGUgSVB2NiBkb21haW4gcmVmZXJz IHRvIHRoZSBuZXR3b3JrIHdoZXJlIHRoZQ0KPiA+IG1vYmlsaXR5DQo+ID4gPiA+PiAgICAgICBt YW5hZ2VtZW50IG9mIGEgbW9iaWxlIG5vZGUgaXMgaGFuZGxlZCB1c2luZyB0aGUgUHJveHkgTW9i aWxlDQo+ID4gPiBJUHY2DQo+ID4gPiA+PiAgICAgICBwcm90b2NvbCBhcyBkZWZpbmVkIGluIHRo aXMgc3BlY2lmaWNhdGlvbi4gIFRoZSBQcm94eSBNb2JpbGUNCj4gPiBJUHY2DQo+ID4gPiA+PiAg ICAgICBkb21haW4gaW5jbHVkZXMgbG9jYWwgbW9iaWxpdHkgYW5jaG9ycyBhbmQgbW9iaWxlIGFj Y2Vzcw0KPiA+IGdhdGV3YXlzDQo+ID4gPiA+PiAgICAgICBiZXR3ZWVuIHdoaWNoIHNlY3VyaXR5 IGFzc29jaWF0aW9ucyBjYW4gYmUgc2V0IHVwIGFuZA0KPiA+ID4gPj4gICAgICAgYXV0aG9yaXph dGlvbiBmb3Igc2VuZGluZyBQcm94eSBCaW5kaW5nIFVwZGF0ZXMgb24gYmVoYWxmIG9mDQo+ID4g dGhlDQo+ID4gPiA+PiAgICAgICBtb2JpbGUgbm9kZXMgY2FuIGJlIGVuc3VyZWQuDQo+ID4gPiA+ Pg0KPiA+ID4gPj4NCj4gPiA+ID4+IEkgcmVtZW1iZXIgdGhpcyB3YXMgc3BlY2lmaWNhbGx5IGRp c2N1c3NlZCBhbmQgd2UgaGFkIGNvbWUgdXAgd2l0aA0KPiBhDQo+ID4gPiB0ZXh0DQo+ID4gPiA+ PiB0aGF0IHJlZmVycyB0byAibG9jYWwgbW9iaWxpdHkgYW5jaG9ycyBhbmQgbW9iaWxlIGFjY2Vz cyBnYXRld2F5cw0KPiA+ID4gYmV0d2Vlbg0KPiA+ID4gPj4gd2hpY2ggc2VjdXJpdHkgYXNzb2Np YXRpb25zIGNhbiBiZSBzZXQgdXAiIGFzIHRoZSBsaW1pdGluZyBmYWN0b3INCj4gPiB0aGF0DQo+ ID4gPiBzZXRzDQo+ID4gPiA+PiB0aGUgYm91bmRhcnkuIEFuZCBzZWN1cml0eSBhc3NvY2lhdGlv bnMgY2FuIGJlIHNldHVwIGJldHdlZW4gTUFHcw0KPiBhbmQNCj4gPiA+IExNQXMNCj4gPiA+ID4+ IGJlbG9uZ2luZyB0byBzZXBhcmF0ZSBvcGVyYXRvcnMgd2hlbiB0aGVyZSBpcyBhIHJvYW1pbmcg YWdyZWVtZW50Lg0KPiA+ID4gV2lNQVgNCj4gPiA+ID4+IGFyY2hpdGVjdHVyZSBhbHJlYWR5IGRv ZXMgdGhhdC4NCj4gPiA+ID4+DQo+ID4gPiA+PiBBbHBlcg0KPiA+ID4gPj4NCj4gPiA+ID4+DQo+ ID4gPiA+Pg0KPiA+ID4gPj4NCj4gPiA+ID4+DQo+ID4gPiA+Pg0KPiA+ID4gPj4NCj4gPiA+ID4+ DQo+ID4gPiA+Pg0KPiA+ID4gPj4NCj4gPiA+ID4+DQo+ID4gPiA+Pj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gPiA+ID4+PiBGcm9tOiBEZXNpcmUgT3VsYWkgW21haWx0bzpkZXNpcmUu b3VsYWlAZXJpY3Nzb24uY29tXQ0KPiA+ID4gPj4+IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDMwLCAy MDA5IDQ6MTMgUE0NCj4gPiA+ID4+PiBUbzogQWxwZXIgWWVnaW47IG5ldGV4dEBpZXRmLm9yZw0K PiA+ID4gPj4+IFN1YmplY3Q6IFJFIDogW25ldGV4dF0gUE1JUDYgYW5kIHJvYW1pbmcNCj4gPiA+ ID4+Pg0KPiA+ID4gPj4+IEhpIEFscGVyLA0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4gICBTZWUgaW5s aW5lIQ0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4gRGVzaXJlDQo+ID4gPiA+Pj4NCj4gPiA+ID4+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4gRGU6 IG5ldGV4dC1ib3VuY2VzQGlldGYub3JnIGRlIGxhIHBhcnQgZGUgQWxwZXIgWWVnaW4NCj4gPiA+ ID4+PiBEYXRlOiBqZXUuIDIwMDktMDctMzAgMDg6MDINCj4gPiA+ID4+PiDAOiBuZXRleHRAaWV0 Zi5vcmcNCj4gPiA+ID4+PiBPYmpldCA6IFtuZXRleHRdIFBNSVA2IGFuZCByb2FtaW5nDQo+ID4g PiA+Pj4NCj4gPiA+ID4+Pg0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4NCj4gPiA+ID4+Pg0KPiA+ID4g Pj4+IENvbnRpbnVpbmcgdGhlIGRpc2N1c3Npb24gb24gdGhlIE1MLi4uLi4uDQo+ID4gPiA+Pj4N Cj4gPiA+ID4+Pg0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4NCj4gPiA+ID4+Pg0KPiA+ID4gPj4+IENv bnNpZGVyIG1vYmlsZTEgYW5kIG1vYmlsZTIgc3Vic2NyaWJlZCB0byBkYXRhIHNlcnZpY2UgaW4g VVNBLg0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4gVGhleSBhcmUgaW4gU3dlZGVuLCBhY2Nlc3Npbmcg SW50ZXJuZXQgYnkgInJvYW1pbmciIHRvIGEgU3dlZGlzaA0KPiA+ID4gPj4+IG9wZXJhdG9yIG5l dHdvcmsuDQo+ID4gPiA+Pj4NCj4gPiA+ID4+Pg0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4gRG9lcyBQ TUlQNiBub3Qgc3VwcG9ydCB0aGlzIGNhc2Ugd2hlcmUgTUFHIGlzIGluIFN3ZWRpc2ggb3BlcmF0 b3INCj4gPiA+ID4+PiBuZXR3b3JrLCBhbmQgTE1BIGluIFVTQSBvcGVyYXRvcidzIG5ldHdvcms/ IEkgdGhpbmsgdGhlIGFuc3dlciBpcw0KPiA+IHllcy4NCj4gPiA+ID4+Pg0KPiA+ID4gPj4+IFtE ZXNpcmVdOiAgIEkgdGhpbmsgUE1JUDYgYXMgZGVmaW5lZCBpbiBSRkM1MjEzIGRvZXMgbm90IHN1 cHBvcnQNCj4gPiB0aGlzDQo+ID4gPiA+Pj4gc2NlbmFyaW8gYXMgdGhlIE1BRyBhcmUgbm90IGlu IHRoZSBzYW1lIFBNSVAgZG9tYWluLiBIb3dldmVyLCBTRE9zDQo+ID4gPiBsaWtlDQo+ID4gPiA+ Pj4gM0dQUCBzdXBwb3J0cyBob21lIHR1bm5lbGxpbmcuDQo+ID4gPiA+Pj4NCj4gPiA+ID4+Pg0K PiA+ID4gPj4+DQo+ID4gPiA+Pj4gV291bGRuJ3Qgd2Ugd2FudCB0byBvcHRpbWl6ZSB0aGUgcGF0 aCBiZXR3ZWVuIG1vYmlsZTEgYW5kIG1vYmlsZTINCj4gdG8NCj4gPiA+ID4+PiBzYXZlIHRoZSB0 cmFmZmljIGZyb20gbWFraW5nIHRoZSB1bm5lY2Vzc2FyeSBVU0EgdHJpcD8gSSB0aGluayB0aGUN Cj4gPiA+ID4+PiBhbnN3ZXIgaXMgeWVzIGFnYWluLg0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4gW0Rl c2lyZV06IEkgYWdyZWUgdGhhdCBpdCBpcyBhbiBpbnRlcmVzdGluZyBvcHRpbWl6YXRpb24uIEJ1 dCB3ZQ0KPiA+IG5lZWQNCj4gPiA+ID4+PiBmaXJzdCB0byBjbGFyaWZ5IHRoZSByZWxhdGlvbiBi ZXR3ZWVuIHRoZSBNQUcgaW4gc3dlZGVuIGFuZCB0aGUNCj4gTE1BDQo+ID4gaW4NCj4gPiA+ID4+ PiBVU0EuIFNvIHdlIG5lZWQgdG8gc3BlY2lmeSBQTUlQNiByb2FtaW5nIGJlZm9yZSB0YWxraW5n IGFib3V0DQo+ID4gPiBMb2NhbGl6ZWQNCj4gPiA+ID4+PiByb3V0aW5nIGluIFBNSVA2IHJvYW1p bmcuDQo+ID4gPiA+Pj4NCj4gPiA+ID4+Pg0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4gQ29tbWVudHM/ DQo+ID4gPiA+Pj4NCj4gPiA+ID4+Pg0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4gQWxwZXINCj4gPiA+ ID4+Pg0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4NCj4gPiA+ID4+Pg0KPiA+ID4gPj4+DQo+ID4gPiA+ Pj4NCj4gPiA+ID4+Pg0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4NCj4gPiA+ID4+Pg0KPiA+ID4gPj4+ DQo+ID4gPiA+Pj4NCj4gPiA+ID4+Pg0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4NCj4gPiA+ID4+Pg0K PiA+ID4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gPiA+ID4+IG5ldGV4dCBtYWlsaW5nIGxpc3QNCj4gPiA+ID4+IG5ldGV4dEBpZXRmLm9yZw0K PiA+ID4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRleHQNCj4g PiA+ID4+DQo+ID4gPiA+Pg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gPiBuZXRleHQgbWFpbGlu ZyBsaXN0DQo+ID4gPiA+IG5ldGV4dEBpZXRmLm9yZw0KPiA+ID4gPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGV4dA0KPiA+ID4NCj4gPiA+DQo+ID4gPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gbmV0ZXh0IG1h aWxpbmcgbGlzdA0KPiA+ID4gbmV0ZXh0QGlldGYub3JnDQo+ID4gPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGV4dA== From xiajinwei@huawei.com Fri Aug 28 02:34:07 2009 Return-Path: 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 F15063A68FA for ; Fri, 28 Aug 2009 02:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 jMc17moAVnWx for ; Fri, 28 Aug 2009 02:34:05 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 5ECD33A6BA0 for ; Fri, 28 Aug 2009 02:34:05 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KP2001GIYI9QY@szxga04-in.huawei.com> for netext@ietf.org; Fri, 28 Aug 2009 17:32:33 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KP200275YI4D1@szxga04-in.huawei.com> for netext@ietf.org; Fri, 28 Aug 2009 17:32:28 +0800 (CST) Received: from x65217 ([10.164.12.67]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KP200GALYHMT1@szxml04-in.huawei.com> for netext@ietf.org; Fri, 28 Aug 2009 17:32:11 +0800 (CST) Date: Fri, 28 Aug 2009 17:32:05 +0800 From: Jinwei Xia To: netext@ietf.org Message-id: <009101ca27c2$6b517680$430ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/mixed; boundary="Boundary_(ID_3x42VWexqWZNkCmD369h1A)" Thread-index: Acol6n/JNQOLPR0wSduCCDzHCU6cBwBmjrzgAA9Y0GA= Subject: [netext] FW: [Netext] New Version Notification for draft-wakikawa-netext-lma-reliability-00 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 09:34:08 -0000 This is a multi-part message in MIME format. --Boundary_(ID_3x42VWexqWZNkCmD369h1A) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Sorry for skipping this WG mail address. If you receive a couple mails, please ignore it. BR Jinwei > -----Original Message----- > From: netext-bounces@mail.mobileip.jp > [mailto:netext-bounces@mail.mobileip.jp] On Behalf Of Jinwei Xia > Sent: Friday, August 28, 2009 10:20 AM > To: netext@mail.mobileip.jp > Cc: ryuji@us.toyota-itc.com > Subject: Re: [Netext] New Version Notification for > draft-wakikawa-netext-lma-reliability-00 > > Hi All, > > A new version of I-D, > draft-wakikawa-netext-lma-reliability-00.txt has been > successfuly submitted to the Netlmm Extension Working Group > of the IETF. > > Filename: draft-wakikawa-netext-lma-reliability > Revision: 00 > Title: PMIP extension to Home Agent > Reliability Protocol > Creation_date: 2009-08-25 > WG ID: Independent Submission > Number_of_pages: 13 > > Abstract: > This document introduces an extension to the Home Agent > Reliability protocol standardized in MEXT Working Group for > LMA reliability. In Proxy Mobile IPv6[RFC5213], LMA is an > anchor which is similar to Home Agent of Mobile > IPv6[RFC3775]. Providing LMA reliability is achieved with > the extensions described in this document. In this document, > we list and analysis two failure detection mechanisms, and > give the solution accroding to each failure detection. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-wakikawa-netext-lma- > reliability-00 > .txt > > Any comments are very appreciated > > > BR > Jinwei > --Boundary_(ID_3x42VWexqWZNkCmD369h1A) Content-type: text/plain; name=draft-wakikawa-netext-lma-reliability-00.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=draft-wakikawa-netext-lma-reliability-00.txt NETEXT Working Group R. Wakikawa, Ed. Internet-Draft Toyota ITC Intended status: Standards Track J. Xia, Ed. Expires: February 26, 2010 Huawei August 25, 2009 PMIP extension to Home Agent Reliability Protocol draft-wakikawa-netext-lma-reliability-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 26, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document introduces an extension to the Home Agent Reliability protocol standardized in MEXT Working Group for LMA reliability. In Wakikawa & Xia Expires February 26, 2010 [Page 1] Internet-Draft LMA Reliability August 2009 Proxy Mobile IPv6[RFC5213], LMA is an anchor which is similar to Home Agent of Mobile IPv6[RFC3775]. Providing LMA reliability is achieved with the extensions described in this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. LMA Failure Detection . . . . . . . . . . . . . . . . . . . . 4 4. LMA Virtual Switch Mode . . . . . . . . . . . . . . . . . . . 5 5. LMA Hard Switch Mode . . . . . . . . . . . . . . . . . . . . . 5 5.1. MAG Operation . . . . . . . . . . . . . . . . . . . . . . 6 5.2. LMA Operation . . . . . . . . . . . . . . . . . . . . . . 7 6. Mobility Option and Message . . . . . . . . . . . . . . . . . 8 6.1. Proxy Binding Cache Information Option . . . . . . . . . . 8 6.2. LMA Failure Indication Mobility Option . . . . . . . . . . 10 6.3. Home Agent Control Message . . . . . . . . . . . . . . . . 11 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Wakikawa & Xia Expires February 26, 2010 [Page 2] Internet-Draft LMA Reliability August 2009 1. Introduction This document specifies small extensions to the Home Agent Reliability protocol[ID-HARELIABILITY]. Local Mobility Anchor (LMA) acts as an anchor point in Proxy Mobile IPv6, while Home Agent (HA) is used in Mobile IPv6 [RFC3775]. Therefore, this specification aims to support LMA reliability for Proxy Mobile IPv6. Since mobility managements are not handled by a mobile node, LMA failure and recovery must be fully transparent to the mobile node. All the operations defined in this specification are completed between LMA and Mobile Access Gateways (MAGs). Figure 1 shows the network configuration of LMAs in a Proxy Mobile IPv6 domain. LMA1' is a standby LMA for LMA1. Besides the failure detection mechanism specified in [ID-HARELIABILITY], there exists other specific mechanism for LMA failure detection. The detail description will be given in Section 3. The Home Agent Reliability protocol has two different operational modes such as hard-switch and virtual-switch. This specification also supports the two modes. All the assumptions are same as [ID-HARELIABILITY] such as IPsec synchronization, same address configuration, etc. For example, if LMAA1 and LMAA1' are same address, the operation can be virtual switch mode. On the other hand, if they are different, it should be hard switch mode. The detail operations will be given in Section 4 and Section 5. While the detail description of new mobility option and message will be given in Section 6. Wakikawa & Xia Expires February 26, 2010 [Page 3] Internet-Draft LMA Reliability August 2009 +----+ +-----+ +----+ +-----+ |LMA1| |LMA1'| |LMA2| |LMA2'| +----+ +-----+ +----+ +-----+ LMAA1 -> | LMAA1'->| LMAA2-> | LMAA2'-> | | | | | \\ || // // \\ || // // \\ || // // +---\\--- ||---------//---- //-------+ ( \\ || // // ) ( \\ \\ // // ) +------\\--||-----//---//----------+ \\ || // // \\|| // // \\\\ //// Proxy-CoA1--> | +----+ |MAG1|-----{MN2} +----+ | | | MN-HNP1 --> | MN-HNP2 {MN1} Figure 1: LMA Network Configuration 2. Terminology The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. All terms in this document are defined in[RFC5213], [ID-HEARTBEAT] and [ID-HARELIABILITY]. In addition or in replacement of these, the following terms are defined or redefined: Current LMA A LMA that is currently serving the MAGs. The LMA maybe still keep active when the tunnel between itself and MAG fail. 3. LMA Failure Detection LMA Failure events used in the Local Mobility Anchor Reliability protocol are listed below. Wakikawa & Xia Expires February 26, 2010 [Page 4] Internet-Draft LMA Reliability August 2009 Detection Mechanism specified in [ID-HARELIABILITY] Three mechanisms are defined in [ID-HARELIABILITY] such as Loss of HA-HELLO, Monitored Server Failure by the Active HA, Routing Peer/ Link Failure. Each LMA should exchange HA-HELLO for failure detection. Heartbeat Mechanism for Proxy Mobile IPv6 [ID-HEARTBEAT] In Proxy Mobile IPv6, both LMA and MAG should involve in detecting LMA failure. Heartbeat mechanism specified in [ID-HEARTBEAT] can be used as an indication of LMA failure. If a MAG detects LMA failure, it can solicit a standby LMA to recover the failed LMA. This solicitation can be sent only in the hard switch mode. In the hard switch mode, MAG cannot reach to the standby LMA until the standby LMA completes taking over the failed LMA. If a LMA detects the tunnel failure with one, some or all MAGs, it can treats this events as a hint of LMA failure. However, the LMA SHOULD NOT start the failover as soon as it detects the failure events by using heartbeat mechanism. It is because the heartbeat mechanism detects only the tunnel failure. The tunnel failure might be caused by transport network failure or other reasons than LMA failure. 4. LMA Virtual Switch Mode In the virtual switch mode, each LMA is configured with a same LMA address (LMAA). A standby LMA MUST support the IPsec states synchronization functionality for this virtual switch mode. As soon as LMA failure is detected, the standby LMA becomes active and takes over the failed LMA as defined in [ID-HARELIABILITY]. 5. LMA Hard Switch Mode In the hard switch mode, each LMA is configured with different LMA address (LMAA). A standby LMA should creates security association with MAGs beforehand. It can also establishes a tunnel with MAGs before LMA failure. In this case that LMA-HELLO mechanism is employed in LMA failure detection, the concrete procedure of LMA Hard Switch is similar to operation specified in [ID-HARELIABILITY]. As soon as LMA failure is detected, the standby LMA sends HA switch message to all the MAGs for which the failed LMA served as defined in [ID-HARELIABILITY]. In this case that Heartbeat Mechanism defined in [ID-HEARTBEAT] is Wakikawa & Xia Expires February 26, 2010 [Page 5] Internet-Draft LMA Reliability August 2009 employed in LMA failure detection, MAG needs to actively involve in detecting LMA failure. After a MAG establishes IPsec/IKE states with all the LMAs in the redundant LMA set beforehand, MAG needs to trigger heartbeat exchanges with each LMA respectively for checking peers reachability. If the transport network between MAG and LMA corrupts than LMA failure, it may result in the loss of connectivity for MAG attached on LMA, however, the LMA is still active. In this case, LMA-HELLO mechanism cannot detect the failure, and more further considerations are needed. The following subsections will only focus on the concrete solution to solve this problem of the tunnel failure. 5.1. MAG Operation MAG needs to discover multiple LMA addresses, the discovery description is specified in [ID-LMADISCOVERY]. MAG authenticates itself to multiple LMAs and creates IPsec SAs with them as defined in [ID-HARELIABILITY]. When MAG sends heartbeat request message to active LMA beyond MISSING_HEARTBEATS_ALLOWED amount without response, MAG concludes that current LMA is unreachable. In this case, MAG indictates current LMA failure to a reachable standby LMA and solicits the standby LMA to takeover the current LMA. MAG initiates proxy binding update message to standby LMA with LMA failure indication. Standby LMA MUST responds proxy binding aknowledge message until standby LMA completes taking over the current LMA. The overview of operation is shown in Figure 2. Wakikawa & Xia Expires February 26, 2010 [Page 6] Internet-Draft LMA Reliability August 2009 MAG LMA1(Current) LMA2(Standby) | | | |<--------------------->| 1. IKEv2 exchange |---------->| | 2. Proxy Binding Update | | | 3. LMA1 allocate MN-HNP, Setup BCE |<----------| | 4. Proxy Binding Acknowledgment | | | |<--------------------->| 5. IKEv2 exchange | | | | |<--------->| 6. State exchange (proxy binding cache) | | | |<--------->X | 7. HeartBeat exchange overtime | X | |---------------------->| 8. Proxy Binding Update (with LMA failure | X | indication) | X | |<----------------------| 9. Proxy Binding Acknowledgment | X | | X | RECOVERY COMPLETE Figure 2: MAG Opertation in LMA Hard Switch 5.2. LMA Operation If a MAG detects the tunnel failure with current LMA by heartbeat mechanism, it should solicit a standby LMA, with which MAG pre- establishes IPsec/IKE state, to recover the failed LMA. Usually the current LMA also can detect the tunnel failure by heartbeat mechanism. However current LMA MUST NOT solicit standby LMA to takeover itself because the unreachability may be caused by MAG failure, and current LMA should not know whether the tunnel between MAG and standby LMA is active or not. Upon receiving PBU message from MAG with LMA failure indication, standby LMA MUST include proxy care-of address of MAG in SwitchOver Request Message as specified in section 6.3 to notify current LMA that packets of MAG will be routed to standby LMA instead of current LMA. Whereas in this case, current LMA should not transit to standby state and still provide mobile service for other reachable MAGs. At that time, two LMA are both available for different MAGs respectively. More details are shown in Figure 3. Wakikawa & Xia Expires February 26, 2010 [Page 7] Internet-Draft LMA Reliability August 2009 MAGs LMA1(Current) LMA2(Standby) | | | | X | |---------------------->| 1. Sending PBU message (with LMA | X | failure indication) | X | | X<----------| 2. LMA2 sends SwitchOver Request (with PCoA option) | X---------->| 3. LMA1 sends SwitchOver Reply | X | |<----------------------| 4. Binding PBA message | X | | X<----------| 5. LMA2 sends SwitchCompl (optional) | X | | X | RECOVERY COMPLETE Figure 3: LMA Opertation in LMA Hard Switch 6. Mobility Option and Message 6.1. Proxy Binding Cache Information Option The LMA Reliability protocol extends Binding Cache Information Option specified in section 5.2.2 of [ID-HARELIABILITY]. The proxy binding cache information option has an alignment requirement of 4n+2. The Proxy Binding Cache Information option is only valid in a State Synchronization message. Its format is as follows: Wakikawa & Xia Expires February 26, 2010 [Page 8] Internet-Draft LMA Reliability August 2009 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = TBD | Length = 40 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Proxy Care-of Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ ~ ~ ~ Mobile Node Mobility Options ~ ~ ~ + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Proxy Binding Cache Information Option Besides of Tunnel Interface ID Option and Proxy Care-of Address option, each LMA also MUST carry the Mobile Node Mobility Options in Proxy Binding Cache Information Option in the State Synchronization message. Mobile Node Mobility Options are very similar to Mobility Options specified in [RFC5213]. 1. Mobile Node Identifier Option (mandatory) 2. Home Network Prefix option (mandatory) 3. Access Technology Type option (mandatory) 4. Timestamp Option (optional) 5. Mobile Node Link-layer Identifier option (optional) 6. Link-local Address option (optional) All the fields of Mobile Node Mobility Options in Proxy Binding Cache information option are copied from the registered proxy binding of one or more particular mobile nodes. The 8-bit Reserved field MUST Wakikawa & Xia Expires February 26, 2010 [Page 9] Internet-Draft LMA Reliability August 2009 be set to zero. 6.2. LMA Failure Indication Mobility Option The LMA Reliability protocol extends this option in PBU message as an indication to standby LMA that MAG detect the tunnel failure and solicit standby LMA to takeover current LMA's role. The LMA Failure Indication mobility option in the PBU MUST contain the IPv6 addresses of the current LMA. The LMA Failure Indication mobility option in the PBU MAY contain the IPv4 addresses of the current LMA. The LMA Failure Indication mobility option has the alignment requirement of 4n+2. There can zero or only one LMA Failure Indication mobility option in the PBU. The format of the LMA Failure Indication mobility option is shown below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6 current LMA Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional IPv4 current LMA Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: LMA Failure Indication Mobility Option Type 8-bit unsigned integer. TBD Length 8-bit unsigned integer indicating the length in octets of the option, excluding the type and length fields. IPv6 current LMA Address the IPv6 address of the current LMA. Optional IPv4 current LMA Address Wakikawa & Xia Expires February 26, 2010 [Page 10] Internet-Draft LMA Reliability August 2009 the IPv4 address of the current LMA. 6.3. Home Agent Control Message The LMA Reliability protocol extends this message for the LMA Hard Switch. When standby LMA receives PBU message from MAG with LMA failure indication, it MUST include proxy care-of address of MAG in MAG Address Option in SwitchOver Request Message (type field of Home Agent Control Message is 0) to notify current LMA that packets of MAG will be routed to standby LMA instead of current LMA from then on. If current LMA also detect the MAG unreachability by heartbeat exchange, current LMA should log the event and respond SwitchOver Reply Message (type field of Home Agent Control Message is 1) to standby LMA as soon as receiving SwitchOver Request Message from a standby LMA. The response operation is same as [ID-HARELIABILITY]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | MAG Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . Mobility options . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Home Agent Control Message Type 8-bit unsigned integer. The type value MUST be 0 to indicate as SwitchOver Request Message. MAG Address The IPv6 or IPv4 address of MAG need to switch LMA, this field value is only valid for SwitchOver Request Message. Standby LMA should take over all sessions of the MNs attached on the current MAG. Wakikawa & Xia Expires February 26, 2010 [Page 11] Internet-Draft LMA Reliability August 2009 7. IANA considerations A new option is used to synchronizing Proxy Binding Cache information of MAG in State Synchronization message between LMAs. This option is specified in section 6.1. A new mobility option is used to indicate current LMA failure to standby LMA. This option is specified in section 6.2. MAG Address Option is used to extend Home Agent Control Message defined in [ID-HARELIABILITY]. This option is specified in section 6.3. 8. Security Considerations No security vulnerability is introduced in this specification. All the signaling are protected as described in [ID-HARELIABILITY] and in [RFC5213]. 9. Acknowledgments The authors would like to thank all colleagues for their review and comments of this draft. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [RFC5142] Haley, B., Devarapalli, V., Deng, H., and J. Kempf, "Mobility Header Home Agent Switch Message", RFC 5142, January 2008. [ID-HARELIABILITY] Wakikawa, R., "Home Agent Reliability Protocol", draft-ietf-mip6-hareliability-04.txt (work in progress), July 2008. Wakikawa & Xia Expires February 26, 2010 [Page 12] Internet-Draft LMA Reliability August 2009 [ID-HEARTBEAT] Devarapalli , V., "Heartbeat Mechanism for Proxy Mobile IPv6", draft-ietf-netlmm-pmipv6-heartbeat-04 (work in progress), February 2009. 10.2. Informative References [ID-PMIP6-IPv4] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-09 (work in progress), January 2009. [ID-LMADISCOVERY] Korhonen, J. and V. Devarapalli, "LMA Discovery for Proxy Mobile IPv6", draft-korhonen-netlmm-lma-discovery-00 (work in progress), October 2008. [ID-GENERICSIGNALING] Haley, B. and S. Gundavelli, "Mobile IPv6 Generic Signaling Message", draft-ietf-mext-generic-signaling-message-00 (work in progress), February 2009. Authors' Addresses Ryuji Wakikawa (editor) Toyota ITC 465 Bernardo Avenue Mountain View, CA 94043 USA Email: ryuji@us.toyota-itc.com Jinwei Xia (editor) Huawei Hui Hong Mansion Nanjing, Baixia District 210001 China Phone: +86-025-84565890 Email: xiajinwei@huawei.com Wakikawa & Xia Expires February 26, 2010 [Page 13] --Boundary_(ID_3x42VWexqWZNkCmD369h1A) Content-type: text/plain; name=ATT00116.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=ATT00116.txt _______________________________________________ NetExt mailing list NetExt@mail.mobileip.jp http://www.mobileip.jp/mailman/listinfo/netext --Boundary_(ID_3x42VWexqWZNkCmD369h1A)--