From mip4-bounces@ietf.org Tue Aug 01 07:38:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7sa6-0007pg-Oo; Tue, 01 Aug 2006 07:38:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7sa5-0007nS-45 for mip4@ietf.org; Tue, 01 Aug 2006 07:38:37 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7sa3-00045h-QI for mip4@ietf.org; Tue, 01 Aug 2006 07:38:37 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 118AD4F0213; Tue, 1 Aug 2006 13:38:35 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Aug 2006 13:38:34 +0200 Received: from [147.214.26.80] ([147.214.26.80]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Aug 2006 13:38:34 +0200 Message-ID: <44CF3D39.7020606@ericsson.com> Date: Tue, 01 Aug 2006 13:38:33 +0200 From: =?ISO-8859-1?Q?Eva_Fogelstr=F6m?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko References: <44C78DF3.30405@piuha.net> In-Reply-To: <44C78DF3.30405@piuha.net> X-OriginalArrivalTime: 01 Aug 2006 11:38:34.0286 (UTC) FILETIME=[0558BCE0:01C6B55F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.6 (/) X-Scan-Signature: fca7d4b87f391aa4d413f865ce6efe79 Cc: mip4@ietf.org Subject: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1028704286==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============1028704286== Content-Type: multipart/alternative; boundary="------------080402080106070009060504" This is a multi-part message in MIME format. --------------080402080106070009060504 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Jari, Comments inline. Jari Arkko wrote: >Eva and others, > >I have performed my AD review on this draft. Overall, its >ready for publication as Experimental. However, there are >two technical issues and a few other nits that I would like >to discuss before submission to the IESG. > > > >> A domain that supports regional registrations SHOULD also be >> backwards compatible. >> >> If a FA only advertises an all-ones care-of address (i.e. for dynamic >> GFA assignment), it will not be backwards compatible with [RFC3344], >> since the MNs and HAs will also be required to support the regional >> registration extensions defined in this document. >> >> > >This seems to suggest a model where those who employ this >mechanism may end up preventing regular Mobile IP clients >from getting service. I do not see why we would have to make this >so. I wonder if it would be better to require both a regular address >and gateway address (possibly all-ones) to be advertised? You could >still require that mobile nodes compliant to reg-tunnel use >dynamic assignment. > > Yes. I believe the original intention was to support FAs with private addresses in regional registrations. However, unless someone has a real need for this feature, we can skip it and instead make it so that regular MIP4 clients can always get service, according to your suggestion. Comments? > > >> When a MN moves to a new domain (determined by comparing its NAI with >> the FA-NAI included in received Agent Advertisements), it can opt to >> use Regional Registrations. >> >> > > > >> If the MN receives an Agent Advertisement with the care-of address >> field indicating the GFA set to all-ones, and if the MN determines >> that it is within the same visited domain as when it did its last >> home registration, it MAY send a Regional Registration Request to its >> current GFA. Otherwise, it MUST send a Registration Request to its >> HA as described in Section 7.1. >> >> > > > >> Upon receipt of an Agent Advertisement message with the 'I' flag set >> and a FA-NAI extension, the MN compares the domain part of the FA NAI >> with the domain part of its own NAI, to determine whether it is in >> its home domain or in a visited domain. If the NAIs do not match, >> the MN MUST assume it is in a foreign domain. Otherwise, if the MN >> determines that it is in its home domain, it acts as defined in >> [RFC3344]. >> >> > >This process produces two bits as output: > >1) Did we move? >2) Are we in the home domain? > >I see a lot of value in determining 1. But is there a value in determining >2? Does this imply that you can not use regional registrations within >the home domain? Do we want or need to prevent that? > > The draft specifies regional registrations in visited domains, but we could update it to support regional registrations in the home domain as well. I see no particular reason to prevent it. > > >> Registration denied by the GFA: >> >> +---------------------+-------+---------------------+ >> | Error Name | Value | Section of Document | >> +---------------------+-------+---------------------+ >> | REPLAY_PROT_UNAVAIL | TBD | Section 5.3 | >> | ZERO_COA_NOT_SUPP | TBD | Section 7.3 | >> +---------------------+-------+---------------------+ >> >> Registration denied by the HA (for dynamic GFA assignment): >> >> +---------------------+-------+---------------------+ >> | Error Name | Value | Section of Document | >> +---------------------+-------+---------------------+ >> | ZERO_CAREOF_ADDRESS | TBD | Section 7.4 | >> | ZERO_COA_NOT_SUPP | TBD | Section 7.4 | >> +---------------------+-------+---------------------+ >> >> > >ZERO_COA_NOT_SUPP appears twice, but presumably this >is the same value? If yes, please clarify so that neither IANA >or readers will get confused. > > Yes. I'll clarify. > > >> If the >> 'I' flag is set, and there are multiple care-of addresses, the first >> care-of address is the local FA, and the last care-of address is the >> GFA. >> >> > >Hmm... this seems to specify only the role of the first and the last >address. What about the rest? > > This draft only specifies the first and the last. Anything in between is out of scope. I'll clarify. The editorial comments I'll take care of when updating the draft. Eva >Nits: > > > >> - The document seems to lack the recommended RFC 2119 boilerplate, even if >> it appears to use RFC 2119 keywords -- however, there's a paragraph with a >> matching beginning. Boilerplate error? >> >> >> >> >Warning from idnits. > > > >> - Unused Reference: 'RFC2486' is defined on line 1345, but not referenced >> >> >> >Another idnits warning. > >Also, if you want to refer to RFC 2486, it has been obsoleted by RFC 4282. >So use 4282 if you need it. > >The document talks about NAIs, so I would assume that a reference is >needed. > > > >> to be protected by a MN-FA Authenticaion extension. >> >> > >Typo. > >--Jari > > > --------------080402080106070009060504 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jari,

Comments inline.

Jari Arkko wrote: 
Eva and others,

I have performed my AD review on this draft. Overall, its
ready for publication as Experimental. However, there are
two technical issues and a few other nits that I would like
to discuss before submission to the IESG.

  
   A domain that supports regional registrations SHOULD also be
   backwards compatible.

   If a FA only advertises an all-ones care-of address (i.e. for dynamic
   GFA assignment), it will not be backwards compatible with [RFC3344],
   since the MNs and HAs will also be required to support the regional
   registration extensions defined in this document.
    

This seems to suggest a model where those who employ this
mechanism may end up preventing regular Mobile IP clients
from getting service. I do not see why we would have to make this
so. I wonder if it would be better to require both a regular address
and gateway address (possibly all-ones) to be advertised? You could
still require that mobile nodes compliant to reg-tunnel use
dynamic assignment.
Yes. I believe the original intention was to support FAs with private addresses in regional registrations. However, unless someone has a real need for this feature, we can skip it and instead make it so that regular MIP4 clients can always get service, according to your suggestion. Comments? 
  
   When a MN moves to a new domain (determined by comparing its NAI with
   the FA-NAI included in received Agent Advertisements), it can opt to
   use Regional Registrations. 
    

  
   If the MN receives an Agent Advertisement with the care-of address
   field indicating the GFA set to all-ones, and if the MN determines
   that it is within the same visited domain as when it did its last
   home registration, it MAY send a Regional Registration Request to its
   current GFA.  Otherwise, it MUST send a Registration Request to its
   HA as described in Section 7.1.
    

  
   Upon receipt of an Agent Advertisement message with the 'I' flag set
   and a FA-NAI extension, the MN compares the domain part of the FA NAI
   with the domain part of its own NAI, to determine whether it is in
   its home domain or in a visited domain.  If the NAIs do not match,
   the MN MUST assume it is in a foreign domain.  Otherwise, if the MN
   determines that it is in its home domain, it acts as defined in
   [RFC3344].
    

This process produces two bits as output:

1) Did we move?
2) Are we in the home domain?

I see a lot of value in determining 1. But is there a value in determining
2? Does this imply that you can not use regional registrations within
the home domain? Do we want or need to prevent that?
The draft specifies regional registrations in visited domains, but we could update it to support regional registrations in the home domain as well. I see no particular reason to prevent it. 
  
                      Registration denied by the GFA:

           +---------------------+-------+---------------------+
           | Error Name          | Value | Section of Document |
           +---------------------+-------+---------------------+
           | REPLAY_PROT_UNAVAIL | TBD   | Section 5.3         |
           | ZERO_COA_NOT_SUPP   | TBD   | Section 7.3         |
           +---------------------+-------+---------------------+

        Registration denied by the HA (for dynamic GFA assignment):

           +---------------------+-------+---------------------+
           | Error Name          | Value | Section of Document |
           +---------------------+-------+---------------------+
           | ZERO_CAREOF_ADDRESS | TBD   | Section 7.4         |
           | ZERO_COA_NOT_SUPP   | TBD   | Section 7.4         |
           +---------------------+-------+---------------------+
    

ZERO_COA_NOT_SUPP appears twice, but presumably this
is the same value? If yes, please clarify so that neither IANA
or readers will get confused.
Yes. I'll clarify.
  
   If the
   'I' flag is set, and there are multiple care-of addresses, the first
   care-of address is the local FA, and the last care-of address is the
   GFA.
    

Hmm... this seems to specify only the role of the first and the last
address. What about the rest?
This draft only specifies the first and the last. Anything in between is out of scope. I'll clarify.

The editorial comments I'll take care of when updating the draft.

Eva

Nits:

  
 - The document seems to lack the recommended RFC 2119 boilerplate, even if
   it appears to use RFC 2119 keywords -- however, there's a paragraph with a
   matching beginning. Boilerplate error?
 

    
Warning from idnits.

  
 - Unused Reference: 'RFC2486' is defined on line 1345, but not referenced

    
Another idnits warning.

Also, if you want to refer to RFC 2486, it has been obsoleted by RFC 4282.
So use 4282 if you need it.

The document talks about NAIs, so I would assume that a reference is
needed.

  
   to be protected by a MN-FA Authenticaion extension.
    

Typo.

--Jari
--------------080402080106070009060504-- --===============1028704286== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1028704286==-- From mip4-bounces@ietf.org Tue Aug 01 10:17:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7v3n-0004uu-OI; Tue, 01 Aug 2006 10:17:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7v3m-0004ul-KW for mip4@ietf.org; Tue, 01 Aug 2006 10:17:26 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7v3l-0006IH-9H for mip4@ietf.org; Tue, 01 Aug 2006 10:17:26 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k71EHMVn011157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 1 Aug 2006 07:17:22 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k71EHLkS021622; Tue, 1 Aug 2006 07:17:21 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Aug 2006 07:17:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt Date: Tue, 1 Aug 2006 07:17:18 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A0CC85D@NAEX14.na.qualcomm.com> In-Reply-To: <44CF3D39.7020606@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt Thread-Index: Aca1XzzDqt57TtsfTZmdX83FlMBKoQAFUDZQ From: "Tsirtsis, George" To: =?iso-8859-1?Q?Eva_Fogelstr=F6m?= , "Jari Arkko" X-OriginalArrivalTime: 01 Aug 2006 14:17:20.0338 (UTC) FILETIME=[3350EB20:01C6B575] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org ________________________________________ From: Eva Fogelstr=F6m [mailto:eva.fogelstrom@ericsson.com]=20 Sent: Tuesday, August 01, 2006 7:39 AM To: Jari Arkko Cc: mip4@ietf.org Subject: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt Hi Jari, Comments inline. Jari Arkko wrote:=20 Eva and others, I have performed my AD review on this draft. Overall, its ready for publication as Experimental. However, there are two technical issues and a few other nits that I would like to discuss before submission to the IESG. =20 A domain that supports regional registrations SHOULD also be backwards compatible. If a FA only advertises an all-ones care-of address (i.e. for dynamic GFA assignment), it will not be backwards compatible with [RFC3344], since the MNs and HAs will also be required to support the regional registration extensions defined in this document. =20 This seems to suggest a model where those who employ this mechanism may end up preventing regular Mobile IP clients from getting service. I do not see why we would have to make this so. I wonder if it would be better to require both a regular address and gateway address (possibly all-ones) to be advertised? You could still require that mobile nodes compliant to reg-tunnel use dynamic assignment. =20 Yes. I believe the original intention was to support FAs with private = addresses in regional registrations. However, unless someone has a real = need for this feature, we can skip it and instead make it so that = regular MIP4 clients can always get service, according to your = suggestion. Comments?=20 GT> Is this really about private addresses? Or is it about dynamic GFA = assignment? I think dynamic GFA assignment is purely defined in this = document so cleaning it out might be a good idea. We can define dynamic = GFAs in a separate draft if there is still interest. George =20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Aug 01 18:52:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G836I-0006fE-P2; Tue, 01 Aug 2006 18:52:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G836H-0006Yo-C3 for mip4@ietf.org; Tue, 01 Aug 2006 18:52:33 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G836D-0004np-DB for mip4@ietf.org; Tue, 01 Aug 2006 18:52:33 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 01 Aug 2006 15:52:25 -0700 X-IronPort-AV: i="4.07,203,1151910000"; d="scan'208,217"; a="1843489700:sNHT104774038" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k71MqOa5001843; Tue, 1 Aug 2006 15:52:24 -0700 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 k71MqLBk027058; Tue, 1 Aug 2006 15:52:23 -0700 (PDT) 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.1830); Tue, 1 Aug 2006 15:52:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt Date: Tue, 1 Aug 2006 15:52:20 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC5202420E16@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt Thread-Index: Aca1XzdPUnkxpf/KTCa0j+MGJwYWPgAWYdRQ From: "Kent Leung \(kleung\)" To: =?iso-8859-1?Q?Eva_Fogelstr=F6m?= , "Jari Arkko" X-OriginalArrivalTime: 01 Aug 2006 22:52:23.0081 (UTC) FILETIME=[26C94990:01C6B5BD] DKIM-Signature: a=rsa-sha1; q=dns; l=5574; t=1154472744; x=1155336744; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kleung@cisco.com; z=From:=22Kent=20Leung=20\(kleung\)=22=20 |Subject:RE=3A=20[Mip4]=20Re=3A=20AD=20review=20of=20draft-ietf-mip4-reg-tunnel-0 2.txt; X=v=3Dcisco.com=3B=20h=3DrbmpMSlDp7Jv1D+lIJ6fwDoKwrQ=3D; b=FilJuH/2P9Zq/ZjcsoZKR2HHXuMTKtli5Amj+5DxVVpQl2JJH9wYRC62VtqSxl+yeeWr04jN jnyhhtnfJCf4q4bXjvZJ1UlGuvKSubuCM1u5fXJ5z41t3gxmo7X4PRIG; Authentication-Results: sj-dkim-6.cisco.com; header.From=kleung@cisco.com; dkim=pass ( 45 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0359374473==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============0359374473== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6B5BD.2694836D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6B5BD.2694836D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Eva. Comments below. ________________________________ From: Eva Fogelstr=F6m [mailto:eva.fogelstrom@ericsson.com]=20 Sent: Tuesday, August 01, 2006 4:39 AM To: Jari Arkko Cc: mip4@ietf.org Subject: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt =09 =09 =20 This seems to suggest a model where those who employ this mechanism may end up preventing regular Mobile IP clients from getting service. I do not see why we would have to make this so. I wonder if it would be better to require both a regular address and gateway address (possibly all-ones) to be advertised? You could still require that mobile nodes compliant to reg-tunnel use dynamic assignment. Yes. I believe the original intention was to support FAs with private = addresses in regional registrations. However, unless someone has a real = need for this feature, we can skip it and instead make it so that = regular MIP4 clients can always get service, according to your = suggestion. Comments?=20 =09 [Kent Leung (kleung)] FAs with private addresses (CoA) can still be = supported via RFC 3519. In this case, it's no different than the scenario covered in that RFC. BTW, this = assumes that the MN is smart enough to use the FA's private or public CoA instead of the all 1's CoA = received from the Agent Advertisement. :) =20 Couple of other clarifications seeked after a quick scan: 1) Is the Hierarchical Foreign Agent Type skippable or non-skippable? 2) Is the Replay Protection Style Type skippable or not? Kent ------_=_NextPart_001_01C6B5BD.2694836D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Eva.  Comments = below.

From: Eva Fogelstr=F6m=20 [mailto:eva.fogelstrom@ericsson.com]
Sent: Tuesday, August = 01, 2006=20 4:39 AM
To: Jari Arkko
Cc:=20 mip4@ietf.org
Subject: [Mip4] Re: AD review of=20 draft-ietf-mip4-reg-tunnel-02.txt

<snip>
 
 This seems to = suggest a model=20 where those who employ this
mechanism may end up preventing regular = Mobile=20 IP clients
from getting service. I do not see why we would have to = make=20 this
so. I wonder if it would be better to require both a regular=20 address
and gateway address (possibly all-ones) to be advertised? = You=20 could
still require that mobile nodes compliant to reg-tunnel=20 use
dynamic assignment.
  Yes. I believe the original = intention was=20 to support FAs with private addresses in regional registrations. = However,=20 unless someone has a real need for this feature, we can skip it and = instead=20 make it so that regular MIP4 clients can always get service, according = to your=20 suggestion. Comments? 

[Kent Leung (kleung)] FAs with private =
addresses (CoA) can still be supported via RFC 3519. In this =
case,
it's no different than the scenario covered in that RFC.  BTW, =
this assumes that the MN is smart enough
to use the FA's private or public CoA instead =
of the all 1's CoA received from the Agent Advertisement. =
:)
 
Couple of other clarifications seeked after a quick =
scan:
1)  Is the Hierarchical Foreign Agent Type skippable or =
non-skippable?
2) Is the Replay Protection Style Type skippable or =
not?
Kent
= ------_=_NextPart_001_01C6B5BD.2694836D-- --===============0359374473== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0359374473==-- From mip4-bounces@ietf.org Tue Aug 01 19:01:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G83Ep-0006yj-Jj; Tue, 01 Aug 2006 19:01:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G83Eo-0006x0-Ts for mip4@ietf.org; Tue, 01 Aug 2006 19:01:22 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G83Em-0006iH-8g for mip4@ietf.org; Tue, 01 Aug 2006 19:01:22 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 01 Aug 2006 16:01:19 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k71N1JXn026390; Tue, 1 Aug 2006 16:01:19 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k71N1IJk009042; Tue, 1 Aug 2006 16:01:19 -0700 (PDT) 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.1830); Tue, 1 Aug 2006 16:01:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt Date: Tue, 1 Aug 2006 16:01:17 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC5202420E1E@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt Thread-Index: Aca1XzzDqt57TtsfTZmdX83FlMBKoQAFUDZQABJB1NA= From: "Kent Leung \(kleung\)" To: "Tsirtsis, George" , =?iso-8859-1?Q?Eva_Fogelstr=F6m?= , "Jari Arkko" X-OriginalArrivalTime: 01 Aug 2006 23:01:18.0611 (UTC) FILETIME=[65FCAE30:01C6B5BE] DKIM-Signature: a=rsa-sha1; q=dns; l=2819; t=1154473279; x=1155337279; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kleung@cisco.com; z=From:=22Kent=20Leung=20\(kleung\)=22=20 |Subject:RE=3A=20[Mip4]=20Re=3A=20AD=20review=20of=20draft-ietf-mip4-reg-tunnel-0 2.txt; X=v=3Dcisco.com=3B=20h=3D9A5XdqoiBEsGyhceXM7zD4hW388=3D; b=OZjx6oBjhmgFf9jKBXgQAu0FMy7MWLIc19Qn9ppgfGOC5DaSeu0aX2yZAM+nNu02VnUGAzj/ D4qPFa/F4wwOuaAAPtGbd/VjrwY2bq8JV86MuzM41qmLokDTdOpGmrIm; Authentication-Results: sj-dkim-2.cisco.com; header.From=kleung@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org I assume that dynamic GFA scheme is completely optional. As long as GFA = is known in the Visited Domain (by some mechanism), it can be advertised = by the FA in the CoA field. Kent=20 > -----Original Message----- > From: Tsirtsis, George [mailto:tsirtsis@qualcomm.com]=20 > Sent: Tuesday, August 01, 2006 7:17 AM > To: Eva Fogelstr=F6m; Jari Arkko > Cc: mip4@ietf.org > Subject: RE: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt >=20 >=20 >=20 > ________________________________________ > From: Eva Fogelstr=F6m [mailto:eva.fogelstrom@ericsson.com] > Sent: Tuesday, August 01, 2006 7:39 AM > To: Jari Arkko > Cc: mip4@ietf.org > Subject: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt >=20 > Hi Jari, >=20 > Comments inline. >=20 > Jari Arkko wrote:=20 > Eva and others, >=20 > I have performed my AD review on this draft. Overall, its=20 > ready for publication as Experimental. However, there are two=20 > technical issues and a few other nits that I would like to=20 > discuss before submission to the IESG. >=20 > =20 > A domain that supports regional registrations SHOULD also be > backwards compatible. >=20 > If a FA only advertises an all-ones care-of address (i.e.=20 > for dynamic > GFA assignment), it will not be backwards compatible with=20 > [RFC3344], > since the MNs and HAs will also be required to support the regional > registration extensions defined in this document. > =20 >=20 > This seems to suggest a model where those who employ this=20 > mechanism may end up preventing regular Mobile IP clients=20 > from getting service. I do not see why we would have to make=20 > this so. I wonder if it would be better to require both a=20 > regular address and gateway address (possibly all-ones) to be=20 > advertised? You could still require that mobile nodes=20 > compliant to reg-tunnel use dynamic assignment. > =20 > Yes. I believe the original intention was to support FAs with=20 > private addresses in regional registrations. However, unless=20 > someone has a real need for this feature, we can skip it and=20 > instead make it so that regular MIP4 clients can always get=20 > service, according to your suggestion. Comments?=20 >=20 > GT> Is this really about private addresses? Or is it about=20 > dynamic GFA assignment? I think dynamic GFA assignment is=20 > purely defined in this document so cleaning it out might be a=20 > good idea. We can define dynamic GFAs in a separate draft if=20 > there is still interest. >=20 > George =20 >=20 > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Aug 01 22:02:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G863h-0000JU-5G; Tue, 01 Aug 2006 22:02:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G863g-0000JP-Hn for mip4@ietf.org; Tue, 01 Aug 2006 22:02:04 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G863e-0008At-3D for mip4@ietf.org; Tue, 01 Aug 2006 22:02:04 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k7221wCx027117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 1 Aug 2006 19:01:59 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7221vQA021154; Tue, 1 Aug 2006 19:01:57 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Aug 2006 19:01:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt Date: Tue, 1 Aug 2006 19:02:02 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A0CC947@NAEX14.na.qualcomm.com> In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC5202420E1E@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt Thread-Index: Aca1XzzDqt57TtsfTZmdX83FlMBKoQAFUDZQABJB1NAABiLl0A== From: "Tsirtsis, George" To: "Kent Leung \(kleung\)" , =?iso-8859-1?Q?Eva_Fogelstr=F6m?= , "Jari Arkko" X-OriginalArrivalTime: 02 Aug 2006 02:01:57.0025 (UTC) FILETIME=[A22F6910:01C6B5D7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org It is not clear that dynamic GFAs is entirely optional, at least from = the mobile's perspective. For static GFA the MN must somehow know the = GFA address (presumably from the FAA) before it can send the = registration request message. If the FAA includes an all 1s GFA address = then, I suppose the mobile must use the dynamic GFA procedure....does it = have a choice? BTW, In my earlier e-mail I misspoke. I DID NOT mean to say that the = dynamic GFA model should be removed from the draft. The draft implies = that a multiple level hierarchy (multiple hierarchical GFAs) can be = supported but it does not provide any details. It is this part that I = think should be removed from this version of the spec.=20 George > -----Original Message----- > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > Sent: Tuesday, August 01, 2006 7:01 PM > To: Tsirtsis, George; Eva Fogelstr=F6m; Jari Arkko > Cc: mip4@ietf.org > Subject: RE: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt >=20 > I assume that dynamic GFA scheme is completely optional. As long as = GFA > is known in the Visited Domain (by some mechanism), it can be = advertised > by the FA in the CoA field. >=20 > Kent >=20 > > -----Original Message----- > > From: Tsirtsis, George [mailto:tsirtsis@qualcomm.com] > > Sent: Tuesday, August 01, 2006 7:17 AM > > To: Eva Fogelstr=F6m; Jari Arkko > > Cc: mip4@ietf.org > > Subject: RE: [Mip4] Re: AD review of = draft-ietf-mip4-reg-tunnel-02.txt > > > > > > > > ________________________________________ > > From: Eva Fogelstr=F6m [mailto:eva.fogelstrom@ericsson.com] > > Sent: Tuesday, August 01, 2006 7:39 AM > > To: Jari Arkko > > Cc: mip4@ietf.org > > Subject: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt > > > > Hi Jari, > > > > Comments inline. > > > > Jari Arkko wrote: > > Eva and others, > > > > I have performed my AD review on this draft. Overall, its > > ready for publication as Experimental. However, there are two > > technical issues and a few other nits that I would like to > > discuss before submission to the IESG. > > > > > > A domain that supports regional registrations SHOULD also be > > backwards compatible. > > > > If a FA only advertises an all-ones care-of address (i.e. > > for dynamic > > GFA assignment), it will not be backwards compatible with > > [RFC3344], > > since the MNs and HAs will also be required to support the = regional > > registration extensions defined in this document. > > > > > > This seems to suggest a model where those who employ this > > mechanism may end up preventing regular Mobile IP clients > > from getting service. I do not see why we would have to make > > this so. I wonder if it would be better to require both a > > regular address and gateway address (possibly all-ones) to be > > advertised? You could still require that mobile nodes > > compliant to reg-tunnel use dynamic assignment. > > > > Yes. I believe the original intention was to support FAs with > > private addresses in regional registrations. However, unless > > someone has a real need for this feature, we can skip it and > > instead make it so that regular MIP4 clients can always get > > service, according to your suggestion. Comments? > > > > GT> Is this really about private addresses? Or is it about > > dynamic GFA assignment? I think dynamic GFA assignment is > > purely defined in this document so cleaning it out might be a > > good idea. We can define dynamic GFAs in a separate draft if > > there is still interest. > > > > George > > > > -- > > Mip4 mailing list: Mip4@ietf.org > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > Charter page: = http://www.ietf.org/html.charters/mip4-charter.html > > Supplemental site: http://www.mip4.org/ > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Aug 02 00:36:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G88TX-0003VK-RR; Wed, 02 Aug 2006 00:36:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G88TW-0003Sw-KP for mip4@ietf.org; Wed, 02 Aug 2006 00:36:54 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G88TV-00035M-9v for mip4@ietf.org; Wed, 02 Aug 2006 00:36:54 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id B24AB89837; Wed, 2 Aug 2006 07:36:51 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 287278980A; Wed, 2 Aug 2006 07:36:51 +0300 (EEST) Message-ID: <44D02BD7.5060501@piuha.net> Date: Wed, 02 Aug 2006 07:36:39 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060725) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Tsirtsis, George" Subject: Re: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt References: <7EB20EA0938B4D42A2D82689365C9B7A0CC947@NAEX14.na.qualcomm.com> In-Reply-To: <7EB20EA0938B4D42A2D82689365C9B7A0CC947@NAEX14.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: "Kent Leung \(kleung\)" , =?ISO-8859-1?Q?Eva_Fogels?=, mip4@ietf.org, =?ISO-8859-1?Q?tr=F6m?= X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Tsirtsis, George wrote: >It is not clear that dynamic GFAs is entirely optional, at least from the mobile's perspective. For static GFA the MN must somehow know the GFA address (presumably from the FAA) before it can send the registration request message. If the FAA includes an all 1s GFA address then, I suppose the mobile must use the dynamic GFA procedure....does it have a choice? > > I think that was part of what I objected to -- if the FAs are allowed to announce only an all 1s GFA address then it seems that it does not have a choice. But I fail to see why this is necessary. --Jari -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Aug 02 02:55:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8Ae3-0007o5-Q2; Wed, 02 Aug 2006 02:55:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8Ae2-0007j2-DG for mip4@ietf.org; Wed, 02 Aug 2006 02:55:54 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8Ae0-00044a-IK for mip4@ietf.org; Wed, 02 Aug 2006 02:55:54 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8C16CED3; Wed, 2 Aug 2006 08:55:51 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Aug 2006 08:55:51 +0200 Received: from [147.214.26.80] ([147.214.26.80]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Aug 2006 08:55:50 +0200 Message-ID: <44D04C73.1040201@ericsson.com> Date: Wed, 02 Aug 2006 08:55:47 +0200 From: =?ISO-8859-1?Q?Eva_Fogelstr=F6m?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko , "Tsirtsis, George" Subject: Re: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt References: <7EB20EA0938B4D42A2D82689365C9B7A0CC947@NAEX14.na.qualcomm.com> <44D02BD7.5060501@piuha.net> In-Reply-To: <44D02BD7.5060501@piuha.net> X-OriginalArrivalTime: 02 Aug 2006 06:55:50.0556 (UTC) FILETIME=[B096B5C0:01C6B600] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.6 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: "Kent Leung \(kleung\)" , mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1655004740==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============1655004740== Content-Type: multipart/alternative; boundary="------------070403090902000801060201" This is a multi-part message in MIME format. --------------070403090902000801060201 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Ok. Let me clarify this. Jari's objection was that if an FA is allowed to announce an all-ones GFA address only, the MN has no choice but to go along with that, i.e. the MN cannot make a regular MIP4 home registration. True. I believe this was discussed on the list a couple of years ago (2002), when the draft was in WG last call. The idea was that an all-ones address indicates dynamic GFA in the case of home registration, and allows for privately addressed FAs in the case of regional registrations (in which case the FA address itself is not advertised). As I said, I don't mind taking out this type of support for private FA addresses, letting the FA advertise its c/o address to support regular MIP4 home registrations, according to Jari's suggestion. So, unless someone objects, I suggest I do exactly that. Eva Jari Arkko wrote: >Tsirtsis, George wrote: > > > >>It is not clear that dynamic GFAs is entirely optional, at least from the mobile's perspective. For static GFA the MN must somehow know the GFA address (presumably from the FAA) before it can send the registration request message. If the FAA includes an all 1s GFA address then, I suppose the mobile must use the dynamic GFA procedure....does it have a choice? >> >> >> >> >I think that was part of what I objected to -- if the FAs are allowed to >announce >only an all 1s GFA address then it seems that it does not have a choice. >But I >fail to see why this is necessary. > >--Jari > > > --------------070403090902000801060201 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Ok. Let me clarify this. Jari's objection was that if an FA is allowed to announce an all-ones GFA address only, the MN has no choice but to go along with that, i.e. the MN cannot make a regular MIP4 home registration. True.

I believe this was discussed on the list a couple of years ago (2002), when the draft was in WG last call. The idea was that an all-ones address indicates dynamic GFA in the case of home registration, and allows for privately addressed FAs in the case of regional registrations (in which case the FA address itself is not advertised).

As I said, I don't mind taking out this type of support for private FA addresses, letting the FA advertise its c/o address to support regular MIP4 home registrations, according to Jari's suggestion. So, unless someone objects, I suggest I do exactly that.

Eva

Jari Arkko wrote:
Tsirtsis, George wrote:

  
It is not clear that dynamic GFAs is entirely optional, at least from the mobile's perspective. For static GFA the MN must somehow know the GFA address (presumably from the FAA) before it can send the registration request message. If the FAA includes an all 1s GFA address then, I suppose the mobile must use the dynamic GFA procedure....does it have a choice?
 

    
I think that was part of what I objected to -- if the FAs are allowed to
announce
only an all 1s GFA address then it seems that it does not have a choice.
But I
fail to see why this is necessary.

--Jari
--------------070403090902000801060201-- --===============1655004740== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1655004740==-- From mip4-bounces@ietf.org Wed Aug 02 03:01:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8Aj5-0005ja-Mb; Wed, 02 Aug 2006 03:01:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8Aj4-0005jV-EQ for mip4@ietf.org; Wed, 02 Aug 2006 03:01:06 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8Aj2-0004Pp-TC for mip4@ietf.org; Wed, 02 Aug 2006 03:01:06 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 53923F23; Wed, 2 Aug 2006 09:01:04 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Aug 2006 09:01:03 +0200 Received: from [147.214.26.80] ([147.214.26.80]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Aug 2006 09:01:03 +0200 Message-ID: <44D04DAB.1070607@ericsson.com> Date: Wed, 02 Aug 2006 09:00:59 +0200 From: =?ISO-8859-1?Q?Eva_Fogelstr=F6m?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Tsirtsis, George" Subject: Re: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt References: <7EB20EA0938B4D42A2D82689365C9B7A0CC947@NAEX14.na.qualcomm.com> In-Reply-To: <7EB20EA0938B4D42A2D82689365C9B7A0CC947@NAEX14.na.qualcomm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Aug 2006 07:01:03.0034 (UTC) FILETIME=[6AD711A0:01C6B601] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: "Kent Leung \(kleung\)" , mip4@ietf.org, Jari Arkko X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi George, Comments inline. Tsirtsis, George wrote: >It is not clear that dynamic GFAs is entirely optional, at least from the mobile's perspective. For static GFA the MN must somehow know the GFA address (presumably from the FAA) before it can send the registration request message. If the FAA includes an all 1s GFA address then, I suppose the mobile must use the dynamic GFA procedure....does it have a choice? > > See my previous email. >BTW, In my earlier e-mail I misspoke. I DID NOT mean to say that the dynamic GFA model should be removed from the draft. The draft implies that a multiple level hierarchy (multiple hierarchical GFAs) can be supported but it does not provide any details. It is this part that I think should be removed from this version of the spec. > > The multiple levels of hierarchy was already removed in an earlier version of the draft. I'll clarify the text. Eva -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Aug 02 03:32:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8BD7-0005DQ-Kz; Wed, 02 Aug 2006 03:32:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8BD5-0005Co-QH for mip4@ietf.org; Wed, 02 Aug 2006 03:32:07 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8BD3-0006yK-Vs for mip4@ietf.org; Wed, 02 Aug 2006 03:32:07 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1DA646E0001; Wed, 2 Aug 2006 09:32:05 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Aug 2006 09:32:04 +0200 Received: from [147.214.26.80] ([147.214.26.80]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Aug 2006 09:32:04 +0200 Message-ID: <44D054F0.6030403@ericsson.com> Date: Wed, 02 Aug 2006 09:32:00 +0200 From: =?ISO-8859-1?Q?Eva_Fogelstr=F6m?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kent Leung (kleung)" Subject: Re: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt References: <2979E38DD6FC6544B789C8DAD7BAFC5202420E16@xmb-sjc-235.amer.cisco.com> In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC5202420E16@xmb-sjc-235.amer.cisco.com> X-OriginalArrivalTime: 02 Aug 2006 07:32:04.0021 (UTC) FILETIME=[C0132650:01C6B605] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: mip4@ietf.org, Jari Arkko X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0958996601==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============0958996601== Content-Type: multipart/alternative; boundary="------------090502000208030002010004" This is a multi-part message in MIME format. --------------090502000208030002010004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Kent, Comments below. Kent Leung (kleung) wrote: > Hi Eva. Comments below. > > -------------------------------------------------------------------= ----- > *From:* Eva Fogelstr=F6m [mailto:eva.fogelstrom@ericsson.com] > *Sent:* Tuesday, August 01, 2006 4:39 AM > *To:* Jari Arkko > *Cc:* mip4@ietf.org > *Subject:* [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.tx= t > > > =20 > This seems to suggest a model where those who employ this > mechanism may end up preventing regular Mobile IP clients > from getting service. I do not see why we would have to make this > so. I wonder if it would be better to require both a regular addres= s > and gateway address (possibly all-ones) to be advertised? You could > still require that mobile nodes compliant to reg-tunnel use > dynamic assignment. > Yes. I believe the original intention was to support FAs with > private addresses in regional registrations. However, unless > someone has a real need for this feature, we can skip it and > instead make it so that regular MIP4 clients can always get > service, according to your suggestion. Comments? > >>[Kent Leung (kleung)] FAs with private addresses (CoA) can still be sup= ported via RFC 3519. In this case, >> >>it's no different than the scenario covered in that RFC. BTW, this ass= umes that the MN is smart enough >> >>to use the FA's private or public CoA instead of the all 1's CoA receiv= ed from the Agent Advertisement. :) >> >>=20 >> >>Couple of other clarifications seeked after a quick scan: >> >>1) Is the Hierarchical Foreign Agent Type skippable or non-skippable? >> >>2) Is the Replay Protection Style Type skippable or not? >> The draft currently defines the following (IANA Considerations section): - GFA IP address (non-skippable) - Hierarchical FA (skippable) - Replay protection style (skippable) I'll clarify. Eva --------------090502000208030002010004 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Kent,

Comments below.

Kent Leung (kleung) wrote:
Hi Eva.  Comments below.

From: Eva Fogelström [mailto:eva.fogelstrom@ericsson.com]
Sent: Tuesday, August 01, 2006 4:39 AM
To: Jari Arkko
Cc: mip4@ietf.org
Subject: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt

<snip>
 
 This seems to suggest a model where those who employ this
mechanism may end up preventing regular Mobile IP clients
from getting service. I do not see why we would have to make this
so. I wonder if it would be better to require both a regular address
and gateway address (possibly all-ones) to be advertised? You could
still require that mobile nodes compliant to reg-tunnel use
dynamic assignment.
  Yes. I believe the original intention was to support FAs with private addresses in regional registrations. However, unless someone has a real need for this feature, we can skip it and instead make it so that regular MIP4 clients can always get service, according to your suggestion. Comments? 
[Kent Leung (kleung)] FAs with private addresses (CoA) can still be supported via RFC 3519. In this case,
it's no different than the scenario covered in that RFC.  BTW, this assumes that the MN is smart enough
to use the FA's private or public CoA instead of the all 1's CoA received from the Agent Advertisement. :)
 
Couple of other clarifications seeked after a quick scan:
1)  Is the Hierarchical Foreign Agent Type skippable or non-skippable?
2) Is the Replay Protection Style Type skippable or not?

The draft currently defines the following (IANA Considerations section):
- GFA IP address (non-skippable)
- Hierarchical FA (skippable)
- Replay protection style (skippable)

I'll clarify.

Eva
--------------090502000208030002010004-- --===============0958996601== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0958996601==-- From mip4-bounces@ietf.org Wed Aug 02 06:34:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8E3Q-0006pt-0O; Wed, 02 Aug 2006 06:34:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8E3O-0006pm-LT for mip4@ietf.org; Wed, 02 Aug 2006 06:34:18 -0400 Received: from airmail.airvananet.com ([12.6.244.34] helo=airmail.wirelessworld.airvananet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8E3N-0005M2-A0 for mip4@ietf.org; Wed, 02 Aug 2006 06:34:18 -0400 Received: from nilgiri.india.wirelessworld.airvananet.com ([192.168.51.3]) by airmail.wirelessworld.airvananet.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Aug 2006 06:34:03 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Aug 2006 16:03:59 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <653F3CF58193744C9DE59C217C072B58793876@nilgiri.india.wirelessworld.airvananet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MS multiple IP add in SIP case. Thread-Index: Aca2Hyn3vzZuTfgcRS+XP92Nr+wrug== From: "Arun SG" To: X-OriginalArrivalTime: 02 Aug 2006 10:34:03.0893 (UTC) FILETIME=[2CD36250:01C6B61F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [Mip4] MS multiple IP add in SIP case. X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org In document X.S0011-002-D v1.0, at one place we see this:=20 3.2.1.5 DHCPv4 Support Blah, lah.... However, if the 25 MS acquires additional IPv4 addresses from a DHCP server using a PDSN as the relay agent, 26 the PDSN shall store the additional IPv4 addresses. But at a later section, we see that:=20 3.4.1.5 DHCPv4 Support 34 The MS may support and use DHCP [RFC 2131] to request specific configuration parameters 35 [RFC 2132], which may include DNS addresses and/or SIP server addresses [RFC 3361].The 36 MS should not use DHCP [RFC 2131] to request additional IPv4 addresses. Is this summary then correct? 1. MS may request multiple IP addresses from the network, but not use DHCP client to do so.=20 2. To get multiple IP addresses, the only option is to use IPCP.=20 3. Since there can be only one IP address per PPP session and one PPP session between MS and PDSN,=20 Is there a case at all when a MS needs to & can get multiple IP address? If there is a case, how does it get that address?=20 Should PDSN's DHCP relay agent discard such requests?=20 Please note that this is a SIP scenario. Thanks, Arun -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Aug 02 08:01:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8FPf-0002yl-6m; Wed, 02 Aug 2006 08:01:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8FPd-0002v5-S6 for mip4@ietf.org; Wed, 02 Aug 2006 08:01:21 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8FPd-0008Dt-0h for mip4@ietf.org; Wed, 02 Aug 2006 08:01:21 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k72C1Cqm030130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 2 Aug 2006 05:01:13 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k72C1BuM023364; Wed, 2 Aug 2006 05:01:11 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Aug 2006 05:01:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt Date: Wed, 2 Aug 2006 05:01:09 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A0CC955@NAEX14.na.qualcomm.com> In-Reply-To: <44D04C73.1040201@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt Thread-Index: Aca2AMEc03KMlZEdSgCDCsjyKvY/+AAKG/Mw From: "Tsirtsis, George" To: =?iso-8859-1?Q?Eva_Fogelstr=F6m?= , "Jari Arkko" X-OriginalArrivalTime: 02 Aug 2006 12:01:11.0112 (UTC) FILETIME=[587DB480:01C6B62B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8eeb555810cda1f2c5989480370dc4ca Cc: "Kent Leung \(kleung\)" , mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2056106429==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============2056106429== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6B62B.57EE43B4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6B62B.57EE43B4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Eva, =20 Sounds good but if you remove the all 1s address, then the FA will not = be able to instruct the mobile that dynamic GFA can or should be used. = Is this true or are you going to try to do this some other way? =20 Since you are making some changes I also have one more suggestion. = According to the draft, the mobile first registers with the HA using = regular registrations (+some extensions) and then uses regional = registrations to the GFA if it handoffs within the area covered by the = local GFA. The draft does not currently require the mobile to register = with the GFA until it hands off. This creates the following issues which = is a bit strange. Once the mobile hands-off and uses regional = registration, the GFA can define a Lifetime that is equal to or smaller = than the Lifetime defined by the HA. This makes sense but the strange = thing is that the GFA can not impose its desired lifetime for regional = registrations until the mobile hands-off in its region. =20 I think this can be trivially fixed by requiring that the mobile uses = regional registration immediately after normal registration when a GFA = is present, and even if the mobile does not hand-off.=20 =20 Thoughts? George =20 ________________________________ From: Eva Fogelstr=F6m [mailto:eva.fogelstrom@ericsson.com]=20 Sent: Wednesday, August 02, 2006 2:56 AM To: Jari Arkko; Tsirtsis, George Cc: Kent Leung (kleung); mip4@ietf.org Subject: Re: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt =20 Ok. Let me clarify this. Jari's objection was that if an FA is allowed = to announce an all-ones GFA address only, the MN has no choice but to go = along with that, i.e. the MN cannot make a regular MIP4 home = registration. True. I believe this was discussed on the list a couple of years ago (2002), = when the draft was in WG last call. The idea was that an all-ones = address indicates dynamic GFA in the case of home registration, and = allows for privately addressed FAs in the case of regional registrations = (in which case the FA address itself is not advertised). As I said, I don't mind taking out this type of support for private FA = addresses, letting the FA advertise its c/o address to support regular = MIP4 home registrations, according to Jari's suggestion. So, unless = someone objects, I suggest I do exactly that. Eva Jari Arkko wrote: Tsirtsis, George wrote: =20 =20 It is not clear that dynamic GFAs is entirely optional, at least from = the mobile's perspective. For static GFA the MN must somehow know the = GFA address (presumably from the FAA) before it can send the = registration request message. If the FAA includes an all 1s GFA address = then, I suppose the mobile must use the dynamic GFA procedure....does it = have a choice? =20 =20 =20 I think that was part of what I objected to -- if the FAs are allowed to announce only an all 1s GFA address then it seems that it does not have a choice. But I fail to see why this is necessary. =20 --Jari =20 =20 ------_=_NextPart_001_01C6B62B.57EE43B4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Eva,

 

Sounds good but if you remove the = all 1s address, then the FA will not be able to instruct the mobile that = dynamic GFA =A0can or should be used. Is this true or are you going to try to do this some = other way?

 

Since you are making some changes I = also have one more suggestion. According to the draft, the mobile first = registers with the HA using regular registrations (+some extensions) and then uses = regional registrations to the GFA if it handoffs within the area covered by the = local GFA. The draft does not currently require the mobile to register with the GFA = until it hands off. This creates the following issues which is a bit strange. = Once the mobile hands-off and uses regional registration, the GFA can define = a Lifetime that is equal to or smaller than the Lifetime defined by the = HA. This makes sense but the strange thing is that the GFA can not impose its = desired lifetime for regional registrations until the mobile hands-off in its = region.

 

I think this can be trivially fixed = by requiring that the mobile uses regional registration immediately after normal registration when a GFA is present, and even if the mobile does not = hand-off.

 

Thoughts?

George

 

From: Eva Fogelstr=F6m [mailto:eva.fogelstrom@ericsson.com] =
Sent: Wednesday, August = 02, 2006 2:56 AM
To: Jari Arkko; Tsirtsis, = George
Cc: Kent Leung (kleung); mip4@ietf.org
Subject: Re: [Mip4] Re: = AD review of draft-ietf-mip4-reg-tunnel-02.txt

 

Ok. Let me clarify this. Jari's objection was = that if an FA is allowed to announce an all-ones GFA address only, the MN has no = choice but to go along with that, i.e. the MN cannot make a regular MIP4 home registration. True.

I believe this was discussed on the list a couple of years ago (2002), = when the draft was in WG last call. The idea was that an all-ones address = indicates dynamic GFA in the case of home registration, and allows for privately addressed FAs in the case of regional registrations (in which case the = FA address itself is not advertised).

As I said, I don't mind taking out this type of support for private FA addresses, letting the FA advertise its c/o address to support regular = MIP4 home registrations, according to Jari's suggestion. So, unless someone = objects, I suggest I do exactly that.

Eva

Jari Arkko wrote:

Tsirtsis, George =
wrote:
 
=A0 
It is not clear that dynamic GFAs is entirely =
optional, at least from the mobile's perspective. For static GFA the MN =
must somehow know the GFA address (presumably from the FAA) before it =
can send the registration request message. If the FAA includes an all 1s =
GFA address then, I suppose the mobile must use the dynamic GFA =
procedure....does it have a choice?
 
 
=A0=A0=A0 
I think that was part of what I objected to =
-- if the FAs are allowed to
announce
only an all 1s GFA address then it seems that =
it does not have a choice.
But I
fail to see why this is =
necessary.
 
--Jari
 
=A0
------_=_NextPart_001_01C6B62B.57EE43B4-- --===============2056106429== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============2056106429==-- From mip4-bounces@ietf.org Wed Aug 02 08:09:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8FXc-0001pV-40; Wed, 02 Aug 2006 08:09:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8FXa-0001pM-TQ for mip4@ietf.org; Wed, 02 Aug 2006 08:09:34 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8FXZ-0001A5-KF for mip4@ietf.org; Wed, 02 Aug 2006 08:09:34 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 2749989842; Wed, 2 Aug 2006 15:09:32 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id D264389837; Wed, 2 Aug 2006 15:09:31 +0300 (EEST) Message-ID: <44D095F1.7070200@piuha.net> Date: Wed, 02 Aug 2006 15:09:21 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060725) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Tsirtsis, George" Subject: Re: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt References: <7EB20EA0938B4D42A2D82689365C9B7A0CC955@NAEX14.na.qualcomm.com> In-Reply-To: <7EB20EA0938B4D42A2D82689365C9B7A0CC955@NAEX14.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: =?ISO-8859-1?Q?Eva_Fogelstr=F6m?= , mip4@ietf.org, "Kent Leung \(kleung\)" X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Tsirtsis, George wrote: > Eva, > > > > Sounds good but if you remove the all 1s address, then the FA will not > be able to instruct the mobile that dynamic GFA can or should be > used. Is this true or are you going to try to do this some other way? > I don't think that was the proposal. The proposal was to prohibit the all 1s address to be the ONLY address you provide. You can still provide the all 1s address, as long as there is another address that MNs without support for this spec can use. --Jari -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Aug 02 08:19:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8FhR-0001oy-N9; Wed, 02 Aug 2006 08:19:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8FhP-0001mu-6k for mip4@ietf.org; Wed, 02 Aug 2006 08:19:43 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8FhN-0002h4-RM for mip4@ietf.org; Wed, 02 Aug 2006 08:19:43 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k72CJYGm031105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 2 Aug 2006 05:19:34 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k72CJXsb002642; Wed, 2 Aug 2006 05:19:33 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Aug 2006 05:19:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt Date: Wed, 2 Aug 2006 05:19:32 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A0CC957@NAEX14.na.qualcomm.com> In-Reply-To: <44D095F1.7070200@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt Thread-Index: Aca2LI1XMj/cVGgsRHCiw+12gqJTagAATfWA From: "Tsirtsis, George" To: "Jari Arkko" X-OriginalArrivalTime: 02 Aug 2006 12:19:33.0292 (UTC) FILETIME=[E97106C0:01C6B62D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: =?iso-8859-1?Q?Eva_Fogelstr=F6m?= , mip4@ietf.org, "Kent Leung \(kleung\)" X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Ok I see. Thanks. George=20 > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Wednesday, August 02, 2006 8:09 AM > To: Tsirtsis, George > Cc: Eva Fogelstr=F6m; mip4@ietf.org; Kent Leung (kleung) > Subject: Re: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt >=20 > Tsirtsis, George wrote: >=20 > > Eva, > > > > > > > > Sounds good but if you remove the all 1s address, then the FA will = not > > be able to instruct the mobile that dynamic GFA can or should be > > used. Is this true or are you going to try to do this some other = way? > > > I don't think that was the proposal. The proposal was to prohibit the > all 1s address to be the ONLY > address you provide. You can still provide the all 1s address, as long > as there is another address > that MNs without support for this spec can use. >=20 > --Jari >=20 >=20 > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Aug 02 10:59:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8IBw-0006CZ-Dg; Wed, 02 Aug 2006 10:59:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8IBv-00065y-1g for mip4@ietf.org; Wed, 02 Aug 2006 10:59:23 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8IBt-0004f8-1d for mip4@ietf.org; Wed, 02 Aug 2006 10:59:23 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 01A524F00AB; Wed, 2 Aug 2006 16:59:20 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Aug 2006 16:59:19 +0200 Received: from [147.214.26.80] ([147.214.26.80]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Aug 2006 16:59:18 +0200 Message-ID: <44D0BDC2.9000604@ericsson.com> Date: Wed, 02 Aug 2006 16:59:14 +0200 From: =?ISO-8859-1?Q?Eva_Fogelstr=F6m?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Tsirtsis, George" Subject: Re: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt References: <7EB20EA0938B4D42A2D82689365C9B7A0CC955@NAEX14.na.qualcomm.com> In-Reply-To: <7EB20EA0938B4D42A2D82689365C9B7A0CC955@NAEX14.na.qualcomm.com> X-OriginalArrivalTime: 02 Aug 2006 14:59:18.0543 (UTC) FILETIME=[3AB241F0:01C6B644] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Cc: "Kent Leung \(kleung\)" , mip4@ietf.org, Jari Arkko X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1070326249==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============1070326249== Content-Type: multipart/alternative; boundary="------------070200060906010709060901" This is a multi-part message in MIME format. --------------070200060906010709060901 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi George, Comments inline. Tsirtsis, George wrote: > Eva, > > > > Sounds good but if you remove the all 1s address, then the FA will not > be able to instruct the mobile that dynamic GFA can or should be > used. Is this true or are you going to try to do this some other way? > Jari already replied to this. > > > Since you are making some changes I also have one more suggestion. > According to the draft, the mobile first registers with the HA using > regular registrations (+some extensions) and then uses regional > registrations to the GFA if it handoffs within the area covered by the > local GFA. The draft does not currently require the mobile to register > with the GFA until it hands off. This creates the following issues > which is a bit strange. Once the mobile hands-off and uses regional > registration, the GFA can define a Lifetime that is equal to or > smaller than the Lifetime defined by the HA. This makes sense but the > strange thing is that the GFA can not impose its desired lifetime for > regional registrations until the mobile hands-off in its region. > > > > I think this can be trivially fixed by requiring that the mobile uses > regional registration immediately after normal registration when a GFA > is present, and even if the mobile does not hand-off. > > > > Thoughts? > > George > I'm not sure I follow. When the MN does a home registration with its HA, the GFA acts as foreign agent towards the HA. The registration request goes as follows: MN-FA-GFA-HA. Ok? The GFA is a foreign agent, as defined in RFC3344, with some additions. In my understanding, this means that if the GFA does not approve of the lifetime in the registration request when it receives it, it can simply deny the home registration with error code 69 (requested lifetime too long). Moreover, the FA advertises the lifetime it is willing to allow for a registration. And the FA can also deny a registration. In case of co-located care-of address, the FA is bypassed in the home registration. However, the registration request still goes through the GFA, so the GFA can deny it. What's the problem? Eva --------------070200060906010709060901 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi George,

Comments inline.

Tsirtsis, George wrote:

Eva,

 

Sounds good but if you remove the all 1s address, then the FA will not be able to instruct the mobile that dynamic GFA  can or should be used. Is this true or are you going to try to do this some other way?

Jari already replied to this.

 

Since you are making some changes I also have one more suggestion. According to the draft, the mobile first registers with the HA using regular registrations (+some extensions) and then uses regional registrations to the GFA if it handoffs within the area covered by the local GFA. The draft does not currently require the mobile to register with the GFA until it hands off. This creates the following issues which is a bit strange. Once the mobile hands-off and uses regional registration, the GFA can define a Lifetime that is equal to or smaller than the Lifetime defined by the HA. This makes sense but the strange thing is that the GFA can not impose its desired lifetime for regional registrations until the mobile hands-off in its region.

 

I think this can be trivially fixed by requiring that the mobile uses regional registration immediately after normal registration when a GFA is present, and even if the mobile does not hand-off.

 

Thoughts?

George


I'm not sure I follow. When the MN does a home registration with its HA, the GFA acts as foreign agent towards the HA. The registration request goes as follows: MN-FA-GFA-HA. Ok?

The GFA is a foreign agent, as defined in RFC3344, with some additions. In my understanding, this means that if the GFA does not approve of the lifetime in the registration request when it receives it, it can simply deny the home registration with error code 69 (requested lifetime too long).

Moreover, the FA advertises the lifetime it is willing to allow for a registration. And the FA can also deny a registration.

In case of co-located care-of address, the FA is bypassed in the home registration. However, the registration request still goes through the GFA, so the GFA can deny it.

What's the problem?

Eva

--------------070200060906010709060901-- --===============1070326249== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1070326249==-- From mip4-bounces@ietf.org Wed Aug 02 11:07:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8IK1-0003Nj-40; Wed, 02 Aug 2006 11:07:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8IJz-0003NF-BM for mip4@ietf.org; Wed, 02 Aug 2006 11:07:43 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8IJx-0005Yv-QC for mip4@ietf.org; Wed, 02 Aug 2006 11:07:43 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k72F7Xui019848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 2 Aug 2006 08:07:34 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k72F2Vtl009746; Wed, 2 Aug 2006 08:07:32 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Aug 2006 08:07:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt Date: Wed, 2 Aug 2006 08:07:30 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A0CC98F@NAEX14.na.qualcomm.com> In-Reply-To: <44D0BDC2.9000604@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt Thread-Index: Aca2REF2ovK1zhevQcGkF+mZcFQzhQAACscg From: "Tsirtsis, George" To: =?iso-8859-1?Q?Eva_Fogelstr=F6m?= X-OriginalArrivalTime: 02 Aug 2006 15:07:31.0833 (UTC) FILETIME=[60B85690:01C6B645] X-Spam-Score: 0.0 (/) X-Scan-Signature: f5932bfc8385127f631fc458a872feb1 Cc: "Kent Leung \(kleung\)" , mip4@ietf.org, Jari Arkko X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1646558463==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============1646558463== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6B645.60688BE4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6B645.60688BE4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In line... =20 ________________________________ From: Eva Fogelstr=F6m [mailto:eva.fogelstrom@ericsson.com]=20 Sent: Wednesday, August 02, 2006 10:59 AM To: Tsirtsis, George Cc: Jari Arkko; Kent Leung (kleung); mip4@ietf.org Subject: Re: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt =20 Hi George, ... Since you are making some changes I also have one more suggestion. = According to the draft, the mobile first registers with the HA using = regular registrations (+some extensions) and then uses regional = registrations to the GFA if it handoffs within the area covered by the = local GFA. The draft does not currently require the mobile to register = with the GFA until it hands off. This creates the following issues which = is a bit strange. Once the mobile hands-off and uses regional = registration, the GFA can define a Lifetime that is equal to or smaller = than the Lifetime defined by the HA. This makes sense but the strange = thing is that the GFA can not impose its desired lifetime for regional = registrations until the mobile hands-off in its region. =20 I think this can be trivially fixed by requiring that the mobile uses = regional registration immediately after normal registration when a GFA = is present, and even if the mobile does not hand-off.=20 =20 Thoughts? George I'm not sure I follow. When the MN does a home registration with its HA, = the GFA acts as foreign agent towards the HA. The registration request = goes as follows: MN-FA-GFA-HA. Ok? GT> Yes The GFA is a foreign agent, as defined in RFC3344, with some additions. = In my understanding, this means that if the GFA does not approve of the = lifetime in the registration request when it receives it, it can simply = deny the home registration with error code 69 (requested lifetime too = long). GT> Yes, but what you describe would result in the lower Lifetime be = forced to the Home Agent too, which is not ideal. What I am looking for = here is separation of the refresh requirements imposed by the Home and = the Foreign domains. The GFA should be able to require a Lifetime that = is different (i.e., lower) than the lifetime required by the HA, without = affecting what the HA requires. Note that your draft already allows for = that but the mobile has to first perform a handoff. At that point the = GFA can return a Lifetime that is independent from the lifetime returned = by the HA. Is this clearer? George ------_=_NextPart_001_01C6B645.60688BE4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

In = line…

 

From: Eva Fogelstr=F6m [mailto:eva.fogelstrom@ericsson.com] =
Sent: Wednesday, August = 02, 2006 10:59 AM
To: Tsirtsis, George
Cc: Jari Arkko; Kent = Leung (kleung); mip4@ietf.org
Subject: Re: [Mip4] Re: = AD review of draft-ietf-mip4-reg-tunnel-02.txt

 

Hi George,
…

Since you are making some changes I = also have one more suggestion. According to the draft, the mobile first = registers with the HA using regular registrations (+some extensions) and then uses regional registrations to the GFA if it handoffs within the area covered = by the local GFA. The draft does not currently require the mobile to register = with the GFA until it hands off. This creates the following issues which is a bit strange. Once the mobile hands-off and uses regional registration, the = GFA can define a Lifetime that is equal to or smaller than the Lifetime defined = by the HA. This makes sense but the strange thing is that the GFA can not = impose its desired lifetime for regional registrations until the mobile hands-off = in its region.

 

I think this can be trivially fixed = by requiring that the mobile uses regional registration immediately after = normal registration when a GFA is present, and even if the mobile does not = hand-off.

 

Thoughts?

George


I'm not sure I follow. When the MN does a home registration with its HA, = the GFA acts as foreign agent towards the HA. The registration request goes = as follows: MN-FA-GFA-HA. Ok?

GT> Yes


The GFA is a foreign agent, as defined in RFC3344, with some additions. = In my understanding, this means that if the GFA does not approve of the = lifetime in the registration request when it receives it, it can simply deny the = home registration with error code 69 (requested lifetime too long).

GT> Yes, but what you describe would result in the lower Lifetime be forced = to the Home Agent too, which is not ideal. What I am looking for here is = separation of the refresh requirements imposed by the Home and the Foreign domains. = The GFA should be able to require a Lifetime that is different (i.e., lower) = than the lifetime required by the HA, without affecting what the HA requires. = Note that your draft already allows for that but the mobile has to first perform a handoff. At that point the GFA can return a Lifetime that is independent = from the lifetime returned by the HA. Is this clearer?

George

------_=_NextPart_001_01C6B645.60688BE4-- --===============1646558463== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1646558463==-- From mip4-bounces@ietf.org Thu Aug 03 03:11:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8XMZ-0008As-PQ; Thu, 03 Aug 2006 03:11:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8XMZ-0008An-7k for mip4@ietf.org; Thu, 03 Aug 2006 03:11:23 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8XMX-0001pP-0V for mip4@ietf.org; Thu, 03 Aug 2006 03:11:23 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 411474F01D1; Thu, 3 Aug 2006 09:11:20 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Aug 2006 09:11:19 +0200 Received: from [147.214.26.80] ([147.214.26.80]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Aug 2006 09:11:18 +0200 Message-ID: <44D1A18E.9000709@ericsson.com> Date: Thu, 03 Aug 2006 09:11:10 +0200 From: =?ISO-8859-1?Q?Eva_Fogelstr=F6m?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Tsirtsis, George" Subject: Re: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt References: <7EB20EA0938B4D42A2D82689365C9B7A0CC98F@NAEX14.na.qualcomm.com> In-Reply-To: <7EB20EA0938B4D42A2D82689365C9B7A0CC98F@NAEX14.na.qualcomm.com> X-OriginalArrivalTime: 03 Aug 2006 07:11:18.0978 (UTC) FILETIME=[04626A20:01C6B6CC] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91 Cc: "Kent Leung \(kleung\)" , mip4@ietf.org, Jari Arkko X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0172837786==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============0172837786== Content-Type: multipart/alternative; boundary="------------020103000407090407090209" This is a multi-part message in MIME format. --------------020103000407090407090209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi George, I understand what you want to do, but I don't understand the motivation=20 for it. In particular, I don't understand why being able to define a=20 separate lifetime at the GFA (compared to the HA) would motivate a=20 mandatory double registration (home + regional registration) each time=20 the MN registers with its HA. Eva Tsirtsis, George wrote: > In line... > > =20 > > -----------------------------------------------------------------------= - > > *From:* Eva Fogelstr=F6m [mailto:eva.fogelstrom@ericsson.com] > *Sent:* Wednesday, August 02, 2006 10:59 AM > *To:* Tsirtsis, George > *Cc:* Jari Arkko; Kent Leung (kleung); mip4@ietf.org > *Subject:* Re: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.tx= t > > =20 > > Hi George, > ... > > Since you are making some changes I also have one more suggestion.=20 > According to the draft, the mobile first registers with the HA using=20 > regular registrations (+some extensions) and then uses regional=20 > registrations to the GFA if it handoffs within the area covered by the=20 > local GFA. The draft does not currently require the mobile to register=20 > with the GFA until it hands off. This creates the following issues=20 > which is a bit strange. Once the mobile hands-off and uses regional=20 > registration, the GFA can define a Lifetime that is equal to or=20 > smaller than the Lifetime defined by the HA. This makes sense but the=20 > strange thing is that the GFA can not impose its desired lifetime for=20 > regional registrations until the mobile hands-off in its region. > > =20 > > I think this can be trivially fixed by requiring that the mobile uses=20 > regional registration immediately after normal registration when a GFA=20 > is present, and even if the mobile does not hand-off. > > =20 > > Thoughts? > > George > > > I'm not sure I follow. When the MN does a home registration with its=20 > HA, the GFA acts as foreign agent towards the HA. The registration=20 > request goes as follows: MN-FA-GFA-HA. Ok? > > GT> Yes > > > The GFA is a foreign agent, as defined in RFC3344, with some=20 > additions. In my understanding, this means that if the GFA does not=20 > approve of the lifetime in the registration request when it receives=20 > it, it can simply deny the home registration with error code 69=20 > (requested lifetime too long). > > GT> Yes, but what you describe would result in the lower Lifetime be=20 > forced to the Home Agent too, which is not ideal. What I am looking=20 > for here is separation of the refresh requirements imposed by the Home=20 > and the Foreign domains. The GFA should be able to require a Lifetime=20 > that is different (i.e., lower) than the lifetime required by the HA,=20 > without affecting what the HA requires. Note that your draft already=20 > allows for that but the mobile has to first perform a handoff. At that=20 > point the GFA can return a Lifetime that is independent from the=20 > lifetime returned by the HA. Is this clearer? > > George > --------------020103000407090407090209 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi George,

I understand what you want to do, but I don't understand the motivation for it. In particular, I don't understand why being able to define a separate lifetime at the GFA (compared to the HA) would motivate a mandatory double registration (home + regional registration) each time the MN registers with its HA.

Eva

Tsirtsis, George wrote:

In line…

 

From: Eva Fogelström [mailto:eva.fogelstrom@ericsson.com]
Sent: Wednesday, August 02, 2006 10:59 AM
To: Tsirtsis, George
Cc: Jari Arkko; Kent Leung (kleung); mip4@ietf.org
Subject: Re: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt

 

Hi George,
…

Since you are making some changes I also have one more suggestion. According to the draft, the mobile first registers with the HA using regular registrations (+some extensions) and then uses regional registrations to the GFA if it handoffs within the area covered by the local GFA. The draft does not currently require the mobile to register with the GFA until it hands off. This creates the following issues which is a bit strange. Once the mobile hands-off and uses regional registration, the GFA can define a Lifetime that is equal to or smaller than the Lifetime defined by the HA. This makes sense but the strange thing is that the GFA can not impose its desired lifetime for regional registrations until the mobile hands-off in its region.

 

I think this can be trivially fixed by requiring that the mobile uses regional registration immediately after normal registration when a GFA is present, and even if the mobile does not hand-off.

 

Thoughts?

George


I'm not sure I follow. When the MN does a home registration with its HA, the GFA acts as foreign agent towards the HA. The registration request goes as follows: MN-FA-GFA-HA. Ok?

GT> Yes


The GFA is a foreign agent, as defined in RFC3344, with some additions. In my understanding, this means that if the GFA does not approve of the lifetime in the registration request when it receives it, it can simply deny the home registration with error code 69 (requested lifetime too long).

GT> Yes, but what you describe would result in the lower Lifetime be forced to the Home Agent too, which is not ideal. What I am looking for here is separation of the refresh requirements imposed by the Home and the Foreign domains. The GFA should be able to require a Lifetime that is different (i.e., lower) than the lifetime required by the HA, without affecting what the HA requires. Note that your draft already allows for that but the mobile has to first perform a handoff. At that point the GFA can return a Lifetime that is independent from the lifetime returned by the HA. Is this clearer?

George

--------------020103000407090407090209-- --===============0172837786== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0172837786==-- From mip4-bounces@ietf.org Thu Aug 03 06:36:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8aZM-0001Gw-Qo; Thu, 03 Aug 2006 06:36:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8aZL-0001C3-HF for mip4@ietf.org; Thu, 03 Aug 2006 06:36:47 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8aZK-0006ra-Qm for mip4@ietf.org; Thu, 03 Aug 2006 06:36:47 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k73AadHT022798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 3 Aug 2006 03:36:39 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k73AacFS026025; Thu, 3 Aug 2006 03:36:38 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Aug 2006 03:36:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt Date: Thu, 3 Aug 2006 03:36:36 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A11CF03@NAEX14.na.qualcomm.com> In-Reply-To: <44D1A18E.9000709@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt Thread-Index: Aca2zAvyV6NDifHAS1qVcBq7TDwMswAGyw6g From: "Tsirtsis, George" To: =?iso-8859-1?Q?Eva_Fogelstr=F6m?= X-OriginalArrivalTime: 03 Aug 2006 10:36:38.0156 (UTC) FILETIME=[B32FCCC0:01C6B6E8] X-Spam-Score: 0.0 (/) X-Scan-Signature: fa183e2955b1d12e35b5783ab5b4f6df Cc: "Kent Leung \(kleung\)" , mip4@ietf.org, Jari Arkko X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1796528968==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============1796528968== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6B6E8.B2D542CA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6B6E8.B2D542CA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The reason I think the GFA should be able to have a different lifetime = than the HA is because I anticipate regional registration to be deployed = in the context of roaming between domains/operators. i.e., a mobile has = an HA in its home operator. When it moves to another operator it uses a = GFA for local mobility management. The GFA is provided by the local = operator and has its own requirements. It is typically in the industry = that each domain/operator has control over its own infrastructure and = does not depend on configuration in a third operator (unless absolutely = necessary). Such refresh lifetimes is one such parameter that they can = control. =20 I will also reiterate that your draft supports this concept already, = since the GFA can impose its own lifetime *after* a handoff takes place. = All I am saying is that if the GFA needs to impose its own lifetime it = should be able to impose it immediately. =20 As to the solution I suggested, it is just one solution. Another, = possibly better solution, would be to define a GFA-Lifetime extension = which the GFA can include in the Registration Reply during the initial = MN-FA-GFA-HA registration. This does what I am suggesting without = requiring a regional registration with the GFA.=20 =20 George =20 ________________________________ From: Eva Fogelstr=F6m [mailto:eva.fogelstrom@ericsson.com]=20 Sent: Thursday, August 03, 2006 3:11 AM To: Tsirtsis, George Cc: Jari Arkko; Kent Leung (kleung); mip4@ietf.org Subject: Re: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt =20 Hi George, I understand what you want to do, but I don't understand the motivation = for it. In particular, I don't understand why being able to define a = separate lifetime at the GFA (compared to the HA) would motivate a = mandatory double registration (home + regional registration) each time = the MN registers with its HA. Eva Tsirtsis, George wrote: In line... =20 ________________________________ From: Eva Fogelstr=F6m [mailto:eva.fogelstrom@ericsson.com]=20 Sent: Wednesday, August 02, 2006 10:59 AM To: Tsirtsis, George Cc: Jari Arkko; Kent Leung (kleung); mip4@ietf.org Subject: Re: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt =20 Hi George, ... Since you are making some changes I also have one more suggestion. = According to the draft, the mobile first registers with the HA using = regular registrations (+some extensions) and then uses regional = registrations to the GFA if it handoffs within the area covered by the = local GFA. The draft does not currently require the mobile to register = with the GFA until it hands off. This creates the following issues which = is a bit strange. Once the mobile hands-off and uses regional = registration, the GFA can define a Lifetime that is equal to or smaller = than the Lifetime defined by the HA. This makes sense but the strange = thing is that the GFA can not impose its desired lifetime for regional = registrations until the mobile hands-off in its region. =20 I think this can be trivially fixed by requiring that the mobile uses = regional registration immediately after normal registration when a GFA = is present, and even if the mobile does not hand-off.=20 =20 Thoughts? George I'm not sure I follow. When the MN does a home registration with its HA, = the GFA acts as foreign agent towards the HA. The registration request = goes as follows: MN-FA-GFA-HA. Ok? GT> Yes The GFA is a foreign agent, as defined in RFC3344, with some additions. = In my understanding, this means that if the GFA does not approve of the = lifetime in the registration request when it receives it, it can simply = deny the home registration with error code 69 (requested lifetime too = long). GT> Yes, but what you describe would result in the lower Lifetime be = forced to the Home Agent too, which is not ideal. What I am looking for = here is separation of the refresh requirements imposed by the Home and = the Foreign domains. The GFA should be able to require a Lifetime that = is different (i.e., lower) than the lifetime required by the HA, without = affecting what the HA requires. Note that your draft already allows for = that but the mobile has to first perform a handoff. At that point the = GFA can return a Lifetime that is independent from the lifetime returned = by the HA. Is this clearer? George ------_=_NextPart_001_01C6B6E8.B2D542CA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

The reason I think the GFA should = be able to have a different lifetime than the HA is because I anticipate = regional registration to be deployed in the context of roaming between domains/operators. i.e., a mobile has an HA in its home operator. When = it moves to another operator it uses a GFA for local mobility management. The GFA = is provided by the local operator and has its own requirements. It is = typically in the industry that each domain/operator has control over its own = infrastructure and does not depend on configuration in a third operator (unless = absolutely necessary). Such refresh lifetimes is one such parameter that they can = control.

 

I will also reiterate that your = draft supports this concept already, since the GFA can impose its own lifetime = *after* a handoff takes place. All = I am saying is that if the GFA needs to impose its own lifetime it should be = able to impose it immediately.

 

As to the solution I suggested, it = is just one solution. Another, possibly better solution, would be to define a GFA-Lifetime extension which the GFA can include in the Registration = Reply during the initial MN-FA-GFA-HA registration. This does what I am = suggesting without requiring a regional registration with the GFA. =

 

George

 

From: Eva Fogelstr=F6m [mailto:eva.fogelstrom@ericsson.com] =
Sent: Thursday, August = 03, 2006 3:11 AM
To: Tsirtsis, George
Cc: Jari Arkko; Kent = Leung (kleung); mip4@ietf.org
Subject: Re: [Mip4] Re: = AD review of draft-ietf-mip4-reg-tunnel-02.txt

 

Hi George,

I understand what you want to do, but I don't understand the motivation = for it. In particular, I don't understand why being able to define a separate = lifetime at the GFA (compared to the HA) would motivate a mandatory double = registration (home + regional registration) each time the MN registers with its = HA.

Eva

Tsirtsis, George wrote:

In = line…

 

From: Eva Fogelstr=F6m [mailto:eva.fogelstrom@ericsso= n.com]
Sent: Wednesday, August = 02, 2006 10:59 AM
To: Tsirtsis, George
Cc: Jari Arkko; Kent = Leung (kleung); mip4@ietf.org
Subject: Re: [Mip4] Re: = AD review of draft-ietf-mip4-reg-tunnel-02.txt

 

Hi George,
…

Since you are making some changes I = also have one more suggestion. According to the draft, the mobile first = registers with the HA using regular registrations (+some extensions) and then uses regional registrations to the GFA if it handoffs within the area covered = by the local GFA. The draft does not currently require the mobile to register = with the GFA until it hands off. This creates the following issues which is a bit = strange. Once the mobile hands-off and uses regional registration, the GFA can = define a Lifetime that is equal to or smaller than the Lifetime defined by the = HA. This makes sense but the strange thing is that the GFA can not impose its = desired lifetime for regional registrations until the mobile hands-off in its = region.

 

I think this can be trivially fixed = by requiring that the mobile uses regional registration immediately after = normal registration when a GFA is present, and even if the mobile does not = hand-off.

 

Thoughts?

George


I'm not sure I follow. When the MN does a home registration with its HA, = the GFA acts as foreign agent towards the HA. The registration request goes = as follows: MN-FA-GFA-HA. Ok?

GT> Yes


The GFA is a foreign agent, as defined in RFC3344, with some additions. = In my understanding, this means that if the GFA does not approve of the = lifetime in the registration request when it receives it, it can simply deny the = home registration with error code 69 (requested lifetime too = long).

GT> Yes, but what you describe would result in the lower Lifetime be forced = to the Home Agent too, which is not ideal. What I am looking for here is = separation of the refresh requirements imposed by the Home and the Foreign domains. = The GFA should be able to require a Lifetime that is different (i.e., lower) = than the lifetime required by the HA, without affecting what the HA requires. = Note that your draft already allows for that but the mobile has to first perform a handoff. At that point the GFA can return a Lifetime that is independent = from the lifetime returned by the HA. Is this clearer?

George

------_=_NextPart_001_01C6B6E8.B2D542CA-- --===============1796528968== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1796528968==-- From mip4-bounces@ietf.org Thu Aug 03 11:11:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8erI-0006yQ-F6; Thu, 03 Aug 2006 11:11:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8erH-0006xk-PA for mip4@ietf.org; Thu, 03 Aug 2006 11:11:35 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8erG-0003Zr-TO for mip4@ietf.org; Thu, 03 Aug 2006 11:11:35 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 03 Aug 2006 08:11:34 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k73FBYPZ018133; Thu, 3 Aug 2006 08:11:34 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k73FBX2D001423; Thu, 3 Aug 2006 08:11:33 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Aug 2006 08:11:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt Date: Thu, 3 Aug 2006 08:11:31 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC520242141C@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt Thread-Index: Aca2zAvyV6NDifHAS1qVcBq7TDwMswAGyw6gAAnXgQA= From: "Kent Leung \(kleung\)" To: "Tsirtsis, George" , =?iso-8859-1?Q?Eva_Fogelstr=F6m?= X-OriginalArrivalTime: 03 Aug 2006 15:11:33.0419 (UTC) FILETIME=[1B212FB0:01C6B70F] DKIM-Signature: a=rsa-sha1; q=dns; l=18903; t=1154617894; x=1155481894; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kleung@cisco.com; z=From:=22Kent=20Leung=20\(kleung\)=22=20 |Subject:RE=3A=20[Mip4]=20Re=3A=20AD=20review=20of=20draft-ietf-mip4-reg-tunnel-0 2.txt; X=v=3Dcisco.com=3B=20h=3Dmza4eAqZ9fUma2LuLjHnGf+Tt6g=3D; b=OM3u9RzxE/5jLwVIE/eWpIBvrVoloZDtczFzjwtnM/5WhHrLacpvi7YU94uwerXARcYaTIFu 0FU3MHNb5wg/b8HD/thaXinQ/CY1+pSuIWP0t6BCTPke4qWx26qcWgHi; Authentication-Results: sj-dkim-2.cisco.com; header.From=kleung@cisco.com; dkim=pass ( 43 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 748ed3980abc7d4bd6a14905626ff64e Cc: mip4@ietf.org, Jari Arkko X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1850991864==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============1850991864== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6B70F.1AF1C47C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6B70F.1AF1C47C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes, I think using the GFA-Lifetime extension is better for separation = of registration lifetime maintenance. =20 Kent ________________________________ From: Tsirtsis, George [mailto:tsirtsis@qualcomm.com]=20 Sent: Thursday, August 03, 2006 3:37 AM To: Eva Fogelstr=F6m Cc: Jari Arkko; Kent Leung (kleung); mip4@ietf.org Subject: RE: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt =09 =09 The reason I think the GFA should be able to have a different lifetime = than the HA is because I anticipate regional registration to be deployed = in the context of roaming between domains/operators. i.e., a mobile has = an HA in its home operator. When it moves to another operator it uses a = GFA for local mobility management. The GFA is provided by the local = operator and has its own requirements. It is typically in the industry = that each domain/operator has control over its own infrastructure and = does not depend on configuration in a third operator (unless absolutely = necessary). Such refresh lifetimes is one such parameter that they can = control. =20 I will also reiterate that your draft supports this concept already, = since the GFA can impose its own lifetime *after* a handoff takes place. = All I am saying is that if the GFA needs to impose its own lifetime it = should be able to impose it immediately. =20 As to the solution I suggested, it is just one solution. Another, = possibly better solution, would be to define a GFA-Lifetime extension = which the GFA can include in the Registration Reply during the initial = MN-FA-GFA-HA registration. This does what I am suggesting without = requiring a regional registration with the GFA.=20 =20 George =20 =09 ________________________________ From: Eva Fogelstr=F6m [mailto:eva.fogelstrom@ericsson.com]=20 Sent: Thursday, August 03, 2006 3:11 AM To: Tsirtsis, George Cc: Jari Arkko; Kent Leung (kleung); mip4@ietf.org Subject: Re: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt =20 Hi George, =09 I understand what you want to do, but I don't understand the motivation = for it. In particular, I don't understand why being able to define a = separate lifetime at the GFA (compared to the HA) would motivate a = mandatory double registration (home + regional registration) each time = the MN registers with its HA. =09 Eva =09 Tsirtsis, George wrote: =09 =09 In line... =20 =09 ________________________________ From: Eva Fogelstr=F6m [mailto:eva.fogelstrom@ericsson.com]=20 Sent: Wednesday, August 02, 2006 10:59 AM To: Tsirtsis, George Cc: Jari Arkko; Kent Leung (kleung); mip4@ietf.org Subject: Re: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt =20 Hi George, ... Since you are making some changes I also have one more suggestion. = According to the draft, the mobile first registers with the HA using = regular registrations (+some extensions) and then uses regional = registrations to the GFA if it handoffs within the area covered by the = local GFA. The draft does not currently require the mobile to register = with the GFA until it hands off. This creates the following issues which = is a bit strange. Once the mobile hands-off and uses regional = registration, the GFA can define a Lifetime that is equal to or smaller = than the Lifetime defined by the HA. This makes sense but the strange = thing is that the GFA can not impose its desired lifetime for regional = registrations until the mobile hands-off in its region. =20 I think this can be trivially fixed by requiring that the mobile uses = regional registration immediately after normal registration when a GFA = is present, and even if the mobile does not hand-off.=20 =20 Thoughts? George =09 I'm not sure I follow. When the MN does a home registration with its = HA, the GFA acts as foreign agent towards the HA. The registration = request goes as follows: MN-FA-GFA-HA. Ok? GT> Yes =09 The GFA is a foreign agent, as defined in RFC3344, with some additions. = In my understanding, this means that if the GFA does not approve of the = lifetime in the registration request when it receives it, it can simply = deny the home registration with error code 69 (requested lifetime too = long). GT> Yes, but what you describe would result in the lower Lifetime be = forced to the Home Agent too, which is not ideal. What I am looking for = here is separation of the refresh requirements imposed by the Home and = the Foreign domains. The GFA should be able to require a Lifetime that = is different (i.e., lower) than the lifetime required by the HA, without = affecting what the HA requires. Note that your draft already allows for = that but the mobile has to first perform a handoff. At that point the = GFA can return a Lifetime that is independent from the lifetime returned = by the HA. Is this clearer? George ------_=_NextPart_001_01C6B70F.1AF1C47C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Yes, I think using the GFA-Lifetime extension = is better for=20 separation of registration lifetime maintenance.
 
Kent

From: Tsirtsis, George=20 [mailto:tsirtsis@qualcomm.com]
Sent: Thursday, August 03, = 2006 3:37=20 AM
To: Eva Fogelstr=F6m
Cc: Jari Arkko; Kent Leung = (kleung);=20 mip4@ietf.org
Subject: RE: [Mip4] Re: AD review of=20 draft-ietf-mip4-reg-tunnel-02.txt

The reason = I think=20 the GFA should be able to have a different lifetime than the HA is = because I=20 anticipate regional registration to be deployed in the context of = roaming=20 between domains/operators. i.e., a mobile has an HA in its home = operator. When=20 it moves to another operator it uses a GFA for local mobility = management. The=20 GFA is provided by the local operator and has its own requirements. It = is=20 typically in the industry that each domain/operator has control over = its own=20 infrastructure and does not depend on configuration in a third = operator=20 (unless absolutely necessary). Such refresh lifetimes is one such = parameter=20 that they can control.

 

I will also = reiterate=20 that your draft supports this concept already, since the GFA can = impose its=20 own lifetime *after* a = handoff=20 takes place. All I am saying is that if the GFA needs to impose its = own=20 lifetime it should be able to impose it immediately.

 

As to the = solution I=20 suggested, it is just one solution. Another, possibly better solution, = would=20 be to define a GFA-Lifetime extension which the GFA can include in the = Registration Reply during the initial MN-FA-GFA-HA registration. This = does=20 what I am suggesting without requiring a regional registration with = the GFA.=20

 

George

 

From: Eva = Fogelstr=F6m [mailto:eva.fogelstrom@ericsson.com]
Sent: Thursday, August 03, 2006 = 3:11=20 AM
To: Tsirtsis,=20 George
Cc: Jari = Arkko; Kent=20 Leung (kleung); mip4@ietf.org
Subject: Re: [Mip4] Re: AD = review of=20 draft-ietf-mip4-reg-tunnel-02.txt

 

Hi George,

I understand what you want = to do,=20 but I don't understand the motivation for it. In particular, I don't=20 understand why being able to define a separate lifetime at the GFA = (compared=20 to the HA) would motivate a mandatory double registration (home + = regional=20 registration) each time the MN registers with its=20 HA.

Eva

Tsirtsis, George = wrote:

In = line=85

 

From: Eva = Fogelstr=F6m [mailto:eva.fogelstrom@ericsso= n.com]=20
Sent: Wednesday, = August 02,=20 2006 10:59 AM
To: = Tsirtsis,=20 George
Cc: Jari = Arkko; Kent=20 Leung (kleung); mip4@ietf.org
Subject: Re: [Mip4] Re: AD = review of=20 draft-ietf-mip4-reg-tunnel-02.txt

 

Hi George,
=85

Since you = are making=20 some changes I also have one more suggestion. According to the draft, = the=20 mobile first registers with the HA using regular registrations (+some=20 extensions) and then uses regional registrations to the GFA if it = handoffs=20 within the area covered by the local GFA. The draft does not currently = require=20 the mobile to register with the GFA until it hands off. This creates = the=20 following issues which is a bit strange. Once the mobile hands-off and = uses=20 regional registration, the GFA can define a Lifetime that is equal to = or=20 smaller than the Lifetime defined by the HA. This makes sense but the = strange=20 thing is that the GFA can not impose its desired lifetime for regional = registrations until the mobile hands-off in its = region.

 

I think = this can be=20 trivially fixed by requiring that the mobile uses regional = registration=20 immediately after normal registration when a GFA is present, and even = if the=20 mobile does not hand-off.

 

Thoughts?

George


I'm not = sure I follow.=20 When the MN does a home registration with its HA, the GFA acts as = foreign=20 agent towards the HA. The registration request goes as follows: = MN-FA-GFA-HA.=20 Ok?

GT>=20 Yes


The GFA is = a foreign=20 agent, as defined in RFC3344, with some additions. In my = understanding, this=20 means that if the GFA does not approve of the lifetime in the = registration=20 request when it receives it, it can simply deny the home registration = with=20 error code 69 (requested lifetime too long).

GT>=20 Yes, but what you describe would result in the lower Lifetime be = forced to the=20 Home Agent too, which is not ideal. What I am looking for here is = separation=20 of the refresh requirements imposed by the Home and the Foreign = domains. The=20 GFA should be able to require a Lifetime that is different (i.e., = lower) than=20 the lifetime required by the HA, without affecting what the HA = requires. Note=20 that your draft already allows for that but the mobile has to first = perform a=20 handoff. At that point the GFA can return a Lifetime that is = independent from=20 the lifetime returned by the HA. Is this clearer?

George

------_=_NextPart_001_01C6B70F.1AF1C47C-- --===============1850991864== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1850991864==-- From mip4-bounces@ietf.org Fri Aug 04 09:56:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G909r-0002Ne-Pp; Fri, 04 Aug 2006 09:56:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7Oj2-000504-VH for mip4@ietf.org; Sun, 30 Jul 2006 23:45:52 -0400 Received: from dash.ece.ufl.edu ([128.227.220.23] helo=ece.ufl.edu) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G7Oj1-0005JE-G1 for mip4@ietf.org; Sun, 30 Jul 2006 23:45:52 -0400 Received: (qmail 88056 invoked by uid 0); 31 Jul 2006 03:33:50 -0000 Received: from 207.46.89.15 by dash.ece.ufl.edu (envelope-from , uid 0) with qmail-scanner-1.25 (uvscan: v4.40.0/vJul 30 03:43. Clear:RC:0(207.46.89.15):SA:0(0.1/5.0):. Processed in 1.220963 secs); 31 Jul 2006 03:33:50 -0000 X-Spam-Status: No, hits=0.1 required=5.0 Received: from unknown (HELO mars) (207.46.89.15) by dot.ece.ufl.edu with SMTP; 31 Jul 2006 03:33:49 -0000 Message-ID: <019901c6b453$b0e83110$eea417ac@mars> From: "Dr. Dapeng Oliver Wu" To: Date: Sun, 30 Jul 2006 23:44:54 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.1 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc X-Mailman-Approved-At: Fri, 04 Aug 2006 09:56:10 -0400 Subject: [Mip4] INFOCOM 2007 CFP: Full paper due 5pm EST, Tuesday, August 1, 2006 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0049386126==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============0049386126== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0196_01C6B432.282C3C70" This is a multi-part message in MIME format. ------=_NextPart_000_0196_01C6B432.282C3C70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [Please accept our apologies if you receive multiple copies of this = message.]=20 =20 INFOCOM 2007 will be held in Anchorage, Alaska, on May 6-12, 2007. The=20 deadline for paper submissions is 5 pm EST, August 1, 2006. However,=20 papers MUST be registered in EDAS by July 24, 2006. Please note the=20 following changes to the submission process this year: (i) Each paper submission is limited to 9 pages. (ii) Upon submission in EDAS, authors will be asked to indicate whether=20 they wish an abbreviated version (5 pages) of their paper to be=20 considered for inclusion in special-topics INFOCOM mini-conferences in=20 the event that the paper cannot be included in the main conference = program. The following is a brief explanation about the Infocom Mini-Conference = process. All submitted papers will be considered as regular papers submissions for Infocom. AFTER the infocom selection is done, papers that did not make it into Infocom will be considered for topical mini-conference to be held on the Friday immediately following Infocom. Hence, the mini-conference can be viewed as an opportunity to get your work published fast even if you did not get your paper accepted into Infocom. The following are answers to frequently asked questions about the mini-conferences: 1) In order to have your paper considered for the Mini-conference, you must indicate when registering your paper that you want your paper to be considered for the mini-conference. 2) Selecting that your paper should be considered for mini-conference will not affect the chances of your paper being accepted to Infocom. Reviewers and TPC members will not know about your choice when they make a decision about your paper for Infocom. 3) The topics of the mini-conference will only be determined after the Infocom selection process has been completed. 4) Papers will be considered for the mini-conferences by a subset of the Infocom TPC from the pool of papers that did not make it into Infocom (whose authors indicated that they want their paper considered for the mini-conference). The website of INFOCOM 2007 is = http://www.comsoc.org/confs/infocom/2007/. ------=_NextPart_000_0196_01C6B432.282C3C70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
[Please = accept our=20 apologies if you receive multiple copies of this message.] =

 
INFOCOM 2007 will be held in Anchorage, Alaska, on May 6-12, 2007. = The=20
deadline for paper submissions is 5 pm EST, August 1, 2006. However, =
papers MUST be registered in EDAS by July 24, 2006. Please note the=20
following changes to the submission process this year:

(i) = Each paper=20 submission is limited to 9 pages.
(ii) Upon submission in EDAS, = authors will=20 be asked to indicate whether
they wish an abbreviated version (5 = pages) of=20 their paper to be
considered for inclusion in special-topics INFOCOM = mini-conferences in
the event that the paper cannot be included in = the main=20 conference program.


The following is a brief explanation = about the=20 Infocom Mini-Conference process.

All submitted papers will be = considered=20 as regular papers submissions
for Infocom.  AFTER the infocom = selection=20 is done, papers that did
not make it into Infocom will be considered = for=20 topical
mini-conference to be held on the Friday immediately=20 following
Infocom.  Hence, the mini-conference can be viewed as = an=20 opportunity
to get your work published fast even if you did not get = your=20 paper
accepted into Infocom.

The following are answers to = frequently=20 asked questions about the
mini-conferences:

1)   In order = to have=20 your paper considered for the Mini-conference,
you must indicate when = registering your paper that you want your
paper to be considered for = the=20 mini-conference.

2) Selecting that your paper should be = considered for=20 mini-conference
will not affect the chances of your paper being = accepted to=20 Infocom.
Reviewers and TPC members will not know about your choice = when=20 they
make a decision about your paper for Infocom.

3) The = topics of=20 the mini-conference will only be determined after
the Infocom = selection=20 process has been completed.

4)  Papers will be considered = for the=20 mini-conferences by a subset of
the Infocom TPC from the pool of = papers that=20 did not make it into
Infocom (whose authors indicated that they want = their=20 paper
considered for the=20 mini-conference).
=
The website of INFOCOM 2007 is http://www.comsoc.org/= confs/infocom/2007/.
------=_NextPart_000_0196_01C6B432.282C3C70-- --===============0049386126== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0049386126==-- From mip4-bounces@ietf.org Sun Aug 06 15:50:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9odk-0000ut-UP; Sun, 06 Aug 2006 15:50:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9j5i-0002nY-ED for mip4@ietf.org; Sun, 06 Aug 2006 09:54:54 -0400 Received: from ns1.siteground5.com ([67.15.157.13] helo=serv01.siteground5.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9j5h-0005Ch-Un for mip4@ietf.org; Sun, 06 Aug 2006 09:54:54 -0400 Received: from boostwor by serv01.siteground5.com with local (Exim 4.52) id 1G9j5f-0003EW-4u for mip4@ietf.org; Sun, 06 Aug 2006 08:54:52 -0500 To: mip4@ietf.org Date: Sun, 6 Aug 2006 08:54:51 -0500 From: labiod@enst.fr Message-ID: X-Priority: 3 X-Mailer: PHPMailer [version 1.73] X-Mailer: PHPlist v2.10.2 X-MessageID: 11 X-ListMember: mip4@ietf.org Precedence: bulk MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - serv01.siteground5.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [32094 596] / [47 12] X-AntiAbuse: Sender Address Domain - serv01.siteground5.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.7 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 X-Mailman-Approved-At: Sun, 06 Aug 2006 15:50:24 -0400 Subject: [Mip4] [CFP] NTMS'2007 - 1th International Conference on New Technologies, Mobility and Security (NTMS 2007) X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Dear Colleagues, Please feel free to send this CFP to your friends and colleagues that might be interested in the topics of NTMS’2007 International Conference. This message is cross-posted to several lists. We apologize for multiple copies. --------------------- CALL FOR PAPERS - NTMS 2007 ---------------------------------- 1th International Conference on New Technologies, Mobility and Security (NTMS 2007) Technically co-sponsored by IFIP and IEEE France Computer Section April 30 to May 3, 2007 - Beirut, Lebanon http://www.ntms2007.org ------------------------------------------------------------------------------------- Due to last events in Lebanon, the NTMS 2007 conference place can be moved to France ------------------------------------------------------------------------------------- NTMS'2007 aims at fostering advances in the areas of New Technologies, Wireless Networks, Mobile Computing, Ad hoc and Ambient Networks, QoS, Network Security and E-commerce, to mention a few, and provides a dynamic forum for researchers, students and professionals to present their state-of-the-art research and development in these interesting areas. The event will be combined with tutorial sessions and workshops. Tutorials will precede the main program, aiming at the dissemination of mature knowledge and technology advances in the field. Two or more Workshops will immediately follow the main conference, offering the opportunity for a more focused exchange of ideas and presentation of on-going research relevant to selected topics. During NTMS'2007, demo areas will also be available to R&D labs and consortia to demonstrate their prototype implementations, or other prominent results. TOPICS OF INTEREST ------------------------------- The organising and technical committees of the conference are seeking original contributions in the areas of, but not limited to: Analysis and design of network architectures and algorithms Network management and traffic engineering Network, transport, and application-layer protocols Resource management, quality of service, signalling & scheduling Routing, switching, and addressing Network fault-tolerance & reliability, debugging & troubleshooting Network security, vulnerability, authentication and access control Intrusion Detection, Prediction, and Countermeasures Smart Device, Identity, Privacy and Trust Privacy, contract agreements, and payment systems Public key infrastructure implementation Mobile code security & Security management E-business and E-commerce security Peer-to-peer, overlay, and content distribution networks Optical networks and switching Wireless Mesh Networks & Metropolitan Area Networks (WiMAX, 802.16e) 3G & Wireless Personal Area Networks (Wimedia, UWB, Bluetooth, ...) Wireless Local Area Networks (Wi-Fi, ...) & Wireless Local Loop Ad hoc, Sensor Networks and Embedded Systems, Ambient Networks Mobility management and Handover Medium Access Control & Scheduling Techniques for Wireless Systems Cross-layer network design and optimization Pervasive, Ubiquitous and Mobile Computing Agents and Middleware, Agent Computing and Agent Applications Grid and cluster computing & Context aware computing Adaptation software development Next generation systems & Service-oriented techniques Component based software engineering &Software verification & analysis Web Commerce & Services, Data models, Web searching & querying XML, Query Processing & Optimization, Storage Structures & Indexing Web Mining & Web Semantic SUBMISSION GUIDELINES -------------------------------------- Authors are invited to submit complete and original papers. All submitted papers will be refereed for quality, correctness, originality and relevance. Authors of accepted papers will be required to produce final versions of their papers in IEEE camera ready format (double column) according to IEEE Computer Society Press style guidelines Preferred maximum paper length is 5 printed pages (10-point font) including figures, graphics and tables. However, papers for review of up to 8 pages in length will also be accepted, although accepted papers exceeding 5 pages will be charged an overlength fee of $100 for the 6th page. NTMS'2007 is using the EDAS Conference Management System (http://edas.info) to manage paper submissions process. The proposal for tutorial should include the title and clear explanation of the content of the proposed tutorial. Please include in the proposal (1) Organizer Name, (2) Name of proposed instructor, (3) Title of tutorial and detailed outline, (4) Qualifications of proposed instructor, (5) Full contact information: mailing address, telephone & fax number, and email address. IMPORTANT DATES ------------------------------ Draft papers should be submitted by December 20, 2006 Authors will receive the acceptance notification by February 20, 2007 Final papers for presentation should be sent before March 15, 2007 Tutorial Workshop (Instructor) Submission due : November 5, 2006 Deadline Notification of Tutorial & Workshop Acceptance : December 30, 2006 CONFERENCE COMMITTEES ----------------------------------------- ----- CONFERENCE PROGRAM CO-CHAIRS Houda Labiod - General Chair (ENST Paris) - France Bassel Souleiman (ENST Bretagne) - France Bilal Chebaro (Lebanese University) - Lebanon ----- TECHNICAL PROGRAM CO-CHAIRS Houda Labiod - General Chair (ENST Paris) - France Stamatios Kartalopoulos, (University of Oklahoma), USA Pascal Lorenz (Université de Haute Alsace), France ----- TECHNICAL PROGRAM COMMITTEE Akmal Abdelfatah (American University of Sharjah), UAE Mohamed Achemlal (France Telecom R&D Caen), France Khaldoun Al Agha (University Paris-Sud), France Kablan Barbar (Lebanese University), Lebanon Carlo Blundo (Di Salerno University), Italy Raouf Boutaba (University of Waterloo), Canada Azzedine Boukerche (University of ottawa), Canada Rajkumar Buyya (University of Melbourne), Australia Jacques Demerjian (ESRGroups), France Mahmoud Doughan (Lebanese University), Lebanon Bertrand du Castel (Axalto), USA Khaled Fouad Elsayed (Cairo University), Egypt Stephan Flake (ORGA Systems), Germany Steve Furnell (University of Plymouth), United Kingdom Giulio Galante (Istituto Superiore Mario Boella), Italy Wassim Haddad (Ericsson Research), Canada James Hughes (Sun Microsystems), USA Bilel Jamoussi (Nortel - Northern Telecom), Canada Joe Khalife (Lebanese American University), Lebanon Yvon Kermarrec (ENST Bretagne), France Bo-Kyung Lee (Korea Polytechnic University), Korea Seng Loke (La Trobe University), Australia Maryline Maknavicius (INT Evry),France Imad Mougharbel (Lebanese University), Lebanon Chafik Moukbel (Balamand University), Lebanon Hasnaa Moustafa (France Telecom R&D Paris), France Elie Najm (ENST Paris), France Ahmad Nasri (American University of Beirut), Lebanon Jose Marcos Nogueira (Federal Univ. of Minas Gerais) , Brasil Alessandro Nordio (Polytechnico di Torino), Italy Pierre Paradinas (CNAM), France Guy Pujolle (Paris 6 Univeristy),France Francis Rousseaux (Université de Reims), France Pedro Ruiz (University of Murcia), Espagne Kassem Saleh (American University of Sharjah), UAE Yahya Sanadidi (University of California), USA Brunilde Sansò (École Polytechnique de Montréal), Canada Christian Schindelhauer (University of Paderborn), Germany David Simplot-Ryl (Université de Lille 1, LIFL & INRIA), France Otto Spaniol (RWTH Aachen University), Germany Steve Uhlig (Université catholique de Louvain), Belgium Pascal Urien (ENST Paris), France Sung-Ming Yen (National Central University), Taiwan Cui Yong (Tsinghua University), China Bin Zhu (Microsoft Research Asia),China ----- Steering Board Prof. Houda Labiod (ENST Paris), France Prof. Algirdas Pakstas (London Metropolitan University), England Prof. Stamatios Kartalopoulos (University of Oklahoma), USA Dr. Mohamad Badra (ENST Paris), France Dr. Jacques Demerjian (ESRGroups), France Mr. Samer El Sawda (ENST Paris), France Dr. Ibrahim Hajjeh (Acti Group), France Dr. Ouahiba Fouial (ESRGroups), France ----- WORKSHOPS & TUTORIALS CHAIR Michel Riguidel (ENST Paris) - France Mohamad Badra (ENST Paris) - France CONTACT: -------------- Associate Prof. Labiod Houda INFRES Department - ENST Paris 46, rue barrault 75634 Paris Cedex 13 - France E-mail :labiod@enst.fr -- Powered by PHPlist, www.phplist.com -- -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Aug 11 09:52:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBXPz-0008HC-K3; Fri, 11 Aug 2006 09:51:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBXLR-0003lj-F5; Fri, 11 Aug 2006 09:46:37 -0400 Received: from firstclass.it.rit.edu ([129.21.21.97]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBXLP-00014R-3z; Fri, 11 Aug 2006 09:46:37 -0400 Message-id: Date: Fri, 11 Aug 2006 09:45:02 -0400 X-Mailer: FirstClass 8.2 (build 8.094) X-FC-SERVER-TZ: 15729388 From: "Nirmala Shenoy" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 X-Mailman-Approved-At: Fri, 11 Aug 2006 09:51:18 -0400 Subject: [Mip4] Sensorware Workshop 2007 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Apologies if you receive multiple copies CALL FOR PAPER 2nd International Workshop on Software for Sensor Networks (SensorWare) To be held with Comsware 2007 ([ http://www.comsware.org ]www.comsware.org) 8th January 2007, Bangalore India www.sensorware.org Advances in technology have made deployment of miniature sensors a realistic proposition. Low-power, inexpensive smart devices with multiple on-board sensors are connected through wireless links so as to form a collaborative sensor network to perform a specific task. As a result, it opens up a new paradigm of ubiquitous computing and enables a range of applications that are previously unrealizable or too costly to be realized. However, given the limitation of on-board hardware, one of the key areas towards achieving superior performance is through software implementation. The workshop is intended to bring together industry experts and researchers to share novel techniques, algorithms and software implementation for sensor networks, and to discuss the current status, technical challenges, standards, fundamental issues, and future services and applications in the form of panels and technical presentation. Topics of interest include but are not limited to the following: 1. Operating System 2. Efficient algorithms 3. Protocol design considerations 4. Performance analysis 5. Performance related issues 6. Cross-layered design considerations 7. Sensor applications and their impact on sensor network architectures 8. Deployment issues and scenarios 9. Middleware 10. Sensor network security 11. Sensor network design and modeling Workshop co-chairs: Nirmala Shenoy ([ mailto:ns@rit.edu ]ns@rit.edu), Rochester Institute of Technology, USA Paul Chou, ([ mailto:pchou@us.ibm.com ]pchou@us.ibm.com), IBM Thomas J Watson Research Center, USA Workshop technical co-chairs: Naoki Wakamiya, ([ mailto:Wakamiya@ist.osaka-u.ac.jp ]Wakamiya@ist.osaka-u.ac.jp), Osaka University, Japan Falko Dressler, (dressler@informatik.uni-erlangen.de),University of Erlangen-Nuremberg, Germany Important Dates: Paper Submission Deadline: 30th August 2006 Notification Acceptance/Rejection: 20th November 2006 Final Camera-Ready Paper Submission: 30th November 2006 **************************************************************************** Nirmala Shenoy PhD, Associate Professor, Networking and Security Department, Director, Lab for Wireless Networking and Security, Rochester Institute of Technology, 102 Lomb Memorial Drive, Rochester, New York 14623 585-475-4887 585-475-2181 Fax ns@it.rit.edu www.nssa.rit.edu/~ns **************************************************************************** -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Aug 11 09:52:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBXQC-0008J7-T9; Fri, 11 Aug 2006 09:51:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBWji-0001LO-SC; Fri, 11 Aug 2006 09:07:38 -0400 Received: from cowpens.ceas.rochester.edu ([128.151.162.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBWjh-0004YZ-55; Fri, 11 Aug 2006 09:07:38 -0400 Received: from h307pc2 (h318fw1.ceas.rochester.edu [128.151.164.245]) by cowpens.ceas.rochester.edu (8.13.6/8.13.6) with SMTP id k7BD7Zsx006895; Fri, 11 Aug 2006 09:07:35 -0400 (EDT) Message-ID: <00ce01c6bd47$1dec2220$c000a8c0@h307pc2> From: "Wendi Heinzelman" To: , Date: Fri, 11 Aug 2006 09:07:36 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: f90f4746216faf1f6cbda6dd26dbc608 X-Mailman-Approved-At: Fri, 11 Aug 2006 09:51:31 -0400 Cc: Subject: [Mip4] IEEE SECON 2006 Call for Participation X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org (Apologies if you receive this information multiple times.) Dear Colleague, Please find below the Call for Participation for IEEE SECON 2006, The Third IEEE International Conference on Sensors, Mesh and Ad Hoc Communications and Networks. The detailed conference program included advance technical program, panel, tutorial and workshops information is presented below. More information is available at: http://www.ieee-secon.org/2006/ Discounted registration for the conference ends September 1, 2006. We look forward to your participation in the conference. If you have any questions, please do not hesitate to contact any of the conference organizers listed below. Best Regards, IEEE SECON 2006 Conference Organizing Committee *********************************************************************** CALL FOR PARTICIPATION IEEE SECON 2006 The Third IEEE International Conference on Sensors, Mesh and Ad Hoc Communications and Networks http://www.ieee-secon.org/2006/ Sponsored by IEEE Communications Society (www.comsoc.org) Technically Co-Sponsored by AFCEA (www.afcea.org) September 25-28, 2006 Hyatt Reston, Reston, Virginia, USA (Near Washington DC's Dulles airport) ************************************************************************ MONDAY, September 25, 2006 A. WORKSHOPS The IEEE SECON 2006 conference will host the following two workshops, that will be held on Monday, September 25, 2006: 1. Second IEEE Workshop on Wireless Mesh Networks: http://www.ieee-secon.org/2006/wimesh/index.htm Workshop Co-Chairs: Prof. Samir R. Das, Stony Brook University Dr. Thyaga Nandagopal, Bell Labs, Lucent Technologies 2. First IEEE Workshop on Networking Technologies for Software Defined Radio (SDR) Networks: http://www.ieee-secon.org/2006/wsdr/index.htm Workshop Chair: Dr. Thomas Hou, Virginia Tech. B. TUTORIAL: Title: 802.11s: Wireless Local Area Mesh Networking Standard Date: Monday, Sep 25, 2006; Time: 1:30 PM - 5:00 PM Speakers * Donald Eastlake, Motorola Laboratories * Susan Hares, NextHop Technologies * Meiyuan Zhao, Intel Research ========================================================================= TENTATIVE CONFERENCE ADVANCE PROGRAM TUESDAY, September 26, 2006 8:30 AM - 10:00 AM: Opening Remarks and Keynote Talk (TBA) 10.00 AM - 11:00 AM: Posters/Demos 11:00 AM - 12:30 PM: Panel 1: Mesh in Metro: reality and future Moderator: Prakash Iyer, Intel Panelists: Edward Naef, CSMG Vann Hasty, Motorola Malik Audeh, Tropos -------------------------------------------------------------------- 2:00 PM - 3:30 PM: (2 Parallel Tracks - Sessions 1 and 2) Session 1: Routing I Data-Centric Routing in Sensor Networks using Biased Walk Huilong Huang (University of Arizona); John Hartman (University of Arizona); Terril Hurst (University of Arizona) Search-Quality Tradeoffs for Routing in Non-Ideal Wireless Networks Chiranjeeb Buragohain (University of California, Santa Barbara); Divyakant Agrawal (University of California, Santa Barbara); Subhash Suri (University of California at Santa Barbara) GMR: Geographic Multicast Routing for Wireless Sensor Networks Juan Sanchez (University of Murcia); Pedro Ruiz (University of Murcia); Ivan Stojmenovic (University of Ottawa) Scalable Routing in Sensor Actuator Networks with Churn Thomas Fuhrmann (University of Karlsruhe) -------------------------------------------------------------------- Session 2: Security and Privacy Security Services in Wireless Sensor Networks Using Sparse Random Coding Farshid Delgosha (Georgia Institute of Technology); Erman ayday (Georgia Institute of Technology); Kevin Chan (Georgia Tech); Faramarz Fekri (Georgia Institute of Technology) Relationship-Based Detection of Spoofing-Related Anomalous Traffic in Ad Hoc Networks Qing Li (Rutgers University); Wade Trappe (Rutgers University) A Trust Based Framework for Secure Data Aggregation in Wireless Sensor Networks Wei Zhang (University of Texas at Arlington); Sajal Das (The University of Texas at Arlington); Yonghe Liu (UT Arlington) An Anonymous Routing Protocol with The Local-Repair Mechanism for Mobile Ad Hoc Networks Bo Zhu (George Mason University); Sushil Jajodia (George Mason University) -------------------------------------------------------------------- 4:00 PM - 5:30 PM: (2 Parallel Tracks - Sessions 3 and 4) Session 3: Forwarding Protocols Minimum Latency Broadcasting in Multi-Radio Multi-Channel Multi-Rate Wireless Meshes Junaid Qadir (University of New South Wales); Archan Misra (IBM T J Watson Research Center); Chun Tung Chou (University of New South Wales) Solicitation-Based Forwarding for Sensor Networks Seoung-Bum Lee (Columbia University); Kyung Joon Kwak (Columbia University); Andrew Campbell (Dartmouth College) Coverage Aware Buffer Management and Scheduling for Wireless Sensor Networks Eugene Chai (National University of Singapore); Mun Choon Chan (National University of Singapore); Akkihebbal L. Ananda (National University of Singapore) A Communication Architecture for Mobile Wireless Sensor and Actor Networks Tommaso Melodia (Georgia Institute of Technology); Dario Pompili (Georgia Institute of Technology); Ian Akyildiz (Georgia Institute of Technology) -------------------------------------------------------------------- Session 4: Spatial Reuse and Spectrum Allocation Belief-Assisted Pricing for Dynamic Spectrum Allocation in Wireless Networks with Selfish Users Zhu Ji (University of Maryland, College Park); K.J. Ray Liu (University of Maryland) Spatial Diversity Benefits by Means of Induced Fading Daniele Puccinelli (University of Notre Dame); Martin Haenggi (University of Notre Dame) Scheduling Optimization in Wireless MESH Networks with Power Control and Rate Adaptation Antonio Capone (Politecnico di Milano); Giuliana Carello (Politecnico di Milano) *************** END OF TUESDAY PROGRAM *********************************** WEDNESDAY, September 27, 2006 8:30 AM - 10.00 AM: Panel 2: Scaling to Large Sensor Networks - How Large is too Large? Moderator: Dr. James A. Freebersyser, BBN Panelists: Mr. Patrick Gonia, Honeywell Prof. William J. Kaiser, UCLA Prof. Prasun Sinha, Ohio State University Mr. Mike Horton, Crossbow 10.00 AM - 11:00 AM: Posters/Demos 11:00 AM - 12:30 PM: (3 Parallel Tracks - Sessions 5, 6 and 7) Session 5: Platforms and Development Environments Balancing Computation and Communication Costs: The Case for Hybrid Execution in Sensor Networks Ingwar Wirjawan (University of California, Davis); Joel Koshy (University of California, Davis); Raju Pandey (University of California, Davis); Yann Ramin (University of California, Davis) EmPro: An Environment/Energy Emulation and Profiling Platform for Wireless Sensor Networks Chulsung Park (University of California, Irvine); Pai Chou (University of California, Irvine) AmbiMax: Efficient, Autonomous Energy Harvesting System for Multiple-Supply Wireless Sensor Nodes Chulsung Park (University of California, Irvine); Pai Chou (University of California, Irivne) TinyXXL: Language and Runtime Support for Cross-Layer Interactions Andreas Lachenmann (University of Stuttgart); Pedro Jos Marrn (University of Stuttgart); Daniel Minder (University of Stuttgart); Matthias Gauger (University of Stuttgart); Olga Saukh (University of Stuttgart); Kurt Rothermel (University of Stuttgart) -------------------------------------------------------------------- Session 6: Cooperative Communication When Does Cooperation Have Better Performance in Sensor Networks? Ahmed Sadek (University of Maryland); Wei Yu (University of Maryland); K.J. Ray Liu (University of Maryland) Balancing Cooperation and Interference in Wireless Sensor Networks Sam Vakil (University of Toronto); Ben Liang (University of Toronto) Progressive Network Coding for Message-Forwarding in Ad-Hoc Wireless Networks Xingkai Bao (Lehigh University); Jing Li (Lehigh University) -------------------------------------------------------------------- Session 7: Disconnection Tolerance A Proactive Data Bundling System for Intermittent Mobile Connections Caitlin Holman (University of Califonia, Santa Barbara); Khaled Harras (University of Califonia, Santa Barbara); Kevin Almeroth (University of Califonia, Santa Barbara); Anderson Lam (University of Califonia, Santa Barbara) Island Hopping: Efficient Mobility-Assisted Forwarding in Partitioned Networks Natasa Sarafijanovic (EPFL); Michal Pirkowski (EPFL); Matthias Grossglauser (EPFL) Effective Dissemination of Presence Information in Highly Partitioned Mobile Ad Hoc Networks Christoph Lindemann (University of Leipzig); Oliver Waldhorst (University of Leipzig) -------------------------------------------------------------------- 2:00 PM - 3:30 PM: (3 Parallel Tracks - Sessions 8, 9, 10) Session 8: Routing II Improving Geographical Routing for Wireless Networks with an Efficient Path Pruning Algorithm Xiaoli Ma (Georgia Institute of Technology); Min-Te Sun (Auburn University); Gang Zhao (University of Louisville); Xiangqian Liu (University of Louisville) Supervised Learning in Sensor Networks: New Approaches with Routing, Reliability Optimizations Yong Wang (Princeton University); Margaret Martonosi (Princeton University); Li-Shiuan Peh (Princeton University) MERLIN: A synergetic integration of MAC and Routing Protocol for Distributed Sensor Networks Antonio Ruzzelli (University College Dublin); Michael O'Grady (University College Dublin); Gregory O'Hare (University College Dublin); Richard Tynan (University College Dublin) -------------------------------------------------------------------- Session 9: Network Modeling and Analysis A Spatio-Temporal Model for Physical Carrier Sensing Wireless Ad-Hoc Networks Eric Wong (University of California, San Diego); Rene Cruz (University of California, San Diego) A Realistic Power Consumption Model for Wireless Sensor Network Devices Qin Wang (Harvard University); Mark Hempstead (Harvard University); Woodward Yang (Harvard University) The Analysis of a Game Theoretic MAC Protocol for Wireless Networks Hazer Inaltekin (Cornell University); Stephen Wicker (Cornell University) Optimizing Delay in Sequential Change Detection on Ad Hoc Wireless Sensor Networks Venkata K. Prasanthi M. (Indian Institute of Science, Bangalore); Anurag Kumar (Indian Institute of Science, Bangalore) -------------------------------------------------------------------- Session 10: Sensor Coverage Deployment Strategies for Differentiated Detection in Wireless Sensor Networks Jingbin Zhang (University of Virginia); Ting Yan (University of Virginia); Sang Son (University of Virginia) Sacrificing a Little Coverage Can Substantially Increase Network Lifetime Limin Wang (Michigan State University); Sandeep Kulkarni (Michigan State University) Optimal Worst-Case Coverage of Directional Field-of-View Sensor Networks Jacob Adriaens (University of Wisconsin Madison); Seapahn Megerian (University of Wisconsin Madison); Miodrag Potkonjak (University of California at Los Angeles) Mutual Exclusion in Wireless Sensor and Actor Networks Ramanuja Vedantham (Georgia Institute of Technology); Zhenyun Zhuang (Georgia Institute of Technology); Raghupathy Sivakumar (Georgia Institute of Technology) -------------------------------------------------------------------- 4:00 PM - 5:30 PM (3 Parallel Tracks - Sessions 11, 12, 13) Session 11: Localization and Ranging I Localization in Sensor Networks using Consistency-based Statistical Error Models Jessica Feng (University of California, Los Angeles); Lewis Girod (University of California, Los Angeles); Miodrag Potkonjak (University of California at Los Angeles) A Practical Approach to Landmark Deployment for Indoor Localization Yingying Chen (Rutgers University); John-Austen Francisco (Rutgers University); Wade Trappe (Rutgers University); Richard Martin (Rutgers University) Angle of Arrival Localization for Wireless Sensor Networks Rong Peng (North Carolina State University); Mihail Sichitiu (North Carolina State University) Robot-Assisted Localization Techniques for Wireless Image Sensor Networks Huang Lee (Stanford University); Hattie Dong (Stanford University); Hamid Aghajan (Stanford University) -------------------------------------------------------------------- Session 12: Medium Access Multichannel MAC Protocols for Wireless Networks Ritesh Maheshwari (Stony Brook University); Himanshu Gupta (Stony Brook University); Samir Das (Stony Brook University) RT-Link: A Time-Synchronized Link Protocol for Energy Constrained Multi-Hop Wireless Networks Anthony Rowe (Carnegie Mellon University); Rahul Mangharam (Carnegie Mellon University); Ragunathan Rajkumar (Carnegie Mellon University) Understanding the Gap between the IEEE 802.11 Protocol Performance and the Theoretical Limits Mathilde Durvy (EPFL); Patrick Thiran (EPFL) Throughput-Oriented MAC for Mobile Ad Hoc Networks with Variable Packet Sizes Ossama Younis (University of Arizona); Fan Wang (University of Arizona); Marwan Krunz (University of Arizona) -------------------------------------------------------------------- Session 13: Theoretical Foundations Topology Control to Simultaneously Achieve Near-Optimal Node Degree and Low Path Stretch in Ad Hoc Networks Ece Gelal (University of California, Riverside); Gentian Jakllari (University of California, Riverside); Srikanth Krishnamurthy (University of California, Riverside); Neal E. Young (University of California, Riverside) Distributed Linear Parameter Estimation in Sensor Networks Based on Laplacian Dynamics Consensus Algorithm Arindam Kumar Das (University of Washington); Mehran Mesbahi (University of Washington) On the Information Lifetime and the Localization Cost in Sensor Networks with Random Topologies Cedric Westphal (Nokia Research Center) Cooperation Enforcement in Autonomous MANETs under Noise and Imperfect Observation Zhu Ji (University of Maryland, College Park); Wei Yu (University of Maryland, College Park); K.J. Ray Liu (University of Maryland, College Park) *********************************** END OF WEDNESDAY PROGRAM *********** THURSDAY, September 28, 2006 8:30 AM - 10:00 AM: Panel/Invited Session: TBA 10:00 AM - 11:00 AM: Posters/Demos 11:00 AM - 12:30 PM: (2 Parallel Tracks - Sessions 14, 15) Session 14: Topology Control Joint Range and Load Considerations for Topology Control in Wireless Ad Hoc Networks Sajjad Zarifzadeh (University of Tehran); Amir Nayyeri (University of Tehran) Distributed Fair Transmit Power Adjustment for Vehicular Ad Hoc Networks Marc Torrent-Moreno (University of Karlsruhe); Paolo Santi (CNR); Hannes Hartenstein (University of Karlsruhe) Low-Complexity Beamforming Techniques for Wireless Multihop Networks Robert Vilzmann (Technische Universit t Mnchen); Jrg Widmer (DoCoMo Euro-Labs); Imad Aad (DoCoMo Euro-Labs); Christian Hartmann (Technische Universit t Mnchen) Energy Efficient Transmission Scheme for Data-Gathering in Mobile Sensor Networks Chao Wang (University of Wisconsin, Madison); Parmesh Ramanathan (University of Wisconsin at Madison) Session 15: Energy Management LEARN: Localized Energy Aware Restricted Neighborhood Routing for Ad Hoc Networks Xiang-Yang Li (Illinois Institute of Technology); Yu Wang (Univeristy of North Carolina at Charlotte); Wen-Zhan Song (Washington State University, Vancouver); Weizhao Wang (Illinois Institute of Technology) A New Method for Distributing Power Usage Across a Sensor Network Patrick Vincent (Naval Postgraduate School); Murali Tummala (Naval Postgraduate School); John McEachen (Naval Postgraduate School) Energy Efficient Network Reconfiguration for Mostly-Off Sensor Networks Yuan Li (University of Southern California); Wei Ye (University of Southern California); John Heidemann (University of Southern California) 2:00 PM - 3:30 PM: (2 Parallel Tracks - Sessions 16, 17) Session 16: Localization and Ranging II Distance Matrix Reconstruction from Incomplete Distance Information for Sensor Network Localization Petros Drineas (RPI); Asif Javed (Rensselaer Polytechnic Institute); Malik Magdon-Ismail (RPI); Gopal Pandurangan (Purdue University); Reino Virrankoski (Helsinki University of Technology) ; Andreas Savvides (Yale University) MERIT: MEsh of RF sensors for Indoor Tracking Yui-Wah Lee (Bell Labs, Lucent Technologies); Erich Stuntebeck (Georgia Institute of Technology); Scott Miller (Bell Labs, Lucent Technologies) Reducing the Computational Cost of Bayesian Indoor Positioning Systems Konstantin Kleisouris (Rutgers University); Richard Martin (Rutgers University) Sensor-Enhanced Mobility Prediction for Energy-Efficient Localization Chuang-wen You (National Taiwan University); Yi-Chao Chen (National Taiwan University); Hao-hua Chu (National Taiwan University); Polly Huang (National Taiwan University); Ji-Rung Chiang (National Taiwan University); Seng-Yong Lau (National Taiwan University) Session 17: Fault Tolerance Memento: A Health Monitoring System for Wireless Sensor Networks Stanislav Rost (Massachusetts Institute of Technology); Hari Balakrishnan (Massachusetts Institute of Technology) Cross-Layer Analysis of Error Control in Wireless Sensor Networks Mehmet Vuran (Georgia Institute of Technology); Ian Akyildiz (Georgia Institute of Technology) RideSharing: Fault Tolerant Aggregation in Sensor Networks Using Corrective Actions Sameh Gobriel (University of Pittsburgh); Sherif Khattab (University of Pittsburgh); Daniel Mosse (University of Pittsburgh); Jose Brustoloni (University of Pittsburgh); Rami Melhem (University of Pittsburgh) ======================================================================== CONFERENCE ORGANIZING COMMITEE ------------------------------ GENERAL CHAIR: Krishna Sivalingam, University of Maryland Baltimore County, krishna@umbc.edu TECHNICAL PROGRAM CO-CHAIRS: Mark Yarvis, Intel Corporation, mark.d.yarvis@intel.com Michele Zorzi, Universita' degli Studi di Padova, zorzi@dei.unipd.it POSTERS/DEMOS CO-CHAIRS: Stefano Basagni, Northeastern University, basagni@ece.neu.edu Cedric Westphal, Nokia, Cedric.Westphal@nokia.com PANELS CO-CHAIRS: Ian Chakeres, Boeing, ian.chakeres@gmail.com Lily Yang, Intel, lily.l.yang@intel.com WORKSHOPS CHAIR: Tom Hou, Virginia Tech, thou@vt.edu STUDENT TRAVEL GRANTS CHAIR: Wenye Wang, NCSU, wwang@eos.ncsu.edu PUBLICITY CHAIR: Wendi Heinzelman, University of Rochester, wheinzel@ece.rochester.edu EXHIBITS/SPONSORSHIPS CHAIR: Vishal Anand, SUNY Brockport, vanand@brockport.edu LOCAL ARRANGEMENTS CHAIR: Mohamed Eltoweissy, Virgina Tech, toweissy@vt.edu STANDING COMMITTEE: Fred Bauer (fred@fredbauer.com) [CHAIR] Harvey Freeman Sung-Ju Lee, HP Labs Prasant Mohapatra, University of California, Davis TECHNICAL PROGRAM COMMITTEE --------------------------- Abouzeid, Alhussein Rensselaer Polytechnic Institute Almeroth, Kevin University of California at Santa Barbara Banerjee, Sujata Hewlett-Packard Laboratories Banerjee, Suman University of Wisconsin Basagni, Stefano Northeastern University Belding-Royer, Elizabeth University of California at Santa Barbara Bianchi, Giuseppe University of Rome, Tor Vergata Boutaba, Raouf University of Waterloo Cao, Guohong Pennsylvania State University Cayirci, Erdal GeNeTLab Chandra, Surendar University of Notre Dame Chevillat, Pierre IBM Zurich Research Laboratory Choi, Sunghyun Seoul National Unversity Chuah, Chen-Nee University of California, Davis Das, Sajal University of Texas at Arlington Das, Samir SUNY at Stony Brook Ekici, Eylem Ohio State University ElBatt, Tamer Hughes Research Laboratories, LLC Ephremides, Anthony University of Maryland at College Park Giordano, Silvia University of Applied Science SUPSI, Lugano Hares, Susan NextHop Havinga, Paul University of Twente Helmy, Ahmed University of Southern California Iyer, Sridhar Indian Institute of Technology Jetcheva, Jorjeta Firetide, Inc. Jha, Sanjay University of New South Wales Kangude, Shantanu Texas Instruments, Inc. Kasera, Sneha University of Utah Ko, Young-Bae Ajou University Koodli, Rajeev Nokia Research Center Krishnamachari, Bhaskar University of Southern California Krishnamurthy, Lakshman Intel Corporation Langendoen, Koen Delft University of Technology Lee, Sung-Ju Hewlett-Packard Laboratories Li, Li Bell Labs, Lucent Technologies Martin, Richard Rutgers University Mohapatra, Prasant University of California, Davis Morabito, Giacomo University of Catania Nandagopal, Thyaga Bell Labs, Lucent Technologies Ning, Peng North Carolina State University Pagani, Elena University of Milano Papagiannaki, Konstantina Intel Corporation Petrioli, Chiara University of Rome, la Sapienza Popovski, Petar Aalborg University Qiu, Lili University of Texas at Austin Ramasubramanian, Srini Unviersity of Arizona Ramasubramanian, Venugopalan Cornell University Reisslein, Martin Arizona State University Rhee, Sokwoo Millennial Net Roemer, Kay Swiss Federal Institute of Technology, Zurich Santi, Paolo CNR (National Research Council), Italy Schurgers, Curt University of California at San Diego Shorey, Rajeev General Motors Research, Bangalore Singh, Harkirat Samsung Electronics Singh, Suresh Portland State University Srinivasan, Vikram National University of Singapore Stankovic, John University of Virginia Trappe, Wade Rutgers University Tseng, Yu-Chee National Chiao-Tung University Wang, Xudong Kiyon, Inc. Westphal, Cedric Nokia Research Center Widmer, Joerg DoCoMo Eurolabs Zhang, Junshan Arizona State University Zhang, Qian Hong Kong University of Science and Technology Zheng, Haitao University of California at Santa Barbara Znati, Taieb University of Pittsburgh -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Aug 14 10:01:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCczW-0003r9-MR; Mon, 14 Aug 2006 10:00:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBjAm-0003BV-Fo for mip4@ietf.org; Fri, 11 Aug 2006 22:24:24 -0400 Received: from ceres.inf.ufsc.br ([150.162.60.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBjAj-0007k2-Cq for mip4@ietf.org; Fri, 11 Aug 2006 22:24:24 -0400 Received: from ceres.inf.ufsc.br (localhost.inf.ufsc.br [127.0.0.1]) by ceres.inf.ufsc.br (Departamento de Informatica e Estatistica (INE/CTC/UFSC)) with ESMTP id 96A032EE49 for ; Fri, 11 Aug 2006 23:24:21 -0300 (BRT) X-Original-To: mycolleagues@inf.ufsc.br Delivered-To: mycolleagues@inf.ufsc.br Received: from localhost (localhost.inf.ufsc.br [127.0.0.1]) by ceres.inf.ufsc.br (Departamento de Informatica e Estatistica (INE/CTC/UFSC)) with ESMTP id E87732E100 for ; Fri, 11 Aug 2006 23:04:20 -0300 (BRT) X-Virus-Scanned: amavisd-new at inf.ufsc.br Received: from ceres.inf.ufsc.br ([127.0.0.1]) by localhost (ceres.inf.ufsc.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3h3MOyD9xgE2 for ; Fri, 11 Aug 2006 23:04:19 -0300 (BRT) Received: from venus (venus.inf.ufsc.br [150.162.60.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ceres.inf.ufsc.br (Departamento de Informatica e Estatistica (INE/CTC/UFSC)) with ESMTP id AA4B62E0D0 for ; Fri, 11 Aug 2006 23:04:19 -0300 (BRT) Date: Fri, 11 Aug 2006 23:04:15 -0300 (BRT) From: Carlos Becker Westphall X-X-Sender: westphal@venus To: mycolleagues@inf.ufsc.br Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-851401618-1152337962=:6773" Content-ID: X-Mailman-Approved-At: Fri, 11 Aug 2006 23:07:25 -0300 X-BeenThere: mycolleagues@inf.ufsc.br X-Mailman-Version: 2.1.8 Precedence: list List-Archive: X-Spam-Score: 0.2 (/) X-Scan-Signature: 6437e26f1586b9f35812ea5ebeedf4ad X-Mailman-Approved-At: Mon, 14 Aug 2006 10:00:29 -0400 Cc: Subject: [Mip4] [mycolleagues] Submission deadline August 18 - SSI 2006 - 8th International Symposium on System and Information Security X-BeenThere: mip4@ietf.org Reply-To: mycolleagues@inf.ufsc.br List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-851401618-1152337962=:6773 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1; FORMAT=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: Just one week to submit papers. ------------------------------------------------------------- =09=09 CALL FOR PAPERS =09=09=09SSI=B42006 8th International Symposium on System and Information Security =09Sao Jose dos Campos, Sao Paulo, Brazil =09=09November 08-10, 2006 =09Submission Deadline: August 18, 2006 =09http://www.ssi.org.br/english/ =09=09 Organized by =09Technological Institute of Aeronautics - ITA =09Department of Computer Engineering =09Casimiro Montenegro Filho Foundation IEEE CNOM and CIS TC technical co-sponsorship =09Supported by IEEE South Brazil Section ------------------------------------------------------------- In addition, authors of selected excellent scientific papers of SSI 2006 will be invited to submit an extended version to be considered for publication in the IEEE/SBrT JCIS (JOURNAL OF COMMUNICATION AND INFORMATION SYSTEMS) and SPRINGER JNSM (JOURNAL OF NETWORK AND SYSTEMS MANAGEMENT). ------------------------------------------------------------- INTRODUCTION The International Symposium on System and Information Security (SSI) is organized by Instituto Tecnologico de Aeronautica (ITA) and is the foremost event of its kind in Latin America. Each year, researchers, students, and practitioners from academia, industry, and government organizations convene in Sao Jose' dos Campos, Brazil, to present and discuss the latest research and developments in the area. Recent SSI speakers have included Radia Perlman (Sun), Peter Gutmann (Univ. Auckland), Ravi Sandhu (George Mason University), Wietse Venema (IBM TJ Watson), Michael Howard (Microsoft), and David Chaum (SureVote). Featuring tracks for refereed and invited technical papers, keynote speakers, panels, special-topic workshops, tutorials, and industry exhibits, SSI attracts yearly around 350 participants from Brazil and around the world. ------------------------------------------------------------- TOPICS OF INTEREST Submission of original papers on all aspects of computer and network security is invited. Topics of interest include but are not limited to the following: =2E Artificial Intelligence methods in system security =2E Authentication, access control and auditing =2E Computer forensics =2E Cryptography =2E Database security =2E Dependability =2E Digital certificates and Public Key Infrastructure - PKI =2E Digital Rights Management =2E E-commerce security =2E Firewalls and other security tools =2E Formal methods in system security =2E Internet/Web security =2E Intrusion detection and prevention =2E Management of enterprise security =2E Mobile code and agent security =2E Network security =2E New security paradigms =2E Operating systems security =2E Risk/vulnerability analysis, assessment and management =2E Security in electronic voting systems =2E Security of distributed systems =2E Security of emerging technologies =2E Security policies =2E Secure programming =2E Security in P2P and Grid computing =2E Threats and information warfare =2E Quantum security =2E Trust management =2E User privacy and anonymity =2E Viruses and other malicious code =2E Wireless and ubiquitous computing security =2E Signal and Image Proceesing for Security Systems ------------------------------------------------------------- LOCATION Sao Jose' dos Campos is located 80 km (50 mi.) from Sao Paulo at the heart of Brazil's aerospace industry. Featuring state-of-the-art transportation and communications infrastructure, Sao Jose' dos Campos has excellent hotels and restaurants. Ubatuba, Ilhabela, and other pristine beaches and verdant islands along famed Rio-Santos road are only an hour away. Campos do Jordao and other prime mountain resorts on Serra da Mantiqueira range are a similar distance away. Temperatures in Sao Jose' dos Campos in early November are usually around 21-23 C (70-75 F). ------------------------------------------------------------- IMPORTANT DATES Regular Papers Paper submission deadline: August 18, 2006 Acceptance notification: September 15, 2006 Final version due: September 25, 2006 Early registration: September 25, 2006 Thesis and Dissertations Award Summary-papers submission: September 11, 2006 Acceptance Notification: October 02, 2006 Final version due: October 13, 2006 ------------------------------------------------------------- PAPER SUBMISSION GUIDELINES Papers must be written in English (preferred) or Portuguese, and must be submitted electronically in Portable Document Format (pdf, preferred) or PostScript (ps) format. Maximum paper length will be 10 printed pages for full papers or 3 pages for short papers, including figures in IEEE 2-column style (see below for Template). Template with the required format for submissions: Word -- http://www.ssi.org.br/modelos/modelPaperSSI-1.rtf Papers should be submitted by the deadline to: https://submissoes.sbc.org.br/ssi2006 ------------------------------------------------------------- PUBLICATION For an accepted submission to be included in the Proceedings and scheduled for presentation at the symposium: (1) a final version that responds to reviewers' comments and conforms to the specified format must be submitted by the final-version deadline, and (2) at least one of the authors must register to the symposium by the early-registration deadline. Submissions accepted for oral or poster presentation will be published, respectively, as full or short papers in the symposium Proceedings. The Proceedings will be published in CD-ROM format, with ISBN indexing. A copy of the Proceedings will be included in the symposium's registration fee. Additional copies will be available for sale. ------------------------------------------------------------- "TERCIO PACITTI" BEST PAPER AWARDS A special committee will select, from among full paper submissions, one best paper and two honorable mentions. Authors of these papers will receive complimentary registration and award certificates at the symposium. ------------------------------------------------------------- THESIS AND DISSERTATION AWARD On the basis of papers resuming doctoral thesis, master of science and undergraduate dissertations, a special committee will select one best work in each category. Authors of these papers will receive complimentary registration and award certificates at the symposium. ------------------------------------------------------------- ORGANIZING COMMITTEE GENERAL CHAIR Jose M. Parente de Oliveira - ITA, Brazil TECHNICAL PROGRAM COMMITTEE CO-CHAIRS Carlos Becker Westphall - Federal Univ. of Santa Catarina, Brazil Jos=E9 Carlos Brustoloni - University of Pittsburgh, USA THESIS AND DISSERTATION AWARD CHAIR Mirela Sechi Moretti Annoni Notare - Fac. Barddal/SC TECHNICAL PROGRAM COMMITTEE Abdelmalek Benzekri - Universit=E9 Paul Sabatier, France Abderrahim Sekkaki - University Hassan II, Morocco Adilson Guelfi - State Univ. of Sao Paulo, Brazil Alessandro Anzaloni - ITA, Brazil Andreas Steffen=09- Hochschule fuer Technik Rapperswil, Switzerland Antonio Loureiro - Federal Univ. of Minas Gerais, Brazil Antonio Montes - CENPRA, Brazil Bart De Decker - Katholieke Universiteit Leuven, Belgium Carla Westphall - Federal Univ. of Santa Catarina, Brazil Celio de Albuquerque -=09Fluminense Federal University, Brazil Charles Palmer - IBM Research, USA Chen Hsiao-Hwa - National Sun Yat-Sen University, Taiwan Chuan-kun Wu - Chinese Academy of Sciences, China Clovis Fernandes - ITA, Brazil Dagmar Brechlerova - Faculty of Economics and Management, Czech Republic David Fuschi - GIUNTI Inteactive Labs, Italy Edson Moreira - State Univ. of Sao Paulo, Brazil Edward Moreno - UNIVEM, Brazil Felix Wu - University of California at Davis, USA Fran=E7ois Cosquer - Alcatel North America, Canada Gianluigi Me - University of Roma "Tor Vergata", Italy G=FCnther Pernul - University of Regensburg, Germany Guenter Schaefer - Technische Universit=E4t Ilmenau, Germany Hao Chi Wong - PARC, USA James Hong - POSTECH, Korea Javier L=F3pez - University of Malaga, Spain Jeroen de Graaf - Federal Univ. of Minas Gerais, Brazil Jo=E3o Barros - University of Porto, Portugal Jos=E9 Fernandez - =C9cole Polytechnique de Montr=E9al, Canada Keith Martin - University of London, UK Konrad Wrona - SAP Research Lab, France Kouichi Sakurai - Kyushu University, Japan Krishnamurthy Subramanian - National Informatics Center, India Lech Janczewski - University of Auckland, New Zealand Luca Vigano - ETH Zurich, Switzerland Luis de Moraes - Federal Univ. of Rio de Janeiro, Brazil Madjid Merabti - Liverpool John Moored University, UK Marcelo Alencar=09- Federal Univ. of Campina Grande, Brazil Markus Endler - PUC-Rio, Brazil M=E1rio Freire - University of Beira Interior, Portugal Martin Fredriksson - Blekinge institute of technology, Sweden Mehmet Hendekli=09- UNIDOST, Austria Michel Cukier - University of Maryland, USA Mirela Notare - Barddal University, Brazil Mohammed Sqalli - King Fahd University, Saudi Arabia Nazim Agoulmine - University of Evry, France Nei Soma - ITA, Brazil Osvaldo Imamura - CTA, Brazil Paulo Pires - Federal Univ. of Rio Grande do Norte, Brazil Pedro Veiga - University of Lisboa, Portugal Peter Gutmann - University of Auckland, New Zealand Peter Mueller - IBM Zurich, Switzerland Raouf Boutaba - University of Waterloo, Canada Ravi Sandhu - George Mason University, USA Ryszard Struzak=09- Research Institute for Telecommunications, Poland Sahin Albayrak - Technische Universitaet Berlin, Germany Shigeo Wada - Tokyo Denki University, Japan Stamatios Kartalopoulos=09- University of Oklahoma, USA Steven Furnell - University of Plymouth, UK Sushil Jajodia - George Mason University, USA Tak-ming Law - Hong Kong Institute of Vocational Education, China Vassily Soloviev - Motorola, Russia Vijay Varadharajan - Macquarie University, Australia Wietse Venema - IBM T.J. Watson Research Center, USA Y=FCcel Karabulut=09- SAP Research Center, USA Yuval Elovici - Ben-Gurion University, Israel ------------------------------------------------------------- SPONSORS IEEE CNOM and CIS TC technical co-sponsorship Supported by IEEE South Brazil Section SBC - Sociedade Brasileira de Computacao SUCESU/SP - Soc, Usuarios Informatica e Telecomunicacoes - SP CAPES - Coord. de Aperfeicoamento de Pessoal de Nivel Superior FAPESP - Fundacao de Amparo a Pesquisa do Estado de Sao Paulo FINEP - Financiadora de Estudos e Projetos CNPq - Conselho Nacional de Desenv. Cientifico e Tecnologico PETROBRAS - Petroleos Brasileiros S.A. Banco do Brasil S.A. Caixa Economica Federal ------------------------------------------------------------- ABOUT ITA Brazil's most selective Engineering school, ITA accepts yearly only about 150 students out of more than 8000 applicants. ITA is one of the few schools in Brazil that recruits students nationally and offers a residential campus where most students and faculty live. All students receive full scholarship from the Brazilian government. ITA's rigorous undergraduate programs are 5 years long and lead directly to professional degrees in Aeronautical, Electronics, Computer, Mechanical, or Civil Engineering. Average scores of ITA Electronics and Computer Engineering students in national comprehensive examinations for graduating engineers have consistently been the highest in Brazil. ITA was founded in 1950 as the initial institute in Brazil's Aerospace Technical Center (CTA), Latin America's largest research center. CTA's planner and ITA's first provost was Richard H. Smith, who previously headed the Aeronautics department at MIT. ITA was the first institution to offer Aeronautical and Electronics Engineering degrees and post-graduate degrees in Brazil. Embraer, now the world's leading regional-jet manufacturer, was spun off from ITA in 1969. ITA/CTA research in the 1970s is also behind Brazil's highly successful renewable-energy program. A majority of cars now sold in Brazil can use ethanol as fuel. ITA pioneered Computer Science in Brazil with the construction of the first computer in 1961 and Tercio Pacitti's best-selling books on numerical methods in the 1960s and 1970s (he would become ITA's provost in 1982). Computer Engineering was organized as an independent ITA department in 1989. ------------------------------------------------------------- FURTHER INFORMATION Conference announcements and updated information will be available at: http://www.ssi.org.br For other information, please send email to the general chair, Jose M. Parente de Oliveira (dir@ssi.org.br). ---559023410-851401618-1152337962=:6773 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mycolleagues mailing list mycolleagues@inf.ufsc.br http://listas.inf.ufsc.br/mailman/listinfo/mycolleagues ---559023410-851401618-1152337962=:6773 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ ---559023410-851401618-1152337962=:6773-- From mip4-bounces@ietf.org Tue Aug 15 15:51:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD4vS-00033P-Sq; Tue, 15 Aug 2006 15:50:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD4vK-00030y-Fy; Tue, 15 Aug 2006 15:50:02 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD4vK-00059t-5X; Tue, 15 Aug 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 2217C26E0C; Tue, 15 Aug 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GD4vK-0007S3-0o; Tue, 15 Aug 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 15 Aug 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: mip4@ietf.org Subject: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-00.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-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 IPv4 Working Group of the IETF. Title : Dual Stack Mobile IPv4 Author(s) : G. Tsirtsis, et al. Filename : draft-ietf-mip4-dsmipv4-00.txt Pages : 20 Date : 2006-8-15 This specification provides IPv6 extensions to the Mobile IPv4 protocol. The extensions allow a dual stack node to use IPv4 and IPv6 home addresses as well as to move between IPv4 and dual stack network infrastructures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-dsmipv4-00.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-mip4-dsmipv4-00.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-mip4-dsmipv4-00.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-8-15143008.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip4-dsmipv4-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip4-dsmipv4-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-8-15143008.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --NextPart-- From mip4-bounces@ietf.org Wed Aug 16 12:47:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDOXI-0003gb-0G; Wed, 16 Aug 2006 12:46:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDOXG-0003gF-9f; Wed, 16 Aug 2006 12:46:30 -0400 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDOXC-0002xg-Rm; Wed, 16 Aug 2006 12:46:30 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id k7GGkOaj028666; Wed, 16 Aug 2006 09:46:24 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id k7GGkLsr011263; Wed, 16 Aug 2006 11:46:22 -0500 (CDT) Message-ID: <44E34BDD.9080908@motorola.com> Date: Wed, 16 Aug 2006 18:46:21 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Internet-Drafts@ietf.org Subject: Re: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: mip4@ietf.org, i-d-announce@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Mobility for IPv4 > Working Group of the IETF. > > Title : Dual Stack Mobile IPv4 Author(s) : G. Tsirtsis, et al. > Filename : draft-ietf-mip4-dsmipv4-00.txt Thanks for submitting. And the Prefix Table? An IPv4 data structure defined in draft-ietf-nemo-v4-base-01.txt contains only IPv4 MNPs, should be extended to contain IPv6 MNPs too. The Prefix Table is used to check a certain IPv4 HoA is allowed to use a certain IPv6 MNP (mobile network prefix). If no Prefix Table then there's no effective means to ensure this. Alex -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Aug 16 13:10:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDOtd-0004OO-2j; Wed, 16 Aug 2006 13:09:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDOtc-0004OG-94; Wed, 16 Aug 2006 13:09:36 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDOtY-000494-Sr; Wed, 16 Aug 2006 13:09:36 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k7GH9TfB025751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 16 Aug 2006 10:09:30 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7GH8bU8010167; Wed, 16 Aug 2006 10:09:28 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Aug 2006 10:08:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-00.txt Date: Wed, 16 Aug 2006 10:08:37 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A11D7EE@NAEX14.na.qualcomm.com> In-Reply-To: <44E34BDD.9080908@motorola.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-00.txt Thread-Index: AcbBVZOKsjpho4hpTQG8Z7+JyJuJxQAAMNNg From: "Tsirtsis, George" To: "Alexandru Petrescu" X-OriginalArrivalTime: 16 Aug 2006 17:08:45.0791 (UTC) FILETIME=[A21EBEF0:01C6C156] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: mip4@ietf.org, i-d-announce@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org A "prefix table" is an implementation thing is it not? If I am not mistaken the dsmipv4 draft already contains the necessary SHOULDs/MUSTs for the behavior you are looking for. Whether this is done based on a table or something else is not a matter for the spec. George > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] > Sent: Wednesday, August 16, 2006 12:46 PM > To: Internet-Drafts@ietf.org > Cc: mip4@ietf.org; i-d-announce@ietf.org > Subject: Re: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-00.txt >=20 > Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. This draft is a work item of the Mobility for IPv4 > > Working Group of the IETF. > > > > Title : Dual Stack Mobile IPv4 Author(s) : G. Tsirtsis, et al. > > Filename : draft-ietf-mip4-dsmipv4-00.txt >=20 > Thanks for submitting. >=20 > And the Prefix Table? An IPv4 data structure defined in > draft-ietf-nemo-v4-base-01.txt contains only IPv4 MNPs, should be > extended to contain IPv6 MNPs too. The Prefix Table is used to check a > certain IPv4 HoA is allowed to use a certain IPv6 MNP (mobile network > prefix). If no Prefix Table then there's no effective means to ensure > this. >=20 > Alex >=20 > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Aug 16 13:24:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDP6m-00006N-Pg; Wed, 16 Aug 2006 13:23:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDP6l-000067-3m; Wed, 16 Aug 2006 13:23:11 -0400 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDP6i-0004pM-LG; Wed, 16 Aug 2006 13:23:11 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id k7GHMwx1006731; Wed, 16 Aug 2006 10:23:03 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id k7GHMu45025535; Wed, 16 Aug 2006 12:22:57 -0500 (CDT) Message-ID: <44E3546F.70108@motorola.com> Date: Wed, 16 Aug 2006 19:22:55 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Tsirtsis, George" Subject: Re: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-00.txt References: <7EB20EA0938B4D42A2D82689365C9B7A11D7EE@NAEX14.na.qualcomm.com> In-Reply-To: <7EB20EA0938B4D42A2D82689365C9B7A11D7EE@NAEX14.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: mip4@ietf.org, i-d-announce@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Tsirtsis, George wrote: > A "prefix table" is an implementation thing is it not? If I am not > mistaken the dsmipv4 draft already contains the necessary SHOULDs/MUSTs > for the behavior you are looking for. Whether this is done based on a > table or something else is not a matter for the spec. I agree that "table" sounds like an implementation variable, which could be represented as a "list" too, etc. Can I write then about this paragraph: > The home agent SHOULD check that all IPv6 packets received from the > mobile client over a tunnel from the home address or the care-of > address, include a source address that falls under the registered > IPv6 prefix(es) for that mobile client. With Mobile IPv6 NEMOv6 the Home Address of the MR does not necessarily fall under the registered IPv6 prefix (HoA can be different than MNP). One wouldn't want the moving networks implemented with DS-MIPv4 (instead of NEMOv6 over UDP tunnel) to lack this HoA-MNP dissociation. Alex -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Aug 16 13:29:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDPCB-0002Po-7N; Wed, 16 Aug 2006 13:28:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDPCA-0002Pj-HX for mip4@ietf.org; Wed, 16 Aug 2006 13:28:46 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDPC8-000538-6G for mip4@ietf.org; Wed, 16 Aug 2006 13:28:46 -0400 Received: from [10.1.201.3] ([10.1.201.3]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Aug 2006 10:28:42 -0700 Message-ID: <44E355C8.70703@azairenet.com> Date: Wed, 16 Aug 2006 10:28:40 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "Tsirtsis, George" Subject: Re: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-00.txt References: <7EB20EA0938B4D42A2D82689365C9B7A11D7EE@NAEX14.na.qualcomm.com> In-Reply-To: <7EB20EA0938B4D42A2D82689365C9B7A11D7EE@NAEX14.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Aug 2006 17:28:42.0783 (UTC) FILETIME=[6B953AF0:01C6C159] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: mip4@ietf.org, Alexandru Petrescu X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org in RFC 3963, the Prefix Table is a conceptual data structure. Vijay Tsirtsis, George wrote: > A "prefix table" is an implementation thing is it not? If I am not > mistaken the dsmipv4 draft already contains the necessary SHOULDs/MUSTs > for the behavior you are looking for. Whether this is done based on a > table or something else is not a matter for the spec. > > George > >> -----Original Message----- >> From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] >> Sent: Wednesday, August 16, 2006 12:46 PM >> To: Internet-Drafts@ietf.org >> Cc: mip4@ietf.org; i-d-announce@ietf.org >> Subject: Re: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-00.txt >> >> Internet-Drafts@ietf.org wrote: >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. This draft is a work item of the Mobility for IPv4 >>> Working Group of the IETF. >>> >>> Title : Dual Stack Mobile IPv4 Author(s) : G. > Tsirtsis, et al. >>> Filename : draft-ietf-mip4-dsmipv4-00.txt >> Thanks for submitting. >> >> And the Prefix Table? An IPv4 data structure defined in >> draft-ietf-nemo-v4-base-01.txt contains only IPv4 MNPs, should be >> extended to contain IPv6 MNPs too. The Prefix Table is used to check > a >> certain IPv4 HoA is allowed to use a certain IPv6 MNP (mobile network >> prefix). If no Prefix Table then there's no effective means to ensure >> this. >> >> Alex >> >> -- >> Mip4 mailing list: Mip4@ietf.org >> Web interface: https://www1.ietf.org/mailman/listinfo/mip4 >> Charter page: http://www.ietf.org/html.charters/mip4-charter.html >> Supplemental site: http://www.mip4.org/ > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Aug 16 14:07:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDPmh-0006ue-R7; Wed, 16 Aug 2006 14:06:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDPmg-0006uW-GE; Wed, 16 Aug 2006 14:06:30 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDPmf-0007Mh-5R; Wed, 16 Aug 2006 14:06:30 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k7GI6H4Y004314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 16 Aug 2006 11:06:18 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7GI6GC1007826; Wed, 16 Aug 2006 11:06:17 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Aug 2006 11:06:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-00.txt Date: Wed, 16 Aug 2006 11:06:00 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A11D801@NAEX14.na.qualcomm.com> In-Reply-To: <44E3546F.70108@motorola.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-00.txt Thread-Index: AcbBWLAMzND0f0SFRjKehmU+wIEOIwABVDIw From: "Tsirtsis, George" To: "Alexandru Petrescu" X-OriginalArrivalTime: 16 Aug 2006 18:06:15.0497 (UTC) FILETIME=[AA4E1B90:01C6C15E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: mip4@ietf.org, i-d-announce@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org DSMIPv4 supports the same functionality. The quoted text talks about "a source address that falls under the registered IPv6 prefix(es)". This wording I assumed, covered all the registered HoAs with any length prefix (including a prefix of 128). If this is not clear I can add a clarification. Thanks George > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] > Sent: Wednesday, August 16, 2006 1:23 PM > To: Tsirtsis, George > Cc: mip4@ietf.org; i-d-announce@ietf.org > Subject: Re: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-00.txt >=20 > Tsirtsis, George wrote: > > A "prefix table" is an implementation thing is it not? If I am not > > mistaken the dsmipv4 draft already contains the necessary SHOULDs/MUSTs > > for the behavior you are looking for. Whether this is done based on a > > table or something else is not a matter for the spec. >=20 > I agree that "table" sounds like an implementation variable, which could > be represented as a "list" too, etc. >=20 > Can I write then about this paragraph: > > The home agent SHOULD check that all IPv6 packets received from the > > mobile client over a tunnel from the home address or the care-of > > address, include a source address that falls under the registered > > IPv6 prefix(es) for that mobile client. >=20 > With Mobile IPv6 NEMOv6 the Home Address of the MR does not necessarily > fall under the registered IPv6 prefix (HoA can be different than MNP). > One wouldn't want the moving networks implemented with DS-MIPv4 (instead > of NEMOv6 over UDP tunnel) to lack this HoA-MNP dissociation. >=20 > Alex -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Aug 17 10:56:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDjGp-0007U4-R8; Thu, 17 Aug 2006 10:54:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDiEO-0004Yq-PG; Thu, 17 Aug 2006 09:48:20 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDhxB-0000qc-GR; Thu, 17 Aug 2006 09:30:33 -0400 Received: from firstclass.it.rit.edu ([129.21.21.97]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GDhjD-0005hX-Ia; Thu, 17 Aug 2006 09:16:11 -0400 Message-id: Date: Thu, 17 Aug 2006 09:14:05 -0400 X-Mailer: FirstClass 8.2 (build 8.094) X-FC-SERVER-TZ: 15729388 From: "Nirmala Shenoy" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.5 (--) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 X-Mailman-Approved-At: Thu, 17 Aug 2006 10:54:54 -0400 Subject: [Mip4] Call for Technical Demonstration at TridentCom 2007 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Apologies if you receive multiple copies Call for Technical Demonstration at TridentCom 2007 http://www.tridentcom.org/ The 3rd International IEEE/Create-Net Conference on Testbeds and Research Infrastructures for the Development of Networks and Communities will take place in Orlando, Florida, USA, during February 5-8, 2007 and it will include a session for live system demonstrations. This is an opportunity to feature mature systems or innovative prototypes that show how applied research results are implemented. We also encourage submission of a demo that has already been described in the published literature in sufficient details. In addition, the demo should be attractive, address an application of broad interest in such a way that it can be appreciated by a diverse audience, and clearly show the contributions to the conference themes. • Next Generation Internet Testbeds • Next Generation Wireless Network Testbeds • Next Generation Optical Network Testbeds • Ubiquitous Network Testbeds • Wireless Sensor Testbeds • Testbed Operation & Management for User Communities • Testbed Operation & Management for Research Communities • Testbed Cooperation & Integration • Innovative Measurements Methodologies & Tools • Traffic Measurements Testbeds • Software Tools to Support Distributed Testbeds / Virtual Laboratories • Management of Massive Databases of Experimental Data • Knowledge & Technology Transfer Procedures • Security (AAA) Testing on Open Testbeds • Social Impacts of Infrastructures • Infrastructure Real-Life Applications • Business Models for Infrastructure Budgeting & Planning • Infrastructure Renting & Pricing Policies • Vendors & Providers Partnerships Demo proposals should consist of: 1. - Title and Description of the Demo, A document (1- 4 pages) that should summarize and possibly provide references to previously published work, or provides sufficient details regarding the underlying technologies. In either case, the document should describe how the system is used to solve practically important problems, and may contain discussion of system implementation, deployment, or case studies of use in the field. In case of mature work, please include some novel (i.e., unpublished) aspect of the work so it can be included in the proceedings. 2. - Infrastructure Requirements, Itemize any equipment or facilities that you will require for your system demonstration 3- Biographical Sketch of the Presenter(s). 4 - All demonstrations should be supported by a poster during the conference, showing both the general set-up of the demo as well as illustrating the chief ideas of the solution. Important Dates Submission of demo September 30, 2006 Notification of acceptance November 30, 2006 ------------------------------------------------------------- -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Aug 17 15:34:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDncG-0000Tk-Lb; Thu, 17 Aug 2006 15:33:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDncF-0000Tc-C4 for mip4@ietf.org; Thu, 17 Aug 2006 15:33:19 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDncB-0003Jo-TE for mip4@ietf.org; Thu, 17 Aug 2006 15:33:19 -0400 Received: from wei.isi.edu (wei.isi.edu [128.9.160.23]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k7HJWEY12879 for ; Thu, 17 Aug 2006 12:32:14 -0700 (PDT) From: Wei Ye To: mip4@ietf.org Content-Type: text/plain Date: Thu, 17 Aug 2006 12:32:07 -0700 Message-Id: <1155843128.4064.27.camel@wei.isi.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.5) Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: weiye@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Subject: [Mip4] Call for Participation: ACM WUWNet'06 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Our Apologies if you have received multiple copies. Volkan Rodoplu and Wei Ye WUWNet 2006 Publicity Co-Chairs ----------------------------------------------------- The First ACM International Workshop on UnderWater Networks (WUWNet 2006) http://wuwnet.engr.uconn.edu/ In conjunction with ACM MobiCom 2006 September 25, 2006 Los Angeles, California, USA Sponsored by ACM SIGMOBILE Technical Co-Sponsorship: IEEE Oceanographic Engineering Society Financial Support From: Boeing, DARPA, MIT SeaGrant, NSF ----------------------------------------------------- CALL FOR PARTICIPATION WUWNet 2006 is the first international workshop on underwater networks in the networking and communications community. The final program comprises 3 invited talks, 10 full technical paper presentations, a poster/demo session including short papers, work-in-progress posters and demos (from both industries and academia), and a fascinating panel entitled "Underwater Networks: Methods, Systems, and Applications". Early registration deadline is Sun, Sep. 3rd, 2006. To register for the workshop, please visit: http://www.sigmobile.org/mobicom/2006/registration.html TENTATIVE PROGRAM 07:00-08:30 Registration/Breakfast 08:30-08:40 Welcome Address 08:40-09:40 Tutorials (Session Chair: Milica Stojanovic, MIT/WHOI) * Acoustic Propagation Considerations for Underwater Acoustic Communications Network Development James Preisig (WHOI) * Modulation and Demodulation Techniques for Underwater Acoustic Communications John Proakis (UCSD) * State-of-the-Art in Protocol Research for Underwater Sensor Networks Ian Akyildiz (Georgia Institute of Technology) 09:40-10:40 Session 1: Systems (Session Chair: Jun-Hong Cui, UCONN) * A Survey of Practical Issues in Underwater Networks Jim Partan (UMASS, Amherst), Lee Freitag (WHOI), Jim Kurose (UMASS, Amherst) * Wide Area Ocean Networks: Architecture and System Design Considerations Sumit Roy, Payman Arabshahi, Dan Rouseff, Warren Fox (University of Washington) * Localization in Underwater Sensor Networks -- Survey and Challenges Vijay Chandrasekhar, Winston KG Seah (Institute for Infocomm Research, Singapore), Yoo Sang Choo, How Voon Ee (National University of Singapore) 10:40-11:00 Coffee break 11:00-12:00 Session 2: Analysis and Algorithms (Session Chair: Urbashi Mitra, USC) * On the relationship between capacity and distance in an underwater acoustic communication channel Milica Stojanovic (MIT/WHOI) * Deployment Analysis in Underwater Acoustic Wireless Sensor Networks Dario Pompili, Tommaso Melodia, Ian F. Akyildiz (Georgia Institute of Technology) * An Optimization Framework for Joint Sensor Deployment, Link Scheduling and Routing in Underwater Sensor Networks Leonardo Badia (IMT Lucca Institute for Advanced Studies, Italy), Michele Mastrogiovanni, Chiara Petrioli, Stamatis Stefanakos (University of Rome, Italy), Michele Zorzi (University of Padova, Italy) 12:00-14:20 Poster/Demo Session (including short papers, work-in-progress posters, and demos) and Lunch Poster Presenations * Sensor Networks of Freely Drifting Autonomous Underwater Explorers Jules S. Jaffe (Scripps Institution of Oceanography/UCSD), Curt Schurgers (UCSD) * Cooperative Multihop Communication for Underwater Acoustic Networks Cecilia Carbonelli (Qualcomm), Urbashi Mitra (USC) * Reconfigurable Acoustic Modem for Underwater Sensor Networks Ethem M. Sozer, Milica Stojanovic (MIT) * Why Underwater Acoustic Nodes Should Sleep With One Eye Open: Idle-time Power Management In Underwater Sensor Networks Albert F. Harris III (University of Padova, Italy), Milica Stojanovic (MIT, USA), Michele Zorzi (University of Padova, Italy) * On Applying Network Coding to Underwater Sensor Networks Zheng Guo, Peng Xie, Jun-Hong Cui, Bing Wang (University of Connecticut) * A MAC Protocol for Ad-Hoc Underwater Acoustic Sensor Networks Borja Peleato, Milica Stojanovic (MIT) 14:20-15:50 Panel Discussion: "Underwater Networks: Methods, Systems, and Applications" Confirmed Panelists: * Chris Clark (Cornell) * Scott Galagher (WHOI) * John Heidemann (USC) * Richard Nielsen (Boeing) * Jason Redi (BBN) * Thomas Torgersen (UCONN) 15:50-16:10 Coffee break 16:10-17:30 Session 3: System Design (Session Chair: Kevin Fall, Intel Research) * Electromagnetic Communications within Swarms of Autonomous Underwater Vehicles Michael R. Frater, Michael J. Ryan, Robin M. Dunbar (The University of New South Wales, Australia) * Design of a Low-cost Acoustic Modem for Moored Oceanographic Applications Bridget Benson, Grace Chang, Derek Manov, Brian Graham, Ryan Kastner (UCSB) * Low-Power Acoustic Modem for Dense Underwater Sensor Networks Jack Wills, Wei Ye, John Heidemann (USC/ISI) * Status Packet Deprecation and Store-Forward Routing in AUSNet Matthew Haag, Emmanuel Agu (Worcester Polytechnic Institute), Rick Komerska, Steven G. Chappell (Autonomous Undersea Systems Institute), Radim Bartos (University of New Hampshire) 17:30-17:40 Wrap-up and end of workshop -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Aug 17 18:10:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDq3Y-000392-BQ; Thu, 17 Aug 2006 18:09:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDq3W-00038x-Ve for mip4@ietf.org; Thu, 17 Aug 2006 18:09:38 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDq3U-0000aP-Jw for mip4@ietf.org; Thu, 17 Aug 2006 18:09:38 -0400 Received: from wei.isi.edu (wei.isi.edu [128.9.160.23]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k7HM8XY06622 for ; Thu, 17 Aug 2006 15:08:33 -0700 (PDT) From: Wei Ye To: mip4@ietf.org Content-Type: text/plain Date: Thu, 17 Aug 2006 15:08:27 -0700 Message-Id: <1155852507.4064.61.camel@wei.isi.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.5) Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: weiye@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Subject: [Mip4] ACM WUWNet'06 call for work-in-progress posters X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Our Apologies if you have received multiple copies. Volkan Rodoplu and Wei Ye WUWNet 2006 Publicity Co-Chairs ----------------------------------------------------- The First ACM International Workshop on UnderWater Networks (WUWNet 2006) http://wuwnet.engr.uconn.edu/ In conjunction with ACM MobiCom 2006 September 25, 2006 Los Angeles, California, USA Sponsored by ACM SIGMOBILE Technical Co-Sponsorship: IEEE Oceanographic Engineering Society Financial Support From: Boeing, DARPA, MIT SeaGrant, NSF ----------------------------------------------------- CALL FOR WORK-IN-PROGRESS POSTERS The work-in-progress poster session will provide a forum for researchers to showcase their work and obtain feedback on ongoing research from conference attendees. Topics of interest include, but are not limited to: - Network architecture design - Efficient acoustic communications - Cooperative underwater communications - Medium access control - Routing and forwarding - Reliable data transfer - Security and robustness - Power management - Data storage and management - Localization and synchronization - Data fusion, dissemination, tracking - Network modeling and simulations - Capacity analysis - New techniques for aquatic applications - New applications for underwater networks POSTER SUBMISSION INSTRUCTIONS Please submit an extended abstract (no more than 2 pages) of your poster as a PDF e-mail attachment to wuwnet06.poster.chairs@gmail.com with the subject line reading "WUWNet Poster Submission" before the deadline. Please be as specific as possible in describing what you will show. Accepted abstracts will be posted and maintained on the workshop website. IMPORTANT DATES Extended abstract due date: 11:59pm (EST), August 27, 2006 Notification of acceptance: August 31, 2006 Web abstract due date: September 8, 2006 Workshop date: September 25, 2006 Work-In-Progress Poster Committee Jun-Hong Cui, UCONN We Ye, USC/ISI Shengli Zhou, UCONN -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Aug 18 07:19:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE2Mr-0004M3-HN; Fri, 18 Aug 2006 07:18:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE2Mq-0004Kp-45 for mip4@ietf.org; Fri, 18 Aug 2006 07:18:24 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GE2Me-0003UD-Tz for mip4@ietf.org; Fri, 18 Aug 2006 07:18:24 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1EDE38E0002; Fri, 18 Aug 2006 13:18:10 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Aug 2006 13:18:09 +0200 Received: from [147.214.26.80] ([147.214.26.80]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Aug 2006 13:18:08 +0200 Message-ID: <44E5A1F0.9080801@ericsson.com> Date: Fri, 18 Aug 2006 13:18:08 +0200 From: =?ISO-8859-1?Q?Eva_Fogelstr=F6m?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Tsirtsis, George" Subject: Re: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt References: <2979E38DD6FC6544B789C8DAD7BAFC520242141C@xmb-sjc-235.amer.cisco.com> In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC520242141C@xmb-sjc-235.amer.cisco.com> X-OriginalArrivalTime: 18 Aug 2006 11:18:08.0924 (UTC) FILETIME=[FBFF15C0:01C6C2B7] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 6379955759c38e2371a49573a0932fc7 Cc: "Kent Leung \(kleung\)" , mip4@ietf.org, Jari Arkko X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2136328730==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============2136328730== Content-Type: multipart/alternative; boundary="------------060104090702090400040602" This is a multi-part message in MIME format. --------------060104090702090400040602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi George, I have added an optional regional registration lifetime extension to the=20 draft. Eva Kent Leung (kleung) wrote: > Yes, I think using the GFA-Lifetime extension is better for separation=20 > of registration lifetime maintenance. > =20 > Kent > > -------------------------------------------------------------------= ----- > *From:* Tsirtsis, George [mailto:tsirtsis@qualcomm.com] > *Sent:* Thursday, August 03, 2006 3:37 AM > *To:* Eva Fogelstr=F6m > *Cc:* Jari Arkko; Kent Leung (kleung); mip4@ietf.org > *Subject:* RE: [Mip4] Re: AD review of > draft-ietf-mip4-reg-tunnel-02.txt > > The reason I think the GFA should be able to have a different > lifetime than the HA is because I anticipate regional registration > to be deployed in the context of roaming between > domains/operators. i.e., a mobile has an HA in its home operator. > When it moves to another operator it uses a GFA for local mobility > management. The GFA is provided by the local operator and has its > own requirements. It is typically in the industry that each > domain/operator has control over its own infrastructure and does > not depend on configuration in a third operator (unless absolutely > necessary). Such refresh lifetimes is one such parameter that they > can control. > > =20 > > I will also reiterate that your draft supports this concept > already, since the GFA can impose its own lifetime **after** a > handoff takes place. All I am saying is that if the GFA needs to > impose its own lifetime it should be able to impose it immediately. > > =20 > > As to the solution I suggested, it is just one solution. Another, > possibly better solution, would be to define a GFA-Lifetime > extension which the GFA can include in the Registration Reply > during the initial MN-FA-GFA-HA registration. This does what I am > suggesting without requiring a regional registration with the GFA. > > =20 > > George > > =20 > > -------------------------------------------------------------------= ----- > > *From:* Eva Fogelstr=F6m [mailto:eva.fogelstrom@ericsson.com] > *Sent:* Thursday, August 03, 2006 3:11 AM > *To:* Tsirtsis, George > *Cc:* Jari Arkko; Kent Leung (kleung); mip4@ietf.org > *Subject:* Re: [Mip4] Re: AD review of > draft-ietf-mip4-reg-tunnel-02.txt > > =20 > > Hi George, > > I understand what you want to do, but I don't understand the > motivation for it. In particular, I don't understand why being > able to define a separate lifetime at the GFA (compared to the HA) > would motivate a mandatory double registration (home + regional > registration) each time the MN registers with its HA. > > Eva > > Tsirtsis, George wrote: > > In line... > > =20 > > -------------------------------------------------------------------= ----- > > *From:* Eva Fogelstr=F6m [mailto:eva.fogelstrom@ericsson.com] > *Sent:* Wednesday, August 02, 2006 10:59 AM > *To:* Tsirtsis, George > *Cc:* Jari Arkko; Kent Leung (kleung); mip4@ietf.org > > *Subject:* Re: [Mip4] Re: AD review of > draft-ietf-mip4-reg-tunnel-02.txt > > =20 > > Hi George, > ... > > Since you are making some changes I also have one more suggestion. > According to the draft, the mobile first registers with the HA > using regular registrations (+some extensions) and then uses > regional registrations to the GFA if it handoffs within the area > covered by the local GFA. The draft does not currently require the > mobile to register with the GFA until it hands off. This creates > the following issues which is a bit strange. Once the mobile > hands-off and uses regional registration, the GFA can define a > Lifetime that is equal to or smaller than the Lifetime defined by > the HA. This makes sense but the strange thing is that the GFA can > not impose its desired lifetime for regional registrations until > the mobile hands-off in its region. > > =20 > > I think this can be trivially fixed by requiring that the mobile > uses regional registration immediately after normal registration > when a GFA is present, and even if the mobile does not hand-off. > > =20 > > Thoughts? > > George > > > I'm not sure I follow. When the MN does a home registration with > its HA, the GFA acts as foreign agent towards the HA. The > registration request goes as follows: MN-FA-GFA-HA. Ok? > > GT> Yes > > > The GFA is a foreign agent, as defined in RFC3344, with some > additions. In my understanding, this means that if the GFA does > not approve of the lifetime in the registration request when it > receives it, it can simply deny the home registration with error > code 69 (requested lifetime too long). > > GT> Yes, but what you describe would result in the lower Lifetime > be forced to the Home Agent too, which is not ideal. What I am > looking for here is separation of the refresh requirements imposed > by the Home and the Foreign domains. The GFA should be able to > require a Lifetime that is different (i.e., lower) than the > lifetime required by the HA, without affecting what the HA > requires. Note that your draft already allows for that but the > mobile has to first perform a handoff. At that point the GFA can > return a Lifetime that is independent from the lifetime returned > by the HA. Is this clearer? > > George > --------------060104090702090400040602 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi George,

I have added an optional regional registration lifetime extension to the draft.

Eva

Kent Leung (kleung) wrote:
Yes, I think using the GFA-Lifetime extension is better for separation of registration lifetime maintenance.
 
Kent

From: Tsirtsis, George [mailto:tsirtsis@qualcomm.com]
Sent: Thursday, August 03, 2006 3:37 AM
To: Eva Fogelström
Cc: Jari Arkko; Kent Leung (kleung); mip4@ietf.org
Subject: RE: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt

The reason I think the GFA should be able to have a different lifetime than the HA is because I anticipate regional registration to be deployed in the context of roaming between domains/operators. i.e., a mobile has an HA in its home operator. When it moves to another operator it uses a GFA for local mobility management. The GFA is provided by the local operator and has its own requirements. It is typically in the industry that each domain/operator has control over its own infrastructure and does not depend on configuration in a third operator (unless absolutely necessary). Such refresh lifetimes is one such parameter that they can control.

 

I will also reiterate that your draft supports this concept already, since the GFA can impose its own lifetime *after* a handoff takes place. All I am saying is that if the GFA needs to impose its own lifetime it should be able to impose it immediately.

 

As to the solution I suggested, it is just one solution. Another, possibly better solution, would be to define a GFA-Lifetime extension which the GFA can include in the Registration Reply during the initial MN-FA-GFA-HA registration. This does what I am suggesting without requiring a regional registration with the GFA.

 

George

 

From: Eva Fogelström [mailto:eva.fogelstrom@ericsson.com]
Sent: Thursday, August 03, 2006 3:11 AM
To: Tsirtsis, George
Cc: Jari Arkko; Kent Leung (kleung); mip4@ietf.org
Subject: Re: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt

 

Hi George,

I understand what you want to do, but I don't understand the motivation for it. In particular, I don't understand why being able to define a separate lifetime at the GFA (compared to the HA) would motivate a mandatory double registration (home + regional registration) each time the MN registers with its HA.

Eva

Tsirtsis, George wrote:

In line…

 

From: Eva Fogelström [mailto:eva.fogelstrom@ericsson.com]
Sent: Wednesday, August 02, 2006 10:59 AM
To: Tsirtsis, George
Cc: Jari Arkko; Kent Leung (kleung); mip4@ietf.org
Subject: Re: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt

 

Hi George,
…

Since you are making some changes I also have one more suggestion. According to the draft, the mobile first registers with the HA using regular registrations (+some extensions) and then uses regional registrations to the GFA if it handoffs within the area covered by the local GFA. The draft does not currently require the mobile to register with the GFA until it hands off. This creates the following issues which is a bit strange. Once the mobile hands-off and uses regional registration, the GFA can define a Lifetime that is equal to or smaller than the Lifetime defined by the HA. This makes sense but the strange thing is that the GFA can not impose its desired lifetime for regional registrations until the mobile hands-off in its region.

 

I think this can be trivially fixed by requiring that the mobile uses regional registration immediately after normal registration when a GFA is present, and even if the mobile does not hand-off.

 

Thoughts?

George


I'm not sure I follow. When the MN does a home registration with its HA, the GFA acts as foreign agent towards the HA. The registration request goes as follows: MN-FA-GFA-HA. Ok?

GT> Yes


The GFA is a foreign agent, as defined in RFC3344, with some additions. In my understanding, this means that if the GFA does not approve of the lifetime in the registration request when it receives it, it can simply deny the home registration with error code 69 (requested lifetime too long).

GT> Yes, but what you describe would result in the lower Lifetime be forced to the Home Agent too, which is not ideal. What I am looking for here is separation of the refresh requirements imposed by the Home and the Foreign domains. The GFA should be able to require a Lifetime that is different (i.e., lower) than the lifetime required by the HA, without affecting what the HA requires. Note that your draft already allows for that but the mobile has to first perform a handoff. At that point the GFA can return a Lifetime that is independent from the lifetime returned by the HA. Is this clearer?

George

--------------060104090702090400040602-- --===============2136328730== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============2136328730==-- From mip4-bounces@ietf.org Fri Aug 18 08:07:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE37A-0008Tz-A6; Fri, 18 Aug 2006 08:06:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE378-0008Tu-SV for mip4@ietf.org; Fri, 18 Aug 2006 08:06:14 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GE377-0001ct-VK for mip4@ietf.org; Fri, 18 Aug 2006 08:06:14 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k7IC678v021254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 18 Aug 2006 05:06:08 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7IC64X8009626; Fri, 18 Aug 2006 05:06:05 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Aug 2006 05:06:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt Date: Fri, 18 Aug 2006 05:05:57 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A11D957@NAEX14.na.qualcomm.com> In-Reply-To: <44E5A1F0.9080801@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt Thread-Index: AcbCuARpWBy6JkKZRVC7UP042iTJ+AABnT7Q From: "Tsirtsis, George" To: =?iso-8859-1?Q?Eva_Fogelstr=F6m?= X-OriginalArrivalTime: 18 Aug 2006 12:06:04.0060 (UTC) FILETIME=[ADB605C0:01C6C2BE] X-Spam-Score: 0.0 (/) X-Scan-Signature: fe6e20eef2d8927c50910823cd0d1c84 Cc: "Kent Leung \(kleung\)" , mip4@ietf.org, Jari Arkko X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1952165783==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============1952165783== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6C2BE.ACF6CB9D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6C2BE.ACF6CB9D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks Eva, =20 It is appreciated. =20 Regards George =20 ________________________________ From: Eva Fogelstr=F6m [mailto:eva.fogelstrom@ericsson.com]=20 Sent: Friday, August 18, 2006 7:18 AM To: Tsirtsis, George Cc: Kent Leung (kleung); Jari Arkko; mip4@ietf.org Subject: Re: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt =20 Hi George, I have added an optional regional registration lifetime extension to the = draft. Eva Kent Leung (kleung) wrote: Yes, I think using the GFA-Lifetime extension is better for separation = of registration lifetime maintenance. =20 Kent =20 =09 ________________________________ From: Tsirtsis, George [mailto:tsirtsis@qualcomm.com]=20 Sent: Thursday, August 03, 2006 3:37 AM To: Eva Fogelstr=F6m Cc: Jari Arkko; Kent Leung (kleung); mip4@ietf.org Subject: RE: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt The reason I think the GFA should be able to have a different lifetime = than the HA is because I anticipate regional registration to be deployed = in the context of roaming between domains/operators. i.e., a mobile has = an HA in its home operator. When it moves to another operator it uses a = GFA for local mobility management. The GFA is provided by the local = operator and has its own requirements. It is typically in the industry = that each domain/operator has control over its own infrastructure and = does not depend on configuration in a third operator (unless absolutely = necessary). Such refresh lifetimes is one such parameter that they can = control. =20 I will also reiterate that your draft supports this concept already, = since the GFA can impose its own lifetime *after* a handoff takes place. = All I am saying is that if the GFA needs to impose its own lifetime it = should be able to impose it immediately. =20 As to the solution I suggested, it is just one solution. Another, = possibly better solution, would be to define a GFA-Lifetime extension = which the GFA can include in the Registration Reply during the initial = MN-FA-GFA-HA registration. This does what I am suggesting without = requiring a regional registration with the GFA.=20 =20 George =20 =09 ________________________________ From: Eva Fogelstr=F6m [mailto:eva.fogelstrom@ericsson.com]=20 Sent: Thursday, August 03, 2006 3:11 AM To: Tsirtsis, George Cc: Jari Arkko; Kent Leung (kleung); mip4@ietf.org Subject: Re: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt =20 Hi George, =09 I understand what you want to do, but I don't understand the motivation = for it. In particular, I don't understand why being able to define a = separate lifetime at the GFA (compared to the HA) would motivate a = mandatory double registration (home + regional registration) each time = the MN registers with its HA. =09 Eva =09 Tsirtsis, George wrote: In line... =20 =09 ________________________________ From: Eva Fogelstr=F6m [mailto:eva.fogelstrom@ericsson.com]=20 Sent: Wednesday, August 02, 2006 10:59 AM To: Tsirtsis, George Cc: Jari Arkko; Kent Leung (kleung); mip4@ietf.org Subject: Re: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt =20 Hi George, ... Since you are making some changes I also have one more suggestion. = According to the draft, the mobile first registers with the HA using = regular registrations (+some extensions) and then uses regional = registrations to the GFA if it handoffs within the area covered by the = local GFA. The draft does not currently require the mobile to register = with the GFA until it hands off. This creates the following issues which = is a bit strange. Once the mobile hands-off and uses regional = registration, the GFA can define a Lifetime that is equal to or smaller = than the Lifetime defined by the HA. This makes sense but the strange = thing is that the GFA can not impose its desired lifetime for regional = registrations until the mobile hands-off in its region. =20 I think this can be trivially fixed by requiring that the mobile uses = regional registration immediately after normal registration when a GFA = is present, and even if the mobile does not hand-off.=20 =20 Thoughts? George =09 I'm not sure I follow. When the MN does a home registration with its = HA, the GFA acts as foreign agent towards the HA. The registration = request goes as follows: MN-FA-GFA-HA. Ok? GT> Yes =09 The GFA is a foreign agent, as defined in RFC3344, with some additions. = In my understanding, this means that if the GFA does not approve of the = lifetime in the registration request when it receives it, it can simply = deny the home registration with error code 69 (requested lifetime too = long). GT> Yes, but what you describe would result in the lower Lifetime be = forced to the Home Agent too, which is not ideal. What I am looking for = here is separation of the refresh requirements imposed by the Home and = the Foreign domains. The GFA should be able to require a Lifetime that = is different (i.e., lower) than the lifetime required by the HA, without = affecting what the HA requires. Note that your draft already allows for = that but the mobile has to first perform a handoff. At that point the = GFA can return a Lifetime that is independent from the lifetime returned = by the HA. Is this clearer? George ------_=_NextPart_001_01C6C2BE.ACF6CB9D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thanks Eva,

 

It is = appreciated.

 

Regards

George

 

From: Eva Fogelstr=F6m [mailto:eva.fogelstrom@ericsson.com] =
Sent: Friday, August 18, = 2006 7:18 AM
To: Tsirtsis, George
Cc: Kent Leung (kleung); = Jari Arkko; mip4@ietf.org
Subject: Re: [Mip4] Re: = AD review of draft-ietf-mip4-reg-tunnel-02.txt

 

Hi George,

I have added an optional regional registration lifetime extension to the = draft.

Eva

Kent Leung (kleung) wrote:

Yes, I think using the GFA-Lifetime extension is better for separation of registration lifetime = maintenance.

 

Kent

 

From: Tsirtsis, George [mailto:tsirtsis@qualcomm.com]
Sent: Thursday, August = 03, 2006 3:37 AM
To: Eva Fogelstr=F6m
Cc: Jari Arkko; Kent = Leung (kleung); mip4@ietf.org
Subject: RE: [Mip4] Re: = AD review of draft-ietf-mip4-reg-tunnel-02.txt

The reason I think the GFA should = be able to have a different lifetime than the HA is because I anticipate regional registration to be deployed in the context of roaming between domains/operators. i.e., a mobile has an HA in its home operator. When = it moves to another operator it uses a GFA for local mobility management. The GFA = is provided by the local operator and has its own requirements. It is = typically in the industry that each domain/operator has control over its own = infrastructure and does not depend on configuration in a third operator (unless = absolutely necessary). Such refresh lifetimes is one such parameter that they can = control.

 

I will also reiterate that your = draft supports this concept already, since the GFA can impose its own lifetime = *after* a handoff takes place. All = I am saying is that if the GFA needs to impose its own lifetime it should be = able to impose it immediately.

 

As to the solution I suggested, it = is just one solution. Another, possibly better solution, would be to define a GFA-Lifetime extension which the GFA can include in the Registration = Reply during the initial MN-FA-GFA-HA registration. This does what I am = suggesting without requiring a regional registration with the GFA. =

 

George

 

From: Eva Fogelstr=F6m [mailto:eva.fogelstrom@ericsso= n.com]
Sent: Thursday, August = 03, 2006 3:11 AM
To: Tsirtsis, George
Cc: Jari Arkko; Kent = Leung (kleung); mip4@ietf.org
Subject: Re: [Mip4] Re: = AD review of draft-ietf-mip4-reg-tunnel-02.txt

 

Hi George,

I understand what you want to do, but I don't understand the motivation = for it. In particular, I don't understand why being able to define a separate = lifetime at the GFA (compared to the HA) would motivate a mandatory double = registration (home + regional registration) each time the MN registers with its = HA.

Eva

Tsirtsis, George wrote:

In = line…

 

From: Eva Fogelstr=F6m [mailto:eva.fogelstrom@ericsso= n.com]
Sent: Wednesday, August = 02, 2006 10:59 AM
To: Tsirtsis, George
Cc: Jari Arkko; Kent = Leung (kleung); mip4@ietf.org
Subject: Re: [Mip4] Re: = AD review of draft-ietf-mip4-reg-tunnel-02.txt

 

Hi George,
…

Since you are making some changes I = also have one more suggestion. According to the draft, the mobile first = registers with the HA using regular registrations (+some extensions) and then uses regional registrations to the GFA if it handoffs within the area covered = by the local GFA. The draft does not currently require the mobile to register = with the GFA until it hands off. This creates the following issues which is a bit strange. Once the mobile hands-off and uses regional registration, the = GFA can define a Lifetime that is equal to or smaller than the Lifetime defined = by the HA. This makes sense but the strange thing is that the GFA can not = impose its desired lifetime for regional registrations until the mobile hands-off = in its region.

 

I think this can be trivially fixed = by requiring that the mobile uses regional registration immediately after = normal registration when a GFA is present, and even if the mobile does not = hand-off.

 

Thoughts?

George


I'm not sure I follow. When the MN does a home registration with its HA, = the GFA acts as foreign agent towards the HA. The registration request goes = as follows: MN-FA-GFA-HA. Ok?

GT> Yes


The GFA is a foreign agent, as defined in RFC3344, with some additions. = In my understanding, this means that if the GFA does not approve of the = lifetime in the registration request when it receives it, it can simply deny the = home registration with error code 69 (requested lifetime too = long).

GT> Yes, but what you describe would result in the lower Lifetime be forced = to the Home Agent too, which is not ideal. What I am looking for here is = separation of the refresh requirements imposed by the Home and the Foreign domains. = The GFA should be able to require a Lifetime that is different (i.e., lower) = than the lifetime required by the HA, without affecting what the HA requires. = Note that your draft already allows for that but the mobile has to first perform a handoff. At that point the GFA can return a Lifetime that is independent = from the lifetime returned by the HA. Is this clearer?

George

------_=_NextPart_001_01C6C2BE.ACF6CB9D-- --===============1952165783== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1952165783==-- From mip4-bounces@ietf.org Fri Aug 18 17:17:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEBhP-0008Cs-Lw; Fri, 18 Aug 2006 17:16:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEBhO-0008CX-1n; Fri, 18 Aug 2006 17:16:14 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEBhM-0001E1-LY; Fri, 18 Aug 2006 17:16:14 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k7ILGAus020285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 18 Aug 2006 14:16:10 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7ILG8LJ008652; Fri, 18 Aug 2006 14:16:10 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Aug 2006 14:16:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 18 Aug 2006 14:16:05 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A11D9F9@NAEX14.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MIPv4 based flow movement Thread-Index: AcbDC4QtFV6hSEoLTJy44RBmpi344A== From: "Tsirtsis, George" To: , X-OriginalArrivalTime: 18 Aug 2006 21:16:07.0350 (UTC) FILETIME=[85346D60:01C6C30B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Subject: [Mip4] MIPv4 based flow movement X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi, We have published a draft providing a solution for per flow movement in the context of MIPv4. The proposal provides equivalent functionality to the draft-ietf-monami6-multiplecoa-00 and draft-soliman-monami6-flow-binding-01.txt but the design in based on extensions to MIPv4 instead of MIPv6. The draft defines Alternate-CoA and Flow Identification extensions. The later supports IPv4 and IPv6 filters and it is compatible to related NEMOv4 and DSMIPv4 work. You can find the draft at: http://www.ietf.org/internet-drafts/draft-tsirtsis-mip4-flowmove-00.txt To limit cross-posting I would suggest that if you have comments related to the concepts of multiple CoA and per flow movement, you should post them to Monami6 list. If you have comments on the details of how the proposal works over MIPv4 you should send them to the MIP4 list. Regards George P.S.: Abstract Mobile IPv4 allows Mobile Nodes (MN) to create mobility bindings between their Home Address (HoA) and their current Care-of Address (CoA) in a Home Agent (HA) so that the HA can redirect traffic for the MN to its current location. This draft extends MIPv4 so that the binding granularity is on a per flow basis. Extensions are defined to allow the registration of multiple CoAs and the definition of individual flows. Individual flows can then be pointed to the registered CoAs. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Aug 18 18:55:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEDEQ-0002JX-Cm; Fri, 18 Aug 2006 18:54:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEDEP-0002JS-Rz for mip4@ietf.org; Fri, 18 Aug 2006 18:54:25 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEDEN-000695-Gi for mip4@ietf.org; Fri, 18 Aug 2006 18:54:25 -0400 Received: from wee.isi.edu (wee.isi.edu [128.9.168.112]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k7IMrtY20982 for ; Fri, 18 Aug 2006 15:53:55 -0700 (PDT) From: Wei Ye To: mip4@ietf.org Content-Type: text/plain Date: Fri, 18 Aug 2006 15:53:50 -0700 Message-Id: <1155941630.13560.29.camel@wee.isi.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.5) Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: weiye@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Subject: [Mip4] ACM WUWNet'06 call for demos X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Our Apologies if you have received multiple copies. Volkan Rodoplu and Wei Ye WUWNet 2006 Publicity Co-Chairs ----------------------------------------------------- The First ACM International Workshop on UnderWater Networks (WUWNet 2006) http://wuwnet.engr.uconn.edu/ In conjunction with ACM MobiCom 2006 September 25, 2006 Los Angeles, California, USA Sponsored by ACM SIGMOBILE Technical Co-Sponsorship: IEEE Oceanographic Engineering Society Financial Support From: Boeing, DARPA, MIT SeaGrant, NSF ----------------------------------------------------- CALL FOR DEMOS -------------- Demonstrations of innovative research, applications, and products are solicited. Demonstrations of technology, platforms, application and products for all aspects of underwater networks are of strong interest. Submission from both industry and universities are encouraged. DEMO SUBMISSION INSTRUCTIONS Please submit an extended abstract (no more than 2 pages) of your demo as a PDF e-mail attachment to: james.w.nash@boeing.com and william.f.whitson@boeing.com with the subject line reading "WUWNet Demo Submission" before the deadline. Please be as specific as possible in describing what you will demonstrate or exhibit. The extended abstract should include a short description of space and equipment requirements. Accepted abstracts will be posted and maintained on the workshop website. IMPORTANT DATES Extended abstract due date: 11:59pm (EST), August 27, 2006 Notification of acceptance: August 31, 2006 Web abstract due date: September 8, 2006 Workshop date: September 25, 2006 WUWNet 2006 Demo Committee James W Nash, Boeing Dana M Graham, Boeing David J Hinkes, Boeing William F Whitson, Boeing -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Aug 21 10:18:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFAbE-0004eg-KZ; Mon, 21 Aug 2006 10:17:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEna8-00035W-Jo; Sun, 20 Aug 2006 09:43:16 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEnMF-0008Al-KS; Sun, 20 Aug 2006 09:28:56 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k7KDSour008111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 20 Aug 2006 06:28:50 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7KDSl5P009949; Sun, 20 Aug 2006 06:28:49 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 20 Aug 2006 06:28:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 20 Aug 2006 06:28:39 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A11DA34@NAEX14.na.qualcomm.com> In-Reply-To: <7EB20EA0938B4D42A2D82689365C9B7A11D9F9@NAEX14.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Monami6] MIPv4 based flow movement Thread-Index: AcbDC4QtFV6hSEoLTJy44RBmpi344ABUL+EA From: "Soliman, Hesham" To: "Monami6 WG" , X-OriginalArrivalTime: 20 Aug 2006 13:28:44.0045 (UTC) FILETIME=[8EEB2BD0:01C6C45C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 X-Mailman-Approved-At: Mon, 21 Aug 2006 10:17:56 -0400 Cc: Subject: [Mip4] RE: [Monami6] MIPv4 based flow movement X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Just one addition to George's email=20 > the context of MIPv4. The proposal provides equivalent=20 > functionality to > the draft-ietf-monami6-multiplecoa-00 and > draft-soliman-monami6-flow-binding-01.txt but the design in based on > extensions to MIPv4 instead of MIPv6. =3D> To be clear, George meant it is equivalent to the new draft-soliman which is coming out soon. I.e. draft-soliman + BID + a cleanup :) As we agreed in the last meeting with the chairs and BID authors, the two drafts are being coordinated together to make them more harmonious.=20 Hesham >=20 > The draft defines Alternate-CoA and Flow Identification=20 > extensions. The > later supports IPv4 and IPv6 filters and it is compatible to related > NEMOv4 and DSMIPv4 work. >=20 > You can find the draft at: > http://www.ietf.org/internet-drafts/draft-tsirtsis-mip4-flowm ove-00.txt >=20 > To limit cross-posting I would suggest that if you have=20 > comments related > to the concepts of multiple CoA and per flow movement, you=20 > should post > them to Monami6 list. If you have comments on the details of how the > proposal works over MIPv4 you should send them to the MIP4 list. >=20 > Regards > George >=20 > P.S.: Abstract >=20 > Mobile IPv4 allows Mobile Nodes (MN) to create mobility bindings > between their Home Address (HoA) and their current Care-of Address > (CoA) in a Home Agent (HA) so that the HA can redirect traffic for > the MN to its current location. This draft extends MIPv4=20 > so that the > binding granularity is on a per flow basis. Extensions=20 > are defined > to allow the registration of multiple CoAs and the definition of > individual flows. Individual flows can then be pointed to the > registered CoAs. >=20 >=20 > _______________________________________________ > Monami6 mailing list > Monami6@ietf.org > https://www1.ietf.org/mailman/listinfo/monami6 >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Aug 23 13:23:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFwRw-0006mX-R9; Wed, 23 Aug 2006 13:23:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFwRv-0006kP-J2 for mip4@ietf.org; Wed, 23 Aug 2006 13:23:31 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFwRr-0001ux-AY for mip4@ietf.org; Wed, 23 Aug 2006 13:23:31 -0400 Received: from [10.1.210.18] ([10.1.210.18]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Aug 2006 10:23:24 -0700 Message-ID: <44EC8F07.9080009@azairenet.com> Date: Wed, 23 Aug 2006 10:23:19 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: mip4@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Aug 2006 17:23:24.0873 (UTC) FILETIME=[D6FC4390:01C6C6D8] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Mip4] MIP4 client implementation X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hello, I wanted to update the list of Mobile IP implementations at the following URL. http://www.mip4.org/2004/implementations/ the web page says a mail should be sent to the MIP4 mailing list. so here it is IP version - IPv4 Operating System - Windows Name - Azaire Networks License - commercial Comments - Available as Windows SDK Vijay -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Aug 23 13:30:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFwYH-00018Z-VF; Wed, 23 Aug 2006 13:30:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFwYG-00018R-8F for mip4@ietf.org; Wed, 23 Aug 2006 13:30:04 -0400 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 1GFwYE-0003K2-TV for mip4@ietf.org; Wed, 23 Aug 2006 13:30:04 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 23 Aug 2006 10:30:02 -0700 X-IronPort-AV: i="4.08,161,1154934000"; d="scan'208"; a="441394678:sNHT39223580" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7NHU2jJ018165; Wed, 23 Aug 2006 10:30:02 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k7NHU21E013701; Wed, 23 Aug 2006 10:30:02 -0700 (PDT) Received: from xmb-sjc-224.amer.cisco.com ([128.107.191.98]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Aug 2006 10:30:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] MIP4 client implementation Date: Wed, 23 Aug 2006 10:30:00 -0700 Message-ID: <28CEA477BE98ED48AF08A0B637A74BF402225841@xmb-sjc-224.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] MIP4 client implementation Thread-Index: AcbG2SnljtJohU+ST12yY/G8zup+bQAAEclQ From: "Gopal Dommety \(gdommety\)" To: "Vijay Devarapalli" , X-OriginalArrivalTime: 23 Aug 2006 17:30:01.0357 (UTC) FILETIME=[C34EEBD0:01C6C6D9] DKIM-Signature: a=rsa-sha1; q=dns; l=931; t=1156354202; x=1157218202; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gdommety@cisco.com; z=From:=22Gopal=20Dommety=20\(gdommety\)=22=20 |Subject:RE=3A=20[Mip4]=20MIP4=20client=20implementation; X=v=3Dcisco.com=3B=20h=3DxdcP4nVABoVPbj1bEZpv1E0aA+w=3D; b=MXDT6eWw+w2bK+6bqKYyqlTeScpA87OJpwRtEgJPcozLb18vo3GfI9A5awkWgAzL+Bf54EXG /zOY11SsDuIZTapFaYRHpQOSTkbqFcSZPWiHvtdyXQdBOQ0VOK6miYKZ; Authentication-Results: sj-dkim-2.cisco.com; header.From=gdommety@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hello, Can you also add Cisco Mobile Client. Cisco Mobile Client is Mobile IP based and is a released product.=20 Thank You. -Gopal =20 -----Original Message----- From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com]=20 Sent: Wednesday, August 23, 2006 10:23 AM To: mip4@ietf.org Subject: [Mip4] MIP4 client implementation Hello, I wanted to update the list of Mobile IP implementations at the following URL. http://www.mip4.org/2004/implementations/ the web page says a mail should be sent to the MIP4 mailing list. so here it is IP version - IPv4 Operating System - Windows Name - Azaire Networks License - commercial Comments - Available as Windows SDK Vijay -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Aug 23 17:34:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG0Ml-0001e0-UB; Wed, 23 Aug 2006 17:34:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG0Mk-0001Xs-83 for mip4@ietf.org; Wed, 23 Aug 2006 17:34:26 -0400 Received: from av10-2-sn2.hy.skanova.net ([81.228.8.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG0Mi-0001LD-U7 for mip4@ietf.org; Wed, 23 Aug 2006 17:34:26 -0400 Received: by av10-2-sn2.hy.skanova.net (Postfix, from userid 502) id C2AE1382C3; Wed, 23 Aug 2006 23:34:23 +0200 (CEST) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av10-2-sn2.hy.skanova.net (Postfix) with ESMTP id AAD39382C3; Wed, 23 Aug 2006 23:34:23 +0200 (CEST) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id 81AE637E45; Wed, 23 Aug 2006 23:34:23 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.62) (envelope-from ) id 1GG0Mg-0007Xh-Iv; Wed, 23 Aug 2006 23:34:22 +0200 Message-ID: <44ECC9DD.2060903@levkowetz.com> Date: Wed, 23 Aug 2006 23:34:21 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip4] MIP4 client implementation References: <44EC8F07.9080009@azairenet.com> In-Reply-To: <44EC8F07.9080009@azairenet.com> X-Enigmail-Version: 0.94.0.0 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1599690879==" Errors-To: mip4-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1599690879== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8899254FBE5F46F61DB1B130" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8899254FBE5F46F61DB1B130 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Vijay, on 2006-08-23 19:23 Vijay Devarapalli said the following: > Hello, >=20 > I wanted to update the list of Mobile IP > implementations at the following URL. > http://www.mip4.org/2004/implementations/ >=20 > the web page says a mail should be sent to the > MIP4 mailing list. so here it is >=20 > IP version - IPv4 > Operating System - Windows > Name - Azaire Networks > License - commercial > Comments - Available as Windows SDK Ok, I've added this. I also would like an URL to the product - would http://www.azairenet.com/products_acm.html be correct? Regards, Henrik --------------enig8899254FBE5F46F61DB1B130 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFE7MndeVhrtTJkXCMRAm6VAKDbhuPgqGvzTAF1Fol+O76j3GhXYgCcCb7q o5CFWYGNyW/OmkBkgJ4BDZs= =DpRQ -----END PGP SIGNATURE----- --------------enig8899254FBE5F46F61DB1B130-- --===============1599690879== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1599690879==-- From mip4-bounces@ietf.org Wed Aug 23 17:36:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG0Oe-0003KL-1f; Wed, 23 Aug 2006 17:36:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG0Oc-0003KB-Pa for mip4@ietf.org; Wed, 23 Aug 2006 17:36:22 -0400 Received: from av11-2-sn2.hy.skanova.net ([81.228.8.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG0Ob-0001bw-AU for mip4@ietf.org; Wed, 23 Aug 2006 17:36:22 -0400 Received: by av11-2-sn2.hy.skanova.net (Postfix, from userid 502) id 7D11D38080; Wed, 23 Aug 2006 23:36:20 +0200 (CEST) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av11-2-sn2.hy.skanova.net (Postfix) with ESMTP id 6BC5238028; Wed, 23 Aug 2006 23:36:20 +0200 (CEST) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id 5C4A137E44; Wed, 23 Aug 2006 23:36:20 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.62) (envelope-from ) id 1GG0Oa-0007iK-6W; Wed, 23 Aug 2006 23:36:20 +0200 Message-ID: <44ECCA52.1020309@levkowetz.com> Date: Wed, 23 Aug 2006 23:36:18 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: "Gopal Dommety (gdommety)" Subject: Re: [Mip4] MIP4 client implementation References: <28CEA477BE98ED48AF08A0B637A74BF402225841@xmb-sjc-224.amer.cisco.com> In-Reply-To: <28CEA477BE98ED48AF08A0B637A74BF402225841@xmb-sjc-224.amer.cisco.com> X-Enigmail-Version: 0.94.0.0 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0949659477==" Errors-To: mip4-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0949659477== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig07EFA234426A7EDCF6CD061B" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig07EFA234426A7EDCF6CD061B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sure - but please provide all the needed information: IP version Operating System Name License Comments URL Regards, Henrik on 2006-08-23 19:30 Gopal Dommety (gdommety) said the following: > Hello, >=20 > Can you also add Cisco Mobile Client. Cisco Mobile Client is Mobile IP > based and is a released product.=20 >=20 > Thank You. > -Gopal > =20 >=20 > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com]=20 > Sent: Wednesday, August 23, 2006 10:23 AM > To: mip4@ietf.org > Subject: [Mip4] MIP4 client implementation >=20 > Hello, >=20 > I wanted to update the list of Mobile IP implementations at the > following URL. > http://www.mip4.org/2004/implementations/ >=20 > the web page says a mail should be sent to the > MIP4 mailing list. so here it is >=20 > IP version - IPv4 > Operating System - Windows > Name - Azaire Networks > License - commercial > Comments - Available as Windows SDK >=20 > Vijay >=20 >=20 > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ >=20 --------------enig07EFA234426A7EDCF6CD061B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFE7MpSeVhrtTJkXCMRAqO8AJ9A7BXBvAnnJFQFEHonoN4g84C4HwCePhHQ qhJPAMSIFjw2yv1PWP9E4Ss= =fNwU -----END PGP SIGNATURE----- --------------enig07EFA234426A7EDCF6CD061B-- --===============0949659477== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0949659477==-- From mip4-bounces@ietf.org Wed Aug 23 18:25:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG1A5-0005Q4-Le; Wed, 23 Aug 2006 18:25:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG1A2-00051S-4I; Wed, 23 Aug 2006 18:25:22 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFzOn-0008Jj-U1; Wed, 23 Aug 2006 16:32:29 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFykC-0002Am-Sf; Wed, 23 Aug 2006 15:50:38 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 71B591757B; Wed, 23 Aug 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GFyji-00067K-0e; Wed, 23 Aug 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 23 Aug 2006 15:50:02 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: mip4@ietf.org Subject: [Mip4] I-D ACTION:draft-ietf-mip4-reg-tunnel-03.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-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 IPv4 Working Group of the IETF. Title : Mobile IPv4 Regional Registration Author(s) : E. Fogelstrom, et al. Filename : draft-ietf-mip4-reg-tunnel-03.txt Pages : 35 Date : 2006-8-23 Using Mobile IP, a mobile node registers with its home agent each time it changes care-of address. This document describes a new kind of "regional registrations", i.e. registrations local to the visited domain. The regional registrations are performed via a new network entity called a Gateway Foreign Agent (GFA) and introduce a layer of hierarchy in the visited domain. Regional registrations reduce the number of signaling messages to the home network, and reduce the signaling delay when a mobile node moves from one foreign agent to another within the same visited domain. This document is an optional extension to the Mobile IPv4 protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-reg-tunnel-03.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-mip4-reg-tunnel-03.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-mip4-reg-tunnel-03.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-8-23105247.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip4-reg-tunnel-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip4-reg-tunnel-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-8-23105247.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --NextPart-- From mip4-bounces@ietf.org Thu Aug 24 01:10:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG7TV-0001Ts-Te; Thu, 24 Aug 2006 01:09:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG7TU-0001TD-Ng for mip4@ietf.org; Thu, 24 Aug 2006 01:09:52 -0400 Received: from f.csce.kyushu-u.ac.jp ([133.5.33.1]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GG7TQ-0000lv-2Z for mip4@ietf.org; Thu, 24 Aug 2006 01:09:52 -0400 Received: (qmail 23795 invoked from network); 24 Aug 2006 05:09:45 -0000 Received: from unknown (HELO ?127.0.0.1?) (127.0.0.1) by localhost with SMTP; 24 Aug 2006 05:09:45 -0000 Date: Thu, 24 Aug 2006 14:09:50 +0900 From: kitasuka@f.csce.kyushu-u.ac.jp To: manet@ietf.org, mip4@ietf.org, mip6@ietf.org, mipshop@ietf.org, monami6@ietf.org, nemo@ietf.org Message-Id: <20060824140453.A1FB.KITASUKA@f.csce.kyushu-u.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.25.02 [ja] X-Spam-Score: 0.2 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: Subject: [Mip4] call for participation: ICMU2006, 11-13 October, London - Int. Conf. on Mobile Computing and Ubiquitous Networking X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org (apologies if you receive multiple copies of this message) Call for Participation ------------------------ The 3rd International Conference on Mobile Computing and Ubiquitous Networking (ICMU2006) October 11-13, 2006 BCS London Office, London, UK Sponsored by Information Processing Society of Japan Technically Co-Sponsored by British Computer Society, Institution of Engineering and Technology, and IEEE ITS Society, Technical Committee on Mobile Communications & Applications Supported by International Communications Foundation and SCAT (Support Center for Advanced Telecommunications Technology Research, Foundation) For detailed information about travel and hotel, please refer to the conference webpage: http://www.icmu.org/icmu2006/ ICMU2006 is the 3rd of a successful series of conferences that aim to serve as a specialized conference on a broad range of research topics centred on mobile computing and ubiquitous networking. ICMU strives to provide a place for researchers and practitioners from the globe to meet together to exchange latest research ideas and outcomes on ubiquitous networks and mobile computing. ICMU2006 is to be held in London, UK, one of the most accessible and attractive cities in the world. Keynote Talks ------------- Wednesday, Oct. 11 2006: "RFID: Towards an IP-based Application ? by Ms. Monique Jeanne Morrow, Cisco Systems, Inc., USA Thursday, Oct. 12, 2006: "Reconciling Communication Networks, Sensor Networks, and Human Networks: a Social Perspective on Ubiquitous Computing ? by Dr. Ken Wood of Microsoft Research Cambridge, UK Friday, Oct. 13, 2006: "Toward Ubiquitous Wireless Networking: the Evolution of Keitai (Cell Phone) Communication?by Dr. Atsushi Murase of NTT DoCoMo, Japan Program in Brief ---------------- 8 Oral Sessions: (1) Location, (2) QoS, Scheduling, Performance; (3) Ad hoc & sensor networks -1, (4) Ad hoc & sensor networks -2; (5) Security, Privacy; (6) Architecture; (7) Application-1; (8) Application-2 Panel Session, Poster Session Organizers ----------- General Chair C K Toh: Univ. of Hong Kong Technical Program Co-Chairs Susumu Ishihara: Shizuoka Univ., Japan Eiji Kamioka: National Institute of Informatics, Japan Publications Co-chairs Gen Kitagata: Tohoku Univ., Japan Yang Yang: University College London, UK Publicity Co-chairs Teruaki Kitasuka: Kyusyu Univ., Japan Kun Yang: Univ. of Essex, UK Local Arrangement Chair David Martland: Kingston University, UK Hiroshi Mineno: Shizuoka University, Japan Treasurers Tomohiko Yagyu: NEC, Japan David Martland: Kingston University, UK Registration Co-Chairs Jindong Hou: France Telecom, UK Homare Murakami: NICT, Japan Steering Committee Osamu Takahashi: Future Univ.Hakodate, Japan Tadanori Mizuno: Shizuoka Univ., Japan Takashi Watanabe: Shizuoka Univ., Japan Miki Yamamoto: Kansai Univ., Japan -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Aug 24 04:42:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGAnT-0007qQ-Sz; Thu, 24 Aug 2006 04:42:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGAnR-0007pR-KW for mip4@ietf.org; Thu, 24 Aug 2006 04:42:41 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGAkw-0007q7-An for mip4@ietf.org; Thu, 24 Aug 2006 04:40:07 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id C324D89837; Thu, 24 Aug 2006 11:40:00 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 813468980A; Thu, 24 Aug 2006 11:40:00 +0300 (EEST) Message-ID: <44ED65DF.100@piuha.net> Date: Thu, 24 Aug 2006 11:39:59 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060725) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Eva Gustafsson (KI/EAB)" Subject: Re: [Mip4] I-D ACTION:draft-ietf-mip4-reg-tunnel-03.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Eva, All issues from my AD review have been addressed. Thanks. The draft moves now forward. --Jari -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Aug 24 11:46:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGHPo-0002Cl-1h; Thu, 24 Aug 2006 11:46:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGCBC-0006ve-7o for mip4@ietf.org; Thu, 24 Aug 2006 06:11:18 -0400 Received: from tomts52-srv.bellnexxia.net ([209.226.175.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGCB8-000283-MV for mip4@ietf.org; Thu, 24 Aug 2006 06:11:18 -0400 Received: from trellianetworks.com ([70.50.240.227]) by tomts52-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20060824101103.CRPN7721.tomts52-srv.bellnexxia.net@trellianetworks.com> for ; Thu, 24 Aug 2006 06:11:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 24 Aug 2006 06:13:14 -0400 Message-ID: <85E0FDF351E7F14EB0E597BA0D102E9023BF5B@fudo.tn-mtl.local> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Mobile IP implementation thread-index: AcbHZekKnvdHITsjTd2iIS2NzLKCiA== From: "Raffi Tchakmakjian" To: X-Spam-Score: 0.5 (/) X-Scan-Signature: af2aae76ea468dc53420d9ba52ca6045 X-Mailman-Approved-At: Thu, 24 Aug 2006 11:46:43 -0400 Subject: [Mip4] Mobile IP implementation X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0667237171==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============0667237171== Content-class: urn:content-classes:message Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C6C765.DFCD3AD2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6C765.DFCD3AD2 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C6C765.DFCD3AD2" ------_=_NextPart_002_01C6C765.DFCD3AD2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Good morning, =20 I would like to add our Mobile IP implementation to this list: =20 IPv4, Trellia Networks, Commercial =20 Can you please confirm? =20 Thanks, =20 Raffi =20 Raffi Tchakmakjian Product Manager 100 Alexis-Nihon, Suite 770 Montreal, Quebec H4M 2P3 Tel.(mobile): 514-992-0232 Tel.(office): 514-747-5222 Fax: 514-747-7375 e-mail: raffi@trellianetworks.com =20 =20 =20 =20 =20 ------_=_NextPart_002_01C6C765.DFCD3AD2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Good morning,

 

I would like to add our Mobile IP implementation to = this list:

 

IPv4, Trellia Networks, = Commercial

 

Can you please confirm?

 

Thanks,

 

Raffi

 

Raffi = Tchakmakjian

Product Manager
100 Alexis-Nihon, Suite 770
Montreal, = Quebec H4M = 2P3

Tel.(mobile): = 514-992-0232

Tel.(office): = 514-747-5222

Fax: 514-747-7375

e-mail: raffi@trellianetworks.com

  =

 

 

------_=_NextPart_002_01C6C765.DFCD3AD2-- ------_=_NextPart_001_01C6C765.DFCD3AD2 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.gif Content-Location: image001.gif R0lGODlhrwBDAPcAAAAAAP///+BvHbu7vLy+wLa4uf39/PX19Nvb2r+/vuDe2YiFfvX08vPy8PHw 7u/u7Ovq6I6EcomAb4yDco+GdZGIeJOKerexps/LxIh+bYuBcLCpnoN+dr64rru1q8bBud3a1ZuS haCYjLOsotfTzero5ebk4ZaMfqScka2lmsG7s7q3s+Pg3NPOyNvX0qKWiaiek6qhl8zGv+Xi35OR j6upp//9++7s6uzq6KKhoJeWlf/+/ff29fb19PTz8vLx8MPCwbOysZeOhpKKg+dtE99qFOBsF+Zy HeVyHeRxHeFwHeVyHuBwHuNzId5xIfB7JdpyJtl1LOF9M9h5M+GAOct0NMp3OsF2PuiQT7t2Q8h/ SeeVWbh4Sbl6S7R4TLZ8UdOUZbJ/WbCDYu62jMeegOO2laiKdK+TfpqFdauUg8yzoP7fyPbYwpqH ebKfkfjey+zWxfni0d/Owevd0vvt4vzw5/Dn4Pzz7KOemt5kC+NmDOZqEd5nEeJqE+BqFOhuFuNs Fu5yGeNuGuBtGup0HuZxHeJvHeJwHeFvHd9uHO52H+hzHuZwHuZyHuRxHuNxHuBvHul0IN9vH+Z0 IeNyIOBxIeN0JOBzJO16J+F0JeV3J9xzJ+F2Kd50KNhyKN93LeJ6L+h+MdRzLdB0MfGKP+SEPsRx NsR0OuWJR9eCRMR4QeSNT/KYV795Rrd2R9WKVPijZeebZL+BVOqibq54UvSsePmwfOuoeKx8Wdeg eOywhfi7j7+QbqV9Ye+7lqmEar+Xe/PBnfTHp52BbfTNsbebh/bSuKSOfqaRg52Kfb6omK+ajOXM utW9ramYjPrm2Pvq3puVkb64tJ2amPDt6+nm5NfU0paGfJqSjaijoP328rOuq/749f76+J6cm/79 /czLy728vP7+/vv7+/r6+vn5+fj4+Pf39/Pz8/Hx8e7u7u3t7erq6ujo6OXl5eLi4t3d3djY2NXV 1dLS0s7OzsnJycbGxsPDw8HBwbm5uba2tq6urqurq6WlpZ+fn////yH5BAEAAP8ALAAAAACvAEMA AAj/AP8JHEiwoEFtcYiNmbWlYSxdwdjUMUixosWLGDNq3Mixo8ePA3fQMaZrSylOAlKmrCQF1axg z7iBLLjj2cSZOHPq3NmRGxtdqJioHEo0JahZxO7khIbFlwGeUKNK/diNzSwpRbMWlbRFmDaQNnQp iVVtqtmzaP89uwVKK6S3cN8ymUuXSadYbDxy88Vpyat649IKHkw1WKmsgwYZMeKnsePGfSJLjqzp llKNd25dEtBIVoIDhEOLrljnViaikBL5EcRpCpVUqV69ii27tmwwuMHEYlZOo7CUh5b8uodutPHR dGIVhTQIUCpeZ15Ei6YjGrbp2Gho375dh78E7J5e/6SzSsAhQlei0QN9vH1aaFuWC9jzirq/fvuC 6MvHv/+ABAAGCCA+9LhDznizCLAEeifsA09g7kUoFXxZMcEHFSHkoA89CLzTzjrqpCNiOugc4MOI JJ5jzjnliEeRNsZgsSAnXpyQQz3oiCPhRzvsWFAdyiG2By/+2KNORTrqyBE3d9TxRjCzYPIEFV0M Q0M/RiopoU9rHGiRNmy84aKP3dyiFRN9hIIMATOUUM0dd0ATxxprGEOMMcLE4QBBO8QRjDDCEMPG oGEaE8wus8RCRjEw4NGPPvOko2V7CAUTixS1+PDiG77EEsoYEBYkzqjiGPBNaMFUopUAfUgBDBm6 2P8CCyqgZHJIYoMIIogetiBAkDZY5JFIIrgaEQozLJCgbAv3hKNPAgWas2OZpVSCSCNktOPlQHfM QoUASmiixg2hCvRAByOMsIEKJhD2zGGrCiAJJ5H0kce9fPBRxL6LFbFHLuDwwC0TeSxmxL5FCJKL O+q4A4888sTzzjrS+khHW+Zp8kI85xT0BkoKThEDPNsKBEIFGWQgQQjzDGaDmfEyt9ggiQgAV11M DILJGfccKVAci+HMhBJRNHMAOiWeU66PbIDcyCgiPFgQMacJsIgVKbwz6T8ySJCyBkMAUVxabGAV 79kqQeIHKcnQM/YOxPBhBCRFPQKGzz5SJIyqVlv/sUE7Bo3B9yKtbMOOqBeoLEEEHOSzTlrdJIj2 5GiiEk08XnYzRh5aKfGJDFvnLZAuQglASBf6PM5nkEo0gks46RTUQwwRTBABBQvcEztab5g9+dmQ EPEKP/Ao2c0WeZROFCJJkNGA6AV1EyQihPSie0HaoAJcE8OAM/ZAPKwwBAfk0wBOx2eF9TvaqQXC SwHucEsFH8oTJUgqLowpOh3aC/DIJWagh8AI8oxvcSYKyIhHbwqSDnvUoB/9CAIC9BcVaPRvfati ghGeYIaeCSQAQCtC/YZyCCioYYHQ+0fvUvK0jenPGE4bRQzeQcEDvANi8oDH7s5CDL5h8Ex+CMUL /wImkB0YIw+DoFtWDkEJYOANesQAGSGw9g6D+EISKVnEFbYBOIOUygBgNEDooKK+H8ZrD6nIhjwg ZANfJG9V15KF1lL4jzE4ISWEyEIQDlcQmCmBELRIgOoiVIf4mHFV9NnHHP+hjVjkwYdZWYIWWkBB CdlAcodwXQKe+I87GPIQTeiF93a0wkMi5g/v4+M/6CAF+sXLEVPoAAozsgNuyOkrF7EBN7ihjV3a QCPASkkSnGAGcLBnIO9KiSOgcAx5lIwg3YDGGi5Dy27wkhvd2Igw7mhK1BhhCWcIB96g4YckvrIT yvjeRerAhoWgghVzqMgd3iCMMdxiFvi8xRiE8f+MbFokmQryRAJn+Y+yIYIzooABPPRng5HcAhVY sMMYB9JQY/jinvmMCDUHwo1nPENausBiN4nSh0/EoB7sCQAbhHU2R2zCDYMUSDfewIZf2iAOY9gC xhyBv2MK5Bm+2IIURpgSJ5RiFnmpCBsw9jQY0LAgweBmI0xRg/hNDRWnacQrWOBTgtiADQ+tGlFA sQVfQEMgdSDGLLAQjB/8I0gjTduFaoA5gdhgc0QlShI2sYwudiMOwvCWLmZ6C3ilBBFL8IwqoQGU 30khGBWDqqqutcUuhkQXNVPCEryQuuhJTkFiqAcnf8oWtCViFcHwBRYucYhSNKMd4yhPXFWSiET/ LtIGqCiCEle11zTET3OlyAQilJCLXJTioENRwiHEIEiBsEG2yT2EdA+BXJVMogzP3IEuUtI6Lziu INwI0iGY8At8qPMfhQSOE35hj67+gxgXVIlypVvdoqpkEVroADzMAd3ZNocXQbDqP7iRCSOgzaXL iB8dDCgAJ2xiaAJAhHSTkAQkKMEMgPlHMDAGLulKQhRWCPEonJCEQwzlWNj7ZCV+gaMfreKghyAm PdCHTAOWMA3zKJkNggGyCB8iCR+ughVGAYUfmzi5i8BFPtwR29mqxAiCKMYABhmHxByYr/F7A4c7 fAhHOKISUBjFFbyACxTE4xvC0IRKkrCEUdBi/xjXEIIQsCEENHQBCklQiSNycQOCWFCZUDDDPCL7 MyocNAmecEY8XtgJ4MhwoQQRhlgP8Qg3w1nOQmiDGK7ghCVU9xCR6F7s+htXI1wiBe0dCDGKMLkl eMIN8YOhShDhiEY4oQqu6AUahkADHXhDHzeAQyhUsgQo0GIIOsjBPvKRACDgIx/8MIMojryEVLSA IG8woCNE4QxIE4QYmxFAEqqQguLxyRc1M88VqqqlbOvZ2MhWNrMTkI995OAXozgCsTdxDAX+w5BO NgIVNpDjD+qCD7td1RLIHb9diDSguT6Bd2oQhHDYo0AsYIVKGiGKYeigH+GYxzvYESIHsAMe4P/g hbXEHUsUbjMlC8+a/nyx5ixsQ8B2hZl5wtBZmcK12L34eAJETnJ1sOOG9nCGFZbAwlE49Sk6ny0g XkFX8dhgC66M17X0GB5YHHYJp0BDsvcBLXi0Ix0HIMc3gqGSQ3hiGP7QRzzSsTSBnAMDU1ACy0ew O+3WDLFcCEI7JlWmwx4iDOGIKSPhulziDGRvwLFEL7wRBHmooxyTEgc50uEOXixC7+i5uY7K8PC4 AgIMilTSgg18NiVQAhcJQAc1NO4/SwzjUfR4RzrMMSb+HbYSvcASNTACh08cdAlWGAEfuTELGDOB uZy8QywOqgRJsLirfwaXE45Bj4ppw5CIWIT/K3SQD3gQtCDlyEUSDkoIL0xZIMToRH1NeVBg5EOV b6gE6+M1TAwbYA6kAHNRcAz24A7mMEa/oRJQ8AViACu7sAtjEIESGIG7AFeLoAqGIxB0sAUwRkxE RED943Y4RlBNAxzcVlcFhTFLEAVoEAQkgxF3QHug1Ast9g9zkAp6F1eDkAluIDaqxgeDcGCj4Azy 8A/GwFRVMDITZQNwJQBM8AiKQAiNkIOttwi9IE4/YzYiuEYFwQaf4GgKtTTEIFJJoArZ8FT/QDoR tghZgAfrkRHQAC/FdgyDJhANEAtHNlJGIAUxMGNFNAZ8kG781wU1UEUOt4Y2Z1kGwUpDMVxK/zB/ 8bIIoxACo/Re3DRuMTBBUNV2qlCIk3JXevYF+rB8nxRK+oBzFlE2LMRt3mYAZUCFpgQJRvAKeICC 4cUHaIMI65UP6vANtcBdi0ALiZeKk9YIxniMyJiMx7gIk9ALdOUl6KZMWZB6XqULyHV4oxg9OvcI YoAPuwNQLlVM51URwRBujXAKG+AOWiIHUgCLZsQEfgAGVSUedVAKuHg2h1AFIgAOBtAAMrhiNag3 peN2plCQBnmQCGmQVUAL0YAPqlN4wBEG30UQzCdf3XhedyBbuhhA7NE7x8dtCFB3FIFZEbYEgadK //AAsZBn3YQmxdBzauEE9xgvSIALxPMPdv8QgAKwTMgwD+c3EL5QOoQTAtaBDUZ5lEiZlNigAw4C IY10UBLGXudVB/2zkX5IEHFgYwLlb0ZofAoiQ+qYERVpHs/njQQhDmpgCYYQi4OABDDgeM4lNy01 CkKAD0eyBlJwUBynUJUkEGNwX62QDfhwD4RZmIZ5mPcABPeAADQWh4flBD1JYz8DMkogCi8gDwRl DOGWBFYwQ+JhDF7ZZhvADhNFEOShXgE0QAMxA6uABKZUCUUQCnhQh/+wA24UhHDUCM64aP8AeZxx CuxmETTHQlawAutwNEiTnMq5nCVSLmwQbpWJAiE5NSrxCFaQDd42EGyXRV3ARUoCmofWCW7/MFoU kZXKlGjxsDQGoAaakIcYRDCvkANS8w/SwzmRaAXY4JCjc1hJ0AUrgJIG8XLmgU6quRE7UC4JaB6d uEh/SGxdsEcFUUZWg3g7VDZ6p1m8AAG+EW6OQG4MOhDu8AqNAIlowwR6AAz8EJaMhAoIp3CdMAz8 gAAHEl4wJgnduEMUAQeb0HZbxRFfFQx2QFHbpUyiCKCXRGzMhaOM9EmPcH0DYQelcGRJIAUfgBHd IAwMlgRbhIoDoQZSwJLrkzN7UAwTqRafkHVFcQjB6A32sDuF1IEBJJkG4QCvAKZ2Mwc9YhENRQy3 oAmsUAJKMpY7KQY++CtV6QjFhH1ayG+0/zlgYJCHSZAKcPBLNMENbzALPaYEjxAG70cR6UAGTQCm lFMEkeAGKDUQxiA3efVHWYAN+oCG7mYeJyiSAzEOatAEyCVhpaALxPAMd6ANwBonbBAMD2Uti8AL CDA22WeVchoHWtgJIYCZXVg1jVAFYUgQzdCebQcKt9CrdEAHz2BROkUUSvB89GBXWzMO8SCi7hgv BEMFs1kxARAMSJRw3EUIp3AC/CAPkUUM3JSP5daXA2ECYLAI7ikAmUAFWBALDGsSX9h2kxBAYxMH GHMIlomCqhZuyIcHaPh4g6MKI6CiAlENBeuOCVsKKNtj5lFdSjAFysAMgLInBWEOMqAFi/9AohWi B/E5nf8QFiy1PIRQBdfQDwH5D8Mpbq0geKUpEAZQs4vgmr+jWYrQCcggre/FN5x5hvqznVZTOACa hqXTCF+wApy0Ax+QCoRwsEu0CExHQotwBJQwCyawNeKADiqgBUeAs0ORGnqAeu4gHmWSB/baN9eQ Az2jJZEzXYWAeORpEHb7BZxACEugtobXCFIYBafQC9mgiTswBtNFCF77ibMwXYrwBbAToaswYYpg PUoqDj3gAVrwCAabFZpFCE1wBbQgCougV6CQC9Ygp/8gDurQAXhLuUMhpmTQqQJRBnogiOaRBFkw BFiyDpPSLZ8QBZ4QBWaQahkhvECADF3/MAqXsAiNsATmuwSNsAiUEAVWwAW6hg3eEA5dFBagEAVR 0AlicLoEIX31GwWfwF5dVQdYcL2bMAXJMA8FyrTrsAJmoApRsAhsa77pWwnt2wtC4A9m8Anki77M qAXOUIkFYQDqIA1isAmelkFG8AfAcA8dU0vPZQS4iQhIsAm4IATTuzXdIAdu0AZo0Aaz+ZMUIcLz sA0iMAy48AVdkMRdQGa6JgTR4A38kA/18A4VswNzoAzJgAZoEA2nSpE6nMVtMA2NKhDaIAfLwMNt kAPpSRHjAAH1kA3J0Au0oMRkNgwnEA3+EAT1UA/LEAZdwAVdgAvDIAT7EA+ERhAGsA72/3AGo0Bh 7ZoSidAHqdAMc/AGuoAFh8B6P+YIVuBx+wAO6lBJ6EAP+lDKQNCx3XsA7kAP4bAP/uAN0xDL3uAP /sAP+nAP9AAP7HAA5cID8jAApZwAL8hA4JAPpYwPqBy861APpawP9jB4FWEA6QAP9hAE2QDLspwD QUAA4PAO6MAA8RAE2OwN2kwP6yCwwjsPKSAGokAJjbB+y2EEgMAIfrAvg0BrjdAEVdALQ+AP+RAP 4zgQ5aAO7VDQ6wDEF2EAPLAO7xAP80APEE0P8xAPupwO51BJ45AO7GDQPEC35kDQ7cAOFEMR5rAO Bd0O6vBMBjEO6NAO8DAPD00POcQwF/9td+4gDw890e6ADgIrEOJwAPAQDs4QBlVwCYSwCI5AXcj1 iPecBJbbCJtgCr1wAtNQAwWI0D5NKjohDuOwIufw1eYwDmLUvaOCEVp9EWetEVzt1ebwA9XgXgZQ DmA9DkuLfuwgD/qAAr/gCqOwCU1gjOeLvo1wCaJgCm8mBNPADwSQrD1NRykkDi2QAjhgFuZw1/hQ Ay9gxFygCiEWYq3gBe87DRFkDzrU2I7tEeXAAg9wFgaQAhJQFmdRDusAD6xszSKADSGQ29EwDfJm D/Kw06Z92h7RAidAAqy9ARRQAoKh0AwdD/RQD/ZwD/ZgD/UwD7qMDiot3CsdGN/Aewb/QQ6H/AEZ YNwfYQDeTRDmcCrfUA4bUAHKTRHkwACHjBNxfQDpoA74TSLnrd0YcQMjoAIysAEwkAIYACEs4AEx AAMXAAL/AAEdIAISEAMe4AEf8AEyMEAKoAKT/Q/UoALG/QMfkAIDLgMySwIjoAAYkAItcAHuLRAM oAItoHkYEAMioOAgQKv8LRouIAESYAEhIAIVoAEtsAMkYAEWgAIwcAIVQAImgAIUkAEnkNvpYgEK 8A/kkAIZoAICIQMT0AIPgAIaEAIwEAIaAAN7kjgWQAEnIAMeYAHv7QAUEANNOwEisAEoUAEp0Gc5 HiEgoAEoAAI98A0uUAEjcAO5PQPj/zAOJmABIuAA46ACGoABPfAD40ACGlClM4AyL7AnG3ACDtAB EqACB8gAHZDlO+ABGQADLVAC5jACFNBnBkACGeABra0BLIB5D8ACPbDnfD4BVSoQDhACKeACGfAC HTDhHVABJ6DcHzAB5M3hwl4OHnACF+DsPBACG9AAP64pAuEDIYAC5NABFNAu/2AAI6ABKoABbS4C ZaECGRACI/ABCpDdvB4aIDABWi4Qhr4BJLAyKCACAI8CHxAYzf7sBnABFkAC1O7tKl4BLeAAFpAC LkIOMPACPJDssH3wGWABJ5ABFTADAsEDHyACJ6ABGXABJhDc9S4V957v/7DvIJDlCv/dAzzQIjry ARrgAgTRAhEQAhSg881+AidwA9ceAjLL4RYAAwbgARVA7ubu7CyQApFe7rtuDiUAAokjAqu98qPh Aug+EIaeAg5A8hjwAD5wAy2gAnsiAydfAjMw7zgQAhmAAgJTDR2fAnQt3hug2gqA5TLwDxcw7kyL 3HvyAD4PAt9wARegAPKNAR6/4VwfGl7v8oYOA/9gAi8gAVF+AhKQAs9zAyig+RWAAg7wDef+9/+Q +BmA+j1wARJQASEQ5B1wICPQ9IOf3AKhABTwAjjA5RSQ2xQgAhiA1ZEvFSXgAQzu4hYuECXw4CEQ Ax+AA3k6AyMg5hhwICDQAVv/DwcmDtv/cHdjHgMYUDEt0AEyC9kd8DzljgEjwALj4AIbkNsbYAJ5 GhAAOw== ------_=_NextPart_001_01C6C765.DFCD3AD2 Content-Type: image/gif; name="image002.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.gif Content-Location: image002.gif R0lGODlhbwAkAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAAAAABv ACQAhwAAAAAAAAAAMwAAZgAAmQAAzAAA/wAzAAAzMwAzZgAzmQAzzAAz/wBmAABmMwBmZgBmmQBm zABm/wCZAACZMwCZZgCZmQCZzACZ/wDMAADMMwDMZgDMmQDMzADM/wD/AAD/MwD/ZgD/mQD/zAD/ /zMAADMAMzMAZjMAmTMAzDMA/zMzADMzMzMzZjMzmTMzzDMz/zNmADNmMzNmZjNmmTNmzDNm/zOZ ADOZMzOZZjOZmTOZzDOZ/zPMADPMMzPMZjPMmTPMzDPM/zP/ADP/MzP/ZjP/mTP/zDP//2YAAGYA M2YAZmYAmWYAzGYA/2YzAGYzM2YzZmYzmWYzzGYz/2ZmAGZmM2ZmZmZmmWZmzGZm/2aZAGaZM2aZ ZmaZmWaZzGaZ/2bMAGbMM2bMZmbMmWbMzGbM/2b/AGb/M2b/Zmb/mWb/zGb//5kAAJkAM5kAZpkA mZkAzJkA/5kzAJkzM5kzZpkzmZkzzJkz/5lmAJlmM5lmZplmmZlmzJlm/5mZAJmZM5mZZpmZmZmZ zJmZ/5nMAJnMM5nMZpnMmZnMzJnM/5n/AJn/M5n/Zpn/mZn/zJn//8wAAMwAM8wAZswAmcwAzMwA /8wzAMwzM8wzZswzmcwzzMwz/8xmAMxmM8xmZsxmmcxmzMxm/8yZAMyZM8yZZsyZmcyZzMyZ/8zM AMzMM8zMZszMmczMzMzM/8z/AMz/M8z/Zsz/mcz/zMz///8AAP8AM/8AZv8Amf8AzP8A//8zAP8z M/8zZv8zmf8zzP8z//9mAP9mM/9mZv9mmf9mzP9m//+ZAP+ZM/+ZZv+Zmf+ZzP+Z///MAP/MM//M Zv/Mmf/MzP/M////AP//M///Zv//mf//zP///wECAwECAwECAwECAwECAwECAwECAwECAwECAwEC AwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwEC AwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwj/AAEIHEhQILZo0EohI5WsFDRoBSNKnEix osWLGDMSZAWNFLJOH4WBBIkMmqmM0FhpXMmyJcZkIkV26iQyGM2ZIJM9qxjtWSdorlwKHaqxFbSb H5F5KrVUD9NSTp16ukYR2iVhgrAR3cq1ILRknTzdLCWoVdlWaNOqbaU14rNgnvaw7UqXKKukN5MJ ogUAG19sgA3y7TvwYLRSz5buodWq7sBr0SSyautYILSPnjzVLMXxa8NkoCNbXvg5GraUptJWBvC1 JOVrraFRxpaWsktWYPHijXlTZLTGrK/eVMZ2ru26PoUFCgwgmuZOrIADMCXoSlmiR8WK1B72JndP prRi/0Nmk7vo1QMvi1SZHrN0AK2uBLoi7bjGa55CjhSpv7+nua3sRlMp9jlmykeksGcZSHrYZpZ1 77EE1nPfUehdMKUAF01YFv5XIF1HwTWXQGB1kuFsgDHXUjS6ITVSfyAtZxl/+/00GHqliJQhQWAp V6CKLG3I23a9eUeThwBc02ORGH5IEFURXSPlh9H0SOBA0QgjjCeTFRQNlBNd4yQAOdYII406AofN czDuWJhWD5UCmm3KdPQMQ6Q8A5GXz6E1kEImnoSlnFcShA1HeCZDSkoCXVMKVRNSKOl2z5kYWJYc UrplY46GlsxH5TWGEDKg3jSTMMicd9p274X4SVADlf/opmWf4mSTTaQhI0x4+bkoYIupLQjjR8kk AgBMNYpEyh5aLUlKVKXkERMpAxnFoG3IlkILZT3KuCB/0OqB5n8BGknkud2B11aJ6AqT4WXeLRUI dWj16EkgZ6XFFE2CHjtToaxhFh6WR44ITTAifZIvWqZwdyUpaJrp4qaiLtlmK9eMdRZt2EhzlDB6 tJLIcWuKBE3FNHmb5E2/pZdmo8+RlaJB2BwYI5yZdqepziYCB42WOYvlSVY/h8WWij8nbIpnAskJ gMCWafYfQUVPPZBPnXwCmJKsAimQcyLyxeKLvprJbF9ltkhxbg0WhE3aZesWctMfzVrltQRB3Emw d93/PBGgpBiXjE28cVe4ugsaPhZbpMwUbEGRZib55JJf56+72xpE3t7SjY34x0hKZG/nEkeM4MBP 86YfKUT3mFVEvZJl1uxl1Y6WeKRyPlDfWFEGejR8AT6i22U+Dt+Sme2cvNWYKr8cNjBtGtFXAw7G XOZ9tQXv0G2dJrV00Cfss5ZWix4W6gLZrDbZj39s5txvv0y8SMn0K9HJXx8ZDazh91ytT8g423SS 4omIHCo3nYgQa07FM8OhbnA8A9mIfLKUAoEtJw+JhgaVoYxPeUJ7rOJRymyzOfSVgnDJyOBDaiWW BBGmMHAzXQI5hUBw+UkgvTLFjbzkq17hxU25ESAO/z8SHYIIbDbPoVGp/AONHdasQkQ6kUAaR6FA HO1rpMgM+tzWik8kDyeS2wN1xJNF8NzIOZnpUl+gkZm5GYopkvKEHgKxL6G9zlCmKEXZthQNjgBK R3JREW3MQhuKAKYVrJiXGK2YleIYZGOFQUsjDdKKaJRlh5RMpCnEKAhXsIUVmxyjAmnDiswwaSTl 0UNZvJa9MRmKY0fz2szcxspZSuSQHCsMLRgzJlq4whSs0EMWMWMiPVDHk65Ez2qwcQ0FZgQwjGkF MAURndspsyI/qpYzL4INQRiQJdjg3zavWRDaFbJ2ABCEIALBCkG0rDmFqZ1o0MIK9jSGNtdJJjlv Y3LF2fnzLP2UJnwEcZKyAFOSliToNa5jFktac5+roaZAatdOQiLSnrUzRWoQ2Za0eBM+jNSKOSFa GbMIxCztHGRjCHrSeU0nkBJN5+z6slFv1kySaiRpV4oIn7Tg63WtYCdbPnqoR6a0p/CZZ1r2QFCt BAQAOw== ------_=_NextPart_001_01C6C765.DFCD3AD2-- --===============0667237171== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0667237171==-- From mip4-bounces@ietf.org Thu Aug 24 12:26:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGI28-0007NW-HO; Thu, 24 Aug 2006 12:26:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGI26-0007NP-Ho for mip4@ietf.org; Thu, 24 Aug 2006 12:26:18 -0400 Received: from av7-2-sn3.vrr.skanova.net ([81.228.9.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGI24-0003Pd-2a for mip4@ietf.org; Thu, 24 Aug 2006 12:26:18 -0400 Received: by av7-2-sn3.vrr.skanova.net (Postfix, from userid 502) id CC09B38488; Thu, 24 Aug 2006 18:26:09 +0200 (CEST) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av7-2-sn3.vrr.skanova.net (Postfix) with ESMTP id BD3413813D; Thu, 24 Aug 2006 18:26:09 +0200 (CEST) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 6A25537E46; Thu, 24 Aug 2006 18:26:12 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.62) (envelope-from ) id 1GGI20-0004Z9-25; Thu, 24 Aug 2006 18:26:12 +0200 Message-ID: <44EDD321.2010103@levkowetz.com> Date: Thu, 24 Aug 2006 18:26:09 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: Raffi Tchakmakjian Subject: Re: [Mip4] Mobile IP implementation References: <85E0FDF351E7F14EB0E597BA0D102E9023BF5B@fudo.tn-mtl.local> In-Reply-To: <85E0FDF351E7F14EB0E597BA0D102E9023BF5B@fudo.tn-mtl.local> X-Enigmail-Version: 0.94.0.0 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1954940737==" Errors-To: mip4-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1954940737== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig74ACC4204E2B3EFB8C4FC0A1" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig74ACC4204E2B3EFB8C4FC0A1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Raffi, Certainly, but there are some more data that would be good to have: Operating System Product Name Product URL Comments? on 2006-08-24 12:13 Raffi Tchakmakjian said the following: > Good morning, >=20 > =20 >=20 > I would like to add our Mobile IP implementation to this list: >=20 > =20 >=20 > IPv4, Trellia Networks, Commercial >=20 > =20 >=20 > Can you please confirm? >=20 > =20 >=20 > Thanks, >=20 > =20 >=20 > Raffi >=20 > =20 >=20 > Raffi Tchakmakjian >=20 > Product Manager > 100 Alexis-Nihon, Suite 770 > Montreal, Quebec H4M 2P3 >=20 > Tel.(mobile): 514-992-0232 >=20 > Tel.(office): 514-747-5222 >=20 > Fax: 514-747-7375 >=20 > e-mail: raffi@trellianetworks.com =20 >=20 > = =20 > =20 >=20 > =20 >=20 > =20 >=20 >=20 >=20 --------------enig74ACC4204E2B3EFB8C4FC0A1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFE7dMheVhrtTJkXCMRAv5FAKCwNrQBaqWBevXBKOMBRlZ5hjKqRgCgjA9p bABXZthUMbcz1hXxW5CU09k= =tg1x -----END PGP SIGNATURE----- --------------enig74ACC4204E2B3EFB8C4FC0A1-- --===============1954940737== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1954940737==-- From mip4-bounces@ietf.org Thu Aug 24 14:10:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGJf6-00023c-IP; Thu, 24 Aug 2006 14:10:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGJf3-00023B-U7; Thu, 24 Aug 2006 14:10:37 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGH68-0000yS-Jv; Thu, 24 Aug 2006 11:26:24 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGGyU-0006id-Dt; Thu, 24 Aug 2006 11:18:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 24C9417592; Thu, 24 Aug 2006 15:18:00 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GGGxz-0002bL-No; Thu, 24 Aug 2006 11:17:59 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Thu, 24 Aug 2006 11:17:59 -0400 X-Spam-Score: -5.8 (-----) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: mip4@ietf.org Subject: [Mip4] Last Call: 'Mobile IPv4 Regional Registration' to Experimental RFC (draft-ietf-mip4-reg-tunnel) X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org The IESG has received a request from the Mobility for IPv4 WG to consider the following document: - 'Mobile IPv4 Regional Registration ' as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-09-07. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mip4-reg-tunnel-03.txt -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Aug 25 15:50:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGhhV-0001VF-5p; Fri, 25 Aug 2006 15:50:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGhhO-0001PC-Mk; Fri, 25 Aug 2006 15:50:38 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGhhO-00057v-KT; Fri, 25 Aug 2006 15:50:38 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGhhI-0004yl-Gg; Fri, 25 Aug 2006 15:50:38 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 6DD5F2ACB0; Fri, 25 Aug 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GGhgo-0004xk-5l; Fri, 25 Aug 2006 15:50:02 -0400 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, 25 Aug 2006 15:50:02 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: mip4@ietf.org Subject: [Mip4] I-D ACTION:draft-ietf-mip4-fmipv4-01.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-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 IPv4 Working Group of the IETF. Title : Mobile IPv4 Fast Handovers Author(s) : R. Koodli, C. Perkins Filename : draft-ietf-mip4-fmipv4-01.txt Pages : 18 Date : 2006-8-25 The Mobile IPv6 fast handover document [2] specifies a protocol to improve latency and packet loss resulting from Mobile IPv6 handover operations. This document adapts the protocol for IPv4 networks to improve performance over Mobile IPv4 operations, including processing of Agent Advertisements, new Care of Address acquisition and Registration Request and Reply. However, operation without Foreign Agent function at a router is also feasible. In addition, the protocol may be used transparently on hosts which do not support Mobile IP, but with limited movement across subnets. Using the concepts outlined in [2], this document also addresses movement detection, IP address configuration and location update latencies during a handover. For reducing the IP address configuration, the document currently proposes that the new CoA is always made to be the new access router's IP address. Additional mechanisms may be defined in the future versions of this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-fmipv4-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-mip4-fmipv4-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-mip4-fmipv4-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-8-25114856.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip4-fmipv4-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip4-fmipv4-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-8-25114856.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --NextPart-- From mip4-bounces@ietf.org Sat Aug 26 11:16:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGzt7-0003X9-P1; Sat, 26 Aug 2006 11:15:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGzt6-0003X4-It for mip4@ietf.org; Sat, 26 Aug 2006 11:15:56 -0400 Received: from av6-1-sn3.vrr.skanova.net ([81.228.9.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGzt2-0006qP-4S for mip4@ietf.org; Sat, 26 Aug 2006 11:15:56 -0400 Received: by av6-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 393C33823F; Sat, 26 Aug 2006 17:15:47 +0200 (CEST) Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av6-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 27F0437E78; Sat, 26 Aug 2006 17:15:47 +0200 (CEST) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id CD8F037E43; Sat, 26 Aug 2006 17:15:46 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.62) (envelope-from ) id 1GGzsw-0008JO-3u; Sat, 26 Aug 2006 17:15:46 +0200 Message-ID: <44F06598.70306@levkowetz.com> Date: Sat, 26 Aug 2006 17:15:36 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: Raffi Tchakmakjian Subject: Re: [Mip4] Mobile IP implementation References: <85E0FDF351E7F14EB0E597BA0D102E9023C006@fudo.tn-mtl.local> In-Reply-To: <85E0FDF351E7F14EB0E597BA0D102E9023C006@fudo.tn-mtl.local> X-Enigmail-Version: 0.94.0.0 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0088294431==" Errors-To: mip4-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0088294431== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEBCC2FA9DD3DD47A146D50E4" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEBCC2FA9DD3DD47A146D50E4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ok, updated the table, which is now at http://mip4.org/2006/implementatio= ns Thanks, Henrik on 2006-08-26 16:19 Raffi Tchakmakjian said the following: > Hi Henrik, >=20 > Here's the info you requested: >=20 > OS: Windows XP, Windows 2000 > Product Name: Nomad Mobility Client > Product URL: > http://www.trellianetworks.com/en/products/mobilitymanager.php > Comments: None >=20 > Thx, >=20 > ..R >=20 >=20 > -----Original Message----- > From: Henrik Levkowetz [mailto:henrik@levkowetz.com]=20 > Sent: August 24, 2006 12:30 PM > To: Raffi Tchakmakjian > Cc: mip4@ietf.org > Subject: Re: [Mip4] Mobile IP implementation >=20 > Hi Raffi, >=20 > Certainly, but there are some more data that would be good to have: >=20 > Operating System > Product Name > Product URL > Comments? >=20 >=20 > on 2006-08-24 12:13 Raffi Tchakmakjian said the following: >> Good morning, >>=20 >> =20 >>=20 >> I would like to add our Mobile IP implementation to this list: >>=20 >> =20 >>=20 >> IPv4, Trellia Networks, Commercial >>=20 >> =20 >>=20 >> Can you please confirm? >>=20 >> =20 >>=20 >> Thanks, >>=20 >> =20 >>=20 >> Raffi >>=20 >> =20 >>=20 >> Raffi Tchakmakjian >>=20 >> Product Manager >> 100 Alexis-Nihon, Suite 770 >> Montreal, Quebec H4M 2P3 >>=20 >> Tel.(mobile): 514-992-0232 >>=20 >> Tel.(office): 514-747-5222 >>=20 >> Fax: 514-747-7375 >>=20 >> e-mail: raffi@trellianetworks.com =20 >>=20 >> = >=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >>=20 >>=20 >=20 >=20 --------------enigEBCC2FA9DD3DD47A146D50E4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFE8GWfeVhrtTJkXCMRAjgdAJ9lcXoQ7umIXF8gn+E2YnR22GY75gCghbf2 Hghk4m7A0aUqv/VgWbivcRw= =J7Lx -----END PGP SIGNATURE----- --------------enigEBCC2FA9DD3DD47A146D50E4-- --===============0088294431== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0088294431==-- From mip4-bounces@ietf.org Sun Aug 27 09:27:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHKfA-0003lD-92; Sun, 27 Aug 2006 09:26:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGyym-0000iF-03 for mip4@ietf.org; Sat, 26 Aug 2006 10:17:44 -0400 Received: from tomts35-srv.bellnexxia.net ([209.226.175.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGyyi-0007gc-Jc for mip4@ietf.org; Sat, 26 Aug 2006 10:17:43 -0400 Received: from trellianetworks.com ([70.50.240.227]) by tomts35-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20060826141731.NZOB14422.tomts35-srv.bellnexxia.net@trellianetworks.com>; Sat, 26 Aug 2006 10:17:31 -0400 Content-class: urn:content-classes:message Subject: RE: [Mip4] Mobile IP implementation Date: Sat, 26 Aug 2006 10:19:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <85E0FDF351E7F14EB0E597BA0D102E9023C006@fudo.tn-mtl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Mip4] Mobile IP implementation thread-index: AcbHmpKtP8l31yJCToGCvX8f2m5ExgBf+IHw From: "Raffi Tchakmakjian" To: "Henrik Levkowetz" X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc X-Mailman-Approved-At: Sun, 27 Aug 2006 09:26:55 -0400 Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Henrik, Here's the info you requested: OS: Windows XP, Windows 2000 Product Name: Nomad Mobility Client Product URL: http://www.trellianetworks.com/en/products/mobilitymanager.php Comments: None Thx, ..R -----Original Message----- From: Henrik Levkowetz [mailto:henrik@levkowetz.com]=20 Sent: August 24, 2006 12:30 PM To: Raffi Tchakmakjian Cc: mip4@ietf.org Subject: Re: [Mip4] Mobile IP implementation Hi Raffi, Certainly, but there are some more data that would be good to have: Operating System Product Name Product URL Comments? on 2006-08-24 12:13 Raffi Tchakmakjian said the following: > Good morning, >=20 > =20 >=20 > I would like to add our Mobile IP implementation to this list: >=20 > =20 >=20 > IPv4, Trellia Networks, Commercial >=20 > =20 >=20 > Can you please confirm? >=20 > =20 >=20 > Thanks, >=20 > =20 >=20 > Raffi >=20 > =20 >=20 > Raffi Tchakmakjian >=20 > Product Manager > 100 Alexis-Nihon, Suite 770 > Montreal, Quebec H4M 2P3 >=20 > Tel.(mobile): 514-992-0232 >=20 > Tel.(office): 514-747-5222 >=20 > Fax: 514-747-7375 >=20 > e-mail: raffi@trellianetworks.com =20 >=20 > > =20 >=20 > =20 >=20 > =20 >=20 >=20 >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Sun Aug 27 09:27:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHKfA-0003l8-2i; Sun, 27 Aug 2006 09:26:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGN0O-0004IK-13; Thu, 24 Aug 2006 17:44:52 -0400 Received: from cowpens.ceas.rochester.edu ([128.151.162.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGN0K-0006aO-AF; Thu, 24 Aug 2006 17:44:52 -0400 Received: from h307pc2 (h318fw1.ceas.roFrom mip4-bounces@ietf.org Sun Aug 27 09:27:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHKfA-0003lD-92; Sun, 27 Aug 2006 09:26:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGyym-0000iF-03 for mip4@ietf.org; Sat, 26 Aug 2006 10:17:44 -0400 Received: from tomts35-srv.bellnexxia.net ([209.226.175.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGyyi-0007gc-Jc for mip4@ietf.org; Sat, 26 Aug 2006 10:17:43 -0400 Received: from trellianetworks.com ([70.50.240.227]) by tomts35-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20060826141731.NZOB14422.tomts35-srv.bellnexxia.net@trellianetworks.com>; Sat, 26 Aug 2006 10:17:31 -0400 Content-class: urn:content-classes:message Subject: RE: [Mip4] Mobile IP implementation Date: Sat, 26 Aug 2006 10:19:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <85E0FDF351E7F14EB0E597BA0D102E9023C006@fudo.tn-mtl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Mip4] Mobile IP implementation thread-index: AcbHmpKtP8l31yJCToGCvX8f2m5ExgBf+IHw From: "Raffi Tchakmakjian" To: "Henrik Levkowetz" X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc X-Mailman-Approved-At: Sun, 27 Aug 2006 09:26:55 -0400 Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Henrik, Here's the info you requested: OS: Windows XP, Windows 2000 Product Name: Nomad Mobility Client Product URL: http://www.trellianetworks.com/en/products/mobilitymanager.php Comments: None Thx, ..R -----Original Message----- From: Henrik Levkowetz [mailto:henrik@levkowetz.com]=20 Sent: August 24, 2006 12:30 PM To: Raffi Tchakmakjian Cc: mip4@ietf.org Subject: Re: [Mip4] Mobile IP implementation Hi Raffi, Certainly, but there are some more data that would be good to have: Operating System Product Name Product URL Comments? on 2006-08-24 12:13 Raffi Tchakmakjian said the following: > Good morning, >=20 > =20 >=20 > I would like to add our Mobile IP implementation to this list: >=20 > =20 >=20 > IPv4, Trellia Networks, Commercial >=20 > =20 >=20 > Can you please confirm? >=20 > =20 >=20 > Thanks, >=20 > =20 >=20 > Raffi >=20 > =20 >=20 > Raffi Tchakmakjian >=20 > Product Manager > 100 Alexis-Nihon, Suite 770 > Montreal, Quebec H4M 2P3 >=20 > Tel.(mobile): 514-992-0232 >=20 > Tel.(office): 514-747-5222 >=20 > Fax: 514-747-7375 >=20 > e-mail: raffi@trellianetworks.com =20 >=20 > > =20 >=20 > =20 >=20 > =20 >=20 >=20 >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Sun Aug 27 09:27:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHKfA-0003l8-2i; Sun, 27 Aug 2006 09:26:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGN0O-0004IK-13; Thu, 24 Aug 2006 17:44:52 -0400 Received: from cowpens.ceas.rochester.edu ([128.151.162.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGN0K-0006aO-AF; Thu, 24 Aug 2006 17:44:52 -0400 Received: from h307pc2 (h318fw1.ceas.rochester.edu [128.151.164.245]) by cowpens.ceas.rochester.edu (8.13.6/8.13.6) with SMTP id k7OLil9V005462; Thu, 24 Aug 2006 17:44:47 -0400 (EDT) Message-ID: <01c301c6c7c6$85c06b70$c000a8c0@h307pc2> From: "Wendi Heinzelman" To: , Date: Thu, 24 Aug 2006 17:44:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: a6ea8837e8866a83aa68ed7cf9155ec9 X-Mailman-Approved-At: Sun, 27 Aug 2006 09:26:55 -0400 Cc: Subject: [Mip4] IEEE SECON 2006 Call for Participation-- early registration deadline approaching! X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org ************************************************************** **** Note the early registration deadline for SECON is September 1, 2006 **** ************************************************************** (Apologies if you receive this information multiple times.) Dear Colleague, Please find below the Call for Participation for IEEE SECON 2006, The Third IEEE International Conference on Sensors, Mesh and Ad Hoc Communications and Networks. The detailed conference program included advance technical program, panel, tutorial and workshops information is presented below. More information is available at: http://www.ieee-secon.org/2006/ Discounted registration for the conference ends September 1, 2006. We look forward to your participation in the conference. If you have any questions, please do not hesitate to contact any of the conference organizers listed below. Best Regards, IEEE SECON 2006 Conference Organizing Committee *********************************************************************** CALL FOR PARTICIPATION IEEE SECON 2006 The Third IEEE International Conference on Sensors, Mesh and Ad Hoc Communications and Networks http://www.ieee-secon.org/2006/ Sponsored by IEEE Communications Society (www.comsoc.org) Technically Co-Sponsored by AFCEA (www.afcea.org) September 25-28, 2006 Hyatt Reston, Reston, Virginia, USA (Near Washington DC's Dulles airport) ************************************************************************ MONDAY, September 25, 2006 A. WORKSHOPS The IEEE SECON 2006 conference will host the following two workshops, that will be held on Monday, September 25, 2006: 1. Second IEEE Workshop on Wireless Mesh Networks: http://www.ieee-secon.org/2006/wimesh/index.htm Workshop Co-Chairs: Prof. Samir R. Das, Stony Brook University Dr. Thyaga Nandagopal, Bell Labs, Lucent Technologies 2. First IEEE Workshop on Networking Technologies for Software Defined Radio (SDR) Networks: http://www.ieee-secon.org/2006/wsdr/index.htm Workshop Chair: Dr. Thomas Hou, Virginia Tech. B. TUTORIAL: Title: 802.11s: Wireless Local Area Mesh Networking Standard Date: Monday, Sep 25, 2006; Time: 1:30 PM - 5:00 PM Speakers * Donald Eastlake, Motorola Laboratories * Susan Hares, NextHop Technologies * Meiyuan Zhao, Intel Research ========================================================================= TENTATIVE CONFERENCE ADVANCE PROGRAM TUESDAY, September 26, 2006 chester.edu [128.151.164.245]) by cowpens.ceas.rochester.edu (8.13.6/8.13.6) with SMTP id k7OLil9V005462; Thu, 24 Aug 2006 17:44:47 -0400 (EDT) Message-ID: <01c301c6c7c6$85c06b70$c000a8c0@h307pc2> From: "Wendi Heinzelman" To: , Date: Thu, 24 Aug 2006 17:44:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: a6ea8837e8866a83aa68ed7cf9155ec9 X-Mailman-Approved-At: Sun, 27 Aug 2006 09:26:55 -0400 Cc: Subject: [Mip4] IEEE SECON 2006 Call for Participation-- early registration deadline approaching! X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org ************************************************************** **** Note the early registration deadline for SECON is September 1, 2006 **** ************************************************************** (Apologies if you receive this information multiple times.) Dear Colleague, Please find below the Call for Participation for IEEE SECON 2006, The Third IEEE International Conference on Sensors, Mesh and Ad Hoc Communications and Networks. The detailed conference program included advance technical program, panel, tutorial and workshops information is presented below. More information is available at: http://www.ieee-secon.org/2006/ Discounted registration for the conference ends September 1, 2006. We look forward to your participation in the conference. If you have any questions, please do not hesitate to contact any of the conference organizers listed below. Best Regards, IEEE SECON 2006 Conference Organizing Committee *********************************************************************** CALL FOR PARTICIPATION IEEE SECON 2006 The Third IEEE International Conference on Sensors, Mesh and Ad Hoc Communications and Networks http://www.ieee-secon.org/2006/ Sponsored by IEEE Communications Society (www.comsoc.org) Technically Co-Sponsored by AFCEA (www.afcea.org) September 25-28, 2006 Hyatt Reston, Reston, Virginia, USA (Near Washington DC's Dulles airport) ************************************************************************ MONDAY, September 25, 2006 A. WORKSHOPS The IEEE SECON 2006 conference will host the following two workshops, that will be held on Monday, September 25, 2006: 1. Second IEEE Workshop on Wireless Mesh Networks: http://www.ieee-secon.org/2006/wimesh/index.htm Workshop Co-Chairs: Prof. Samir R. Das, Stony Brook University Dr. Thyaga Nandagopal, Bell Labs, Lucent Technologies 2. First IEEE Workshop on Networking Technologies for Software Defined Radio (SDR) Networks: http://www.ieee-secon.org/2006/wsdr/index.htm Workshop Chair: Dr. Thomas Hou, Virginia Tech. B. TUTORIAL: Title: 802.11s: Wireless Local Area Mesh Networking Standard Date: Monday, Sep 25, 2006; Time: 1:30 PM - 5:00 PM Speakers * Donald Eastlake, Motorola Laboratories * Susan Hares, NextHop Technologies * Meiyuan Zhao, Intel Research ========================================================================= TENTATIVE CONFERENCE ADVANCE PROGRAM TUESDAY, September 26, 2006 8:30 AM - 10:00 AM: Opening Remarks and Keynote Talk (TBA) 10.00 AM - 11:00 AM: Posters/Demos 11:00 AM - 12:30 PM: Panel 1: Mesh in Metro: reality and future Moderator: Prakash Iyer, Intel Panelists: Edward Naef, CSMG Vann Hasty, Motorola Malik Audeh, Tropos -------------------------------------------------------------------- 2:00 PM - 3:30 PM: (2 Parallel Tracks - Sessions 1 and 2) Session 1: Routing I Data-Centric Routing in Sensor Networks using Biased Walk Huilong Huang (University of Arizona); John Hartman (University of Arizona); Terril Hurst (University of Arizona) Search-Quality Tradeoffs for Routing in Non-Ideal Wireless Networks Chiranjeeb Buragohain (University of California, Santa Barbara); Divyakant Agrawal (University of California, Santa Barbara); Subhash Suri (University of California at Santa Barbara) GMR: Geographic Multicast Routing for Wireless Sensor Networks Juan Sanchez (University of Murcia); Pedro Ruiz (University of Murcia); Ivan Stojmenovic (University of Ottawa) Scalable Routing in Sensor Actuator Networks with Churn Thomas Fuhrmann (University of Karlsruhe) -------------------------------------------------------------------- Session 2: Security and Privacy Security Services in Wireless Sensor Networks Using Sparse Random Coding Farshid Delgosha (Georgia Institute of Technology); Erman ayday (Georgia Institute of Technology); Kevin Chan (Georgia Tech); Faramarz Fekri (Georgia Institute of Technology) Relationship-Based Detection of Spoofing-Related Anomalous Traffic in Ad Hoc Networks Qing Li (Rutgers University); Wade Trappe (Rutgers University) A Trust Based Framework for Secure Data Aggregation in Wireless Sensor Networks Wei Zhang (University of Texas at Arlington); Sajal Das (The University of Texas at Arlington); Yonghe Liu (UT Arlington) An Anonymous Routing Protocol with The Local-Repair Mechanism for Mobile Ad Hoc Networks Bo Zhu (George Mason University); Sushil Jajodia (George Mason University) -------------------------------------------------------------------- 4:00 PM - 5:30 PM: (2 Parallel Tracks - Sessions 3 and 4) Session 3: Forwarding Protocols Minimum Latency Broadcasting in Multi-Radio Multi-Channel Multi-Rate Wireless Meshes Junaid Qadir (University of New South Wales); Archan Misra (IBM T J Watson Research Center); Chun Tung Chou (University of New South Wales) Solicitation-Based Forwarding for Sensor Networks Seoung-Bum Lee (Columbia University); Kyung Joon Kwak (Columbia University); Andrew Campbell (Dartmouth College) Coverage Aware Buffer Management and Scheduling for Wireless Sensor Networks Eugene Chai (National University of Singapore); Mun Choon Chan (National University of Singapore); Akkihebbal L. Ananda (National University of Singapore) A Communication Architecture for Mobile Wireless Sensor and Actor Networks Tommaso Melodia (Georgia Institute of Technology); Dario Pompili (Georgia Institute of Technology); Ian Akyildiz (Georgia Institute of Technology) -------------------------------------------------------------------- Session 4: Spatial Reuse and Spectrum Allocation Belief-Assisted Pricing for Dynamic Spectrum Allocation in Wireless Networks with Selfish Users Zhu Ji (University of Maryland, College Park); K.J. Ray Liu (University of Maryland) Spatial Diversity Benefits by Means of Induced Fading Daniele Puccinelli (University of Notre Dame); Martin Haenggi (University of Notre Dame) Scheduling Optimization in Wireless MESH Networks with Power Control and Rate Adaptation Antonio Capone (Politecnico di Milano); Giuliana Carello (Politecnico di Milano) *************** END OF TUESDAY PROGRAM *********************************** WEDNESDAY, September 27, 2006 8:30 AM - 10.00 AM: Panel 2: Scaling to Large Sensor Networks - How Large is too Large? Moderator: Dr. James A. Freebersyser, BBN Panelists: Mr. Patrick Gonia, Honeywell Prof. William J. Kaiser, UCLA Prof. Prasun Sinha, Ohio State University 8:30 AM - 10:00 AM: Opening Remarks and Keynote Talk (TBA) 10.00 AM - 11:00 AM: Posters/Demos 11:00 AM - 12:30 PM: Panel 1: Mesh in Metro: reality and future Moderator: Prakash Iyer, Intel Panelists: Edward Naef, CSMG Vann Hasty, Motorola Malik Audeh, Tropos -------------------------------------------------------------------- 2:00 PM - 3:30 PM: (2 Parallel Tracks - Sessions 1 and 2) Session 1: Routing I Data-Centric Routing in Sensor Networks using Biased Walk Huilong Huang (University of Arizona); John Hartman (University of Arizona); Terril Hurst (University of Arizona) Search-Quality Tradeoffs for Routing in Non-Ideal Wireless Networks Chiranjeeb Buragohain (University of California, Santa Barbara); Divyakant Agrawal (University of California, Santa Barbara); Subhash Suri (University of California at Santa Barbara) GMR: Geographic Multicast Routing for Wireless Sensor Networks Juan Sanchez (University of Murcia); Pedro Ruiz (University of Murcia); Ivan Stojmenovic (University of Ottawa) Scalable Routing in Sensor Actuator Networks with Churn Thomas Fuhrmann (University of Karlsruhe) -------------------------------------------------------------------- Session 2: Security and Privacy Security Services in Wireless Sensor Networks Using Sparse Random Coding Farshid Delgosha (Georgia Institute of Technology); Erman ayday (Georgia Institute of Technology); Kevin Chan (Georgia Tech); Faramarz Fekri (Georgia Institute of Technology) Relationship-Based Detection of Spoofing-Related Anomalous Traffic in Ad Hoc Networks Qing Li (Rutgers University); Wade Trappe (Rutgers University) A Trust Based Framework for Secure Data Aggregation in Wireless Sensor Networks Wei Zhang (University of Texas at Arlington); Sajal Das (The University of Texas at Arlington); Yonghe Liu (UT Arlington) An Anonymous Routing Protocol with The Local-Repair Mechanism for Mobile Ad Hoc Networks Bo Zhu (George Mason University); Sushil Jajodia (George Mason University) -------------------------------------------------------------------- 4:00 PM - 5:30 PM: (2 Parallel Tracks - Sessions 3 and 4) Session 3: Forwarding Protocols Minimum Latency Broadcasting in Multi-Radio Multi-Channel Multi-Rate Wireless Meshes Junaid Qadir (University of New South Wales); Archan Misra (IBM T J Watson Research Center); Chun Tung Chou (University of New South Wales) Solicitation-Based Forwarding for Sensor Networks Seoung-Bum Lee (Columbia University); Kyung Joon Kwak (Columbia University); Andrew Campbell (Dartmouth College) Coverage Aware Buffer Management and Scheduling for Wireless Sensor Networks Eugene Chai (National University of Singapore); Mun Choon Chan (National University of Singapore); Akkihebbal L. Ananda (National University of Singapore) A Communication Architecture for Mobile Wireless Sensor and Actor Networks Tommaso Melodia (Georgia Institute of Technology); Dario Pompili (Georgia Institute of Technology); Ian Akyildiz (Georgia Institute of Technology) -------------------------------------------------------------------- Session 4: Spatial Reuse and Spectrum Allocation Belief-Assisted Pricing for Dynamic Spectrum Allocation in Wireless Networks with Selfish Users Zhu Ji (University of Maryland, College Park); K.J. Ray Liu (University of Maryland) Spatial Diversity Benefits by Means of Induced Fading Daniele Puccinelli (University of Notre Dame); Martin Haenggi (University of Notre Dame) Scheduling Optimization in Wireless MESH Networks with Power Control and Rate Adaptation Antonio Capone (Politecnico di Milano); Giuliana Carello (Politecnico di Milano) *************** END OF TUESDAY PROGRAM *********************************** WEDNESDAY, September 27, 2006 8:30 AM - 10.00 AM: Panel 2: Scaling to Large Sensor Networks - How Large is too Large? Moderator: Dr. James A. Freebersyser, BBN Panelists: Mr. Patrick Gonia, Honeywell Prof. William J. Kaiser, UCLA Prof. Prasun Sinha, Ohio State University Mr. Mike Horton, Crossbow 10.00 AM - 11:00 AM: Posters/Demos 11:00 AM - 12:30 PM: (3 Parallel Tracks - Sessions 5, 6 and 7) Session 5: Platforms and Development Environments Balancing Computation and Communication Costs: The Case for Hybrid Execution in Sensor Networks Ingwar Wirjawan (University of California, Davis); Joel Koshy (University of California, Davis); Raju Pandey (University of California, Davis); Yann Ramin (University of California, Davis) EmPro: An Environment/Energy Emulation and Profiling Platform for Wireless Sensor Networks Chulsung Park (University of California, Irvine); Pai Chou (University of California, Irvine) AmbiMax: Efficient, Autonomous Energy Harvesting System for Multiple-Supply Wireless Sensor Nodes Chulsung Park (University of California, Irvine); Pai Chou (University of California, Irivne) TinyXXL: Language and Runtime Support for Cross-Layer Interactions Andreas Lachenmann (University of Stuttgart); Pedro Jos Marrn (University of Stuttgart); Daniel Minder (University of Stuttgart); Matthias Gauger (University of Stuttgart); Olga Saukh (University of Stuttgart); Kurt Rothermel (University of Stuttgart) -------------------------------------------------------------------- Session 6: Cooperative Communication When Does Cooperation Have Better Performance in Sensor Networks? Ahmed Sadek (University of Maryland); Wei Yu (University of Maryland); K.J. Ray Liu (University of Maryland) Balancing Cooperation and Interference in Wireless Sensor Networks Sam Vakil (University of Toronto); Ben Liang (University of Toronto) Progressive Network Coding for Message-Forwarding in Ad-Hoc Wireless Networks Xingkai Bao (Lehigh University); Jing Li (Lehigh University) -------------------------------------------------------------------- Session 7: Disconnection Tolerance A Proactive Data Bundling System for Intermittent Mobile Connections Caitlin Holman (University of Califonia, Santa Barbara); Khaled Harras (University of Califonia, Santa Barbara); Kevin Almeroth (University of Califonia, Santa Barbara); Anderson Lam (University of Califonia, Santa Barbara) Island Hopping: Efficient Mobility-Assisted Forwarding in Partitioned Networks Natasa Sarafijanovic (EPFL); Michal Pirkowski (EPFL); Matthias Grossglauser (EPFL) Effective Dissemination of Presence Information in Highly Partitioned Mobile Ad Hoc Networks Christoph Lindemann (University of Leipzig); Oliver Waldhorst (University of Leipzig) -------------------------------------------------------------------- 2:00 PM - 3:30 PM: (3 Parallel Tracks - Sessions 8, 9, 10) Session 8: Routing II Improving Geographical Routing for Wireless Networks with an Efficient Path Pruning Algorithm Xiaoli Ma (Georgia Institute of Technology); Min-Te Sun (Auburn University); Gang Zhao (University of Louisville); Xiangqian Liu (University of Louisville) Supervised Learning in Sensor Networks: New Approaches with Routing, Reliability Optimizations Yong Wang (Princeton University); Margaret Martonosi (Princeton University); Li-Shiuan Peh (Princeton University) MERLIN: A synergetic integration of MAC and Routing Protocol for Distributed Sensor Networks Antonio Ruzzelli (University College Dublin); Michael O'Grady (University College Dublin); Gregory O'Hare (University College Dublin); Richard Tynan (University College Dublin) -------------------------------------------------------------------- Session 9: Network Modeling and Analysis A Spatio-Temporal Model for Physical Carrier Sensing Wireless Ad-Hoc Networks Eric Wong (University of California, San Diego); Rene Cruz (University of California, San Diego) A Realistic Power Consumption Model for Wireless Sensor Network Devices Qin Wang (Harvard University); Mark Hempstead (Harvard University); Woodward Yang (Harvard University) The Analysis of a Game Theoretic MAC Protocol for Wireless Networks Hazer Inaltekin (Cornell University); Stephen Wicker (Cornell University) Optimizing Delay in Sequential Change Detect Mr. Mike Horton, Crossbow 10.00 AM - 11:00 AM: Posters/Demos 11:00 AM - 12:30 PM: (3 Parallel Tracks - Sessions 5, 6 and 7) Session 5: Platforms and Development Environments Balancing Computation and Communication Costs: The Case for Hybrid Execution in Sensor Networks Ingwar Wirjawan (University of California, Davis); Joel Koshy (University of California, Davis); Raju Pandey (University of California, Davis); Yann Ramin (University of California, Davis) EmPro: An Environment/Energy Emulation and Profiling Platform for Wireless Sensor Networks Chulsung Park (University of California, Irvine); Pai Chou (University of California, Irvine) AmbiMax: Efficient, Autonomous Energy Harvesting System for Multiple-Supply Wireless Sensor Nodes Chulsung Park (University of California, Irvine); Pai Chou (University of California, Irivne) TinyXXL: Language and Runtime Support for Cross-Layer Interactions Andreas Lachenmann (University of Stuttgart); Pedro Jos Marrn (University of Stuttgart); Daniel Minder (University of Stuttgart); Matthias Gauger (University of Stuttgart); Olga Saukh (University of Stuttgart); Kurt Rothermel (University of Stuttgart) -------------------------------------------------------------------- Session 6: Cooperative Communication When Does Cooperation Have Better Performance in Sensor Networks? Ahmed Sadek (University of Maryland); Wei Yu (University of Maryland); K.J. Ray Liu (University of Maryland) Balancing Cooperation and Interference in Wireless Sensor Networks Sam Vakil (University of Toronto); Ben Liang (University of Toronto) Progressive Network Coding for Message-Forwarding in Ad-Hoc Wireless Networks Xingkai Bao (Lehigh University); Jing Li (Lehigh University) -------------------------------------------------------------------- Session 7: Disconnection Tolerance A Proactive Data Bundling System for Intermittent Mobile Connections Caitlin Holman (University of Califonia, Santa Barbara); Khaled Harras (University of Califonia, Santa Barbara); Kevin Almeroth (University of Califonia, Santa Barbara); Anderson Lam (University of Califonia, Santa Barbara) Island Hopping: Efficient Mobility-Assisted Forwarding in Partitioned Networks Natasa Sarafijanovic (EPFL); Michal Pirkowski (EPFL); Matthias Grossglauser (EPFL) Effective Dissemination of Presence Information in Highly Partitioned Mobile Ad Hoc Networks Christoph Lindemann (University of Leipzig); Oliver Waldhorst (University of Leipzig) -------------------------------------------------------------------- 2:00 PM - 3:30 PM: (3 Parallel Tracks - Sessions 8, 9, 10) Session 8: Routing II Improving Geographical Routing for Wireless Networks with an Efficient Path Pruning Algorithm Xiaoli Ma (Georgia Institute of Technology); Min-Te Sun (Auburn University); Gang Zhao (University of Louisville); Xiangqian Liu (University of Louisville) Supervised Learning in Sensor Networks: New Approaches with Routing, Reliability Optimizations Yong Wang (Princeton University); Margaret Martonosi (Princeton University); Li-Shiuan Peh (Princeton University) MERLIN: A synergetic integration of MAC and Routing Protocol for Distributed Sensor Networks Antonio Ruzzelli (University College Dublin); Michael O'Grady (University College Dublin); Gregory O'Hare (University College Dublin); Richard Tynan (University College Dublin) -------------------------------------------------------------------- Session 9: Network Modeling and Analysis A Spatio-Temporal Model for Physical Carrier Sensing Wireless Ad-Hoc Networks Eric Wong (University of California, San Diego); Rene Cruz (University of California, San Diego) A Realistic Power Consumption Model for Wireless Sensor Network Devices Qin Wang (Harvard University); Mark Hempstead (Harvard University); Woodward Yang (Harvard University) The Analysis of a Game Theoretic MAC Protocol for Wireless Networks Hazer Inaltekin (Cornell University); Stephen Wicker (Cornell University) Optimizing Delay in Sequential Change Detection on Ad Hoc Wireless Sensor Networks Venkata K. Prasanthi M. (Indian Institute of Science, Bangalore); Anurag Kumar (Indian Institute of Science, Bangalore) -------------------------------------------------------------------- Session 10: Sensor Coverage Deployment Strategies for Differentiated Detection in Wireless Sensor Networks Jingbin Zhang (University of Virginia); Ting Yan (University of Virginia); Sang Son (University of Virginia) Sacrificing a Little Coverage Can Substantially Increase Network Lifetime Limin Wang (Michigan State University); Sandeep Kulkarni (Michigan State University) Optimal Worst-Case Coverage of Directional Field-of-View Sensor Networks Jacob Adriaens (University of Wisconsin Madison); Seapahn Megerian (University of Wisconsin Madison); Miodrag Potkonjak (University of California at Los Angeles) Mutual Exclusion in Wireless Sensor and Actor Networks Ramanuja Vedantham (Georgia Institute of Technology); Zhenyun Zhuang (Georgia Institute of Technology); Raghupathy Sivakumar (Georgia Institute of Technology) -------------------------------------------------------------------- 4:00 PM - 5:30 PM (3 Parallel Tracks - Sessions 11, 12, 13) Session 11: Localization and Ranging I Localization in Sensor Networks using Consistency-based Statistical Error Models Jessica Feng (University of California, Los Angeles); Lewis Girod (University of California, Los Angeles); Miodrag Potkonjak (University of California at Los Angeles) A Practical Approach to Landmark Deployment for Indoor Localization Yingying Chen (Rutgers University); John-Austen Francisco (Rutgers University); Wade Trappe (Rutgers University); Richard Martin (Rutgers University) Angle of Arrival Localization for Wireless Sensor Networks Rong Peng (North Carolina State University); Mihail Sichitiu (North Carolina State University) Robot-Assisted Localization Techniques for Wireless Image Sensor Networks Huang Lee (Stanford University); Hattie Dong (Stanford University); Hamid Aghajan (Stanford University) -------------------------------------------------------------------- Session 12: Medium Access Multichannel MAC Protocols for Wireless Networks Ritesh Maheshwari (Stony Brook University); Himanshu Gupta (Stony Brook University); Samir Das (Stony Brook University) RT-Link: A Time-Synchronized Link Protocol for Energy Constrained Multi-Hop Wireless Networks Anthony Rowe (Carnegie Mellon University); Rahul Mangharam (Carnegie Mellon University); Ragunathan Rajkumar (Carnegie Mellon University) Understanding the Gap between the IEEE 802.11 Protocol Performance and the Theoretical Limits Mathilde Durvy (EPFL); Patrick Thiran (EPFL) Throughput-Oriented MAC for Mobile Ad Hoc Networks with Variable Packet Sizes Ossama Younis (University of Arizona); Fan Wang (University of Arizona); Marwan Krunz (University of Arizona) -------------------------------------------------------------------- Session 13: Theoretical Foundations Topology Control to Simultaneously Achieve Near-Optimal Node Degree and Low Path Stretch in Ad Hoc Networks Ece Gelal (University of California, Riverside); Gentian Jakllari (University of California, Riverside); Srikanth Krishnamurthy (University of California, Riverside); Neal E. Young (University of California, Riverside) Distributed Linear Parameter Estimation in Sensor Networks Based on Laplacian Dynamics Consensus Algorithm Arindam Kumar Das (University of Washington); Mehran Mesbahi (University of Washington) On the Information Lifetime and the Localization Cost in Sensor Networks with Random Topologies Cedric Westphal (Nokia Research Center) Cooperation Enforcement in Autonomous MANETs under Noise and Imperfect Observation Zhu Ji (University of Maryland, College Park); Wei Yu (University of Maryland, College Park); K.J. Ray Liu (University of Maryland, College Park) *********************************** END OF WEDNESDAY PROGRAM *********** THURSDAY, September 28, 2006 8:30 AM - 10:00 AM: Panel/Invited Session: TBA 10:00 AMion on Ad Hoc Wireless Sensor Networks Venkata K. Prasanthi M. (Indian Institute of Science, Bangalore); Anurag Kumar (Indian Institute of Science, Bangalore) -------------------------------------------------------------------- Session 10: Sensor Coverage Deployment Strategies for Differentiated Detection in Wireless Sensor Networks Jingbin Zhang (University of Virginia); Ting Yan (University of Virginia); Sang Son (University of Virginia) Sacrificing a Little Coverage Can Substantially Increase Network Lifetime Limin Wang (Michigan State University); Sandeep Kulkarni (Michigan State University) Optimal Worst-Case Coverage of Directional Field-of-View Sensor Networks Jacob Adriaens (University of Wisconsin Madison); Seapahn Megerian (University of Wisconsin Madison); Miodrag Potkonjak (University of California at Los Angeles) Mutual Exclusion in Wireless Sensor and Actor Networks Ramanuja Vedantham (Georgia Institute of Technology); Zhenyun Zhuang (Georgia Institute of Technology); Raghupathy Sivakumar (Georgia Institute of Technology) -------------------------------------------------------------------- 4:00 PM - 5:30 PM (3 Parallel Tracks - Sessions 11, 12, 13) Session 11: Localization and Ranging I Localization in Sensor Networks using Consistency-based Statistical Error Models Jessica Feng (University of California, Los Angeles); Lewis Girod (University of California, Los Angeles); Miodrag Potkonjak (University of California at Los Angeles) A Practical Approach to Landmark Deployment for Indoor Localization Yingying Chen (Rutgers University); John-Austen Francisco (Rutgers University); Wade Trappe (Rutgers University); Richard Martin (Rutgers University) Angle of Arrival Localization for Wireless Sensor Networks Rong Peng (North Carolina State University); Mihail Sichitiu (North Carolina State University) Robot-Assisted Localization Techniques for Wireless Image Sensor Networks Huang Lee (Stanford University); Hattie Dong (Stanford University); Hamid Aghajan (Stanford University) -------------------------------------------------------------------- Session 12: Medium Access Multichannel MAC Protocols for Wireless Networks Ritesh Maheshwari (Stony Brook University); Himanshu Gupta (Stony Brook University); Samir Das (Stony Brook University) RT-Link: A Time-Synchronized Link Protocol for Energy Constrained Multi-Hop Wireless Networks Anthony Rowe (Carnegie Mellon University); Rahul Mangharam (Carnegie Mellon University); Ragunathan Rajkumar (Carnegie Mellon University) Understanding the Gap between the IEEE 802.11 Protocol Performance and the Theoretical Limits Mathilde Durvy (EPFL); Patrick Thiran (EPFL) Throughput-Oriented MAC for Mobile Ad Hoc Networks with Variable Packet Sizes Ossama Younis (University of Arizona); Fan Wang (University of Arizona); Marwan Krunz (University of Arizona) -------------------------------------------------------------------- Session 13: Theoretical Foundations Topology Control to Simultaneously Achieve Near-Optimal Node Degree and Low Path Stretch in Ad Hoc Networks Ece Gelal (University of California, Riverside); Gentian Jakllari (University of California, Riverside); Srikanth Krishnamurthy (University of California, Riverside); Neal E. Young (University of California, Riverside) Distributed Linear Parameter Estimation in Sensor Networks Based on Laplacian Dynamics Consensus Algorithm Arindam Kumar Das (University of Washington); Mehran Mesbahi (University of Washington) On the Information Lifetime and the Localization Cost in Sensor Networks with Random Topologies Cedric Westphal (Nokia Research Center) Cooperation Enforcement in Autonomous MANETs under Noise and Imperfect Observation Zhu Ji (University of Maryland, College Park); Wei Yu (University of Maryland, College Park); K.J. Ray Liu (University of Maryland, College Park) *********************************** END OF WEDNESDAY PROGRAM *********** THURSDAY, September 28, 2006 8:30 AM - 10:00 AM: Panel/Invited Session: TBA 10:00 AM - 11:00 AM: Posters/Demos 11:00 AM - 12:30 PM: (2 Parallel Tracks - Sessions 14, 15) Session 14: Topology Control Joint Range and Load Considerations for Topology Control in Wireless Ad Hoc Networks Sajjad Zarifzadeh (University of Tehran); Amir Nayyeri (University of Tehran) Distributed Fair Transmit Power Adjustment for Vehicular Ad Hoc Networks Marc Torrent-Moreno (University of Karlsruhe); Paolo Santi (CNR); Hannes Hartenstein (University of Karlsruhe) Low-Complexity Beamforming Techniques for Wireless Multihop Networks Robert Vilzmann (Technische Universit t Mnchen); Jrg Widmer (DoCoMo Euro-Labs); Imad Aad (DoCoMo Euro-Labs); Christian Hartmann (Technische Universit t Mnchen) Energy Efficient Transmission Scheme for Data-Gathering in Mobile Sensor Networks Chao Wang (University of Wisconsin, Madison); Parmesh Ramanathan (University of Wisconsin at Madison) Session 15: Energy Management LEARN: Localized Energy Aware Restricted Neighborhood Routing for Ad Hoc Networks Xiang-Yang Li (Illinois Institute of Technology); Yu Wang (Univeristy of North Carolina at Charlotte); Wen-Zhan Song (Washington State University, Vancouver); Weizhao Wang (Illinois Institute of Technology) A New Method for Distributing Power Usage Across a Sensor Network Patrick Vincent (Naval Postgraduate School); Murali Tummala (Naval Postgraduate School); John McEachen (Naval Postgraduate School) Energy Efficient Network Reconfiguration for Mostly-Off Sensor Networks Yuan Li (University of Southern California); Wei Ye (University of Southern California); John Heidemann (University of Southern California) 2:00 PM - 3:30 PM: (2 Parallel Tracks - Sessions 16, 17) Session 16: Localization and Ranging II Distance Matrix Reconstruction from Incomplete Distance Information for Sensor Network Localization Petros Drineas (RPI); Asif Javed (Rensselaer Polytechnic Institute); Malik Magdon-Ismail (RPI); Gopal Pandurangan (Purdue University); Reino Virrankoski (Helsinki University of Technology) ; Andreas Savvides (Yale University) MERIT: MEsh of RF sensors for Indoor Tracking Yui-Wah Lee (Bell Labs, Lucent Technologies); Erich Stuntebeck (Georgia Institute of Technology); Scott Miller (Bell Labs, Lucent Technologies) Reducing the Computational Cost of Bayesian Indoor Positioning Systems Konstantin Kleisouris (Rutgers University); Richard Martin (Rutgers University) Sensor-Enhanced Mobility Prediction for Energy-Efficient Localization Chuang-wen You (National Taiwan University); Yi-Chao Chen (National Taiwan University); Hao-hua Chu (National Taiwan University); Polly Huang (National Taiwan University); Ji-Rung Chiang (National Taiwan University); Seng-Yong Lau (National Taiwan University) Session 17: Fault Tolerance Memento: A Health Monitoring System for Wireless Sensor Networks Stanislav Rost (Massachusetts Institute of Technology); Hari Balakrishnan (Massachusetts Institute of Technology) Cross-Layer Analysis of Error Control in Wireless Sensor Networks Mehmet Vuran (Georgia Institute of Technology); Ian Akyildiz (Georgia Institute of Technology) RideSharing: Fault Tolerant Aggregation in Sensor Networks Using Corrective Actions Sameh Gobriel (University of Pittsburgh); Sherif Khattab (University of Pittsburgh); Daniel Mosse (University of Pittsburgh); Jose Brustoloni (University of Pittsburgh); Rami Melhem (University of Pittsburgh) ======================================================================== CONFERENCE ORGANIZING COMMITEE ------------------------------ GENERAL CHAIR: Krishna Sivalingam, University of Maryland Baltimore County, krishna@umbc.edu TECHNICAL PROGRAM CO-CHAIRS: Mark Yarvis, Intel Corporation, mark.d.yarvis@intel.com Michele Zorzi, Universita' degli Studi di Padova, zorzi@dei.unipd.it POSTERS/DEMOS CO-CHAIRS: Stefano Basagni, Northeastern University, basagni@ece.neu.edu Cedric Westphal, Nokia, Cedric.Westphal@nokia.com PANELS CO-CHAIRS: Ian Chakeres, Boeing, ian.chakeres@gmail.com Lily Yang, Intel, - 11:00 AM: Posters/Demos 11:00 AM - 12:30 PM: (2 Parallel Tracks - Sessions 14, 15) Session 14: Topology Control Joint Range and Load Considerations for Topology Control in Wireless Ad Hoc Networks Sajjad Zarifzadeh (University of Tehran); Amir Nayyeri (University of Tehran) Distributed Fair Transmit Power Adjustment for Vehicular Ad Hoc Networks Marc Torrent-Moreno (University of Karlsruhe); Paolo Santi (CNR); Hannes Hartenstein (University of Karlsruhe) Low-Complexity Beamforming Techniques for Wireless Multihop Networks Robert Vilzmann (Technische Universit t Mnchen); Jrg Widmer (DoCoMo Euro-Labs); Imad Aad (DoCoMo Euro-Labs); Christian Hartmann (Technische Universit t Mnchen) Energy Efficient Transmission Scheme for Data-Gathering in Mobile Sensor Networks Chao Wang (University of Wisconsin, Madison); Parmesh Ramanathan (University of Wisconsin at Madison) Session 15: Energy Management LEARN: Localized Energy Aware Restricted Neighborhood Routing for Ad Hoc Networks Xiang-Yang Li (Illinois Institute of Technology); Yu Wang (Univeristy of North Carolina at Charlotte); Wen-Zhan Song (Washington State University, Vancouver); Weizhao Wang (Illinois Institute of Technology) A New Method for Distributing Power Usage Across a Sensor Network Patrick Vincent (Naval Postgraduate School); Murali Tummala (Naval Postgraduate School); John McEachen (Naval Postgraduate School) Energy Efficient Network Reconfiguration for Mostly-Off Sensor Networks Yuan Li (University of Southern California); Wei Ye (University of Southern California); John Heidemann (University of Southern California) 2:00 PM - 3:30 PM: (2 Parallel Tracks - Sessions 16, 17) Session 16: Localization and Ranging II Distance Matrix Reconstruction from Incomplete Distance Information for Sensor Network Localization Petros Drineas (RPI); Asif Javed (Rensselaer Polytechnic Institute); Malik Magdon-Ismail (RPI); Gopal Pandurangan (Purdue University); Reino Virrankoski (Helsinki University of Technology) ; Andreas Savvides (Yale University) MERIT: MEsh of RF sensors for Indoor Tracking Yui-Wah Lee (Bell Labs, Lucent Technologies); Erich Stuntebeck (Georgia Institute of Technology); Scott Miller (Bell Labs, Lucent Technologies) Reducing the Computational Cost of Bayesian Indoor Positioning Systems Konstantin Kleisouris (Rutgers University); Richard Martin (Rutgers University) Sensor-Enhanced Mobility Prediction for Energy-Efficient Localization Chuang-wen You (National Taiwan University); Yi-Chao Chen (National Taiwan University); Hao-hua Chu (National Taiwan University); Polly Huang (National Taiwan University); Ji-Rung Chiang (National Taiwan University); Seng-Yong Lau (National Taiwan University) Session 17: Fault Tolerance Memento: A Health Monitoring System for Wireless Sensor Networks Stanislav Rost (Massachusetts Institute of Technology); Hari Balakrishnan (Massachusetts Institute of Technology) Cross-Layer Analysis of Error Control in Wireless Sensor Networks Mehmet Vuran (Georgia Institute of Technology); Ian Akyildiz (Georgia Institute of Technology) RideSharing: Fault Tolerant Aggregation in Sensor Networks Using Corrective Actions Sameh Gobriel (University of Pittsburgh); Sherif Khattab (University of Pittsburgh); Daniel Mosse (University of Pittsburgh); Jose Brustoloni (University of Pittsburgh); Rami Melhem (University of Pittsburgh) ======================================================================== CONFERENCE ORGANIZING COMMITEE ------------------------------ GENERAL CHAIR: Krishna Sivalingam, University of Maryland Baltimore County, krishna@umbc.edu TECHNICAL PROGRAM CO-CHAIRS: Mark Yarvis, Intel Corporation, mark.d.yarvis@intel.com Michele Zorzi, Universita' degli Studi di Padova, zorzi@dei.unipd.it POSTERS/DEMOS CO-CHAIRS: Stefano Basagni, Northeastern University, basagni@ece.neu.edu Cedric Westphal, Nokia, Cedric.Westphal@nokia.com PANELS CO-CHAIRS: Ian Chakeres, Boeing, ian.chakeres@gmail.com Lily Yang, Intel, lily.l.yang@intel.com WORKSHOPS CHAIR: Tom Hou, Virginia Tech, thou@vt.edu STUDENT TRAVEL GRANTS CHAIR: Wenye Wang, NCSU, wwang@eos.ncsu.edu PUBLICITY CHAIR: Wendi Heinzelman, University of Rochester, wheinzel@ece.rochester.edu EXHIBITS/SPONSORSHIPS CHAIR: Vishal Anand, SUNY Brockport, vanand@brockport.edu LOCAL ARRANGEMENTS CHAIR: Mohamed Eltoweissy, Virgina Tech, toweissy@vt.edu STANDING COMMITTEE: Fred Bauer (fred@fredbauer.com) [CHAIR] Harvey Freeman Sung-Ju Lee, HP Labs Prasant Mohapatra, University of California, Davis TECHNICAL PROGRAM COMMITTEE --------------------------- Abouzeid, Alhussein Rensselaer Polytechnic Institute Almeroth, Kevin University of California at Santa Barbara Banerjee, Sujata Hewlett-Packard Laboratories Banerjee, Suman University of Wisconsin Basagni, Stefano Northeastern University Belding-Royer, Elizabeth University of California at Santa Barbara Bianchi, Giuseppe University of Rome, Tor Vergata Boutaba, Raouf University of Waterloo Cao, Guohong Pennsylvania State University Cayirci, Erdal GeNeTLab Chandra, Surendar University of Notre Dame Chevillat, Pierre IBM Zurich Research Laboratory Choi, Sunghyun Seoul National Unversity Chuah, Chen-Nee University of California, Davis Das, Sajal University of Texas at Arlington Das, Samir SUNY at Stony Brook Ekici, Eylem Ohio State University ElBatt, Tamer Hughes Research Laboratories, LLC Ephremides, Anthony University of Maryland at College Park Giordano, Silvia University of Applied Science SUPSI, Lugano Hares, Susan NextHop Havinga, Paul University of Twente Helmy, Ahmed University of Southern California Iyer, Sridhar Indian Institute of Technology Jetcheva, Jorjeta Firetide, Inc. Jha, Sanjay University of New South Wales Kangude, Shantanu Texas Instruments, Inc. Kasera, Sneha University of Utah Ko, Young-Bae Ajou University Koodli, Rajeev Nokia Research Center Krishnamachari, Bhaskar University of Southern California Krishnamurthy, Lakshman Intel Corporation Langendoen, Koen Delft University of Technology Lee, Sung-Ju Hewlett-Packard Laboratories Li, Li Bell Labs, Lucent Technologies Martin, Richard Rutgers University Mohapatra, Prasant University of California, Davis Morabito, Giacomo University of Catania Nandagopal, Thyaga Bell Labs, Lucent Technologies Ning, Peng North Carolina State University Pagani, Elena University of Milano Papagiannaki, Konstantina Intel Corporation Petrioli, Chiara University of Rome, la Sapienza Popovski, Petar Aalborg University Qiu, Lili University of Texas at Austin Ramasubramanian, Srini Unviersity of Arizona Ramasubramanian, Venugopalan Cornell University Reisslein, Martin Arizona State University Rhee, Sokwoo Millennial Net Roemer, Kay Swiss Federal Institute of Technology, Zurich Santi, Paolo CNR (National Research Council), Italy Schurgers, Curt University of California at San Diego Shorey, Rajeev General Motors Research, Bangalore Singh, Harkirat Samsung Electronics Singh, Suresh Portland State University Srinivasan, Vikram National University of Singapore Stankovic, John University of Virginia Trappe, Wade Rutgers University Tseng, Yu-Chee National Chiao-Tung University Wang, Xudong Kiyon, Inc. Westphal, Cedric Nokia Research Center Widmer, Joerg DoCoMo Eurolabs Zhang, Junshan Arizona State University Zhang, Qian Hong Kong University of Science and Technology Zheng, Haitao University of California at Santa Barbara Znati, Taieb University of Pittsburgh -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ lily.l.yang@intel.com WORKSHOPS CHAIR: Tom Hou, Virginia Tech, thou@vt.edu STUDENT TRAVEL GRANTS CHAIR: Wenye Wang, NCSU, wwang@eos.ncsu.edu PUBLICITY CHAIR: Wendi Heinzelman, University of Rochester, wheinzel@ece.rochester.edu EXHIBITS/SPONSORSHIPS CHAIR: Vishal Anand, SUNY Brockport, vanand@brockport.edu LOCAL ARRANGEMENTS CHAIR: Mohamed Eltoweissy, Virgina Tech, toweissy@vt.edu STANDING COMMITTEE: Fred Bauer (fred@fredbauer.com) [CHAIR] Harvey Freeman Sung-Ju Lee, HP Labs Prasant Mohapatra, University of California, Davis TECHNICAL PROGRAM COMMITTEE --------------------------- Abouzeid, Alhussein Rensselaer Polytechnic Institute Almeroth, Kevin University of California at Santa Barbara Banerjee, Sujata Hewlett-Packard Laboratories Banerjee, Suman University of Wisconsin Basagni, Stefano Northeastern University Belding-Royer, Elizabeth University of California at Santa Barbara Bianchi, Giuseppe University of Rome, Tor Vergata Boutaba, Raouf University of Waterloo Cao, Guohong Pennsylvania State University Cayirci, Erdal GeNeTLab Chandra, Surendar University of Notre Dame Chevillat, Pierre IBM Zurich Research Laboratory Choi, Sunghyun Seoul National Unversity Chuah, Chen-Nee University of California, Davis Das, Sajal University of Texas at Arlington Das, Samir SUNY at Stony Brook Ekici, Eylem Ohio State University ElBatt, Tamer Hughes Research Laboratories, LLC Ephremides, Anthony University of Maryland at College Park Giordano, Silvia University of Applied Science SUPSI, Lugano Hares, Susan NextHop Havinga, Paul University of Twente Helmy, Ahmed University of Southern California Iyer, Sridhar Indian Institute of Technology Jetcheva, Jorjeta Firetide, Inc. Jha, Sanjay University of New South Wales Kangude, Shantanu Texas Instruments, Inc. Kasera, Sneha University of Utah Ko, Young-Bae Ajou University Koodli, Rajeev Nokia Research Center Krishnamachari, Bhaskar University of Southern California Krishnamurthy, Lakshman Intel Corporation Langendoen, Koen Delft University of Technology Lee, Sung-Ju Hewlett-Packard Laboratories Li, Li Bell Labs, Lucent Technologies Martin, Richard Rutgers University Mohapatra, Prasant University of California, Davis Morabito, Giacomo University of Catania Nandagopal, Thyaga Bell Labs, Lucent Technologies Ning, Peng North Carolina State University Pagani, Elena University of Milano Papagiannaki, Konstantina Intel Corporation Petrioli, Chiara University of Rome, la Sapienza Popovski, Petar Aalborg University Qiu, Lili University of Texas at Austin Ramasubramanian, Srini Unviersity of Arizona Ramasubramanian, Venugopalan Cornell University Reisslein, Martin Arizona State University Rhee, Sokwoo Millennial Net Roemer, Kay Swiss Federal Institute of Technology, Zurich Santi, Paolo CNR (National Research Council), Italy Schurgers, Curt University of California at San Diego Shorey, Rajeev General Motors Research, Bangalore Singh, Harkirat Samsung Electronics Singh, Suresh Portland State University Srinivasan, Vikram National University of Singapore Stankovic, John University of Virginia Trappe, Wade Rutgers University Tseng, Yu-Chee National Chiao-Tung University Wang, Xudong Kiyon, Inc. Westphal, Cedric Nokia Research Center Widmer, Joerg DoCoMo Eurolabs Zhang, Junshan Arizona State University Zhang, Qian Hong Kong University of Science and Technology Zheng, Haitao University of California at Santa Barbara Znati, Taieb University of Pittsburgh -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Aug 30 10:06:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIQiC-0003jy-6K; Wed, 30 Aug 2006 10:06:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIPj5-0005U7-Hb; Wed, 30 Aug 2006 09:03:27 -0400 Received: from firstclass.it.rit.edu ([129.21.21.97]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIPj3-0002v5-72; Wed, 30 Aug 2006 09:03:27 -0400 Message-id: Date: Wed, 30 Aug 2006 09:02:21 -0400 X-Mailer: FirstClass 8.2 (build 8.094) X-FC-SERVER-TZ: 15729388 From: "Nirmala Shenoy" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-Mailman-Approved-At: Wed, 30 Aug 2006 10:06:35 -0400 Subject: [Mip4] Fwd: Sensorware 2007 - New deadline - 15 Sept 2006 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org CORRECTED DEADLINE APOLOGIES IF YOU RECEIVE MULTIPLE COPIES CALL FOR PAPER – Deadline Extended – 15th Sept 2006 2nd International Workshop on Software for Sensor Networks (SensorWare) To be held with Comsware 2007 ([ http://www.comsware.org ]www.comsware.org) 8th January 2007, CityBangalore country-regionplaceIndia www.sensorware.org BEST PAPER AWARD INLCUDED Advances in technology have made deployment of miniature sensors a realistic proposition. Low-power, inexpensive smart devices with multiple on-board sensors are connected through wireless links so as to form a collaborative sensor network to perform a specific task. As a result, it opens up a new paradigm of ubiquitous computing and enables a range of applications that are previously unrealizable or too costly to be realized. However, given the limitation of on-board hardware, one of the key areas towards achieving superior performance is through software implementation. The workshop is intended to bring together industry experts and researchers to share novel techniques, algorithms and software implementation for sensor networks, and to discuss the current status, technical challenges, standards, fundamental issues, and future services and applications in the form of panels and technical presentation. Topics of interest include but are not limited to the following: 1. Operating System 2. Efficient algorithms 3. Protocol design considerations 4. Performance analysis 5. Performance related issues 6. Cross-layered design considerations 7. Sensor applications and their impact on sensor network architectures 8. Deployment issues and scenarios 9. Middleware 10. Sensor network security 11. Sensor network design and modeling Workshop co-chairs: Nirmala Shenoy ([ mailto:ns@rit.edu ]ns@rit.edu), Rochester Institute of Technology, placecountry-regionUSA Paul Chou, ([ mailto:pchou@us.ibm.com ]pchou@us.ibm.com), placeCityIBM Thomas J Watson Research Center, country-regionUSA Workshop technical co-chairs: Naoki Wakamiya, ([ mailto:Wakamiya@ist.osaka-u.ac.jp ]Wakamiya@ist.osaka-u.ac.jp), CityplaceOsaka University, country-regionJapan Falko Dressler, (dressler@informatik.uni-erlangen.de), CityplaceUniversity of Erlangen-Nuremberg, country-regionGermany Important Dates: Extended Paper Submission Deadline: 15th Sept 2006 Notification Acceptance/Rejection: 20th November 2006 Final Camera-Ready Paper Submission: 30th November 2006 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html SupplementaFrom mip4-bounces@ietf.org Wed Aug 30 10:06:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIQiC-0003jy-6K; Wed, 30 Aug 2006 10:06:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIPj5-0005U7-Hb; Wed, 30 Aug 2006 09:03:27 -0400 Received: from firstclass.it.rit.edu ([129.21.21.97]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIPj3-0002v5-72; Wed, 30 Aug 2006 09:03:27 -0400 Message-id: Date: Wed, 30 Aug 2006 09:02:21 -0400 X-Mailer: FirstClass 8.2 (build 8.094) X-FC-SERVER-TZ: 15729388 From: "Nirmala Shenoy" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-Mailman-Approved-At: Wed, 30 Aug 2006 10:06:35 -0400 Subject: [Mip4] Fwd: Sensorware 2007 - New deadline - 15 Sept 2006 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org CORRECTED DEADLINE APOLOGIES IF YOU RECEIVE MULTIPLE COPIES CALL FOR PAPER – Deadline Extended – 15th Sept 2006 2nd International Workshop on Software for Sensor Networks (SensorWare) To be held with Comsware 2007 ([ http://www.comsware.org ]www.comsware.org) 8th January 2007, CityBangalore country-regionplaceIndia www.sensorware.org BEST PAPER AWARD INLCUDED Advances in technology have made deployment of miniature sensors a realistic proposition. Low-power, inexpensive smart devices with multiple on-board sensors are connected through wireless links so as to form a collaborative sensor network to perform a specific task. As a result, it opens up a new paradigm of ubiquitous computing and enables a range of applications that are previously unrealizable or too costly to be realized. However, given the limitation of on-board hardware, one of the key areas towards achieving superior performance is through software implementation. The workshop is intended to bring together industry experts and researchers to share novel techniques, algorithms and software implementation for sensor networks, and to discuss the current status, technical challenges, standards, fundamental issues, and future services and applications in the form of panels and technical presentation. Topics of interest include but are not limited to the following: 1. Operating System 2. Efficient algorithms 3. Protocol design considerations 4. Performance analysis 5. Performance related issues 6. Cross-layered design considerations 7. Sensor applications and their impact on sensor network architectures 8. Deployment issues and scenarios 9. Middleware 10. Sensor network security 11. Sensor network design and modeling Workshop co-chairs: Nirmala Shenoy ([ mailto:ns@rit.edu ]ns@rit.edu), Rochester Institute of Technology, placecountry-regionUSA Paul Chou, ([ mailto:pchou@us.ibm.com ]pchou@us.ibm.com), placeCityIBM Thomas J Watson Research Center, country-regionUSA Workshop technical co-chairs: Naoki Wakamiya, ([ mailto:Wakamiya@ist.osaka-u.ac.jp ]Wakamiya@ist.osaka-u.ac.jp), CityplaceOsaka University, country-regionJapan Falko Dressler, (dressler@informatik.uni-erlangen.de), CityplaceUniversity of Erlangen-Nuremberg, country-regionGermany Important Dates: Extended Paper Submission Deadline: 15th Sept 2006 Notification Acceptance/Rejection: 20th November 2006 Final Camera-Ready Paper Submission: 30th November 2006 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Aug 30 10:06:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIQiC-0003jt-0D; Wed, 30 Aug 2006 10:06:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIPiG-0005NE-9G; Wed, 30 Aug 2006 09:02:36 -0400 Received: from firstclass.it.rit.edu ([129.21.21.97]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIPiB-0002k4-Uf; Wed, 30 Aug 2006 09:02:36 -0400 Message-id: Date: Wed, 30 Aug 2006 08:58:21 -0400 X-Mailer: FirstClass 8.2 (build 8.094) X-FC-SERVER-TZ: 15729388 From: "Nirmala Shenoy" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-Mailman-Approved-At: Wed, 30 Aug 2006 10:06:35 -0400 Subject: [Mip4] Sensorware 2007 - New deadline - 15 Sept 2007 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org APOLOGIES IF YOU RECEIVE MULTIPLE COPIES CALL FOR PAPER – Deadline Extended – 15th Sept 2007 2nd International Workshop on Software for Sensor Networks (SensorWare) To be held with Comsware 2007 ([ http://www.comsware.org ]www.comsware.org) 8th January 2007, CityBangalore country-regionplaceIndia www.sensorware.org BEST PAPER AWARD INLCUDED Advances in technology have made deployment of miniature sensors a realistic proposition. Low-power, inexpensive smart devices with multiple on-board sensors are connected through wireless links so as to form a collaborative sensor network to perform a specific task. As a result, it opens up a new paradigm of ubiquitous computing and enables a range of applications that are previously unrealizable or too costly to be realized. However, given the limitation of on-board hardware, one of the key areas towards achieving superior performance is through software implementation. The workshop is intended to bring together industry experts and researchers to share novel techniques, algorithms and software implementation for sensor networks, and to discuss the current status, technical challenges, standards, fundamental issues, and future services and applications in the form of panels and technical presentation. Topics of interest include but are not limited to the following: 1. Operating System 2. Efficient algorithms 3. Protocol design considerations 4. Performance analysis 5. Performance related issues 6. Cross-layered design considerations 7. Sensor applications and their impact on sensor network architectures 8. Deployment issues and scenarios 9. Middleware 10. Sensor network security 11. Sensor network design and modeling Workshop co-chairs: Nirmala Shenoy ([ mailto:ns@rit.edu ]ns@rit.edu), Rochester Institute of Technology, placecountry-regionUSA Paul Chou, ([ mailto:pchou@us.ibm.com ]pchou@us.ibm.com), placeCityIBM Thomas J Watson Research Center, country-regionUSA Workshop technical co-chairs: Naoki Wakamiya, ([ mailto:Wakamiya@ist.osaka-u.ac.jp ]Wakamiya@ist.osaka-u.ac.jp), CityplaceOsaka University, country-regionJapan Falko Dressler, (dressler@informatik.uni-erlangen.de), CityplaceUniversity of Erlangen-Nuremberg, country-regionGermany Important Dates: Extended Paper Submission Deadline: 15th Sept 2006 Notification Acceptance/Rejection: 20th November 2006 Final Camera-Ready Paper Submission: 30th November 2006 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Suppleml site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Aug 30 10:06:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIQiC-0003jt-0D; Wed, 30 Aug 2006 10:06:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIPiG-0005NE-9G; Wed, 30 Aug 2006 09:02:36 -0400 Received: from firstclass.it.rit.edu ([129.21.21.97]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIPiB-0002k4-Uf; Wed, 30 Aug 2006 09:02:36 -0400 Message-id: Date: Wed, 30 Aug 2006 08:58:21 -0400 X-Mailer: FirstClass 8.2 (build 8.094) X-FC-SERVER-TZ: 15729388 From: "Nirmala Shenoy" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-Mailman-Approved-At: Wed, 30 Aug 2006 10:06:35 -0400 Subject: [Mip4] Sensorware 2007 - New deadline - 15 Sept 2007 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org APOLOGIES IF YOU RECEIVE MULTIPLE COPIES CALL FOR PAPER – Deadline Extended – 15th Sept 2007 2nd International Workshop on Software for Sensor Networks (SensorWare) To be held with Comsware 2007 ([ http://www.comsware.org ]www.comsware.org) 8th January 2007, CityBangalore country-regionplaceIndia www.sensorware.org BEST PAPER AWARD INLCUDED Advances in technology have made deployment of miniature sensors a realistic proposition. Low-power, inexpensive smart devices with multiple on-board sensors are connected through wireless links so as to form a collaborative sensor network to perform a specific task. As a result, it opens up a new paradigm of ubiquitous computing and enables a range of applications that are previously unrealizable or too costly to be realized. However, given the limitation of on-board hardware, one of the key areas towards achieving superior performance is through software implementation. The workshop is intended to bring together industry experts and researchers to share novel techniques, algorithms and software implementation for sensor networks, and to discuss the current status, technical challenges, standards, fundamental issues, and future services and applications in the form of panels and technical presentation. Topics of interest include but are not limited to the following: 1. Operating System 2. Efficient algorithms 3. Protocol design considerations 4. Performance analysis 5. Performance related issues 6. Cross-layered design considerations 7. Sensor applications and their impact on sensor network architectures 8. Deployment issues and scenarios 9. Middleware 10. Sensor network security 11. Sensor network design and modeling Workshop co-chairs: Nirmala Shenoy ([ mailto:ns@rit.edu ]ns@rit.edu), Rochester Institute of Technology, placecountry-regionUSA Paul Chou, ([ mailto:pchou@us.ibm.com ]pchou@us.ibm.com), placeCityIBM Thomas J Watson Research Center, country-regionUSA Workshop technical co-chairs: Naoki Wakamiya, ([ mailto:Wakamiya@ist.osaka-u.ac.jp ]Wakamiya@ist.osaka-u.ac.jp), CityplaceOsaka University, country-regionJapan Falko Dressler, (dressler@informatik.uni-erlangen.de), CityplaceUniversity of Erlangen-Nuremberg, country-regionGermany Important Dates: Extended Paper Submission Deadline: 15th Sept 2006 Notification Acceptance/Rejection: 20th November 2006 Final Camera-Ready Paper Submission: 30th November 2006 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ ental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Aug 31 11:53:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIoqm-0004J1-Rj; Thu, 31 Aug 2006 11:53:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIoaX-00020F-IG for mip4@ietf.org; Thu, 31 Aug 2006 11:36:17 -0400 Received: from smtp106.biz.mail.re2.yahoo.com ([206.190.52.175]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GIoaT-0002AB-L2 for mip4@ietf.org; Thu, 31 Aug 2006 11:36:17 -0400 Received: (qmail 31821 invoked from network); 31 Aug 2006 15:33:46 -0000 Received: from unknown (HELO YEOBS) (siewfern.lim@sensimesh.com@218.186.172.126 with login) by smtp106.biz.mail.re2.yahoo.com with SMTP; 31 Aug 2006 15:33:44 -0000 Message-ID: <003a01c6cd12$d7f5e680$6501a8c0@Wavex.com> From: "Boon Sain Yeo" To: Date: Thu, 31 Aug 2006 23:33:32 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 1.0 (+) X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213 X-Mailman-Approved-At: Thu, 31 Aug 2006 11:53:03 -0400 Cc: Subject: [Mip4] CFP - ISWPC 2007, San Juan, Pureto Rico X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0780581056==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============0780581056== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0031_01C6CD55.DF3C19D0" This is a multi-part message in MIME format. ------=_NextPart_000_0031_01C6CD55.DF3C19D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Apologies if you receive multiple copies of this message) ---------------------------------------------------------------------- International Symposium on Wireless Pervasive Computing 2007 (ISWPC 2007) 5-7 February 2007, San Juan, Puerto Rico, USA http://www.iswpc.org/2007/ Technically Sponsored By IEEE Communications Society and IEEE Vehicular Technology Society Hosted By University of Puerto Rico at Mayaguez *** Submission Deadline Extended -- September 15, 2006 **** ---------------------------------------------------------------------- SCOPE Wireless pervasive computing is a rapidly growing area that has = attracted significant attention due to its potential impact on the quality of lifestyles of individuals. To enable wireless pervasive computing, it is necessary to integrate technologies from the fields of communications, signal processing, distributed computing, and numerous other fields. The = aim of this symposium is to provide a platform for researchers in the area = of wireless pervasive computing and related areas to showcase their = results, launch new ideas, as well as to interact with colleagues from these = areas. The scope of the symposium covers all enabling technologies of wireless pervasive computing. This includes a huge variety of topics ranging from wireless communications and networking to services and applications of pervasive computing. A series of panel and tutorials will also seek to inform and invoke interaction among researchers which are interested in = this area. ---------------------------------------------------------------------- TOPICS OF INTEREST (INCLUDE BUT ARE NOT LIMITED TO THE FOLLOWING) +Ad hoc networks +Air interfaces (e.g. CDMA, OFDM, TDMA) +Bluetooth technologies +Coding and modulation techniques +Cognitive radio +Cooperative communications technologies +Cross-layer design +Detection and estimation +Diversity techniques & equalization +Dynamic spectrum management +Healthcare applications +Hybrid wireless networks +Interference avoidance +Interoperation of WLAN and other wireless systems +Localization and tracking techniques +Location management techniques +Middleware +MIMO systems +Multimedia systems +Multirate and multicarrier communications +Multi-user Detection +PCS, GPRS, EDGE, 3GPP, UMTS, GSM and B3G systems +Power control +Programmable radio +Propagation and channel characterization +QoS Support in wireless systems +Resource management and interference management +RF systems +Security applications +Signal processing +Signal separation and interference rejection +Speech and videprocessing +Switching and routing techniques +UWB +Wearable devices +WiMAX +Wireless access techniques +Wireless multicasting +Wireless multimedia +Wireless network architecture +Wireless security +Wireless sensor networks +Wireless systems design +WLANs and WPANs ---------------------------------------------------------------------- PAPER SUBMISSION GUIDELINES Acceptance will be based on an extended abstract of about 1500 words = (two pages in the standard IEEE conference format). The extended abstract = should include diagrams, initial results, and details required for the = reviewers to assess the contribution of your work. A short summary of approximately = 150 words is also required at the time of submission of the extended = abstract. Extended abstracts must be submitted electronically by August 20, 2006 , = via EDAS (http://edas.info). Proceedings of the conference will be available = on IEEE Xplore after the event. ---------------------------------------------------------------------- PANEL SESSIONS & TUTORIALS Proposals for Tutorial and Panel Sessions are also being solicited. Tutorials (half-day or full-day sessions) are intended to provide = in-depth learning on a specific topic of interest to the participants. Panel sessions are 60 minutes long. They present leaders in a particular area discussing a topic of interest within the scope of the symposium. Proposals for Tutorials and Panel sessions should consist of 1000 words summary, a 150 word abstract, and a cover page listing the details of = the author(s). For further details, please contact either the Tutorial = Chair, Prof. Xiaoyan Hong (hxy@cs.ua.edu), or Panel Chair, Prof. Wilson Rivera (wrivera@ece.uprm.edu). ---------------------------------------------------------------------- IMPORTANT DATES Submission of Papers, proposals for tutorials and panel sessions: =3D> September 15, 2006 Notification of Acceptance: =3D> October 13, 2006 Submission of camera-ready versions of accepted papers: =3D> November 24, 2006 ---------------------------------------------------------------------- ------=_NextPart_000_0031_01C6CD55.DF3C19D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Apologies if you receive multiple = copies of this=20 message)

---------------------------------------------------------= -------------

International=20 Symposium on Wireless Pervasive Computing=20 2007
           = ;            =     =20 (ISWPC=20 2007)
          &nbs= p; =20 5-7 February 2007, San Juan, Puerto Rico,=20 USA
           =          =20 http://www.iswpc.org/2007/


          &nbs= p;          =20 Technically Sponsored By
IEEE Communications Society and IEEE = Vehicular=20 Technology=20 Society

         &nbs= p;           =20 Hosted By
University of Puerto Rico at=20 Mayaguez

     *** Submission Deadline = Extended=20 --  September 15, 2006=20 ****

-------------------------------------------------------------= ---------

SCOPE

Wireless=20 pervasive computing is a rapidly growing area that has = attracted
significant=20 attention due to its potential impact on the quality of
lifestyles of = individuals. To enable wireless pervasive computing, it is
necessary = to=20 integrate technologies from the fields of communications,
signal = processing,=20 distributed computing, and numerous other fields. The aim
of this = symposium=20 is to provide a platform for researchers in the area of
wireless = pervasive=20 computing and related areas to showcase their results,
launch new = ideas, as=20 well as to interact with colleagues from these areas.

The scope = of the=20 symposium covers all enabling technologies of wireless
pervasive = computing.=20 This includes a huge variety of topics ranging from
wireless = communications=20 and networking to services and applications of
pervasive computing. A = series=20 of panel and tutorials will also seek to
inform and invoke = interaction among=20 researchers which are interested in=20 this
area.


------------------------------------------------= ----------------------
TOPICS=20 OF INTEREST (INCLUDE BUT ARE NOT LIMITED TO THE FOLLOWING)

+Ad = hoc=20 networks
+Air interfaces (e.g. CDMA, OFDM, TDMA)
+Bluetooth=20 technologies
+Coding and modulation techniques
+Cognitive=20 radio
+Cooperative communications technologies
+Cross-layer=20 design
+Detection and estimation
+Diversity techniques &=20 equalization
+Dynamic spectrum management
+Healthcare=20 applications
+Hybrid wireless networks
+Interference=20 avoidance
+Interoperation of WLAN and other wireless = systems
+Localization=20 and tracking techniques
+Location management=20 techniques
+Middleware
+MIMO systems
+Multimedia = systems
+Multirate=20 and multicarrier communications
+Multi-user Detection
+PCS, GPRS, = EDGE,=20 3GPP, UMTS, GSM and B3G systems
+Power control
+Programmable=20 radio
+Propagation and channel characterization
+QoS Support in = wireless=20 systems
+Resource management and interference management
+RF=20 systems
+Security applications
+Signal processing
+Signal = separation=20 and interference rejection
+Speech and videprocessing
+Switching = and=20 routing techniques
+UWB
+Wearable devices
+WiMAX
+Wireless = access=20 techniques
+Wireless multicasting
+Wireless = multimedia
+Wireless=20 network architecture
+Wireless security
+Wireless sensor=20 networks
+Wireless systems design
+WLANs and=20 WPANs

------------------------------------------------------------= ----------
PAPER=20 SUBMISSION GUIDELINES

Acceptance will be based on an extended = abstract of=20 about 1500 words (two
pages in the standard IEEE conference format). = The=20 extended abstract should
include diagrams, initial results, and = details=20 required for the reviewers to
assess the contribution of your work. A = short=20 summary of approximately 150
words is also required at the time of = submission=20 of the extended abstract.
Extended abstracts must be submitted = electronically=20 by August 20, 2006 , via
EDAS (http://edas.info). Proceedings of the = conference=20 will be available on
IEEE Xplore after the=20 event.

-----------------------------------------------------------= -----------
PANEL=20 SESSIONS & TUTORIALS

Proposals for Tutorial and Panel = Sessions are=20 also being solicited.
Tutorials (half-day or full-day sessions) are = intended=20 to provide in-depth
learning on a specific topic of interest to the=20 participants.
Panel sessions are 60 minutes long. They present = leaders in a=20 particular
area discussing a topic of interest within the scope of = the=20 symposium.
Proposals for Tutorials and Panel sessions should consist = of 1000=20 words
summary, a 150 word abstract, and a cover page listing the = details of=20 the
author(s). For further details, please contact either the = Tutorial=20 Chair,
Prof. Xiaoyan Hong (hxy@cs.ua.edu), or Panel Chair, Prof. = Wilson=20 Rivera
(wrivera@ece.uprm.edu).

------------------------------------------------------= ----------------
IMPORTANT=20 DATES

Submission of Papers, proposals for tutorials and panel=20 sessions:
=3D>  September 15, 2006
Notification of=20 Acceptance:
=3D>  October 13, 2006
Submission of = camera-ready=20 versions of accepted papers:
=3D>  November 24,=20 2006

-------------------------------------------------------------= ---------
------=_NextPart_000_0031_01C6CD55.DF3C19D0-- --===============0780581056== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0780581056==-- From mip4-bounces@ietf.org Thu Aug 31 13:22:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIqFS-0006pQ-N7; Thu, 31 Aug 2006 13:22:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIqFR-0006pI-Ck for mip4@ietf.org; Thu, 31 Aug 2006 13:22:37 -0400 Received: from dsl3.halflab.com ([64.81.61.172] helo=outpost.thehouse.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIqFQ-0003fQ-0R for mip4@ietf.org; Thu, 31 Aug 2006 13:22:37 -0400 Received: from localhost ([127.0.0.1] ident=mccap) by outpost.thehouse.org with esmtp (Exim 4.50) id 1GIqFG-0005xc-VQ for mip4@ietf.org; Thu, 31 Aug 2006 10:22:27 -0700 Message-ID: <44F71AD2.7010601@petoni.org> Date: Thu, 31 Aug 2006 12:22:26 -0500 From: Pete McCann User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: mip4@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [Mip4] mip6: WG last call on draft-ietf-mip6-dsmip-problem-02.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org As indicated below, the mip6 working group is conducting a WG last call on draft-ietf-mip6-dsmip-problem-02.txt. Mip4 members may be interested in commenting on this draft, as it also reflects requirements for draft-ietf-mip4-dsmipv4-00.txt. Please send comments to the mip6 mailing list at mip6@ietf.org. -Pete ------ Forwarded Message > > From: Basavaraj Patil > > Date: Wed, 30 Aug 2006 20:14:53 -0500 > > To: > > Conversation: WG LC: draft-ietf-mip6-dsmip-problem-02.txt > > Subject: WG LC: draft-ietf-mip6-dsmip-problem-02.txt > > > > > > Hello, > > > > Please consider this as the WG last call for I-D: Mobility management > > for Dual stack mobile nodes : A Problem Statement > > (draft-ietf-mip6-dsmip-problem-02.txt) > > > > The status intended for I-D draft-ietf-mip6-dsmip-problem-02.txt is > > Informational. > > > > The last call will expire on Sept 14th. Please send your comments to > > the WG list or to the authors. > > > > -Raj ------ End of Forwarded Message -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/