From mip6-bounces@ietf.org Wed Jan 04 15:05:47 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuEtH-000502-7o; Wed, 04 Jan 2006 15:05:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuEtF-0004z6-Ca for mip6@megatron.ietf.org; Wed, 04 Jan 2006 15:05:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18897 for ; Wed, 4 Jan 2006 15:04:29 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuEyk-0006kE-V4 for mip6@ietf.org; Wed, 04 Jan 2006 15:11:29 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-3.cisco.com with ESMTP; 04 Jan 2006 11:57:00 -0800 X-IronPort-AV: i="3.99,330,1131350400"; d="scan'208,217"; a="387386072:sNHT3455483774" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k04Juxuj012420 for ; Wed, 4 Jan 2006 11:56:59 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 4 Jan 2006 11:56:59 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 4 Jan 2006 11:56:59 -0800 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC520123B475@xmb-sjc-235.amer.cisco.com> Thread-Topic: Generalizing draft-jang-dhc-haopt for MIPv6 support in DHCP Thread-Index: AcYRaQWj0fiHYK7lT5mt084tSDibLA== From: "Kent Leung \(kleung\)" To: X-OriginalArrivalTime: 04 Jan 2006 19:56:59.0493 (UTC) FILETIME=[05E77150:01C61169] X-Spam-Score: 0.8 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Subject: [Mip6] Generalizing draft-jang-dhc-haopt for MIPv6 support in DHCP X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0121132887==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============0121132887== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61169.05F059D3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C61169.05F059D3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi. This draft should probably be named draft-jang-dhc-mip6options. 1) There were talks of folding this draft into draft-ietf-mip6-bootstrapping-integrated-dhc. I would prefer to keep the DHCP draft as standalone as an independent DHCP options document for MIPv6. How is this going to be decided? 2) Can we add the Home Address Option to the DHCP draft to provide general MIPv6 capability. This allows the Home Address to be assigned by the network via DHCPv6. There are solutions that use DHCP to obtain the Home Address for MN to register. The Home Agent address can be obtained via DHCP, so seems natural for the HoA to be available as well. There doesn't seem to be any harm for this additional option in the draft. 3) Any other MIPv6 attributes that should be conveyed in DHCP Options? Kent -- | | Kent Leung :|: :|: IP Mobility Development :|||: :|||: Internet Technologies Division :|||||||: :|||||||: Voice: +1.408.526.5030 .:|||||||||:.:|||||||||:. Email: kleung@cisco.com c i s c o S y s t e m s http://www.ciscopress.com/title/158705132X =20 ------_=_NextPart_001_01C61169.05F059D3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi.   This = draft should=20 probably be named draft-jang-dhc-mip6options.

1) There were talks of folding this draft = into draft-ietf-mip6-bootstrapping-integrated-dhc.  I would = prefer to=20 keep the DHCP draft as standalone as an independent DHCP options = document for=20 MIPv6.  How is this going to be decided?

2)=20 Can we add the Home Address Option to the DHCP draft to provide general = MIPv6=20 capability.  This allows the Home Address to be assigned by the = network via=20 DHCPv6.  There are solutions that use DHCP to obtain the Home = Address for=20 MN to register.  The Home Agent address can be obtained via DHCP, = so seems=20 natural for the HoA to be available as well.  There doesn't seem to = be any=20 harm for this additional option in the = draft.

3) Any = other MIPv6=20 attributes that should be conveyed in DHCP Options?

Kent

--
    =20 |        =20 |            =       =20 Kent Leung
    :|:       = :|:           &nbs= p;     =20 IP Mobility Development
   :|||:     =20 :|||:           &n= bsp;    =20 Internet Technologies Division
  :|||||||: =20 :|||||||:         =20       Voice:=20 +1.408.526.5030
.:|||||||||:.:|||||||||:.    =20          Email: kleung@cisco.com
c i s c o S y s = t e m=20 s  http://www.ciscopress.com/title/158705132X

 
------_=_NextPart_001_01C61169.05F059D3-- --===============0121132887== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0121132887==-- From mip6-bounces@ietf.org Sun Jan 08 05:23:14 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvXhh-0003rb-SR; Sun, 08 Jan 2006 05:23:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvXhg-0003qc-BC for mip6@megatron.ietf.org; Sun, 08 Jan 2006 05:23:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14386 for ; Sun, 8 Jan 2006 05:21:54 -0500 (EST) Received: from web15110.mail.cnb.yahoo.com ([202.165.103.79]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EvXnu-00057J-Ei for mip6@ietf.org; Sun, 08 Jan 2006 05:29:41 -0500 Received: (qmail 21457 invoked by uid 60001); 8 Jan 2006 10:22:54 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.cn; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=TJKBXnQ3O14kMhBMbED7Ly4VqDFNvppwB4r0mZnYAL9X1Y3p49/lynuHo7rCJkpqYHTYNAv8vVaoXepPEymFTLHqecWsdcAzMYKBE8f4FNxdfcLgS0thK1F+K/n+EBQdolyD/d43nLgi0XsrYRS558BrCtKKBpOBfj2Zb4AKM74= ; Message-ID: <20060108102254.21455.qmail@web15110.mail.cnb.yahoo.com> Received: from [59.64.217.81] by web15110.mail.cnb.yahoo.com via HTTP; Sun, 08 Jan 2006 18:22:54 CST Date: Sun, 8 Jan 2006 18:22:54 +0800 (CST) From: johnny pan To: mip6@ietf.org MIME-Version: 1.0 X-Spam-Score: 1.4 (+) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [Mip6] A question about MIPv6! X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2102710932==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org --===============2102710932== Content-Type: multipart/alternative; boundary="0-735103287-1136715774=:20815" --0-735103287-1136715774=:20815 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id FAA14386 Hello everybody, i have a question about RFC3775 and i hope somebody ca= n solve my puzzle. It's about the procedure of the MIPv6.=20 When MN move into the foreign network, it register in HA with its CoA, = and then the outside CN or MN itself may initiate the first communication= with each other. Does that mean whoever initiate the communication, the = first packet must pass the HA through the IPv6-in-IPv6 tunnel? Does MIPv6= differ from MIPv4 in this point? Because as i know in MIPv4, the packets= sent by MN will be directed toward CN, but the packets return from CN wi= ll pass the tunnel between HA and MN. Does that mean before MN initiate the Return Routability test and the B= inding Update between MN and CN, the communication between MN and CN must= forwarded by HA through the bi-directional tunnel between MN and HA? In= my opinion, the procedure is: 1.Registration of MN with HA. 2.Communications between MN and CN through HA with the bi-directional t= unnel. 3.MN initiate the Return Routability test, and then send Binding Update= to CN 4.After the BU and BA between MN and CN, communication between MN and C= N can be set up directly without the participation of HA. I don't know whether my understanding is right or not. The two modes of= Reverse Tunneling and RO only one of them could be used? or just they c= an be used both according to the accomplishment of RRT and Binding Update= procedure between MN and CN. =20 Thank you so much! =20 =20 --------------------------------- =20 pann 2006-01-08 =09 --------------------------------- =D1=C5=BB=A21G=C3=E2=B7=D1=D3=CA=CF=E4=B0=D9=B7=D6=B0=D9=B7=C0=C0=AC=BB=F8= =D0=C5 =D1=C5=BB=A2=D6=FA=CA=D6=A1=A7D=CB=D1=CB=F7=A1=A2=C9=B1=B6=BE=A1=A2=B7=C0= =C9=A7=C8=C5 =20 --0-735103287-1136715774=:20815 Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id FAA14386
Hello eve= rybody, i have a question about RFC3775 and i hope somebody can solve my = puzzle.
It'= s about the procedure of the MIPv6.
When MN move into the foreign network, it regis= ter in HA with its CoA, and then the outside CN or MN itself may initiate= the first communication with each other. Does that mean whoever initiate= the communication, the first packet must pass the HA through the IPv6-in= -IPv6 tunnel? Does MIPv6 differ from MIPv4 in this point? Because as i kn= ow in MIPv4, the packets sent by MN will be directed toward CN, but the p= ackets return from CN will pass the tunnel between HA and MN.
Does that mean be= fore MN initiate the Return Routability test and the Binding Update betwe= en MN and CN, the communication between MN and CN must forwarded by HA through the bi-directional tunnel between MN and HA?  In my opin= ion, the procedure is:
1.Registration of MN with HA.
2.Communications between MN and CN th= rough HA with the bi-directional tunnel.
3.MN initiate the Return Routability test, = and then send Binding Update to CN
4.After the BU and BA between MN and CN, communica= tion between MN and CN can be set up directly without the participat= ion of HA.
= I don't know whether my understanding is right or not. The two modes = ;of Reverse Tunneling and RO  only one of them could be used? o= r just they can be used both according to the accomplishment of = ;RRT and Binding Update procedure between MN and CN.
 = ;
Thank you so much!
 
pann
2006-= 01-08

=20 =D1=C5=BB=A21G=C3=E2=B7=D1=D3=CA=CF=E4=B0=D9=B7=D6=B0=D9=B7=C0=C0=AC=BB=F8= =D0=C5
=20 =D1=C5=BB=A2=D6=FA=CA=D6= =A1=A7D=CB=D1=CB=F7=A1=A2=C9=B1=B6=BE=A1=A2=B7=C0=C9=A7=C8=C5=20 =20 --0-735103287-1136715774=:20815-- --===============2102710932== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============2102710932==-- From mip6-bounces@ietf.org Sun Jan 08 12:27:46 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EveKY-0003rU-HV; Sun, 08 Jan 2006 12:27:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EveKW-0003qb-Bp for mip6@megatron.ietf.org; Sun, 08 Jan 2006 12:27:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07065 for ; Sun, 8 Jan 2006 12:26:25 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EveQp-0007JK-8q for mip6@ietf.org; Sun, 08 Jan 2006 12:34:17 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id k08HR2w29749; Sun, 8 Jan 2006 18:27:02 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id k08HR3M7026179; Sun, 8 Jan 2006 18:27:03 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200601081727.k08HR3M7026179@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: johnny pan Subject: Re: [Mip6] A question about MIPv6! In-reply-to: Your message of Sun, 08 Jan 2006 18:22:54 +0800. <20060108102254.21455.qmail@web15110.mail.cnb.yahoo.com> Date: Sun, 08 Jan 2006 18:27:03 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org In your previous mail you wrote: Does that mean before MN initiate the Return Routability test and the Binding Update between MN and CN, the communication between MN and CN must forwarded by HA through the bi-directional tunnel between MN and HA? => this is the standard behavior but is not mandatory, i.e., the MN or the CN may launch a RR test before sending the first traffic packet. (The real issue is this needs a priori knowledge of future communications) I don't know whether my understanding is right or not. The two modes of Reverse Tunneling and RO only one of them could be used? => Routing Optimization is as its name suggests an *optimization*. Regards Francis.Dupont@point6.net _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jan 09 05:03:06 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Evtrm-0001r9-8y; Mon, 09 Jan 2006 05:03:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Evtrk-0001r4-JM for mip6@megatron.ietf.org; Mon, 09 Jan 2006 05:03:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01833 for ; Mon, 9 Jan 2006 05:01:46 -0500 (EST) Received: from web15102.mail.cnb.yahoo.com ([202.165.103.71]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EvtyC-0007TU-AQ for mip6@ietf.org; Mon, 09 Jan 2006 05:09:46 -0500 Received: (qmail 86671 invoked by uid 60001); 9 Jan 2006 10:02:44 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.cn; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=kyypBtqWOk+/ps63PQAnNBqGcKEvnzFpS4WW4Mm9LRy/5xY62O1a+S3W2ROcYsAF3GfYKU2nxhXjYA1Yaf4jcHkrHen35CxQsh9LO2gVok2XUPSZuIQ9dSHdFvLLtHxguEaVyh4sSQquEjyVjbTXfIVyVEhk7UJ1/GDg9HMZSnM= ; Message-ID: <20060109100244.86669.qmail@web15102.mail.cnb.yahoo.com> Received: from [59.64.217.81] by web15102.mail.cnb.yahoo.com via HTTP; Mon, 09 Jan 2006 18:02:44 CST Date: Mon, 9 Jan 2006 18:02:44 +0800 (CST) From: johnny pan Subject: Re: [Mip6] A question about MIPv6! To: Francis.Dupont@point6.net MIME-Version: 1.0 X-Spam-Score: 1.9 (+) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2022209590==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org --===============2022209590== Content-Type: multipart/alternative; boundary="0-1436931982-1136800964=:85251" --0-1436931982-1136800964=:85251 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id FAA01833 So when will the RRT begin? Can this happen: after a short time of data= transmission between MN and CN through bi-direnctional tunnel, MN start= RRT and send BU to CN, after that MN switch the transmisson directly to = CN? Can this happen? Or it is for sure that after MN register with HA, it= will start RRT and register with CN at once before any data transmission= between MN and CN, if CN support MIPv6 and have a binding cache? When i disscuss this with my classmate, we cannot agree with each other= , and we cannot find enough evidence in RFC3775, so i hope i can get some= help here. His opinion about the procedure is as follow: 1.MN register with HA and get a CoA 2.begin RRT with CN at once before any data transmission, and through w= hich MN will know whether CN support RO. If CN does support RO, MN will s= end data directly to CN; if not, all data transmission will pass HA. It c= an be described as a procedure of "Register with HA->RRT->direct data tra= nsmission". And my opion is: 1.MN register with HA and get a CoA 2.MN or CN may initiate data communication first, and becauce MN have n= o information about CN(if MN send data to the "unknown" CN first), this k= ind of communication will have to pass HA. After some time of data transm= ission, MN initiate the RRT and register with CN. It can be described as = a procedure of "Register with HA->data transmission->RRT->new transmissio= n route". I don't know who is right. So what do you think? Thank you so much! =20 ps: I am a postgraduate student and also a part-time tourist guide of B= eijing. If anyone answer this letter and help me to solve this problem, i= will offer you a free interpretation. =20 Regards =20 =20 --------------------------------- =20 pann 2006-01-09 =20 --------------------------------- =20 =B7=A2=BC=FE=C8=CB=A3=BA Francis Dupont =B7=A2=CB=CD=CA=B1=BC=E4=A3=BA 2006-01-09 01:27:48 =CA=D5=BC=FE=C8=CB=A3=BA johnny pan =B3=AD=CB=CD=A3=BA mip6@ietf.org =D6=F7=CC=E2=A3=BA Re: [Mip6] A question about MIPv6! =20 In your previous mail you wrote: =20 Does that mean before MN initiate the Return Routabili= ty test and the Binding Update between MN and CN, the communication bet= ween MN and CN must forwarded by HA through the bi-directional tunn= el between MN and HA? =20 =3D > this is the standard behavior but is not mandatory, i.e= ., the MN or the CN may launch a RR test before sending the first traffic= packet. (The real issue is this needs a priori knowledge of future c= ommunications) =20 I don't know whether my understanding is right or not. T= he two modes of Reverse Tunneling and RO only one of them could be use= d? =20 =3D > Routing Optimization is as its name suggests an *optimiz= ation*. =20 Regards =20 Francis.Dupont@point6.net =20 =09 --------------------------------- =D1=C5=BB=A21G=C3=E2=B7=D1=D3=CA=CF=E4=B0=D9=B7=D6=B0=D9=B7=C0=C0=AC=BB=F8= =D0=C5 =D1=C5=BB=A2=D6=FA=CA=D6=A1=A7D=CB=D1=CB=F7=A1=A2=C9=B1=B6=BE=A1=A2=B7=C0= =C9=A7=C8=C5 =20 --0-1436931982-1136800964=:85251 Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id FAA01833
So when will the RRT begin? Can this happen: after a short&nbs= p;time of data transmission between MN and CN through bi-direnc= tional tunnel,  MN start RRT and send BU to CN, after that MN switch= the transmisson directly to CN? Can this happen? Or it is for sure that = after MN register with HA, it will start RRT and register with CN at once= before any data transmission between MN and CN, if CN support MIPv6 and = have a binding cache?
When i disscuss this with my classmate, we cannot agree wit= h each other, and we cannot find enough evidence in RFC3775, so i hope i = can get some help here.
His opinion about the procedure is as follow:
1.MN register with = HA and get a CoA
2.begin RRT with CN at once before any data transmission, and t= hrough which MN will know whether CN support RO. If CN does support = RO, MN will send data directly to CN; if not, all data transmission will&= nbsp;pass HA. It can be described as a procedure of "Register w= ith HA->RRT->direct data transmission".
And my opion is:
1.MN register with HA and = get a CoA
2.MN or CN may initiate data communication first, and becauce MN have n= o information about CN(if MN send data to the "unknown" CN first), this k= ind of communication will have to pass HA. After some time of data transm= ission, MN initiate the RRT and register with CN. It can be describe= d as a procedure of "Register with HA->data transmission->RRT-= >new transmission route".
I don't know who is right. So what do you think= ? Thank you so much!
 
ps: I am a postgraduate student and also a part-time tourist = guide of Beijing. If anyone answer this letter and help me to solve = this problem, i will offer you a free interpretation.
=  
<= FONT face=3DVerdana color=3D#0000ff size=3D2>Regards
<= FONT face=3DVerdana size=3D2> 
pann
2006-01-09
=B7=A2=BC=FE=C8=CB=A3=BA Francis Dupont
=B7=A2=CB=CD=CA=B1=BC=E4=A3=BA 2006-01-09 01:27:48
=CA=D5= =BC=FE=C8=CB=A3=BA johnny pan
=B3=AD=CB=CD=A3=BA mip6@ietf= .org
=D6=F7=CC=E2=A3=BA Re: [Mip6] A question about MIPv6!
 
 In  your  previous =  mail  you  wrote:
 
  &= nbsp;      Does  that  mean  before  M= N  initiate  the  Return  Routability  test &nbs= p;and
   the  Binding  Update  betwe= en  MN  and  CN,  the  communication  betwe= en  MN
   and  CN  must  forwarded  by  HA  through  the  bi-direc= tional  tunnel
   between  MN  and &= nbsp;HA?
 
=3D >  this  is &nbs= p;the  standard  behavior  but  is  not  ma= ndatory,  i.e.,  the  MN  or
the  CN=  may  launch  a  RR  test  before  se= nding  the  first  traffic  packet.
(The =  real  issue  is  this  needs  a  prio= ri  knowledge  of  future  communications)
 
     I  don't  know  w= hether  my  understanding  is  right  or  n= ot.  The  two  modes  of
    &n= bsp;Reverse  Tunneling  and  RO    only  on= e  of  them  could  be  used?
 
=3D >  Routing  = Optimization  is  as  its  name  suggests  = an  *optimization*.
 
Regards
     
Francis.Dupont@point6.net
 

=20 =D1=C5=BB=A21G=C3=E2=B7=D1=D3=CA=CF=E4=B0=D9=B7=D6=B0=D9=B7=C0=C0=AC=BB=F8= =D0=C5
=20 =D1=C5=BB=A2=D6=FA=CA=D6= =A1=A7D=CB=D1=CB=F7=A1=A2=C9=B1=B6=BE=A1=A2=B7=C0=C9=A7=C8=C5=20 =20 --0-1436931982-1136800964=:85251-- --===============2022209590== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============2022209590==-- From mip6-bounces@ietf.org Mon Jan 09 05:50:33 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Evubh-0000zT-TP; Mon, 09 Jan 2006 05:50:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Evubg-0000yx-A2 for mip6@megatron.ietf.org; Mon, 09 Jan 2006 05:50:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04552 for ; Mon, 9 Jan 2006 05:49:13 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Evui9-0000H2-8X for mip6@ietf.org; Mon, 09 Jan 2006 05:57:14 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id k09Anta23938; Mon, 9 Jan 2006 11:49:56 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id k09AnuEN029372; Mon, 9 Jan 2006 11:49:56 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200601091049.k09AnuEN029372@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: johnny pan Subject: Re: [Mip6] A question about MIPv6! In-reply-to: Your message of Mon, 09 Jan 2006 18:02:44 +0800. <20060109100244.86669.qmail@web15102.mail.cnb.yahoo.com> Date: Mon, 09 Jan 2006 11:49:56 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org In your previous mail you wrote: His opinion about the procedure is as follow: 1.MN register with HA and get a CoA 2.begin RRT with CN at once before any data transmission, and through which MN will know whether CN support RO. If CN does support RO, MN will send data directly to CN; if not, all data transmission will pass HA. It can be described as a procedure of "Register with HA->RRT->direct data transmission". And my opinion is: 1.MN register with HA and get a CoA 2.MN or CN may initiate data communication first, and becauce MN have no information about CN(if MN send data to the "unknown" CN first), this kind of communication will have to pass HA. After some time of data transmission, MN initiate the RRT and register with CN. It can be described as a procedure of "Register with HA->data transmission->RRT->new transmission route". => in fact both are possible, it is a matter of implementation. At one possible exception, IMHO all implementations are reactive (i.e., launch RRT only when some unoptimized traffic is seen on the MN-HA tunnel) but some offer an API which can be used to support the preactive (i.e., the first option) way. BTW RFC 3775 gives some hints in the 11.7.2 section with this statement at the beginning: Considerations regarding when (and if) to initiate the procedure depend on the specific movement and traffic patterns of the mobile node and are outside the scope of this document. but just after there are the conditions for triggering RRT from received traffic on the tunnel: In addition, the mobile node MAY initiate the correspondent registration in response to receiving a packet that meets all of the following tests: this is why I use the term "hints" (:-). Regards Francis.Dupont@point6.net PS: the possible exception is from a very old discussion in this list where an implementor described the proactive way (which has interesting security properties). _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jan 09 16:47:33 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew4rV-0005Xs-Ma; Mon, 09 Jan 2006 16:47:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew4rT-0005XY-AZ for mip6@megatron.ietf.org; Mon, 09 Jan 2006 16:47:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01324 for ; Mon, 9 Jan 2006 16:46:12 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew4y2-0007BM-3n for mip6@ietf.org; Mon, 09 Jan 2006 16:54:19 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id k09LB4d12872; Mon, 9 Jan 2006 13:11:04 -0800 X-mProtect: <200601092111> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.18.141.41, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdnNxVu2; Mon, 09 Jan 2006 13:11:01 PST Message-ID: <43C2D9CC.2020501@iprg.nokia.com> Date: Mon, 09 Jan 2006 13:46:52 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center, Mtn. View User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: johnny pan Subject: Re: [Mip6] A question about MIPv6! References: <20060109100244.86669.qmail@web15102.mail.cnb.yahoo.com> In-Reply-To: <20060109100244.86669.qmail@web15102.mail.cnb.yahoo.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: Francis.Dupont@point6.net, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Hello Johnny, Following up on what Francis wrote, I'd agree except that it's probably better to characterize the initiation of RRT as "whenever". It can be before or after the initiation of some other data communication. Of course it's a waste of time if there aren't going to be any data to communicate. As I remember, the exact timing to run RRT is left as "out of scope" because nobody had a convincing answer whether anything needed to be mandated or specified about it. For instance, if a mobile system only needs to communicate a single packet to a correspondent node, it makes little sense to do RRT. It's also likely to be wise to deregister bindings after the applications are finished and no more data needs to be communicated. Regards, Charlie P. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jan 09 18:09:20 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew68e-0005l0-JY; Mon, 09 Jan 2006 18:09:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew68c-0005jm-Ub for mip6@megatron.ietf.org; Mon, 09 Jan 2006 18:09:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06529 for ; Mon, 9 Jan 2006 18:07:59 -0500 (EST) Received: from mout.perfora.net ([217.160.230.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew6FC-00016Q-8F for mip6@ietf.org; Mon, 09 Jan 2006 18:16:07 -0500 Received: from [85.97.3.104] (helo=sysadmin13c23c) by mrelay.perfora.net (node=mrelayus1) with ESMTP (Nemesis), id 0MKp2t-1Ew68W0uq3-0003bP; Mon, 09 Jan 2006 18:09:15 -0500 From: "Alper Yegin" To: "'Kent Leung \(kleung\)'" , Subject: RE: [Mip6] Generalizing draft-jang-dhc-haopt for MIPv6 support in DHCP Date: Tue, 10 Jan 2006 01:08:54 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcYRaQWj0fiHYK7lT5mt084tSDibLAECGFbw In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC520123B475@xmb-sjc-235.amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-ID: <0MKp2t-1Ew68W0uq3-0003bP@mrelay.perfora.net> X-Provags-ID: perfora.net abuse@perfora.net login:abf7a4bb310ea4dfc9b6841113e2970f X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Hi.=A0=A0 This draft should probably be named = draft-jang-dhc-mip6options. 1) There were talks of folding this draft into draft-ietf-mip6-bootstrapping-integrated-dhc.=A0 I would prefer to keep = the DHCP draft as standalone as an independent DHCP options document for = MIPv6.=A0 How is this going to be decided? Alper>>> FWIW, the authors also think that it makes sense to keep this = I-D a standalone one. 2) Can we add the Home Address Option to the DHCP draft to provide = general MIPv6 capability.=A0 This allows the Home Address to be assigned by the network via DHCPv6.=A0 There are solutions that use DHCP to obtain the = Home Address for MN to register.=A0 The Home Agent address can be obtained = via DHCP, so seems natural for the HoA to be available as well.=A0 There = doesn't seem to be any harm for this additional option in the draft. Alper>>> It sounds useful and I cannot think of any problems with doing = so. Alper. 3) Any other MIPv6 attributes that should be conveyed in DHCP Options? Kent -- =A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0 = |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Kent Leung =A0=A0=A0 :|:=A0=A0=A0=A0=A0=A0 = :|:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 IP Mobility = Development =A0=A0 :|||:=A0=A0=A0 =A0 = :|||:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Internet = Technologies Division =A0 :|||||||:=A0 :|||||||:=A0=A0=A0=A0=A0=A0=A0 =A0 =A0=A0=A0=A0=A0 = Voice: +1.408.526.5030 .:|||||||||:.:|||||||||:.=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0 Email: = kleung@cisco.com c i s c o S y s t e m s=A0 http://www.ciscopress.com/title/158705132X =A0 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jan 09 20:38:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew8TF-0001Su-1w; Mon, 09 Jan 2006 20:38:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew8TC-0001Sc-VY; Mon, 09 Jan 2006 20:38:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17915; Mon, 9 Jan 2006 20:37:22 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew8Zo-0005we-Ak; Mon, 09 Jan 2006 20:45:32 -0500 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k0A1c7i05889; Mon, 9 Jan 2006 17:38:07 -0800 (PST) Message-Id: <200601100138.k0A1c7i05889@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Mon, 09 Jan 2006 17:38:07 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: mip6@ietf.org, rfc-editor@rfc-editor.org Subject: [Mip6] RFC 4285 on Authentication Protocol for Mobile IPv6 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4285 Title: Authentication Protocol for Mobile IPv6 Author(s): A. Patel, K. Leung, M. Khalil, H. Akhtar, K. Chowdhury Status: Informational Date: January 2006 Mailbox: alpesh@cisco.com, kleung@cisco.com, mkhalil@nortel.com, haseebak@nortel.com, kchowdhury@starentnetworks.com Pages: 19 Characters: 40874 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mip6-auth-protocol-07.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4285.txt IPsec is specified as the means of securing signaling messages between the Mobile Node and Home Agent for Mobile IPv6 (MIPv6). MIPv6 signaling messages that are secured include the Binding Updates and Acknowledgement messages used for managing the bindings between a Mobile Node and its Home Agent. This document proposes an alternate method for securing MIPv6 signaling messages between Mobile Nodes and Home Agents. The alternate method defined here consists of a MIPv6-specific mobility message authentication option that can be added to MIPv6 signaling messages. This document is a product of the Mobility for IPv6 Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <060109173625.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4285 --OtherAccess Content-Type: Message/External-body; name="rfc4285.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <060109173625.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Wed Jan 11 02:49:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwajZ-0001gg-UE; Wed, 11 Jan 2006 02:49:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwajX-0001gb-GX for mip6@megatron.ietf.org; Wed, 11 Jan 2006 02:49:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22159 for ; Wed, 11 Jan 2006 02:48:06 -0500 (EST) Received: from web15105.mail.cnb.yahoo.com ([202.165.103.74]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EwaqN-00021G-Vv for mip6@ietf.org; Wed, 11 Jan 2006 02:56:33 -0500 Received: (qmail 23698 invoked by uid 60001); 11 Jan 2006 07:16:06 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.cn; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=qX3r0of02GirZBTPgi7dRYNudpi3Bf8Ctwc9TLk+alz5gVCSh7IL3y0tIEptWH60vOGrqq+cax/5X7PaaTUFwD4LmYYoX9g3G8QdvwgBr5WmNAHj9u4eSFhDCDxQxhrJT2er62w+LNthLpzLAiOecajR9Z5Rmj3Jarz37Ua2vKk= ; Message-ID: <20060111071606.23696.qmail@web15105.mail.cnb.yahoo.com> Received: from [59.64.217.81] by web15105.mail.cnb.yahoo.com via HTTP; Wed, 11 Jan 2006 15:16:06 CST Date: Wed, 11 Jan 2006 15:16:06 +0800 (CST) From: johnny pan To: Francis.Dupont@point6.net MIME-Version: 1.0 X-Spam-Score: 1.8 (+) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: mip6@ietf.org Subject: [Mip6] Re: A question about MIPv6! X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1366158953==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org --===============1366158953== Content-Type: multipart/alternative; boundary="0-694908713-1136963766=:22514" --0-694908713-1136963766=:22514 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id CAA22159 Thank you so much! You are such a kind man! =20 But my classmate still have some puzzle about the details and we still = have some different understanding about the "Preactive mode" and the "Rea= ctive mode".=20 =20 In my previous letter, i wrote: =20 His opinion about the procedure is as follow: 1.MN register with HA and get a CoA 2.begin RRT with CN at once before any data transmiss= ion, and through which MN will know whether CN support RO. If = CN does support RO, MN will send data directly to CN; if not= , all data transmission will pass HA. It can be described as a = procedure of "Register with HA- >RRT- >direct data transmission". =20 And my opinion is: 1.MN register with HA and get a CoA 2.MN or CN may initiate data communication first, and = becauce MN have no information about CN(if MN send data to the = "unknown" CN first), this kind of communication will have to pass = HA. After some time of data transmission, MN initiate the RRT a= nd register with CN. It can be described as a procedure of "Regi= ster with HA- >data transmission- >RRT- >new transmission route". =20 In my understanding of your reply, the frist opinion is "Preactive mode= " and the second is "Reactive mode" .And which mode to be chosen is just = a matter of implentation as your very clear discription " in fact both ar= e possible, it is a matter of implementation". And my classmate's understanding is a little different. His opinion is= : After MN registered with HA. If MN initiate communication first, it MU= ST start RRT first before any data transmission to CN. But my understandi= ng of your "Both are possible", it is possible to send data to CN throu= gh HA, and after some such data transmission, then switch the data transm= ission through HA to CN directly.=20 =20 So what do you think about this? Thanks again! :) =20 Best Regards =20 Johnny Pan =09 --------------------------------- =CF=EB=B3=C9=CE=AA=B7=EB=D0=A1=B8=D5=A1=A2=B3=C2=BF=AD=B8=E8=A1=A2=D5=C5= =BC=CD=D6=D0=C8=FD=B4=F3=B5=BC=D1=DD=B5=C4=D6=F7=BD=C7=C2=F0=A3=BF --0-694908713-1136963766=:22514 Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id CAA22159
Thank you so m= uch! You are such a kind man!
 
= But my classmate still have=  some puzzle about the details and we still have some different unde= rstanding about the "Preactive mode" and the "Reactive mode".
 
In my previous lett= er, i wrote:
 
         His  opinion  a= bout  the  procedure  is  as  follow:
         = 1.MN  register  with  HA  and  get  a  CoA
         2.begin  R= RT  with  CN  at  once  before  any  d= ata  transmission,  and
         through  which  MN =  will  know  whether  CN  support  RO. &nbs= p;If  CN  does
         support  RO,  MN  will =  send  data  directly  to  CN;  if  no= t,  all  data
=          transmission  will  pass &nbs= p;HA.  It  can  be  described  as  a  = procedure  of
 = ;        "Register  with  HA- >RRT- >direct  data  transmission".
 
         And  my  opinion  is:<= /FONT>
      &nb= sp;  1.MN  register  with  HA  and  get &nb= sp;a  CoA
  &n= bsp;      2.MN  or  CN  may  initiate =  data  communication  first,  and  becauce  = ;MN
     =    have  no  information  about  CN(if &nb= sp;MN  send  data  to  the  "unknown"  CN
      &nbs= p;  first),  this  kind  of  communication  = ;will  have  to  pass  HA.  After
=20
         som= e  time  of  data  transmission,  MN  initi= ate  the  RRT  and  register
         with  CN.=  It  can  be  described  as  a  proce= dure  of  "Register  with
         HA- >data  tra= nsmission- >RRT- >new  transmission  route".
=
=  
In my un= derstanding of your reply, the frist opinion is "Preactive mode" and the = second is "Reactive mode" .And which mode to be cho= sen is just a matter of implentation as your very clear discription "&nbs= p;in fact both are possible, it is a matter of implementation".
And my classmate's understanding is a little different.&= nbsp; His opinion is : After MN registered with HA. If MN initiate c= ommunication first, it MUST start RRT first before any data transmis= sion to CN. But my understanding of your "Both  are  possi= ble", it is possible to send data to CN through HA, and after som= e such data transmission, then switch the data transmission throug= h HA to CN directly.
 
So what do you think about this? Thanks again! :)
&nbs= p;
Best Regards=
 
Johnny Pan

=20 =CF=EB=B3=C9=CE=AA=B7=EB=D0=A1=B8=D5=A1=A2=B3=C2=BF=AD=B8=E8=A1=A2=D5=C5=BC= =CD=D6=D0=C8=FD=B4=F3=B5=BC=D1=DD=B5=C4=D6=F7=BD=C7=C2=F0=A3=BF --0-694908713-1136963766=:22514-- --===============1366158953== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1366158953==-- From mip6-bounces@ietf.org Wed Jan 11 10:06:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwhYM-0005AL-Cr; Wed, 11 Jan 2006 10:06:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwhYL-00059n-4L for mip6@megatron.ietf.org; Wed, 11 Jan 2006 10:06:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18723 for ; Wed, 11 Jan 2006 10:04:59 -0500 (EST) Received: from atlrel7.hp.com ([156.153.255.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwhfE-0005gY-2n for mip6@ietf.org; Wed, 11 Jan 2006 10:13:30 -0500 Received: from taynzmail03.nz-tay.cpqcorp.net (idcmailrelay.wipro.tcpn.com [16.47.4.103]) by atlrel7.hp.com (Postfix) with ESMTP id CBCDF36726; Wed, 11 Jan 2006 10:06:06 -0500 (EST) Received: from kitche.zk3.dec.com (kitche4.zk3.dec.com [16.140.160.166]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id 7175044E1; Wed, 11 Jan 2006 10:06:06 -0500 (EST) Received: from [16.116.104.135] by kitche.zk3.dec.com (8.11.1/1.1.27.5/27Oct00-1235PM) id k0BF65m0002456356; Wed, 11 Jan 2006 10:06:05 -0500 (EST) Message-ID: <43C51EDD.3010100@hp.com> Date: Wed, 11 Jan 2006 10:06:05 -0500 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051010) X-Accept-Language: en-us, en MIME-Version: 1.0 To: johnny pan Subject: Re: [Mip6] Re: A question about MIPv6! References: <20060111071606.23696.qmail@web15105.mail.cnb.yahoo.com> In-Reply-To: <20060111071606.23696.qmail@web15105.mail.cnb.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: Francis.Dupont@point6.net, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org johnny pan wrote: > In my understanding of your reply, the frist opinion is "Preactive mode" > and the second is "Reactive mode" .And which mode to be chosen is just a > matter of implentation as your very clear discription " in fact both are > possible, it is a matter of implementation". > And my classmate's understanding is a little different. His opinion is > : After MN registered with HA. If MN initiate communication first, > it MUST start RRT first before any data transmission to CN. But my > understanding of your "Both are possible", it is possible to send data > to CN through HA, and after some such data transmission, then switch the > data transmission through HA to CN directly. Section 11.7.2 addresses this. A snippet: Considerations regarding when (and if) to initiate the procedure depend on the specific movement and traffic patterns of the mobile node and are outside the scope of this document. There are only SHOULDs and MAYs regarding this decision in that section, no MUSTs... -Brian _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jan 11 11:05:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwiTm-00071j-Tv; Wed, 11 Jan 2006 11:05:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwiTm-00071X-7P for mip6@megatron.ietf.org; Wed, 11 Jan 2006 11:05:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22477 for ; Wed, 11 Jan 2006 11:04:22 -0500 (EST) Received: from smtp8.clb.oleane.net ([213.56.31.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewiah-0007Nk-02 for mip6@ietf.org; Wed, 11 Jan 2006 11:12:52 -0500 Received: from Pavillonquatre ([194.3.133.88]) by smtp8.clb.oleane.net with ESMTP id k0BG5KGe015053 for ; Wed, 11 Jan 2006 17:05:20 +0100 Message-Id: <200601111605.k0BG5KGe015053@smtp8.clb.oleane.net> From: "Chantal Ladouce" To: Date: Wed, 11 Jan 2006 17:04:18 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYWyK0niLjxBMIUTTWahq6pJRgBfA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Subject: [Mip6] International SIP Conference / WiMAX Summit 2006 - Paris - France X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0117953562==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============0117953562== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0305_01C616D1.0F5DF6B0" This is a multi-part message in MIME format. ------=_NextPart_000_0305_01C616D1.0F5DF6B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The International SIP conference and the WiMAX Summit will start next February 21st in Paris. The two events are co-organised and will bring any necessary information on VoIP, mobility convergence and wireless broadband access. The early registration 10% discount will end in one week. Get all details on International SIP at: http://www.upperside.fr/sip2006/sip2006intro.htm Get all details on the WiMAX Summit at: http://www.upperside.fr/wimax2006/wimax2006intro.htm ------=_NextPart_000_0305_01C616D1.0F5DF6B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 The = International SIP conference and the WiMAX Summit will start next February 21st in = Paris. The two = events are co-organised and will bring any necessary information on VoIP, mobility convergence and wireless broadband access.

 

The early registration 10% discount will end = in one week.

 

Get all details on International SIP = at:

http://www.upp= erside.fr/sip2006/sip2006intro.htm

 

Get all details on the WiMAX Summit = at:

http://www= .upperside.fr/wimax2006/wimax2006intro.htm

 

 

 

------=_NextPart_000_0305_01C616D1.0F5DF6B0-- --===============0117953562== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0117953562==-- From mip6-bounces@ietf.org Wed Jan 11 12:36:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwjtW-0004VW-Hu; Wed, 11 Jan 2006 12:36:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwjtU-0004VL-IB for mip6@megatron.ietf.org; Wed, 11 Jan 2006 12:36:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29050 for ; Wed, 11 Jan 2006 12:34:59 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewk0O-0001s8-Lz for mip6@ietf.org; Wed, 11 Jan 2006 12:43:31 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id k0BHZU226994; Wed, 11 Jan 2006 18:35:30 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id k0BHZUpT038583; Wed, 11 Jan 2006 18:35:30 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200601111735.k0BHZUpT038583@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: johnny pan In-reply-to: Your message of Wed, 11 Jan 2006 15:16:06 +0800. <20060111071606.23696.qmail@web15105.mail.cnb.yahoo.com> Date: Wed, 11 Jan 2006 18:35:30 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: mip6@ietf.org Subject: [Mip6] Re: A question about MIPv6! X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org In your previous mail you wrote: But my classmate still have some puzzle about the details and we still have some different understanding about the "Preactive mode" and the "Reactive mode". ^ => Proactive In my understanding of your reply, the frist opinion is "Preactive mode" and the second is "Reactive mode" .And which mode to be chosen is just a matter of implementation as your very clear discription " in fact both are possible, it is a matter of implementation". => yes, RFC 3775 doesn't choose between these two basic strategies. And my classmate's understanding is a little different. His opinion is : After MN registered with HA. If MN initiate communication first, it MUST start RRT first before any data transmission to CN. => no, this "MUST" is far too strong. You have only a MAY. But my understanding of your "Both are possible", it is possible to send data to CN through HA, and after some such data transmission, then switch the data transmission through HA to CN directly. => you are right. Regards Francis.Dupont@point6.net _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jan 13 05:22:49 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExM53-0001p5-5i; Fri, 13 Jan 2006 05:22:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExM51-0001ov-LI for mip6@megatron.ietf.org; Fri, 13 Jan 2006 05:22:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19853 for ; Fri, 13 Jan 2006 05:21:25 -0500 (EST) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExMBv-00047w-Rr for mip6@ietf.org; Fri, 13 Jan 2006 05:29:56 -0500 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 512A6898F1; Fri, 13 Jan 2006 12:21:54 +0200 (EET) Message-ID: <43C77F60.8070901@kolumbus.fi> Date: Fri, 13 Jan 2006 12:22:24 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mobile IPv6 Mailing List , Vijay Devarapalli Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Content-Transfer-Encoding: 7bit Cc: Subject: [Mip6] review of draft-ietf-mip6-ikev2-ipsec X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Per request, I'm reviewing this a second time now that its going to the AD and the IESG. Overall: I liked this document, particularly the home address allocation that becomes much, much easier with this. And the ability to employ in practise any type of existing AAA via EAP. The spec does still have some issues. My main concern is that it tries to do perhaps a bit too much, there are parts we should and others that we could delete -- likely resulting in more readable and easily implementable spec. Technical: > The IKEv2 specification [4] requires that public key based mechanism > be used to authenticate the home agent to the mobile node, when EAP > is used. This should be used by default by the mobile node and the > home agent. If the EAP method that is used, supports mutual > authentication and key generation, then the mobile node MAY use EAP > itself to authenticate the home agent. The mobile node can request > this by including the EAP_ONLY_AUTHENTICATION notification payload > [8] in message 3. If the home agent supports the > EAP_ONLY_AUTHENTICATION notification payload and agrees to use EAP, > it omits the public key based AUTH and CERT payloads in message 4. > If the home agent does not support this mechanism, it rejects it by > including an AUTH payload in message 4. More details can be found in > [8]. > (snip) > The use of EAP for authenticating the mobile node to the home agent > is described in Section 8. This document recommends that if the EAP > method used, supports mutual authentication, then EAP itself be used > for authenticating the home agent to the mobile node also. This runs > contrary to the recommendation in [4]. The home agent can ignore the > recommendation in this document and implement EAP authentication as > described in the IKEv2 specification. Security considerations > related to the use of EAP with IKEv2 are described in [4] and [8]. > > I think that EAP-only auth mode in IKEv2 makes a lot of sense. But I'm very concerned that a document from MIP6 WG overrides a MUST in another WG's main document. Here's what RFC 4306 says: In addition to authentication using public key signatures and shared secrets, IKE supports authentication using methods defined in RFC 3748 [EAP]. Typically, these methods are asymmetric (designed for a user authenticating to a server), and they may not be mutual. For this reason, these protocols are typically used to authenticate the initiator to the responder and MUST be used in conjunction with a public key signature based authentication of the responder to the initiator. My suggestion would be to take the specific extension of IKEv2 out of the draft and pursue that separately. Obviously, this extension is also very useful in non-MIPv6 scenarios, so this is also logical from the point of view of keeping our specs modular. In any case, I think the above text would make [8] normative dependency, which I don't think you want... > o If the mobile node has used IKEv2 to establish security > associations with its home agent, it should follow the procedures > discussed in Section 11.7.1 and 11.7.3 of the base specification > [2] to determine whether the IKE endpoints can be moved or if the > IKE SA has to be re-established. > > o If the home agent has used IKEv2 to establish security > associations with the mobile node, it should follow the procedures > discussed in Section 10.3.1 and 10.3.2 of the base specification > [2] to determine whether the IKE endpoints can be moved or if the > IKE SA has to be re-established. > > Hmm... I wonder if we really want to carry the K bit scheme forward. I saw that as an intermediate solution. There's no requirement for you to handle everything in this spec, you can also streamline & simplify. Also, I would prefer the above text to allow IKEv2-specific address changes. In particular, there seems to be no reason to disallow automatic NAT-T address changes or even MOBIKE. None of that has any effect on Mobile IPv6, as long as the client still sends a correct Mobile IPv6 Binding Update inside. And MOBIKE is already referenced from elsewhere of the spec, so this is also a consistency issue. Same issue in Section 7.3. >MIP6 Working Group V. Devarapalli >Internet-Draft Nokia >Expires: April 26, 2006 F. Dupont > Point6 > October 23, 2005 > > > > The header says nothing about the relationship to RFC 3776. Updates? Obsoletes? Personally, I think "updates" would make more sense, but this is related to the issue of whether you want to carry the manual SA stuff from 3776 here. Its quite a lot to carry, and everyone who uses manual SAs can still use 3776, so no one would actually lose anything. But YMMV, maybe you wanted to show how you get rid of per-interface policies with the new architecture. Editorial: > The IPsec architecture has been revised [5]. Among the many changes, > Maybe "RFC 3776 was, however, defined for the first revision of the IPsec architecture. The second revision [5] has introduced..." And change "revised IPsec architecture" later in the document to "the second revision of the IPsec architecture". (Or is the 2nd? Was the something before 2401? Anyway, my point is that when someone reads this 10 years from now, it may no longer be obvious what "revised ipsec architecture" means.) >If the > home address of the mobile node changes, the SPD and SAD entries need > to re-created or updated for the new home address. > s/need to/need to be/ > The author would like to thank Mika Joutsenvirta, Pasi Eronen, > Francis Dupont, Jari Arkko, Gerardo Giaretta and Shinta Sugimoto for > reviewing the draft. > > Francis is thanking himself :-) --Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jan 13 06:00:07 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExMf9-0003SD-MZ; Fri, 13 Jan 2006 06:00:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExMey-0003Om-US for mip6@megatron.ietf.org; Fri, 13 Jan 2006 05:59:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26049 for ; Fri, 13 Jan 2006 05:58:34 -0500 (EST) Received: from mail.um.es ([155.54.212.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExMmF-0006QM-54 for mip6@ietf.org; Fri, 13 Jan 2006 06:07:29 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id 9AC3F23CD2B for ; Fri, 13 Jan 2006 11:59:40 +0100 (CET) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon2 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 27780-01-2 for ; Fri, 13 Jan 2006 11:59:40 +0100 (CET) Received: from [137.73.11.205] (dibulibu.um.es [155.54.1.250]) by mail.um.es (Postfix) with ESMTP id 1986123CD02 for ; Fri, 13 Jan 2006 11:59:40 +0100 (CET) Message-ID: <43C78827.90400@dif.um.es> Date: Fri, 13 Jan 2006 11:59:51 +0100 From: "Pedro M. Ruiz" User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip6@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: 7bit Subject: [Mip6] Summer School in Wireless Sensor Networks X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Please, find below information about a summer school to be held together with AD HOC NOW 2006. Regards, -- Pedro M. Ruiz Publicity Co-chair AD HOC NOW 2006 http://ants.dif.um.es/staff/pedrom/ -- CALL FOR PARTICIPATION SUMMER SCHOOL IN WIRELESS SENSOR NETWORKS OTTAWA, CANADA, AUGUST 14-16, 2006 http://kunz-pc.sce.carleton.ca/AdHocNow2006/sensors.html Sponsored by Mathematics of Information Technology and Complex Systems (MITACS: http://www.mitacs.math.ca/) Processors, sensors, and wireless radios are becoming extremely small and inexpensive. We therefore foresee a world where many everyday objects and physical environments are enriched by computational power. Wireless sensor networks are a relatively recent and exciting example of networked embedded sensing systems and significant research projects in this area are under way throughout the world. The area provides a rich field of research challenges and possibilities for technology transfer (for example, RFID sensors and supply chain management, smart homes/cities, health care, etc.). Goals and Audience ================== The intended audience are post-graduate students from primarily Canadian universities at both the Master's and PhD level, and young researchers from universities and industrial laboratories around the world. If there is room, senior undergraduate students who have a strong research interest in sensor networks will also be considered. The number of participants will be limited to approximately 50. The goal of the summer school is to provide a basic survey of the most relevant subfields, to present the perspectives and the underlying technologies, as well as to identify important research themes. Furthermore, the school will provide the opportunity to get to know other people working in the field, to meet other graduate students and to interact with distinguished scholars. We hope that it will lead to the establishment of contacts that may result in future research collaborations as well. Schedule/Topics (tentative) =========================== The summer school will last for 3 days and will feature a number of different activities. * Lectures * TinyOS and ZigBee tutorial * Participants workshop. Some time will be reserved for a workshop where participants can present their own work and involvement in the field. * Social event(s) to encourage the development of a community among the researchers. * AdHoc NOW conference. The summer school will be held just before AdHoc NOW (http://kunz-pc.sce.carleton.ca/AdHocNow2006/). This will allow participants to register for and participate in the conference. Registration, Costs, and Travelling =================================== Participation is open to all qualified applicants, but the number of participants is limited to a maximum of 50 (with 40 spots reserved for graduate students). If we receive more applications, we will select participants based on their work area and background, geographic distribution, and date of registration. If you are interested in participating, please send an e-mail with the pertinent information (name, contact information, research area and background) to tkunz@sce.carleton.ca. If you want to give a brief talk about your own work, please also include a short title and abstract. Graduate students should also provide their student ID and e-mail address of their faculty advisor/supervisor, to allow us to verify their student status. The nominal registration fee will be C$400, with the registration fee for the graduate student participants covered through support from MITACS. Participants are responsible to arrange for their own travel and accomodation. For example, residence space at the University of Ottawa is available for approximately C$35/day for a single room or C$50/day for a shared room. Participants are expected to arrive in the afternoon or evening of Sunday, August 13. The school itself will begin on Monday (Aug. 14) morning and end on Wednesday (Aug. 16) evening. Important Dates =============== Application deadline: May 6, 2006 Notification of admittance: May 20, 2006 Summer School: August 14-16, 2006 AdHoc-Now conference: August 17-19, 2006 Contact Information =================== Thomas Kunz Associate Professor Carleton University tkunz@.sce.carleton.ca _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jan 13 07:50:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExOOD-0001CE-QV; Fri, 13 Jan 2006 07:50:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExOOB-0001AB-AW for mip6@megatron.ietf.org; Fri, 13 Jan 2006 07:50:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02740 for ; Fri, 13 Jan 2006 07:49:22 -0500 (EST) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX18N4i9f0JClpzIgt0OmZx85GkbbUJA4yfc=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExOVQ-0001gN-Uv for mip6@ietf.org; Fri, 13 Jan 2006 07:58:17 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1ExONx-0007ZD-Gd; Fri, 13 Jan 2006 13:50:36 +0100 Received: from [IPv6:2001:638:204:6:20c:6eff:fe40:8d95] (archimedes.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:20c:6eff:fe40:8d95]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 4CC587E2E; Fri, 13 Jan 2006 13:50:29 +0100 (CET) Message-ID: <43C7A215.1040804@tm.uka.de> Date: Fri, 13 Jan 2006 13:50:29 +0100 From: Christian Vogt User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.7.12) Gecko/20050923 Thunderbird/1.0.7 Mnenhy/0.7.2.0 X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Mip6 X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -6.5 (------) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] -2.1 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Subject: [Mip6] Delay Analysis for Handoffs with Mobile IPv6 Route Optimization X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org I would like to call your attention on work that we have done on IPv6 handoff procedures: "A Comprehensive Delay Analysis for Reactive and Proactive Handoffs with Mobile IPv6 Route Optimization" http://doc.tm.uka.de/2006/vogt-2006-delay-analysis-for-reactive-and-proactive-handoffs.pdf Abstract: Optimizations to reduce handoff delays inherent in Mobile IPv6 Route Optimization as well as IPv6 router discovery, address configuration, and movement detection have so far been mostly considered on an individual basis. This document evaluates three integrated solutions for improved handoff experience in surroundings with different preconditions: reactive handoffs with unmodified routers, reactive handoffs with router support, and movement anticipation and proactive handoff manage- ment. Your feedback will be welcome! Regards, - Christian -- Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH) www.tm.uka.de/~chvogt/pubkey/ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Jan 15 10:16:09 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ey9by-0001mb-Mm; Sun, 15 Jan 2006 10:16:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ey9bw-0001lM-Da; Sun, 15 Jan 2006 10:16:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29460; Sun, 15 Jan 2006 10:14:37 -0500 (EST) Received: from mail1.rz.fhtw-berlin.de ([141.45.5.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ey9Rl-0000zk-Cj; Sun, 15 Jan 2006 10:05:34 -0500 Received: from e178178094.adsl.alicedsl.de ([85.178.178.94] helo=[192.168.178.20]) by mail1.rz.fhtw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.42 (FreeBSD)) id 1Ey9Ju-000C1V-Jq; Sun, 15 Jan 2006 15:57:26 +0100 Message-ID: <43CA6387.8080306@fhtw-berlin.de> Date: Sun, 15 Jan 2006 16:00:23 +0100 From: Thomas C Schmidt User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Vogt Subject: Re: [Mip6] Delay Analysis for Handoffs with Mobile IPv6 Route Optimization References: <43C7A215.1040804@tm.uka.de> <43C91C45.3090909@fhtw-berlin.de> <43CA50C7.1000206@tm.uka.de> In-Reply-To: <43CA50C7.1000206@tm.uka.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: Mip6 , Mipshop , Mobopts X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: schmidt@fhtw-berlin.de List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Hi Christian, the mailinglist seems to be gone for the weekend ... so this is very private ... Christian Vogt wrote: > While your results [1] on FMIPv6 and HMIPv6 shed light on the > performance of proactivity in combination with local mobility > optimizations and are as such undoubtedly very important, I do not > necessarily consent with your statement that those results can be > conveyed to the end-to-end mobility management that we have been > analyzing [2]. > I perfectly agree with your characterisation. I did'nt mean to say that both approaches are the same. What I tried to suggest is that there might be some lessons to be learned from [1] for your work. From an abstract point of view the approaches of FMIPv6 (predictive part) and proactive end-to-end mobility management agree in hiding update delays by advancing handover negotiations on the basis of predictions. Beside problems with the reliability of predictions they both rely on timing issues: negotiations have to be successfully completed for the schemes to work. You are addressing this issue in section 7.1 of [2], but what we would like to contribute as the essence of [1] reads: There are three different timescales, one defined by the HO scheme + Internet topology, another by the L2 technologie and the third by the actual movement of the mobile user. They are fairly independent of each other. It may as well happen that the degree of coincidence required by your scheme corresponds to a quite narrow regime in phase space, which is hardly ever met. Thus it is *possible* that the fascinating perspective of zero update delay is just a conceptual result, which basically does not hold in reality. Details of course are subject to a thorough analysis, which you will probably do. Best regards, thomas > [1] http://www.informatik.haw-hamburg.de/~schmidt/papers/telesys05.pdf > [2] > http://doc.tm.uka.de/2006/vogt-2006-delay-analysis-for-reactive-and-proactive-handoffs.pdf > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Jan 15 10:32:32 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ey9rs-00081n-CP; Sun, 15 Jan 2006 10:32:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ey9qj-0007Fs-L4; Sun, 15 Jan 2006 10:31:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01057; Sun, 15 Jan 2006 10:16:32 -0500 (EST) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX18J92O5oGuMkfz3/gDdHaWyNKWIDkFZeio=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ey8FZ-00009i-Kh; Sun, 15 Jan 2006 08:48:56 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1Ey87O-0000w2-C8; Sun, 15 Jan 2006 14:40:32 +0100 Received: from [192.168.2.100] (p54A35C6C.dip.t-dialin.net [84.163.92.108]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id E41B38A4D; Sun, 15 Jan 2006 14:40:24 +0100 (CET) Message-ID: <43CA50C7.1000206@tm.uka.de> Date: Sun, 15 Jan 2006 14:40:23 +0100 From: Christian Vogt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.5) Gecko/20041206 Thunderbird/1.0 Mnenhy/0.7.3.0 X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: schmidt@fhtw-berlin.de Subject: Re: [Mip6] Delay Analysis for Handoffs with Mobile IPv6 Route Optimization References: <43C7A215.1040804@tm.uka.de> <43C91C45.3090909@fhtw-berlin.de> In-Reply-To: <43C91C45.3090909@fhtw-berlin.de> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Spam-Status: No X-Spam-Report: -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.0 AWL AWL: From: address is in the auto white-list X-Spam-Score: 2.4 (++) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Content-Transfer-Encoding: 7bit Cc: Mip6 , Mipshop , Mobopts X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org > We analysed these properties for the case of FMIPv6 (which should be > transferable in major parts, e.g., fmip needs fback, you need BU to > arrive ...) and found no significant improvement by predicitions (see > bib-reference attached). Thomas, thanks for bringing this up. While your results [1] on FMIPv6 and HMIPv6 shed light on the performance of proactivity in combination with local mobility optimizations and are as such undoubtedly very important, I do not necessarily consent with your statement that those results can be conveyed to the end-to-end mobility management that we have been analyzing [2]. During an end-to-end Mobile IPv6 handoff, communications are delayed for at least a global RTT between the MN and the CN (assuming that end-to-end optimizations such as EBU and CBA are deployed). This minimum delay can basically be eliminated in two ways: - Proactivity, i.e., send a BU from the old location and move to the new location only when packets can expected to have arrived there. - Local mobility optimizations such as FMIPv6 and HMIPv6, which either eliminate global signaling (HMIPv6), or move it off the critical blackout period (FMIPv6). Your work [1] deals with the second option, our's [2] deals with the first. To be more explicit, let's assume we use FMIPv6. All global signaling is then deferred until the MN has already resumed communications, from the new link, through the AR-to-AR tunnel. This is true for both proactive and reactive FMIPv6 modes. What *FMIPv6 proactivity* saves you is just an FBU's propagation time from the new AR to the old AR. Compare this to the global RTT that *end-to-end proacitvity* potentially saves you. Referring to the problems with predictive handoff procedures that you mention: You are correct, and section 7.1 in our analysis duely discusses this. As far as unreliability in predictions goes: Unfortunately, you are right, but that's a different construction site. ;) Regards, - Christian [1] http://www.informatik.haw-hamburg.de/~schmidt/papers/telesys05.pdf [2] http://doc.tm.uka.de/2006/vogt-2006-delay-analysis-for-reactive-and-proactive-handoffs.pdf -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ Thomas C Schmidt wrote: > Dear Christian, > > thanks for bringing your technical report to our attention! > > For a comment: it is our experience that the optimistic concept of zero > handover delay due to predictive procedures does not survive reality. > > This is mainly due to > > - the independence of anticipation, signaling and handoff in > occurrence and timescale. > > - predictions turning out as rather unreliable. > > We analysed these properties for the case of FMIPv6 (which should be > transferable in major parts, e.g., fmip needs fback, you need BU to > arrive ...) and found no significant improvement by predicitions (see > bib-reference attached). > > Song et al. ([11] in our references) made empirical studies on > predicitions including the campus geometry, statistical correlation > analysis of user date ... and arrived at dissapointing 72 %. > > It's a nice vision - but sometimes real-world isn't as nice ;) > > Best regards, > > thomas > > Christian Vogt wrote: > >> I would like to call your attention on work that we have done on IPv6 >> handoff procedures: >> >> "A Comprehensive Delay Analysis >> for Reactive and Proactive Handoffs >> with Mobile IPv6 Route Optimization" >> >> http://doc.tm.uka.de/2006/vogt-2006-delay-analysis-for-reactive-and-proactive-handoffs.pdf >> >> >> Abstract: Optimizations to reduce handoff delays >> inherent in Mobile IPv6 Route Optimization as well >> as IPv6 router discovery, address configuration, >> and movement detection have so far been mostly >> considered on an individual basis. This document >> evaluates three integrated solutions for improved >> handoff experience in surroundings with different >> preconditions: reactive handoffs with unmodified >> routers, reactive handoffs with router support, and >> movement anticipation and proactive handoff manage- >> ment. >> >> Your feedback will be welcome! >> >> Regards, >> - Christian >> > > ------------------------------------------------------------------------ > > @article{sw-pvrah-05, > author = {Thomas C. Schmidt and Matthias W{\"a}hlisch}, > title = {{P}redictive versus {R}eactive -- {A}nalysis of {H}andover {P}erformance and {I}ts {I}mplications on {IP}v6 and {M}ulticast {M}obility}, > journal = {Telecommunication Systems}, > volume = {30}, > number = {1--3}, > pages = {123--142}, > month = {November}, > year = {2005}, > publisher = {Springer}, > address = {Berlin Heidelberg}, > url = {http://dx.doi.org/10.1007/s11235-005-4321-4}, > abstract = {Handovers in mobile packet networks commonly produce packet loss, delay and jitter, thereby significantly degrading network performance. Mobile IPv6 handover performance is strongly topology dependent and results in inferior service quality in wide area scenarios. To approach seamless mobility in IPv6 networks predictive, reactive and proxy schemes have been proposed for improvement. In this article we analyse and compare handover performance and frequencies for the corresponding protocols, as they are an immediate measure on service quality. Using analytical methods as well as stochastic simulations, we calculate the performance decreases originating from different handover schemes, the expected number of handovers as functions of mobility and proxy ratios, as well as the mean correctness of predictions. In detail we treat the more delicate case of these rates in mobile multicast communication. > It is obtained that performance benefits, expected from simple analysis of predictive schemes, do not hold in practice. Reactive and predictive handovers rather admit comparable performance. Hierarchical proxy environments -- foremost in regions of high mobility -- can significantly reduce the processing of inter--network changes. Reliability of handover predictions is found on average at about 50 \%.}, > theme = {mipv6|mmcast}, > file = {http://www.informatik.haw-hamburg.de/~schmidt/papers/telesys05.pdf} > } _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Jan 15 13:03:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyC64-0004JG-81; Sun, 15 Jan 2006 12:55:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyC5e-0008P8-Ad for mip6@megatron.ietf.org; Sun, 15 Jan 2006 12:54:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28135 for ; Sun, 15 Jan 2006 11:08:52 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExqHg-0006mZ-0s for mip6@ietf.org; Sat, 14 Jan 2006 13:37:55 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id k0EITeQ26011; Sat, 14 Jan 2006 19:29:40 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id k0EITbb9057547; Sat, 14 Jan 2006 19:29:38 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200601141829.k0EITbb9057547@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko Subject: Re: [Mip6] review of draft-ietf-mip6-ikev2-ipsec In-reply-to: Your message of Fri, 13 Jan 2006 12:22:24 +0200. <43C77F60.8070901@kolumbus.fi> Date: Sat, 14 Jan 2006 19:29:36 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: Mobile IPv6 Mailing List , Vijay Devarapalli X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org In your previous mail you wrote: The spec does still have some issues. My main concern is that it tries to do perhaps a bit too much, there are parts we should and others that we could delete -- likely resulting in more readable and easily implementable spec. => it seems most concerns are for Vijay (:-). Technical: I think that EAP-only auth mode in IKEv2 makes a lot of sense. But I'm very concerned that a document from MIP6 WG overrides a MUST in another WG's main document. => I leave this point to Vijay as I already raised this point. In any case, I think the above text would make [8] normative dependency, which I don't think you want... => same (:-)! > o If the mobile node has used IKEv2 to establish security > associations with its home agent, it should follow the procedures > discussed in Section 11.7.1 and 11.7.3 of the base specification > [2] to determine whether the IKE endpoints can be moved or if the > IKE SA has to be re-established. > > o If the home agent has used IKEv2 to establish security > associations with the mobile node, it should follow the procedures > discussed in Section 10.3.1 and 10.3.2 of the base specification > [2] to determine whether the IKE endpoints can be moved or if the > IKE SA has to be re-established. => note the situation is different between IKEv1 which "established" SAs and IKEv2 which "manages" SAs, i.e., in IKEv2 when the IKE SA goes down all the IPsec SAs are closed too. So the K bit stuff is more important (and BTW easier) to implement with IKEv2 than in IKEv1 where one can consider it as an optimization. Hmm... I wonder if we really want to carry the K bit scheme forward. I saw that as an intermediate solution. There's no requirement for you to handle everything in this spec, you can also streamline & simplify. Also, I would prefer the above text to allow IKEv2-specific address changes. In particular, there seems to be no reason to disallow automatic NAT-T address changes or even MOBIKE. => there is a simple reason: to have two mechanisms doing the same thing is bad, and to have two conflicting mechanisms is very bad. None of that has any effect on Mobile IPv6, as long as the client still sends a correct Mobile IPv6 Binding Update inside. And MOBIKE is already referenced from elsewhere of the spec, so this is also a consistency issue. Same issue in Section 7.3. => section 7.3 is supposed to solve the consistency issue. I suppose you can propose a better wording? The header says nothing about the relationship to RFC 3776. => this is the rule for an I-D. I agree for an update mention in the RFC. Updates? Obsoletes? Personally, I think "updates" would make more sense, but this is related to the issue of whether you want to carry the manual SA stuff from 3776 here. Its quite a lot to carry, and everyone who uses manual SAs can still use 3776, so no one would actually lose anything. But YMMV, maybe you wanted to show how you get rid of per-interface policies with the new architecture. Editorial: > The IPsec architecture has been revised [5]. Among the many changes, Maybe "RFC 3776 was, however, defined for the first revision of the IPsec architecture. The second revision [5] has introduced..." And change "revised IPsec architecture" later in the document to "the second revision of the IPsec architecture". (Or is the 2nd? Was the something before 2401? => 1825 (August 1995, both IPsec and IPv6 are a bit more than 10 year old). Anyway, my point is that when someone reads this 10 years from now, it may no longer be obvious what "revised ipsec architecture" means.) => 4301 says "updated" which should be better. > The author would like to thank Mika Joutsenvirta, Pasi Eronen, > Francis Dupont, Jari Arkko, Gerardo Giaretta and Shinta Sugimoto for > reviewing the draft. Francis is thanking himself :-) => oops, we missed this one (:-). Thanks Francis.Dupont@point6.net _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Jan 15 13:59:48 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyD6R-00072P-Q1; Sun, 15 Jan 2006 13:59:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyD4E-0004NV-Av; Sun, 15 Jan 2006 13:57:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01538; Sun, 15 Jan 2006 11:20:22 -0500 (EST) Received: from mail1.rz.fhtw-berlin.de ([141.45.5.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExneJ-0008Sw-9z; Sat, 14 Jan 2006 10:49:05 -0500 Received: from e178165109.adsl.alicedsl.de ([85.178.165.109] helo=[192.168.178.20]) by mail1.rz.fhtw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.42 (FreeBSD)) id 1ExnWV-000DJA-3J; Sat, 14 Jan 2006 16:40:59 +0100 Message-ID: <43C91C45.3090909@fhtw-berlin.de> Date: Sat, 14 Jan 2006 16:44:05 +0100 From: Thomas C Schmidt User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Vogt Subject: Re: [Mip6] Delay Analysis for Handoffs with Mobile IPv6 Route Optimization References: <43C7A215.1040804@tm.uka.de> In-Reply-To: <43C7A215.1040804@tm.uka.de> Content-Type: multipart/mixed; boundary="------------000001090005080001050904" X-Spam-Score: 3.1 (+++) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: Mip6 , mipshop , mobopts X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: schmidt@fhtw-berlin.de List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --------------000001090005080001050904 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Dear Christian, thanks for bringing your technical report to our attention! For a comment: it is our experience that the optimistic concept of zero handover delay due to predictive procedures does not survive reality. This is mainly due to - the independence of anticipation, signaling and handoff in occurrence and timescale. - predictions turning out as rather unreliable. We analysed these properties for the case of FMIPv6 (which should be transferable in major parts, e.g., fmip needs fback, you need BU to arrive ...) and found no significant improvement by predicitions (see bib-reference attached). Song et al. ([11] in our references) made empirical studies on predicitions including the campus geometry, statistical correlation analysis of user date ... and arrived at dissapointing 72 %. It's a nice vision - but sometimes real-world isn't as nice ;) Best regards, thomas Christian Vogt wrote: > I would like to call your attention on work that we have done on IPv6 > handoff procedures: > > "A Comprehensive Delay Analysis > for Reactive and Proactive Handoffs > with Mobile IPv6 Route Optimization" > > http://doc.tm.uka.de/2006/vogt-2006-delay-analysis-for-reactive-and-proactive-handoffs.pdf > > > Abstract: Optimizations to reduce handoff delays > inherent in Mobile IPv6 Route Optimization as well > as IPv6 router discovery, address configuration, > and movement detection have so far been mostly > considered on an individual basis. This document > evaluates three integrated solutions for improved > handoff experience in surroundings with different > preconditions: reactive handoffs with unmodified > routers, reactive handoffs with router support, and > movement anticipation and proactive handoff manage- > ment. > > Your feedback will be welcome! > > Regards, > - Christian > --------------000001090005080001050904 Content-Type: text/plain; name="sw-pvrah-05.bib" Content-Disposition: inline; filename="sw-pvrah-05.bib" Content-Transfer-Encoding: quoted-printable @article{sw-pvrah-05, author =3D {Thomas C. Schmidt and Matthias W{\"a}hlisch}, title =3D {{P}redictive versus {R}eactive -- {A}nalysis of {H}andover {= P}erformance and {I}ts {I}mplications on {IP}v6 and {M}ulticast {M}obilit= y}, journal =3D {Telecommunication Systems}, volume =3D {30}, number =3D {1--3}, pages =3D {123--142}, month =3D {November}, year =3D {2005}, publisher =3D {Springer}, address =3D {Berlin Heidelberg}, url =3D {http://dx.doi.org/10.1007/s11235-005-4321-4}, abstract =3D {Handovers in mobile packet networks commonly produce pack= et loss, delay and jitter, thereby significantly degrading network perfor= mance. Mobile IPv6 handover performance is strongly topology dependent an= d results in inferior service quality in wide area scenarios. To approach= seamless mobility in IPv6 networks predictive, reactive and proxy scheme= s have been proposed for improvement. In this article we analyse and comp= are handover performance and frequencies for the corresponding protocols,= as they are an immediate measure on service quality. Using analytical me= thods as well as stochastic simulations, we calculate the performance dec= reases originating from different handover schemes, the expected number o= f handovers as functions of mobility and proxy ratios, as well as the mea= n correctness of predictions. In detail we treat the more delicate case o= f these rates in mobile multicast communication. It is obtained that performance benefits, expected from simple analysis = of predictive schemes, do not hold in practice. Reactive and predictive h= andovers rather admit comparable performance. Hierarchical proxy environm= ents -- foremost in regions of high mobility -- can significantly reduce = the processing of inter--network changes. Reliability of handover predict= ions is found on average at about 50 \%.}, theme =3D {mipv6|mmcast}, file =3D {http://www.informatik.haw-hamburg.de/~schmidt/papers/telesys0= 5.pdf} } --------------000001090005080001050904 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --------------000001090005080001050904-- From mip6-bounces@ietf.org Mon Jan 16 02:10:59 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyOW2-0002yJ-Qr; Mon, 16 Jan 2006 02:10:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyOW0-0002y8-US; Mon, 16 Jan 2006 02:10:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18321; Mon, 16 Jan 2006 02:09:32 -0500 (EST) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX19QGUynzpWoRb4JKtbt5spvKg9jqWsIH2o=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyOds-0005Vp-9s; Mon, 16 Jan 2006 02:19:05 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1EyOVn-0001gd-BM; Mon, 16 Jan 2006 08:10:46 +0100 Received: from [IPv6:2001:638:204:6:20c:6eff:fe40:8d95] (archimedes.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:20c:6eff:fe40:8d95]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id BD3A18B94; Mon, 16 Jan 2006 08:10:40 +0100 (CET) Message-ID: <43CB46F0.5020001@tm.uka.de> Date: Mon, 16 Jan 2006 08:10:40 +0100 From: Christian Vogt User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.7.12) Gecko/20050923 Thunderbird/1.0.7 Mnenhy/0.7.2.0 X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: "Atiquzzaman, Mohammed" Subject: Re: [Mobopts] Re: [Mip6] Delay Analysis for Handoffs with Mobile IPv6Route Optimization References: <96F80D7EBB8DC34092D083C6E2EE5EF504EA2165@XMAIL1.sooner.net.ou.edu> In-Reply-To: <96F80D7EBB8DC34092D083C6E2EE5EF504EA2165@XMAIL1.sooner.net.ou.edu> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -6.2 (------) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] -1.8 AWL AWL: From: address is in the auto white-list X-Spam-Score: 2.4 (++) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: Mip6 , Mipshop , Mobopts , schmidt@fhtw-berlin.de X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Mohammed, it's very good that you point to related work that you did. Still, I refer to the discussion that Thomas and I had yesterday on the differences between network-assisted mobility (which is what you have experimented with) and end-to-end mobility (which is what our analysis is about). To be brief: Our work is truly orthogonal. Further, I should mention that our analysis assumes the use of DNA mechanisms (DNA protocol, CPL, FastRA) to eliminate router-discovery and movement-detection delays during reactive handoffs, Optimistic DAD to get rid of the address-configuration latency, and Media Independent Handover Services (including Information Services) to facilitate proactive handoffs. Hope this makes things more clear. Regards, - Christian -- Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH) www.tm.uka.de/~chvogt/pubkey/ Atiquzzaman, Mohammed wrote: > We also studied the handoff delay between various MIPv6 variants and > SIGMA (a transport layer handoff scheme) and presented the result at > Globecom 2005. In most cases, SIGMA achieved a lower handoff latency > than the MIPv6 variants by exploting multihoming. > > Shaojian Fu, Mohammed Atiquzzaman, Handover latency comparison of SIGMA, > FMIPv6, HMIPv6, and FHMIPv6, IEEE GlobeCom, St. Louis, MO, November > 28-December 02, 2005 > http://www.cs.ou.edu/~netlab/Pub/L2effect-TraSH-globecom05-camera.pdf > > > Mohammed Atiquzzaman Tel: (405) 325 8077 > Professor, School of Computer Science Fax: (405) 325 4044, > University of Oklahoma > 200 Felgar St., Room EL-160 Email: atiq@ou.edu > Norman, OK 73019-6151 atiq@ieee.org > www.cs.ou.edu/~atiq _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jan 16 02:40:00 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyOy7-0000ue-RW; Mon, 16 Jan 2006 02:39:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyOy6-0000uP-0D; Mon, 16 Jan 2006 02:39:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19827; Mon, 16 Jan 2006 02:38:33 -0500 (EST) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX194y3HCdnkp2b3vbNzjFm1G5v3rQ9+BU2s=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyP5y-0006Dk-Dv; Mon, 16 Jan 2006 02:48:07 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1EyOxz-0002qP-Tx; Mon, 16 Jan 2006 08:39:54 +0100 Received: from [IPv6:2001:638:204:6:20c:6eff:fe40:8d95] (archimedes.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:20c:6eff:fe40:8d95]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 7B29886BB; Mon, 16 Jan 2006 08:39:51 +0100 (CET) Message-ID: <43CB4DC7.7030600@tm.uka.de> Date: Mon, 16 Jan 2006 08:39:51 +0100 From: Christian Vogt User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.7.12) Gecko/20050923 Thunderbird/1.0.7 Mnenhy/0.7.2.0 X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: schmidt@fhtw-berlin.de Subject: Re: [Mip6] Delay Analysis for Handoffs with Mobile IPv6 Route Optimization References: <43C7A215.1040804@tm.uka.de> <43C91C45.3090909@fhtw-berlin.de> <43CA50C7.1000206@tm.uka.de> <43CA6387.8080306@fhtw-berlin.de> In-Reply-To: <43CA6387.8080306@fhtw-berlin.de> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -6.1 (------) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] -1.7 AWL AWL: From: address is in the auto white-list X-Spam-Score: 2.4 (++) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 7bit Cc: Mip6 , Mipshop , Mobopts X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Hi Thomas. > I perfectly agree with your characterisation. I did'nt mean to say > that both approaches are the same. What I tried to suggest is that > there might be some lessons to be learned from [1] for your work. Yes, in particular with respect to the reliability of movement predictions, which you are considering in [1]. This is definitely an interesting issue, albeit it is the link-layer folks that must eventually solve it. I would also assume that the reliability of predictions strongly depends on the access technology. E.g., in GSM, you have bidirectional measurements that you can take into account. This is not necessarily true for other link layers, such as IEEE 802.11. > It may as well happen that the degree of coincidence required by your > scheme corresponds to a quite narrow regime in phase space, which is > hardly ever met. Zero handoff delay, at the IP layer, is indeed possible only when certain assumptions hold. And as discussed in section 7.1 of [2], this is not always the case. However, end-to-end proactivity can perform better than reactive approaches even when conditions are sub-optimal. To exemplify this, let's consider the packet-propagation latencies on the old path versus the new path during a proactively managed handoff: If the new path is longer, the mobile node may have to wait for packets after it has switched links (subsequent to receiving a Binding Acknowledgment on the old link). If the new path is shorter, some packets may already be lost on the new link before the mobile node arrives there. But in both cases, the blackout time is usually shorter than in a pure reactive approach. Anyway, all this is discussed in more detail in [2]. - Christian [1] http://www.informatik.haw-hamburg.de/~schmidt/papers/telesys05.pdf [2] http://doc.tm.uka.de/2006/vogt-2006-delay-analysis-for-reactive-and-proactive-handoffs.pdf -- Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH) www.tm.uka.de/~chvogt/pubkey/ Thomas C Schmidt wrote: > Hi Christian, > > the mailinglist seems to be gone for the weekend ... so this is very > private ... > > > Christian Vogt wrote: > >> While your results [1] on FMIPv6 and HMIPv6 shed light on the >> performance of proactivity in combination with local mobility >> optimizations and are as such undoubtedly very important, I do not >> necessarily consent with your statement that those results can be >> conveyed to the end-to-end mobility management that we have been >> analyzing [2]. >> > > I perfectly agree with your characterisation. I did'nt mean to say > that both approaches are the same. What I tried to suggest is that > there might be some lessons to be learned from [1] for your work. > > From an abstract point of view the approaches of FMIPv6 (predictive > part) and proactive end-to-end mobility management agree in hiding > update delays by advancing handover negotiations on the basis of > predictions. > > Beside problems with the reliability of predictions they both rely on > timing issues: negotiations have to be successfully completed for > the schemes to work. You are addressing this issue in section 7.1 of > [2], but what we would like to contribute as the essence of [1] > reads: > > There are three different timescales, one defined by the HO scheme + > Internet topology, another by the L2 technologie and the third by > the actual movement of the mobile user. They are fairly independent > of each other. > > It may as well happen that the degree of coincidence required by your > scheme corresponds to a quite narrow regime in phase space, which is > hardly ever met. Thus it is *possible* that the fascinating > perspective of zero update delay is just a conceptual result, which > basically does not hold in reality. Details of course are subject to > a thorough analysis, which you will probably do. > > Best regards, > > thomas > >> [1] >> http://www.informatik.haw-hamburg.de/~schmidt/papers/telesys05.pdf >> [2] >> http://doc.tm.uka.de/2006/vogt-2006-delay-analysis-for-reactive-and-proactive-handoffs.pdf _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jan 16 07:10:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyTBt-0000ge-Ux; Mon, 16 Jan 2006 07:10:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyB27-0004fw-W6 for mip6@megatron.ietf.org; Sun, 15 Jan 2006 11:47:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06367; Sun, 15 Jan 2006 11:45:15 -0500 (EST) Received: from mail.ece.gatech.edu ([199.77.227.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExlMW-0007PE-VS; Sat, 14 Jan 2006 08:22:35 -0500 Received: from localhost (k4-3.ece.gatech.edu [199.77.227.203]) by mail.ece.gatech.edu (8.12.10/8.13.4) with ESMTP id k0EDDKp2009845; Sat, 14 Jan 2006 08:13:20 -0500 (EST) Received: from mail.ece.gatech.edu ([199.77.227.200]) by localhost (k4-3.ece.gatech.edu [199.77.227.203]) (amavisd-new, port 10024) with LMTP id 21204-09; Sat, 14 Jan 2006 08:13:18 -0500 (EST) Received: from [192.168.1.64] ([85.103.0.59]) (authenticated bits=0) by mail.ece.gatech.edu (8.12.10/8.13.4) with ESMTP id k0EDC36L009618 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 14 Jan 2006 08:12:05 -0500 (EST) Message-ID: <43C8F89D.7050408@ece.gatech.edu> Date: Sat, 14 Jan 2006 15:11:57 +0200 From: "Ozgur B. Akan" User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ozgur B. Akan" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at ece.gatech.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 16 Jan 2006 07:10:29 -0500 Cc: Subject: [Mip6] CFP-MEDHOCNET2006: 5th Annual Mediterranean Ad Hoc Networking Workshop X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org We apologize in advance for the multiple copies of this CFP. NEWS - Pictures from Lipari: http://www.medhoc.diit.unict.it/2006/pictures.html ************************************************************ PRELIMINARY ANNOUNCEMENT AND CALL FOR PAPERS MED HOC NET 2006 The Fifth Annual MEDITERRANEAN AD HOC NETWORKING Workshop http://www.medhoc.diit.unict.it/2006/ June 14-17 2006 Lipari, Italy ************************************************************ Ad hoc networks have attracted the attention of the research community in the last several years. Now that some of the fundamental issues and challenges of ad hoc networking have been clearly assessed, the focus is partially shifting to new issues, which include application scenarios (road safety, disaster recovery, sensors and actuators, etc.), autonomous Organization and operation, optimization and control, service creation and support, middleware. Moreover, wireless MESH networking is emerging as an "ad hoc spin-off" aimed at extending and integrating the multi-hop paradigm with more traditional networking, which poses new and exciting technical challenges. Med-Hoc-Net 2006 is the major annual international workshop aiming to serve as a platform for researchers and visionaries from academia, research labs, and industry from all over the world. Sharing ideas, views, results, and experiences in the field of wireless multi-hop networking is what Med-Hoc-Net 2006 intends to be about. Anything from theoretical and experimental achievements, to innovative ad hoc systems, prototyping efforts, and case studies is of interest to the Med-Hoc-Net community. The papers solicited in Med-Hoc-Net 2006 cover a variety of topics related to ad hoc and MESH networks, including but not limited to: - Novel multi-hop wireless network architectures - Routing algorithms and protocols - MAC protocols, scheduling, power control and radio resource sharing - Transport layer protocols for multi-hop networks - Middleware for ad hoc networks - Application driven architectures and protocols - Sensor network applications and protocols - Vehicular networks - Integration of ad hoc networks with wireless access networks - Implementations, testbeds, and prototypes - Technology related issues (IEEE 802.11, Bluetooth, ZigBee, IEEE 802.16, IEEE 802.20, etc.) - Self organization and network reconfiguration - Optimization models and algorithms - Resource and service discovery - Call admission and traffic shaping policies for ad-hoc networks - Use of advanced antenna technologies (MIMO, beam forming, etc.) - QoS support - Security and privacy The members of program committee will referee all papers, and accepted papers will be published in the conference proceedings. Papers of particular merit will be published in the Elsevier Ad Hoc Networks journal. Manuscripts must be formatted according to the IEEE double-column standard format, with the exception of the font size, which must be 11pt. Authors should use only standard fonts, i.e., Times Roman, Courier, Symbol, and Helvetica, or their equivalent. The maximum length of the manuscript is 8 pages, including figure, tables and references. Papers should be submitted in pdf or ps format through EDAS system (http://edas.info) according to the timetable below. IMPORTANT DATES Full Paper Electronic Submission: Friday February 24, 2006 Tutorial proposal submission: Sunday April 23, 2006 Notification of acceptance/rejection: Tuesday May 2, 2006 Camera ready submission of full papers: Friday May 22, 2006 Tutorial date: June 14, 2006 Conference dates: June 15-17, 2006 -- Dr. Ozgur B. Akan Assistant Professor Department of Electrical and Electronics Engineering Middle East Technical University Ankara, Turkey 06531 Tel: +90-312-210 2353 Fax: +90-312-210 1261 E-mail: akan@eee.metu.edu.tr http://www.eee.metu.edu.tr/~akan _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jan 16 07:10:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyTBu-0000h6-KN; Mon, 16 Jan 2006 07:10:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyCSD-0000G3-Kv; Sun, 15 Jan 2006 13:18:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28922; Sun, 15 Jan 2006 13:16:47 -0500 (EST) Received: from ip-129-15-0-90.zero.ou.edu ([129.15.0.90] helo=it-hollywood.sooner.net.ou.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyCZw-000484-1B; Sun, 15 Jan 2006 13:26:12 -0500 Received: from XMAIL1.sooner.net.ou.edu ([129.15.7.69]) by it-hollywood.sooner.net.ou.edu with Microsoft SMTPSVC(6.0.3790.211); Sun, 15 Jan 2006 12:17:58 -0600 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Mobopts] Re: [Mip6] Delay Analysis for Handoffs with Mobile IPv6Route Optimization Date: Sun, 15 Jan 2006 12:14:40 -0600 Message-ID: <96F80D7EBB8DC34092D083C6E2EE5EF504EA2165@XMAIL1.sooner.net.ou.edu> Thread-Topic: [Mobopts] Re: [Mip6] Delay Analysis for Handoffs with Mobile IPv6Route Optimization Thread-Index: AcYZ6dN6MRTF0OPmTX2W8kBR4nXe0wAFTdSA From: "Atiquzzaman, Mohammed" To: "Christian Vogt" , X-OriginalArrivalTime: 15 Jan 2006 18:17:58.0419 (UTC) FILETIME=[034ABE30:01C61A00] X-Spam-Score: 2.4 (++) X-Scan-Signature: a492040269d440726bfd84680622cee7 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 16 Jan 2006 07:10:29 -0500 Cc: Mip6 , Mipshop , Mobopts X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org We also studied the handoff delay between various MIPv6 variants and SIGMA (a transport layer handoff scheme) and presented the result at Globecom 2005. In most cases, SIGMA achieved a lower handoff latency than the MIPv6 variants by exploting multihoming. Shaojian Fu, Mohammed Atiquzzaman, Handover latency comparison of SIGMA, FMIPv6, HMIPv6, and FHMIPv6, IEEE GlobeCom, St. Louis, MO, November 28-December 02, 2005 http://www.cs.ou.edu/~netlab/Pub/L2effect-TraSH-globecom05-camera.pdf=20 Mohammed Atiquzzaman Tel: (405) 325 8077 Professor, School of Computer Science Fax: (405) 325 4044, University of Oklahoma =20 200 Felgar St., Room EL-160 Email: atiq@ou.edu Norman, OK 73019-6151 atiq@ieee.org www.cs.ou.edu/~atiq=20 > -----Original Message----- > From: mobopts-bounces@irtf.org=20 > [mailto:mobopts-bounces@irtf.org] On Behalf Of Christian Vogt > Sent: Sunday, January 15, 2006 7:40 AM > To: schmidt@fhtw-berlin.de > Cc: Mip6; Mipshop; Mobopts > Subject: [Mobopts] Re: [Mip6] Delay Analysis for Handoffs=20 > with Mobile IPv6Route Optimization >=20 > > We analysed these properties for the case of FMIPv6 (which should be > > transferable in major parts, e.g., fmip needs fback, you need BU to > > arrive ...) and found no significant improvement by=20 > predicitions (see > > bib-reference attached). >=20 > Thomas, >=20 > thanks for bringing this up. >=20 > While your results [1] on FMIPv6 and HMIPv6 shed light on the > performance of proactivity in combination with local mobility > optimizations and are as such undoubtedly very important, I do not > necessarily consent with your statement that those results can be > conveyed to the end-to-end mobility management that we have been > analyzing [2]. >=20 > During an end-to-end Mobile IPv6 handoff, communications are=20 > delayed for > at least a global RTT between the MN and the CN (assuming that > end-to-end optimizations such as EBU and CBA are deployed). This > minimum delay can basically be eliminated in two ways: >=20 > - Proactivity, i.e., send a BU from the old location and move=20 > to the new > location only when packets can expected to have arrived there. >=20 > - Local mobility optimizations such as FMIPv6 and HMIPv6, which either > eliminate global signaling (HMIPv6), or move it off the critical > blackout period (FMIPv6). >=20 > Your work [1] deals with the second option, our's [2] deals=20 > with the first. >=20 > To be more explicit, let's assume we use FMIPv6. All global signaling > is then deferred until the MN has already resumed communications, from > the new link, through the AR-to-AR tunnel. This is true for both > proactive and reactive FMIPv6 modes. What *FMIPv6 proactivity* saves > you is just an FBU's propagation time from the new AR to the old AR. > Compare this to the global RTT that *end-to-end proacitvity*=20 > potentially > saves you. >=20 > Referring to the problems with predictive handoff procedures that you > mention: You are correct, and section 7.1 in our analysis duely > discusses this. As far as unreliability in predictions goes: > Unfortunately, you are right, but that's a different=20 > construction site. ;) >=20 > Regards, > - Christian >=20 > [1] http://www.informatik.haw-hamburg.de/~schmidt/papers/telesys05.pdf > [2] > http://doc.tm.uka.de/2006/vogt-2006-delay-analysis-for-reactiv > e-and-proactive-handoffs.pdf >=20 > --=20 > Christian Vogt, Institute of Telematics, University of Karlsruhe > www.tm.uka.de/~chvogt/pubkey/ >=20 >=20 >=20 > Thomas C Schmidt wrote: > > Dear Christian, > >=20 > > thanks for bringing your technical report to our attention! > >=20 > > For a comment: it is our experience that the optimistic=20 > concept of zero > > handover delay due to predictive procedures does not=20 > survive reality. > >=20 > > This is mainly due to > >=20 > > - the independence of anticipation, signaling and handoff in > > occurrence and timescale. > >=20 > > - predictions turning out as rather unreliable. > >=20 > > We analysed these properties for the case of FMIPv6 (which should be > > transferable in major parts, e.g., fmip needs fback, you need BU to > > arrive ...) and found no significant improvement by=20 > predicitions (see > > bib-reference attached). > >=20 > > Song et al. ([11] in our references) made empirical studies on > > predicitions including the campus geometry, statistical correlation > > analysis of user date ... and arrived at dissapointing 72 %. > >=20 > > It's a nice vision - but sometimes real-world isn't as nice ;) > >=20 > > Best regards, > >=20 > > thomas > >=20 > > Christian Vogt wrote: > >=20 > >> I would like to call your attention on work that we have=20 > done on IPv6 > >> handoff procedures: > >> > >> "A Comprehensive Delay Analysis > >> for Reactive and Proactive Handoffs > >> with Mobile IPv6 Route Optimization" > >> > >>=20 > http://doc.tm.uka.de/2006/vogt-2006-delay-analysis-for-reactiv > e-and-proactive-handoffs.pdf > >> > >> > >> Abstract: Optimizations to reduce handoff delays > >> inherent in Mobile IPv6 Route Optimization as well > >> as IPv6 router discovery, address configuration, > >> and movement detection have so far been mostly > >> considered on an individual basis. This document > >> evaluates three integrated solutions for improved > >> handoff experience in surroundings with different > >> preconditions: reactive handoffs with unmodified > >> routers, reactive handoffs with router support, and > >> movement anticipation and proactive handoff manage- > >> ment. > >> > >> Your feedback will be welcome! > >> > >> Regards, > >> - Christian > >> > >=20 > >=20 > -------------------------------------------------------------- > ---------- > >=20 > > @article{sw-pvrah-05, > > author =3D {Thomas C. Schmidt and Matthias W{\"a}hlisch}, > > title =3D {{P}redictive versus {R}eactive -- {A}nalysis of=20 > {H}andover {P}erformance and {I}ts {I}mplications on {IP}v6=20 > and {M}ulticast {M}obility}, > > journal =3D {Telecommunication Systems}, > > volume =3D {30}, > > number =3D {1--3}, > > pages =3D {123--142}, > > month =3D {November}, > > year =3D {2005}, > > publisher =3D {Springer}, > > address =3D {Berlin Heidelberg}, > > url =3D {http://dx.doi.org/10.1007/s11235-005-4321-4}, > > abstract =3D {Handovers in mobile packet networks commonly=20 > produce packet loss, delay and jitter, thereby significantly=20 > degrading network performance. Mobile IPv6 handover=20 > performance is strongly topology dependent and results in=20 > inferior service quality in wide area scenarios. To approach=20 > seamless mobility in IPv6 networks predictive, reactive and=20 > proxy schemes have been proposed for improvement. In this=20 > article we analyse and compare handover performance and=20 > frequencies for the corresponding protocols, as they are an=20 > immediate measure on service quality. Using analytical=20 > methods as well as stochastic simulations, we calculate the=20 > performance decreases originating from different handover=20 > schemes, the expected number of handovers as functions of=20 > mobility and proxy ratios, as well as the mean correctness of=20 > predictions. In detail we treat the more delicate case of=20 > these rates in mobile multicast communication. > > It is obtained that performance benefits, expected from=20 > simple analysis of predictive schemes, do not hold in=20 > practice. Reactive and predictive handovers rather admit=20 > comparable performance. Hierarchical proxy environments --=20 > foremost in regions of high mobility -- can significantly=20 > reduce the processing of inter--network changes. Reliability=20 > of handover predictions is found on average at about 50 \%.}, > > theme =3D {mipv6|mmcast}, > > file =3D=20 > {http://www.informatik.haw-hamburg.de/~schmidt/papers/telesys05.pdf} > > } >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jan 16 09:13:44 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyV7A-0000ac-SJ; Mon, 16 Jan 2006 09:13:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyV78-0000aU-IY for mip6@megatron.ietf.org; Mon, 16 Jan 2006 09:13:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15688 for ; Mon, 16 Jan 2006 09:12:17 -0500 (EST) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX1+RIkMJRe8X/RegULjIiTR+PQtQA3Lo8IU=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyVF1-0002sP-R4 for mip6@ietf.org; Mon, 16 Jan 2006 09:21:55 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1EyV6s-0006MG-Mb for ; Mon, 16 Jan 2006 15:13:33 +0100 Received: from [IPv6:2001:638:204:6:20c:6eff:fe40:8d95] (archimedes.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:20c:6eff:fe40:8d95]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 7EB758BF9 for ; Mon, 16 Jan 2006 15:13:26 +0100 (CET) Message-ID: <43CBAA06.1000101@tm.uka.de> Date: Mon, 16 Jan 2006 15:13:26 +0100 From: Christian Vogt User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.7.12) Gecko/20050923 Thunderbird/1.0.7 Mnenhy/0.7.2.0 X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Mip6 X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -6.0 (------) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] -1.6 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Subject: [Mip6] EBU/CBA Implementation X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Everybody, here is a link to our software implementation of Early Binding Updates and Credit-Based Authorization: http://www.tm.uka.de/~chvogt/ebucba/ The implementation is a patch for the Kame- Shisa Mobile IPv6 software, version 20050822, for FreeBSD 5.4. Kind regards, - Christian -- Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH) www.tm.uka.de/~chvogt/pubkey/ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jan 17 20:16:10 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez1uK-0006bZ-2F; Tue, 17 Jan 2006 20:14:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eytb8-0006CC-Iz; Tue, 17 Jan 2006 11:22:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27997; Tue, 17 Jan 2006 11:20:54 -0500 (EST) Received: from ee.eee.metu.edu.tr ([144.122.166.16] ident=_postfix) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EytjG-0006CX-4m; Tue, 17 Jan 2006 11:30:44 -0500 Received: from localhost (localhost.eee.metu.edu.tr [127.0.0.1]) by ee.eee.metu.edu.tr (Postfix) with ESMTP id B780ED7BA7; Tue, 17 Jan 2006 18:10:50 +0200 (EET) Received: from ee.eee.metu.edu.tr ([127.0.0.1]) by localhost (ee.eee.metu.edu.tr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32354-05; Tue, 17 Jan 2006 18:10:47 +0200 (EET) Received: from [144.122.167.158] (ee-167-158.eee.metu.edu.tr [144.122.167.158]) by ee.eee.metu.edu.tr (Postfix) with ESMTP id 20CE7D7B80; Tue, 17 Jan 2006 18:10:47 +0200 (EET) Message-ID: <43CD19A2.2010305@ece.gatech.edu> Date: Tue, 17 Jan 2006 18:21:54 +0200 From: "Ozgur B. Akan" User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ozgur B. Akan" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at eee.metu.edu.tr X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 17 Jan 2006 20:14:38 -0500 Cc: Subject: [Mip6] CFP: Special Issue on Mobile Video - Signal Processing: Image Communication Journal (Elsevier) X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Please accept our apologies for the multiple copies of this CFP. ******************************************************************* ******************************************************************* CALL FOR PAPERS SIGNAL PROCESSING: IMAGE COMMUNICATION JOURNAL (ELSEVIER) Special Issue on MOBILE VIDEO http://www.MobiMedia.org/MobileVideo ******************************************************************* ******************************************************************* Video communication over wireless networks is destined to become pervasive in daily life and a pillar for key emerging telecommunication services. The success of advanced services in mobile environments requires integrative approaches embracing video signal processing and networking technology. The interlinking of these research fields is fostering the development of underlying technology and workflows for mobile video. These technologies, generally hidden to the user, will be pre-requisite to allow for efficient multimedia support of digital communication and leisure time over wireless channels. This special issue will report the results of latest research efforts on video communication in mobile environments. The main goal of this special issue is to collate and disseminate the most relevant achievements of researchers working on video signal processing and communication for mobile applications. High quality contributions addressing related theoretical and practical aspects are solicited. Topics of interest include (but are not limited to): * Low-bit rate video coding * Scalable video coding for wireless communication channels * Error control resilience and concealment * Multiple video descriptions for wireless communications * Video transcoding for heterogeneous wireless channels interoperability * Video streaming over wireless channels * Video communication in wireless ad hoc and sensor networks * Mobile video multicast * Quality measurement for mobile video * Mobile video testbeds and applications Submission Procedure -------------------- Prospective contributors are invited to submit papers according to the instructions in the ''Information for Authors'' on the back cover of a recent issue of the Signal Processing: Image Communication Journal. Authors should submit their manuscripts in PDF format through the COCUS Conference Management System. If you are not a COCUS user yet, you need to register at first. Then, select SPIC-MobileVideo from the ''Events' list'' page and follow the instructions to submit your manuscript. Selected papers on mobile video submitted to MobiMedia 2006 (www.MobiMedia.org) will also be considered for publication in this special issue. Important Dates --------------- Deadline for Manuscript Submission: May 12, 2006 Notification of Acceptance: August 15, 2006 Camera-Ready Papers Due: September 15, 2006 Publication Date: January 2007 Guest Editors ------------- Luigi Atzori (l.atzori@diee.unica.it) DIEE, University of Cagliari, Cagliari, Italy Ebroul Izquierdo (ebroul.izquierdo@elec.qmul.ac.uk) Multimedia and Vision Lab, Queen Mary, University of London London, UK Pascal Frossard (pascal.frossard@epfl.ch) EPFL, Signal Processing Institute Lausanne, Switzerland Ozgur B. Akan (akan@eee.metu.edu.tr) Dept. of Electrical Eng. Middle East Technical University, Ankara, Turkey -- Dr. Ozgur B. Akan Assistant Professor Department of Electrical and Electronics Engineering Middle East Technical University Ankara, Turkey 06531 Tel: +90-312-210 2353 Fax: +90-312-210 1261 E-mail: akan@eee.metu.edu.tr http://www.eee.metu.edu.tr/~akan _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jan 17 20:16:11 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez1uK-0006bi-Qs; Tue, 17 Jan 2006 20:14:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eytde-00078P-DK; Tue, 17 Jan 2006 11:24:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28182; Tue, 17 Jan 2006 11:23:30 -0500 (EST) Received: from ee.eee.metu.edu.tr ([144.122.166.16] ident=_postfix) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eytln-0006H5-1E; Tue, 17 Jan 2006 11:33:20 -0500 Received: from localhost (localhost.eee.metu.edu.tr [127.0.0.1]) by ee.eee.metu.edu.tr (Postfix) with ESMTP id A4B10D7BBD; Tue, 17 Jan 2006 18:13:42 +0200 (EET) Received: from ee.eee.metu.edu.tr ([127.0.0.1]) by localhost (ee.eee.metu.edu.tr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03903-04; Tue, 17 Jan 2006 18:13:39 +0200 (EET) Received: from [144.122.167.158] (ee-167-158.eee.metu.edu.tr [144.122.167.158]) by ee.eee.metu.edu.tr (Postfix) with ESMTP id 0BA01D7BB4; Tue, 17 Jan 2006 18:13:39 +0200 (EET) Message-ID: <43CD1A4E.7010609@ece.gatech.edu> Date: Tue, 17 Jan 2006 18:24:46 +0200 From: "Ozgur B. Akan" User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ozgur B. Akan" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at eee.metu.edu.tr X-Spam-Score: 0.1 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 17 Jan 2006 20:14:38 -0500 Cc: Subject: [Mip6] CFP: Mobile Multimedia Communications Conference (MobiMedia 2006) X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org [ We apologize in advance for the multiple copies of this CFP. ] ------------------------------------------------------------------- CALL FOR PAPERS MOBIMEDIA 2006 Mobile Multimedia Communications Conference (formerly MSAN) September 18-20, 2006 -- Alghero, Sardinia, Italy http://www.mobimedia.org ------------------------------------------------------------------- SCOPE The successful development of multimedia services and applications in mobile environments requires adopting an interdisciplinary approach where both multimedia and networking issues are addressed jointly. Multimedia data characteristics, coding standards functionalities, as well as network protocols performance and channel behavior are some of the key aspects that need to be carefully examined when proposing new solutions. Many are the applications that are going to be enabled by the new standards for mobile networking, such as packet telephony, video mail, video streaming, audio conferencing, interactive gaming, conversational navigation services, digital television, infomobility, and immersive communications in virtual environments. Some of these novel networking protocols and technologies include IEEE 802.11 (infrastructured, mesh, and sensor networks), 802.15, 802.16, UWB, DVB-H, Bluetooth, Mobile IP and its variants. Within this scope, MobiMedia is intended to provide a unique international forum for researchers working in multimedia and mobile networking fields to study new applications, solutions, and standards. Original unpublished contributions are solicited that can improve the knowledge and practice in the integrated design of efficient technologies and the relevant provision of advanced mobile multimedia applications. TECHNICAL PROGRAMS The technical program features a key-note speech from Roberto Cencioni (Head of Unit INFSO E2, EC) and Albert Gauthier (DG Information Society, EC) on the 7th Work program and the EU IST vision. The conference will also include invited panels, to facilitate for exchanging ideas and discussion, and specific sessions and workshops on focused interest areas. Submissions of proposals on workshops and special sessions on emerging topics are invited. Please submit proposals to Technical Program Chairs and Workshop Chairs. PAPER SUBMISSION AND PUBLICATION Prospective authors are invited to submit extended summaries of not more than five pages including figures and references. Papers will be accepted only by electronic submission through the conference web site. Conference proceedings will be published by the IEEE and will be available through IEEExplore (approval pending). Extended versions of high quality papers on mobile video will be reviewed and considered for a special issue in the Signal Processing: Image Communications Journal. WORKSHOPS Proposals for one-day workshops to be held in conjunction with the conference are solicited. A maximum of 2 pages should be submitted which include the workshop name, its scope and a list of topic of interests.Proposals should be submitted to both the Workshop Chairs. STUDENT AWARD AND GRANTS A student prize of 1000 Euros will be awarded to the best paper authored by a full time student as first author. Travel grants will be provided to students attending the conference. Additional information can be found at the conference website. IMPORTANT DEADLINES Workshop proposals: January 20, 2006 Special session proposals: March 15, 2006 Submission of extended summaries: April 30, 2006 Notification of acceptance: June 15, 2006 Submission of camera-ready papers: July 10, 2006 ORGANIZING COMMITTEE General Co-Chairs: Luigi Atzori, University of Cagliari, ITA Ebroul Izquierdo, University of London, UK Steering Committee Chair: Imrich Chlamtac, Create-Net, ITA Technical Program Co-Chairs: Ozgur B. Akan, Middle East Technical University, TUR Pascal Frossard, EPFL, SUI Publications Chair: Giovanni Pau, UCLA, USA Workshops Chair: Eylem Ekici, Ohio State University, USA Radha Poovendran, University of WA, USA Panels Chair: Daniele D. Giusto, University of Cagliari, ITA Local Chair: Giaime Ginesu, University of Cagliari, ITA Publicity Co-Chairs: Gozde Bozdagi Akar, Middle East Technical University, TUR Ali Bilgin, The University of Arizona, USA Conference Management: Anna Rieger, ICST, Europe -- Dr. Ozgur B. Akan Assistant Professor Department of Electrical and Electronics Engineering Middle East Technical University Ankara, Turkey 06531 Tel: +90-312-210 2353 Fax: +90-312-210 1261 E-mail: akan@eee.metu.edu.tr http://www.eee.metu.edu.tr/~akan _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jan 20 06:56:38 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezusg-0007fT-6u; Fri, 20 Jan 2006 06:56:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezusc-0007eI-Tx for mip6@megatron.ietf.org; Fri, 20 Jan 2006 06:56:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05087 for ; Fri, 20 Jan 2006 06:55:06 -0500 (EST) Received: from smtp7.clb.oleane.net ([213.56.31.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezv1L-0000z8-Ve for mip6@ietf.org; Fri, 20 Jan 2006 07:05:36 -0500 Received: from Pavillonquatre ([194.3.133.88]) by smtp7.clb.oleane.net with ESMTP id k0KBuKbf026136 for ; Fri, 20 Jan 2006 12:56:22 +0100 Message-Id: <200601201156.k0KBuKbf026136@smtp7.clb.oleane.net> From: "Chantal Ladouce" To: Date: Fri, 20 Jan 2006 12:55:12 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYduF6cO1EhGm1ZT1WF9JgxqfxpeA== X-Spam-Score: 0.2 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Subject: [Mip6] WiMAX Summit - International SIP conference - Paris - France X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2030343963==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============2030343963== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0119_01C61DC0.C08E5EC0" This is a multi-part message in MIME format. ------=_NextPart_000_0119_01C61DC0.C08E5EC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The WiMAX Summit and the International SIP conference will jointly open their doors in one month, on February 21st, in Paris. Everything you must know about broadband wireless access, VoIP and convergence will be delivered by operators and key technical players. An exhibition, close to the two conferences, welcome industrials wishing to demonstrate their solutions. Get details on International SIP at: http://www.upperside.fr/sip2006/sip2006intro.htm Get details on the WiMAX Summit at: http://www.upperside.fr/wimax2006/wimax2006intro.htm ------=_NextPart_000_0119_01C61DC0.C08E5EC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The WiMAX Summit and the International SIP = conference will jointly open their doors in one month, on February 21st, in = Paris.

Everything you must know about broadband = wireless access, VoIP and convergence will be delivered by operators and key = technical players.

An exhibition, close to the two conferences, welcome industrials wishing to demonstrate their = solutions.

 

Get details on International SIP = at:

http://www.upperside.fr/sip2006/sip2006intro.htm<= /span>

 

Get details on the WiMAX Summit = at:

http://www.upperside.fr/wimax2006/wimax2006intro.htm<= /a>

 

 

------=_NextPart_000_0119_01C61DC0.C08E5EC0-- --===============2030343963== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============2030343963==-- From mip6-bounces@ietf.org Mon Jan 23 15:43:41 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F18XM-0001I4-Vx; Mon, 23 Jan 2006 15:43:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F18XL-0001Hy-G8 for mip6@megatron.ietf.org; Mon, 23 Jan 2006 15:43:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16636 for ; Mon, 23 Jan 2006 15:42:08 -0500 (EST) Received: from mail.um.es ([155.54.212.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F18gj-0003l1-NN for mip6@ietf.org; Mon, 23 Jan 2006 15:53:23 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id 43A7B1FAB23 for ; Mon, 23 Jan 2006 21:43:21 +0100 (CET) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon1 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 19647-01-15 for ; Mon, 23 Jan 2006 21:43:20 +0100 (CET) Received: from [137.73.11.205] (dibulibu.um.es [155.54.1.250]) by mail.um.es (Postfix) with ESMTP id 94E511FAB1E for ; Mon, 23 Jan 2006 21:43:20 +0100 (CET) Message-ID: <43D53FEB.2060206@dif.um.es> Date: Mon, 23 Jan 2006 21:43:23 +0100 From: "Pedro M. Ruiz" User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip6@ietf.org Content-Type: multipart/mixed; boundary="------------030300010702060307050805" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Subject: [Mip6] Call for Papers AD HOC NOW 2006 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --------------030300010702060307050805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Please, find below a call for papers that may be of your interest. All the best, --Pedro M. Ruiz http://ants.dif.um.es/staff/pedrom/ --------------030300010702060307050805 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="cfp.txt" Content-Disposition: inline; filename="cfp.txt" Content-Transfer-Encoding: 7bit We apologize if you receive this CFP more than once. ---------------------------------------------------------------------------- PRELIMINARY CALL FOR PAPERS - AD HOC NOW 2006 5th International Conference on Ad hoc Networks and Wireless Ottawa, August 17-19, 2006 http://kunz-pc.sce.carleton.ca/AdHocNow2006/ ---------------------------------------------------------------------------- IMPORTANT DATES --------------- Abstract Submission: February 24, 2006 Paper Submission : March 3, 2006 Notification of Acceptance: May 3, 2006 Camera-ready versions due: June 7, 2006 Demo proposals due: May 1, 2006 SCOPE ----- We are interested in work in progress, experimental and theoretical research in Wireless Sensor, Ad-Hoc, Mobile and Wireless Networks. Of interest, but not limited to, are research papers in any of the following areas: * Access Control * Ad Hoc Networks of Autonomous Intelligent Systems * Analytic Methods and Modeling for Performance Evaluation * Application for Ad Hoc Networks * Architectures of Ad-Hoc Networks * Distributed Algorithms for Ad Hoc Networks * Location Discovery and Management * Low Power and Energy-Efficient Designs * Mobile Ad Hoc Computing Platforms, Systems and Testbeds * Quality-of-Service * Routing Protocols (Unicast, Multicast, etc.) * Secure Services and Protocols * Sensor Networks * Self-Configuration * Service Discovery * Timing Synchronization * Wireless Internet PROCEEDINGS ----------- As in the past years, we plan to have the proceedings of Adhoc Now 2006 published by Springer-Verlag, as part of the Lecture Notes in Computer Science (LNCS) series. PAPER SUBMISSION INSTRUCTIONS ---------------------------- Authors are strongly encouraged to (but not required to) submit a 150 word abstract of their paper along with three keywords by the abstract submission deadline (February 24, 2006). Acceptable formats for the abstracts are plain text, postscript (PS) and portable document format (PDF). Submissions should not exceed 14 pages (including a 150 word abstract, all figures, tables and references) in Springer Verlag LNCS format. Acceptable formats for papers are PS and PDF. Submissions which are not in the appropriate format will be rejected without review. All papers will be reviewed for technical merit. Each accepted paper will be published in the conference proceedings, provided at least one author of the paper registers to present the paper at the conference. All abstract and paper submissions will be handled electronically at the conference website. SYSTEM DEMONSTRATIONS --------------------- Proposals for system demonstrations related to wireless networks are also solicited. Proposals should not exceed 3 pages in LNCS format and should include a description of the demo and the equipment to be used. Potential demonstrators are requested to submit a proposal in PS or PDF format to one of the Co-Chairs of the Technical Program Committee (Thomas Kunz -- tkunz@sce.carleton.ca or S. S. Ravi -- ravi@cs.albany.edu) by May 1, 2006. Please include contact information (postal address, email address, phone and fax numbers) in the submission. Accepted proposals for system demonstrations will be allotted three pages in the proceedings, provided at least one author registers to present the demo at the conference. TECHNICAL COMMITTEES -------------------- Program Committee Co-Chairs: Thomas Kunz, Carleton University, Canada S. S. Ravi, SUNY Albany, USA Steering Committee: Evangelos Kranakis, Carleton University, Canada Michel Barbeau, Carleton University, Canada S. S. Ravi, SUNY Albany, USA Ioanis Nikolaidis, Univ. of Alberta, Canada Violet R. Syrotiuk, Arizona State Univ., USA Publicity Committee: Mieso Denko, University of Guelph, Canada Pedro M. Ruiz, Univ. of Murcia, Spain Technical Program Committee: Nael Abu-Ghazaleh, SUNY Binghamton, USA Eitan Altman, INRIA, France Michel Barbeau, Carleton University, Canada Rida Bazzi, Arizona State Univ., USA Prosenjit Bose, Carleton University, Canada Torsten Brown, Univ. Berne, Switzerland Gruia Calinescu, Illinois Inst. of Tech., USA Edgar Chavez, Univ. Michoacana, Mexico Hsiao-Hwa Chen, National Sun Yat-Sen Univ., Taiwan Jorge Cobb, UT Dallas, USA Pilu Crescenzi, Univ. Florence, Italy Mieso Denko, Univ. of Guelph, Canada Stefan Dobrev, Univ. of Ottawa, Canada Mischa Dohler, King's College, London, UK Andras Farago, UT Dallas, USA Laura Feeney, Swedish Institute of Computer Science, Sweden Stefan Fischer, Univ. Luebeck, Germany Antonio Gomez-Skarmeta, Univ. of Murcia, Spain Alex Hall, ETH, Zurich Admela Jukan, Georgia Tech, USA Valerie King, Univ. Victoria, Canada Evangelos Kranakis, Carleton University, Canada Danny Krizanc, Wesleyan University, USA Sven Krumke, Univ. Kaiseslautern, Germany Thomas Kunz, Carleton Univ., Canada Louise Lamont, Communications Research Center, Canada Errol Lloyd, Univ. Delaware, USA Angela Mielke, Los Alamos National Labs, USA Jelena Misic, Univ. Manitoba, Canada Pat Morin, Carleton University, Canada Lata Narayanan, Concordia Univ, Canada Ioanis Nikolaidis, U. Alberta, Canada J. Opatrny, Concordia Univ., Canada Marina Papatriantafilou, Chalmers Univ., Sweden Paolo Penna, Univ. Salerno, Italy Cristina Pinotti, Univ. Perugia, Italy Guy Pujolle, Univ. Pierre et Marie Curie, France Ravi Prakash, Univ. Texas at Dallas, USA Sergio Rajsbaum, UNAM, Mexico S. S. Ravi, SUNY Albany, USA Jean-Marc Robert, Alcatel, Canada Pedro M. Ruiz, Univ. of Murcia, Spain Christian Schindelhauer, Univ. Paderborn, Germany Andrew Scott, Lancaster Univ., UK Martha Steenstrup, Stow Research LLC and Clemson Univ., USA Ivan Stojmenovic, Univ. Ottawa, Canada Ravi Sundaram, Northeastern University, USA Violet R. Syrotiuk, Arizona State Univ., USA Damla Turgut, Univ. of Florida, USA Anil Kumar Vullikanti, Virginia Tech., USA Paul Ward, Univ. Waterloo, Canada Gergely Zaruba, Univ. Texas at Arlington, USA Jerry Zhao, ICSI-Berkeley, USA FOR ADDITIONAL INFORMATION ------------------------- For questions regarding obtaining visas, accommodation, etc, please contact Thomas Kunz (mailto:tkunz@sce.carleton.ca). Questions regarding paper submissions should be addressed to S. S. Ravi (mailto:ravi@cs.albany.edu). --------------030300010702060307050805 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --------------030300010702060307050805-- From mip6-bounces@ietf.org Mon Jan 23 16:05:29 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F18sS-0007ux-QE; Mon, 23 Jan 2006 16:05:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F18sQ-0007tI-Vl for mip6@megatron.ietf.org; Mon, 23 Jan 2006 16:05:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19041 for ; Mon, 23 Jan 2006 16:03:56 -0500 (EST) Received: from mail.um.es ([155.54.212.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F191n-0004uQ-Su for mip6@ietf.org; Mon, 23 Jan 2006 16:15:11 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id 3A26A23CBC7 for ; Mon, 23 Jan 2006 22:05:14 +0100 (CET) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon2 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 25867-01-7 for ; Mon, 23 Jan 2006 22:05:13 +0100 (CET) Received: from [137.73.11.205] (dibulibu.um.es [155.54.1.250]) by mail.um.es (Postfix) with ESMTP id A421F23CBB4 for ; Mon, 23 Jan 2006 22:05:13 +0100 (CET) Message-ID: <43D5450C.2080202@dif.um.es> Date: Mon, 23 Jan 2006 22:05:16 +0100 From: "Pedro M. Ruiz" User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip6@ietf.org Content-Type: multipart/mixed; boundary="------------000901020509060501000102" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Subject: [Mip6] Call for Papers IEEE MASS 2006 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --------------000901020509060501000102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit We apologize if you receive this CFP more than once. Please, find below a call for papers that may be of your interest. All the best, Pedro M. Ruiz Publicity co-chair MASS 2006 http://ants.dif.um.es/staff/pedrom/ --------------000901020509060501000102 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="cfp_MASS_2006.txt" Content-Disposition: inline; filename="cfp_MASS_2006.txt" Content-Transfer-Encoding: 7bit Call for Papers The 3rd IEEE International Conference on Mobile Ad hoc and Sensor Systems (MASS-2006) October 9 - 12, 2006 Vancouver, Canada http://www.ieee-mass.org Sponsored by IEEE Computer Society, IEEE TC on Distributed Processing and TC on Simulation OVERVIEW Earlier research in wireless networks and mobile computing has concentrated on single-hop networks, where network nodes communicate directly with a fixed infrastructure, such as cellular or satellite systems. More recently, interest in multi-hop networks, such as mobile ad hoc networks and sensor networks, has stimulated a significant amount of scientific research. In particular, wireless mesh networking (a new community network architecture) has been proposed as an alternative for providing Internet access to business and residential customers. This conference focuses on multi-hop ad hoc and sensor networks systems, covering topics ranging from physical issues to applications. TOPICS Manuscripts that focus on analytical modeling, protocol/algorithm design, and/or experimental studies of the following topics of interest are sought: - Channel behavior modeling and its impact on design of higher-layer protocols - Directional and smart antennas for ad hoc networks - MAC protocols for ad hoc and sensor networks (802.11, 802.15.4, UWB) - Provisioning of wireless QoS; e.g., bandwidth and delay assurance - Routing protocols (unicast, multicast, broadcast, geocast) and routing metrics - Data transport in wireless ad hoc and sensor networks - Power-aware and energy-efficient design - Topology construction and maintenance of coverage - Cross-layer design and optimization - Incentives and game theoretic approaches in wireless ad hoc networks - Localization and synchronization in wireless sensor networks - Data gathering, fusion, and dissemination in wireless sensor - Reliability, security, and trustworthiness in ad hoc and sensor networks - Operating system and middleware support - Applications of multi-hop technology SUBMISSION Technical papers: All submissions must be full papers in .pdf or .ps (PostScript) format. Papers must be uploaded to EDAS by March 31, 2006, and must not exceed 10 single-spaced, two-column pages using at least 11 point size fonts on 8.5 x 11 inch pages. Detailed submission instructions will be published in due time on the conference website http://www.ieee-mass.org together with format files. Workshops: Proposals for full day workshops are solicited. Selections will be made considering the expertise and experience of the workshop organizers and the relevance of the topic to the central theme of the conference. Proposals of at most 4 pages, including a 1-page biographical sketch, should be submitted to the Workshops Chair, Elizabeth M. Belding-Royer (ebelding@cs.ucsb.edu ) by March 31, 2006. IMPORTANT DATES Manuscript Submission Due: March 31, 2006 Acceptance Notification: June 30 2006 Final Manuscript Due: August 10, 2006 Conference: Octorber 9-12, 2006 COMMITTEE GENERAL CO-CHAIRS Charles E. Perkins Nokia Research Center Jie Wu Florida Atlantic University PROGRAM CO-CHAIRS Zygmunt J. Haas Cornell University Jennifer Hou University of Illinois at Urbana-Champaign PROGRAM VICE CO-CHAIRS Ben Liang University of Toronto Mingyan Liu University of Michigan WORKSHOPS CHAIR Elizabeth M. Belding-Royer University of California, Santa Barbara PROGRAM COMMITTEE check http://www.ieee-mass.org --------------000901020509060501000102 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --------------000901020509060501000102-- From mip6-bounces@ietf.org Thu Jan 26 12:49:17 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2BFF-00051w-Gd; Thu, 26 Jan 2006 12:49:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2BFD-00051o-25 for mip6@megatron.ietf.org; Thu, 26 Jan 2006 12:49:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09116 for ; Thu, 26 Jan 2006 12:47:41 -0500 (EST) Received: from zaz.kom.auc.dk ([130.225.51.10] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2BPB-0007QG-Kn for mip6@ietf.org; Thu, 26 Jan 2006 12:59:34 -0500 Received: from bs-w2k.kom.auc.dk ([192.168.110.161]) by zaz.kom.auc.dk with esmtp (Exim 2.05 #3) id 1F2BF3-0005PP-00 for mip6@ietf.org; Thu, 26 Jan 2006 18:49:05 +0100 Message-ID: <43D90C7A.2030502@kom.aau.dk> Date: Thu, 26 Jan 2006 18:52:58 +0100 From: Thibault Renier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip6@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Subject: [Mip6] MIP protocol interface X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Hi all, I hope Im posting to the correct mailing list. If not, pls redirect me to the relevant one :) Ive been working for some time on the integration of MIPv6 in an IMS-based environment (with, as an example, the UMTS access network) and as some of you may know it causes quite a few interoperability issues with respect to service and access control at the SIP layer. Because of those limits, it could be required that a UE implementing MIP (probably in the kernel) does not encapsulate the packets at L3 (IP-in-IP), ie the UE does not hide its actual location. My question, which might sound trivial and is probably relevant not only for this scenario, is the following: Is it possible to temporarily disable ALL MIP functions when the UE connects to an access network working with an IMS...and how? Im not sure how the protocol stack can be logically changed so that the normal IP schemes (ie no encapsulation) are applied and MIP mechanisms don't impact the SIP session. Regards from Dk, Tibo _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jan 26 15:50:49 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2E4v-0004TW-0q; Thu, 26 Jan 2006 15:50:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2E4G-0004K4-Hx; Thu, 26 Jan 2006 15:50:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24030; Thu, 26 Jan 2006 15:48:35 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2EEE-0005W1-NY; Thu, 26 Jan 2006 16:00:27 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1F2E4A-0008Nn-6B; Thu, 26 Jan 2006 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 26 Jan 2006 15:50:02 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-firewalls-04.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : Mobile IPv6 and Firewalls: Problem statement Author(s) : F. Le, et al. Filename : draft-ietf-mip6-firewalls-04.txt Pages : 23 Date : 2006-1-26 Network elements such as firewalls are an integral aspect of a majority of IP networks today, given the state of security in the Internet, threats, and vulnerabilities to data networks. Current IP networks are predominantly based on IPv4 technology and hence firewalls have been designed for these networks. Deployment of IPv6 networks is currently progressing, albeit at a slower pace. Firewalls for IPv6 networks are still maturing and in development. Mobility support for IPv6 has been standardized as specified in RFC 3775. Given the fact that Mobile IPv6 is a recent standard, most firewalls available for IPv6 networks do not support Mobile IPv6. Unless firewalls are aware of Mobile IPv6 protocol details, these security devices will interfere in the smooth operation of the protocol and can be a detriment to deployment. This document captures the issues that may arise in the deployment of IPv6 networks when they support Mobile IPv6 and firewalls. The issues are not only applicable to firewalls protecting enterprise networks, but are also applicable in 3G mobile networks such as GPRS/ UMTS and CDMA 2000 networks. The goal of this Internet draft is to highlight the issues with firewalls and Mobile IPv6 and act as an enabler for further discussion. Issues identified here can be solved by developing appropriate solutions in the MIP6 WG. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-firewalls-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip6-firewalls-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip6-firewalls-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-1-26142834.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-firewalls-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-firewalls-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-1-26142834.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Fri Jan 27 18:50:12 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2dM4-0003vu-AO; Fri, 27 Jan 2006 18:50:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2dLw-0003t2-8g; Fri, 27 Jan 2006 18:50:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27033; Fri, 27 Jan 2006 18:48:29 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2dWA-0003uY-Ln; Fri, 27 Jan 2006 19:00:39 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1F2dLt-000680-U0; Fri, 27 Jan 2006 18:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 27 Jan 2006 18:50:01 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-aaa-ha-goals-01.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : Goals for AAA-HA interface Author(s) : G. Giaretta, et al. Filename : draft-ietf-mip6-aaa-ha-goals-01.txt Pages : 14 Date : 2006-1-27 In commercial deployments Mobile IPv6 can be a service offered by a Mobility Services Provider (MSP). In this case all protocol operations may need to be explicitly authorized and traced, requiring the interaction between Mobile IPv6 and the AAA infrastructure. Integrating the AAA infrastructure offers also a solution component for Mobile IPv6 bootstrapping in integrated and split scenarios. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-aaa-ha-goals-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip6-aaa-ha-goals-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip6-aaa-ha-goals-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-1-27155011.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-aaa-ha-goals-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-aaa-ha-goals-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-1-27155011.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Sun Jan 29 07:29:42 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3Bgc-00042i-Et; Sun, 29 Jan 2006 07:29:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3BgV-00040a-OJ for mip6@megatron.ietf.org; Sun, 29 Jan 2006 07:29:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24893 for ; Sun, 29 Jan 2006 07:28:00 -0500 (EST) Received: from ip-10-194-65-202.rev.dyxnet.com ([202.65.194.10] helo=hitachi.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F3Bqy-0006Hm-2p for mip6@ietf.org; Sun, 29 Jan 2006 07:40:30 -0500 Received: (qmail 15985 invoked from network); 29 Jan 2006 12:28:59 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk1;c5c3743224d52119bc2a2cac0da95321; Received: from unknown (HELO hitachihk5.hitachi.cn) (170.95.94.1)by ip-11-194-65-202.rev.dyxnet.com with SMTP; 29 Jan 2006 12:28:58 -0000 Received: (qmail 8462 invoked from network); 29 Jan 2006 12:29:00 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk5;82349defaafb43a93cbdc2d0f7a93c95; Received: from hchidc204.hitachi-china.com (HELO hchidc204.hitachi.cn) (170.95.82.6)by 172.16.10.9 with SMTP; 29 Jan 2006 12:29:00 -0000 Received: from hcbjdc2.hitachi.cn ([170.95.81.2]) by hchidc204.hitachi.cn with Microsoft SMTPSVC(6.0.3790.1830); Sun, 29 Jan 2006 20:28:59 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Sun, 29 Jan 2006 20:28:58 +0800 Message-ID: <834B54D356AA8F46B9B233DD88BEAA38BC6AA9@hcbjdc2> Thread-Topic: One IETF related Workshop informaiton, Thread-Index: AcYkz5M+s6WWFkP8QCORp9rwOWciLw== From: "DENG, HUI -HCHBJ" To: "DENG, HUI -HCHBJ" , X-OriginalArrivalTime: 29 Jan 2006 12:28:59.0847 (UTC) FILETIME=[94B6B570:01C624CF] X-Scanned-By-hitachihk5: Virus scan performed by network-box X-Scanned-By-hitachihk5: Scanner file id is hitachihk5-1138537740.41-8459-000 X-Scanned-By-hitachihk5: No known viruses found in message (received+scanned in 0.02/0.06 secs) X-Scanned-By-hitachihk5: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Spam-Status: No X-Scanned-By-hitachihk1: Virus scan performed by network-box X-Scanned-By-hitachihk1: Scanner file id is hitachihk1-1138537738.985-15978-000 X-Scanned-By-hitachihk1: No known viruses found in message (received+scanned in 0.01/0.01 secs) X-Scanned-By-hitachihk1: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Scanned-By-hitachihk1: Whitelisted with valid signature (outbound via Network Box hitachihk5) X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: mip6@ietf.org, sip@ietf.org, wuhq@catt.ac.cn, mip4@ietf.org, softwires@ietf.org, jianping@cernet.edu.cn, netlmm@ngnet.it Subject: [Mip6] One IETF related Workshop informaiton, X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2139221035==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org --===============2139221035== content-class: urn:content-classes:message Content-Type: text/plain;charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 RGVhciBBbGwNCiANClRvZGF5IGlzIENoaW5hJ3MgbHVuYXIgbmV3IHllYXIgZGF5LCBhbmQgdGhp cyB5ZWFyIHNheXMgIkRvZyIgeWVhci4gQnkgdGFraW5nIHRoaXMgb3Bwb3J0dW5pdHksDQpXZSdk IGxpa2UgdG8gYW5ub3VuY2Ugb25lIHdvcmtzaG9wIGluZm9ybWF0aW9uIHdoaWNoIGlzIHJlbGF0 ZWQgdG8gSUVURiBtYWlubHkuDQogDQpBcm91bmQgRmViLiAyNy0yOHRoLCAyMDA2LCBCZWlqaW5n LCBDaGluYSwgQ05HSSBFeHBlcnQgQ29tbWlzc2lvbiB3aWxsIGhvc3QgYSAgc3BlY2lhbCANCndv cmtzaG9wIG9uIE5ldyBUcmVuZCBvZiBOZXh0IEdlbmVyYXRpb24gSW50ZXJuZXQuIFdlIHdlbGNv bWUgYW5kIGludml0ZSAgcmVzZWFyY2hlcnMgDQp3aG8gaXMgaW52b2x2ZWQgaW4gSUVURiwgM0dQ UDIsIElFRUUgcmVsYXRlZCB0byBNSVAsIElQdjYsIFNJUCwgYW5kIEZNQyBldCBhbC4gDQp0byBh dHRlbmQgdGhpcyB3b3Jrc2hvcCBmb3IgZnJlZS4gSWYgeW91IGFyZSBpbnRlcmVzdGVkIGluIGF0 dGVuZGluZyB0aGlzIHdvcmtzaG9wLA0KcGxlYXNlIGRvbnQnIGhlc2l0YXRlIHRvIGxldCB1cyBr bm93IGl0Lg0KIA0KVGhlIGZvbGxvd2luZyBsaW5rIGlzIGxhc3QgeWVhciB3b3Jrc2hvcCBpbmZv cm1hdGlvbjoNCmh0dHA6Ly93d3cxLmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbWlwNi9jdXJy ZW50L21zZzAyMzUzLmh0bWwNCiANCldlIGFyZSBhbHNvIGV4cGVjdGluZyB0aGF0IElFVEYgbWVl dGluZyBjb3VsZCBiZSBoZWxkIGluIENoaW5hIHNvbWVkYXkuDQogDQpIYXBweSBEb2dnaWUsIERv ZywgRG9uZ2xlIFllYXIgdG8gcGVvcGxlIHdobyBpcyBpbnRlcmVzdGVkIGluIENoaW5hJ3MgY3Vs dHVyZS4NCk1hbnkgdGhhbmtzLA0KIA0KUHJvZi4gSGVxdWFuIFd1DQpDaGllZiBTY2llbnRpc3Qs IENoaW5hIE5leHQtR2VuZXJhdGlvbiBJbnRlcm5ldCBFeHBlcnRzIENvbW1pc3Npb24gDQpWaWNl IFByZXNpZGVudCwgQ2hpbmVzZSBBY2FkZW15IG9mIEVuZ2luZWVyaW5nDQogDQpIdWkgRGVuZw0K Q2hhaXIgb2YgT3JnYW5pemluZyBDb21taXR0ZWUNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t IC0tLS0tLS0tLS0tLS0tLS0tLSANCldvcmtzaG9wIG9uIE5ldyBUcmVuZCBvZiBOZXh0IEdlbmVy YXRpb24gSW50ZXJuZXQNCg0KKDEpIE9yZ2FuaXplcnM6ICBDaGluYSBOZXh0LUdlbmVyYXRpb24g SW50ZXJuZXQgRXhwZXJ0cyBDb21taXNzaW9uDQogICAgICBIb3N0OiAgICAgICAgICBDRVJORVQg Q2VudGVyOiBDaGluYSBFZHVjYXRpb24gYW5kIFJlc2VhcmNoIE5ldHdvcmsgQ2VudGVyDQogICAg ICBTcG9uc29yOiAgICAgSGl0YWNoaSAoQ2hpbmEpIFImRCBDb3Jwb3JhdGlvbi4NCigyKSBEYXRl L1RpbWU6ICAgRmViLiAyN3RoLTI4dGguIE1vbmRheS9UdWVzZGF5LCAyMDA2DQooMykgUGxhY2U6 ICAgICAgICAgIFRzaW5naHVhIFVuaXYuIEZJVCBCdWlsZGluZw0KDQpDb250YWN0IFBlb3BsZToN CiANCiBGYW5nIEx2DQogVGVsOiAoODYpIDEw77yNNjI3OTU4MTjvvI02MzIyDQogRS1tYWlsOiBm YW5nbEBjZXJuZXQuZWR1LmNuDQogDQogWWFvaHVpIEFuDQogVGVsOiAoODYpIDEwLTY4NTIyNjY5 DQogRmF4OiAoODYpIDEwLTY4NTIyNjY5DQogRS1tYWlsOiBheWhAY2FlLmNuDQogDQogSHVpIERF TkcNCiBNb2I6ICg4NikgMTM5MTA3NTAyMDENCiBGYXg6ICg4NikgMTAtNjU5MC04MTc5DQogRS1t YWlsOiBoZGVuZ0BoaXRhY2hpLmNuDQoNCldvcmtzaG9wIFRvcGljczoNCi0gSUVURiBNb2JpbGUg SVAgcmVsYXRlZCAoTUlQdjQsIE1JUDYsIE5FTU8sIE1vYm9wdHMsIE5FVExNTSkuDQotIElFVEYg U0lQIHJlbGF0ZWQgKDNHUFAyIHJlbGF0ZWQpLg0KLSAzR1BQMiBJUCByZWxhdGVkIHRlY2hub2xv Z3kgKE1JUCBhbmQgSU1TKS4NCi0gSUVFRSA4MDIuMTYsMjEgSUVURiByZWxhdGVkDQotIDEwMCBi eSAxMDAgcHJvamVjdCByZWxhdGVkDQotIEdFTkkgcHJvamVjdCByZWxhdGVkDQotIENoaW5hIE1v YmlsZSBPcGVyYXRvcnMgc3RyYXRlZ3kgYW5kIHNvbWUgc29sdXRpb24uIChDaGluYSBNb2JpbGUg YW5kIENoaW5hICBVbmljb20pDQotIENoaW5hIEZpeGVkIE9wZXJhdG9ycyBzdHJhdGVneSBhbmQg c29tZSBzb2x1dGlvbi4gKENoaW5hIFRlbGVjb20gYW5kIENoaW5hICBOZXRjb20pDQotIEZvcmVp Z24gTW9iaWxlIENhcnJpZXIncyBzdHJhdGVneSBmb3IgbmV4dCBnZW5lcmF0aW9uIEludGVybmV0 Lg0KLSBDaGluYSBSZXNlYXJjaCBOZXR3b3JrIFN0cmF0ZWd5IGZvciBuZXh0IGdlbmVyYXRpb24g SW50ZXJuZXQuIChDRVJORVQpDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQpEcmFmdCBBZ2VuZGEgYnV0IG5vdCB5ZXQgZmluYWxpemVkOg0KIA0K RmViLiAyN3RoDQrvvJxNb3JuaW5nIFNlc3Npb27vvJ7jgIDjgIDjgIDjgIBDaGFpcjogUHJvZi4g SGVxdWFuIFd1IChDaGllZiBTY2llbnRpc3Qgb2YgQ05HSSBFeHBlcnRzIENvbW1pc3Npb24pDQo5 OjAwLTk6MzAgICAgT3BlbmluZyBBZGRyZXNzDQogICAgICAgICAgICAgRHIuIEhlcXVhbiBXdSAg KENoaWVmIFNjaWVudGlzdCBvZiBDTkdJIEV4cGVydHMgQ29tbWlzc2lvbikNCjk6MzAtMTA6MDAg ICBNb2JpbGl0eSBpbiBJUHY0OiBUZWNobm9sb2d5IGFuZCBEZXBsb3ltZW50LCBhbmQgb3RoZXIg bmV3IHRyZW5kcyBvZiBuZXR3b3JrLg0KICAgICAgICAgICAgIE1yLiBIZW5yaWsgTGV2a293ZXR6 IChDaGFpciBvZiBNSVA0IFdHIGluIElFVEYpDQoxMDowMC0xMDozMCAgSW52aXRlZCBzcGVha2Vy IGZvcm0gTlNGIG9mIFVTQQ0KICAgICAgICAgICAgIE1yLiAoSW52aXRlZCBieSBDRVJORVQpDQox MDozMC0xMDo0MCAgIO+8nCAgQ29mZmVlIEJyZWFrIO+8ng0KMTA6NDAtMTE6MTAgIE5ldyBUcmVu ZCBvZiBOZXh0IEdlbmVyYXRpb24gSW50ZXJuZXQgb2YgQ2hpbmEgVW5pY29tLg0KICAgICAgICAg ICAgIERyLiBZdW5qaWUgTGl1IChQcmUtQ1RPIG9mIENoaW5hIFVuaWNvbSkNCjExOjEwLTExOjQw ICBEb2NvbW8gTmV4dCBHZW5lcmF0aW9uIEFsbCBJUCBuZXR3b3JrDQogICAgICAgICAgICAgTXIu IE1hc2FtaSBZYWJ1c2FraSAoRGlyZWN0b3Igb2YgQWxsLUlQIG5ldHdvcmsgZGV2ZWxvcG1lbnQg YW5kIHN0YW5kYXJkaXphdGlvbiwgRG9Db01vKQ0KICAgICAgICANCu+8nCBMdW5jaCDvvJ4NCjEy OjIwLTE0OjAwICANCu+8nEFmdGVybm9vbiBTZXNzaW9u77yeICAgICAgIENoYWlyOiBHb3BhbCBE b21tZXR5IChWaWNlIENoYWlybWFuIG9mIE1JUDYgV0cpDQoxNDowMC0xNDozMCAgQ0VSTkVUMg0K ICAgICAgICAgICAgIE1yLiAgICggQ0VSTkVUKQ0KMTQ6MzAtMTU6MDAgIC4uIFdHIGluIElFVEYN CiAgICAgICAgICAgICBNci4gIChJRVRGKSANCjE1OjAwLTE1OjIwICAg77ycICBDb2ZmZWUgQnJl YWsg77yeDQoxNToyMC0xNTo1MCAgTmV3IFRyZW5kIG9mIE5leHQgR2VuZXJhdGlvbiBJbnRlcm5l dCBvZiBDaGluYSBUZWxlY29tLg0KICAgICAgICAgICAgIE1yLiAoQ2hpbmEgVGVsZWNvbSkNCjE1 OjUwLTE2OjIwICBGaXhlZCBhbmQgTW9iaWxlIGNvbnZlcmdlbmNlDQogICAgICAgICAgICAgRHIu ICAoSGl0YWNoaSkNCjE2OjIwLTE2OjUwICBJVFUgYW5kIElFVEYgcmVsYXRpb25zaGlwDQogICAg ICAgICAgICAgTXMuICAoSVRVKSAoTGluZ3RhbywgSmlhbmcpDQoxNjo1MC0xNzoyMCAgTmV0d29y ayBUcmVuZA0KICAgICAgICAgICAgIE1zLiAoSW52aXRlZCBieSBDRVJORVQpDQoxNzoyMC0xODow MCAgM0dQUDIgSU1TDQogICAgICAgICAgICAgTXMuIFlhbiBMaSAoUXVhbGNvbW0pDQo8QmFucXVl dD4gICAgMTg6MjAtMjA6MDANCkZlYi4gMjh0aA0K77ycTW9ybmluZyBTZXNzaW9u77ye44CA44CA 44CA44CAQ2hhaXI6IFByb2YuWmlxaWFuZyBIb3UgKENoaWVmIEFkdmlzb3Igb2YgQ2hpbmEgTmV0 Y29tKQ0KOTowMC05OjMwICAgIElFRUUgODAyLjE2IGFuZCBIdWF3ZWkNCiAgICAgICAgICAgIE1y LiBQaGlsbGlwIEJhcmJlciAgKENoYWlyIG9mIE5FVE1BTiwgSUVFRSA4MDIuMTYpDQo5OjMwLTEw OjAwICAgTW9iaWxlIElQdjYgaW4gSUVURg0KICAgICAgICAgICAgRHIuIEdvcGFsIERvbW1ldHkg KENvLUNoYWlyIG9mIE1JUDYgV0cgaW4gSUVURiwgQ2lzY28pIA0KMTA6MDAtMTA6MzAgIEludml0 ZWQgc3BlYWtlciBmb3JtIENoaW5hIEFjYWRlbXkgb2YgU2NpZW5jZQ0KICAgICAgICAgICAgIE1y Lg0KMTA6MzAtMTA6NDAgICDvvJwgIENvZmZlZSBCcmVhayDvvJ4NCjEwOjQwLTExOjEwICBOZXcg VHJlbmQgb2YgTmV4dCBHZW5lcmF0aW9uIEludGVybmV0IG9mIENoaW5hIE1vYmlsZS4NCiAgICAg ICAgICAgICBNcy4gKENoaW5hIE1vYmlsZSkNCjExOjEwLTExOjQwICBJRUVFIDgwMi4yMSBXRw0K ICAgICAgICAgICAgIERyLiBBamF5IFJhamt1bWFyIChMdWNlbnQpDQoxMDozMC0xMTowMCAgTmV3 IFRyZW5kIG9mIE5leHQgR2VuZXJhdGlvbiBJbnRlcm5ldCBvZiBDaGluYSBOZXRjb20uDQogICAg ICAgICAgICAgTXMuIChDaGluYSBOZXRjb20pDQoNCu+8nEFmdGVybm9vbiBTZXNzaW9u77yeICBE aXJlY3RvciBvZiBDRVJORVQsIERyLiBKaWFucGluZyBXdQ0KIEZvcnVtIGFuZCBWaXNpdCBDRVJO RVQyDQogIEFsbCBJbnZpdGVkIFNwZWFrZXJzOg0KICBUb3BpY3M6IE5ldyBUcmVuZCBvZiBOZXh0 IEdlbmVyYXRpb24gSW50ZXJuZXQNCkNsb3NpbmcgQWRkcmVzcw0KIA0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQpQbGVhc2UgYWxsb3cgdXMg dG8gaW50cm9kdWNlIENOR0kgaGVyZSwNCiANClRoZSBDTkdJIChDaGluYSBOZXh0IEdlbmVyYXRp b24gSW50ZXJuZXQgUHJvamVjdCkgd2FzIHN0YXJ0ZWQgaW4gMjAwMy4gSXQgd2lsbCAgY29uc3Ry dWN0IGEgYmlnIElQdjYgbmV0d29yayBieSB0aGUgZW5kIG9mIDIwMDUgdGhhdCB3aWxsIGNvdmVy IHdob2xlIGNvdW50cnksIDIwKyAgY2l0aWVzLCAzOSBjb3JlIG5vZGVzLCBhbmQgMzAwKyBhY2Nl c3Mgbm9kZXMuIFRoZW4gQ2hpbmEgbWF5IGJlY29tZSBhIGNvdW50cnkgdGhhdCAgaGFzIHRoZSBs YXJnZXN0IElQdjYgbmV0d29yay4gVGhlIENOR0kgcHJvamVjdCBpcyBsZWFkZWQgYnkgc3RhdGUg YWRtaW5pc3RyYXRpb25zLiAgVGhleSBhcmUgTmF0aW9uYWwgRGV2ZWxvcG1lbnQgYW5kIFJlZm9y bSBDb21taXNzaW9uIChORFJDKSx0aGUgTWluaXN0cnkgb2YgU2NpZW5jZSAgYW5kIFRlY2hub2xv Z3kgKE1PU1QpLCB0aGUgTWluaXN0cnkgb2YgRWR1Y2F0aW9uIChNT0UpLCB0aGUgTWluaXN0cnkg b2YgSW5mb3JtYXRpb24gIEluZHVzdHJ5IChNSUkpLCB0aGUgU3RhdGUgQ291bmNpbCBJbmZvcm1h dGl6YXRpb24gT2ZmaWNlLCB0aGUgQ2hpbmVzZSBBY2FkZW15IG9mICBTY2llbmNlcyAoQ0FTKSwg dGhlIENoaW5lc2UgQWNhZGVteSBvZiBFbmdpbmVlcmluZyAoQ0FFKSBhbmQgdGhlIE5hdGlvbmFs IE5hdHVyYWwgIFNjaWVuY2UgRm91bmRhdGlvbiBvZiBDaGluYSAoTlNGQykuIA0KIA0KVG8gYmUg dGhlIHBhcnQgb2YgQ05HSSBwcm9qZWN0LCB0aGUgdGVsZWNvbSBvcGVyYXRvcnMsIHdobyBpbmNs dWRlIENoaW5hIFRlbGVjb20sICBDaGluYSBVbmljb20sIENoaW5hIE5ldGNvbSwgQ2hpbmEgTW9i aWxlIGFuZCBDaGluYSBSYWlsY29tLCBhbG9uZyB3aXRoIHRoZSBhY2FkZW1pYyAgbmV0d29yayBD RVJORVQgYW5kIENTVE5FVCwgYXJlIHJlc3BvbnNpYmxlIGZvciBjb25zdHJ1Y3RpbmcgdGhlaXIg b3duIElQdjYgY29yZSAgbmV0d29ya3MuIFRoZSBDTkdJIG5ldHdvcmsgc3dpdGNoIGNlbnRlcnMg bG9jYXRlZCBpbiBCZWlqaW5nIGFuZCBTaGFuZ2hhaSB3aWxsICBjb25uZWN0IGFib3ZlIElQdjYg Y29yZSBuZXR3b3JrcyBhbmQgaW50ZXItd29ya2luZyB3aXRoIGludGVybmF0aW9uYWwgSVB2NiB0 cmFpbCAgbmV0d29ya3MuIC4gDQogDQpUaGUgQ05HSSBFeHBlcnQgQ29tbWlzc2lvbiB3YXMgZXN0 YWJsaXNoZWQgdG8gbWFuYWdlIHRoZSBwcm9qZWN0LCBhbmQgdGVsZWNvbSAgb3BlcmF0b3JzLCBt YW51ZmFjdHVyZXMgYW5kIHJlc2VhcmNoIGluc3RpdHV0ZXMgaGF2ZSBqb2luZWQgdGhlIGVmZm9y dC4gQ05HSSBFeHBlcnQgIENvbW1pc3Npb24gaGFzIHRocmVlIHN1YiB3b3JraW5nIGdyb3Vwczog dGhlIENOR0kgTmV0d29yayBDb25zdHJ1Y3Rpb24gV29ya2luZyAgR3JvdXAsIHRoZSBOZXR3b3Jr IEFwcGxpY2F0aW9uIGFuZCBTZXJ2aWNlIFdvcmtpbmcgR3JvdXAgYW5kIHRoZSBOZXR3b3JrIFIm RCBhbmQgIEluZHVzdHJpYWxpemF0aW9uIFdvcmtpbmcgR3JvdXAuIA0KIA0KQ0VSTkVUMiAoTmV4 dCBHZW5lcmF0aW9uIEVkdWNhdGlvbiBhbmQgUmVzZWFyY2ggTmV0d29yayBpbiBDaGluYSkgaXMg dGhlIGJpZ2dlc3QgIE5hdGl2ZSBJUHY2IG5ldHdvcmsgYXJvdW5kIHRoZSB3b3JsZCB3aGljaCBj b25uZWN0IDEwMCsgVW5pdmVyc2l0aWVzIGFuZCAxMDArICBSZXNlYXJjaCBJbnN0aXR1dGVzIGF0 IDFHYnBzKyANCkNoaW5hIE1vYmlsZTogICAgTW9iaWxlIE9wZXJhdG9yIHdpdGggbGFyZ2VzdCBj YXBhY2l0eSBpbiB0aGUgd29ybGQNCkNoaW5hIFRlbGVjb206ICBNb3N0IHNvdXRoIHBhcnQgb2Yg Q2hpbmEgZml4ZWQgb3BlcmF0b3IgYW5kIG5ldHdvcmsgYWNjZXNzIHByb3ZpZGVyDQpDaGluYSBV bmljb206ICAgTm8uIDMgTW9iaWxlIE9wZXJhdG9yIGFuZCBOby4gMiBDRE1BIG9wZXJhdG9yIHJh bmtlZCBpbiBudW1iZXIgb2YgIHN1YnNjcmliZXIgaW4gdGhlIHdvcmxkDQpDaGluYSBOZXRjb206 ICAgTW9zdCBub3J0aCBwYXJ0IG9mIENoaW5hIGZpeGVkIG9wZXJhdG9yIGFuZCBuZXR3b3JrIGFj Y2VzcyBwcm92aWRlcg0KQ1NUTkVUICAgICAgICAgIChDaGluYSBTY2llbmNlIGFuZCBUZWNobm9s b2d5IE5ldHdvcmspDQpDaGluYSBSYWlsY29tOiAgTmV3IHRlbGVjb20gb3BlcmF0b3IuDQoNCg== Disclaimer: The contents of this e-mail, and its attachments, if any, are confidential and may be protected by law against any unauthorized use. If you have received this e-mail by mistake or have reason to believe that you are not the intended recipient, please notify the sender by reply e-mail as soon as possible and delete it from your computer system immediately thereafter. If you are not the intended recipient, you must not copy this e-mail or attachment or disclose the contents to any other person. While we have made every effort to keep our network virus free, we take no responsibility for any computer virus which might be transferred by way of this e-mail. --===============2139221035== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============2139221035==-- From mip6-bounces@ietf.org Sun Jan 29 12:13:59 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3G7j-0005GV-H7; Sun, 29 Jan 2006 12:13:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3G7h-0005Fl-QZ for mip6@megatron.ietf.org; Sun, 29 Jan 2006 12:13:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12722 for ; Sun, 29 Jan 2006 12:12:13 -0500 (EST) Received: from dns1.tilab.com ([163.162.42.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3GI8-0005mb-3J for mip6@ietf.org; Sun, 29 Jan 2006 12:24:45 -0500 Received: from iowa2k01a.cselt.it ([163.162.242.201]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0ITV0050L6IECB@dns1.cselt.it> for mip6@ietf.org; Sun, 29 Jan 2006 18:13:26 +0100 (MET) Received: from EXC01B.cselt.it ([163.162.4.218]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Sun, 29 Jan 2006 18:13:26 +0100 Date: Sun, 29 Jan 2006 18:13:30 +0100 From: Gerardo Giaretta To: mip6@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.326 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: New version of AAA-HA Goals draft Thread-Index: AcYk91DNzIIkEcJoRmOV0PSn//i38g== Content-class: urn:content-classes:message X-OriginalArrivalTime: 29 Jan 2006 17:13:26.0384 (UTC) FILETIME=[51299700:01C624F7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Subject: [Mip6] New version of AAA-HA Goals draft X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Hi all, a new version of the AAA-HA Goals draft is available at http://www.ietf.org/internet-drafts/draft-ietf-mip6-aaa-ha-goals-01.txt. The draft has been updated based on the bootstrapping solutions defined by the Bootstrapping Design Team.=20 Please provide your comments and feedback. Regards, --Gerardo Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =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=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to=20 MailAdmin@tilab.com. Thank you =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=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jan 31 06:37:25 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3tp7-0007WS-Ja; Tue, 31 Jan 2006 06:37:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3tp6-0007Tw-DC for mip6@megatron.ietf.org; Tue, 31 Jan 2006 06:37:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07727 for ; Tue, 31 Jan 2006 06:35:39 -0500 (EST) Received: from smtp1.clb.oleane.net ([213.56.31.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3tzs-0007oe-CM for mip6@ietf.org; Tue, 31 Jan 2006 06:48:34 -0500 Received: from Pavillonquatre ([194.3.133.88]) by smtp1.clb.oleane.net with ESMTP id k0VBaia2009843 for ; Tue, 31 Jan 2006 12:36:48 +0100 Message-Id: <200601311136.k0VBaia2009843@smtp1.clb.oleane.net> From: "Chantal Ladouce" To: Date: Tue, 31 Jan 2006 12:36:40 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYmWpmdwGmm2Eo/Ruqr2ngpiHOWVw== X-Spam-Score: 0.2 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Subject: [Mip6] International SIP/WiMAX Summit - Paris - France X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1638827948==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============1638827948== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0092_01C62662.FBF86B90" This is a multi-part message in MIME format. ------=_NextPart_000_0092_01C62662.FBF86B90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit More than 500 participants will attend International SIP and the WiMAX Summit next February 21st to 24th in Paris. Registration is still open for both events. The 7th edition of the International SIP conference program is mainly dedicated to IMS architectures and Peer-to-Peer communications: http://www.upperside.fr/sip2006/sip2006intro.htm The 3rd WiMAX Summit is largely devoted to case studies presented by both incumbent and new entrant operators: http://www.upperside.fr/wimax2006/wimax2006intro.htm Close to the conference rooms an exhibition welcomes industrials involved in VoIP and wireless broadband access. ------=_NextPart_000_0092_01C62662.FBF86B90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

More than 500 participants will attend = International = SIP and the WiMAX Summit next February 21st to 24th in = Paris.

        = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;           =

Registration is still open for both = events.

 

The 7th edition of the International SIP = conference program is mainly dedicated to IMS architectures = and Peer-to-Peer communications:

http://www.upperside.fr/sip2006/sip2006intro.htm<= /span>

 

The 3rd WiMAX Summit is largely devoted to case studies presented by both incumbent and new entrant = operators:

http://www.upperside.fr/wimax2006/wimax2006intro.htm<= /a>

 

Close to the conference rooms an exhibition = welcomes industrials involved in VoIP and wireless broadband = access.

 

------=_NextPart_000_0092_01C62662.FBF86B90-- --===============1638827948== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1638827948==-- From mip6-bounces@ietf.org Tue Jan 31 13:29:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F40Fs-0004CE-9u; Tue, 31 Jan 2006 13:29:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F40Fm-0004B3-44; Tue, 31 Jan 2006 13:29:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15820; Tue, 31 Jan 2006 13:27:46 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F40Qn-00071U-LT; Tue, 31 Jan 2006 13:40:45 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1F40Ff-0001Bb-89; Tue, 31 Jan 2006 13:29:15 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Tue, 31 Jan 2006 13:29:15 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: mip6 chair , mip6 mailing list , Internet Architecture Board , mip6 chair , RFC Editor Subject: [Mip6] Protocol Action: 'Securing Mobile IPv6 Route Optimization Using a Static Shared Key' to Proposed Standard X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org The IESG has approved the following document: - 'Securing Mobile IPv6 Route Optimization Using a Static Shared Key ' as a Proposed Standard This document is the product of the Mobility for IPv6 Working Group. The IESG contact persons are Margaret Wasserman and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-precfgkbm-04.txt Technical Summary A mobile node and a correspondent node may preconfigure data useful for precomputing a Binding Management Key that can subsequently be used for authorizing Binding Updates. Working Group Summary This is a Mobile IP version 6 (MIP6) WG work item. Protocol Quality Jari Arkko provided a very helpful IETF LC review of this document. The document was reviewed for the IESG by Margaret Wasserman _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6